Ich spreche nicht von TCP Timeouts und Retransmissions. Der Fall sieht so aus, dass nach TCP alle bisher übertragenen Packete vollständig von beiden Seiten bestätigt worden sind. Es gibt also keinen Grund, dass der TCP-Stack des Clients eine Art TCP Keep-Alive macht. Der Client könnte also nur dann nachfragen, wenn die Applikation diese Logik implementiert hätte. Nach dem Motto ich warte nun schon so lange auf meine angeforderten Daten, da klopfe ich beim Server nocheinmal an was nun Sache ist. Ist aber hier nicht implementiert. Der Client verhält sich also still und wartet mit seiner offenen Verbindung auf Anweisungen vom Server.
Der Server ist immer noch mit seiner Verarbeitung beschäftigt (warum auch immer). Wenn der Client nun in dieser Zeit zu einem anderen AP wechselt,
und dabei immer noch von sich aus nichts verschickt hat, dann ist der Switch dahinter immer noch der Meinung, dass der Client auf dem alten AP zu erreichen ist. Jetzt schickt der Server aber Daten an eben diesen Client, aber sie können nicht zugestellt werden so lange seine MAC-Adresse immer noch dem falschen Switchport, alter AP, zugeordnet ist. Bei einer default mac table aging-time von 300sec ist das schon recht lang.
Ja das ist konkretes Problem. Ich habe leider keinen direkten Zugriff auf die Infrastruktur des Standortes. Die wird von einem anderen Dienstleister betreut. Ich betreue die Infrastruktur des Kunden an einem anderen Standort, wo wir solche Probleme nicht beobachten.
Bei uns sind die Clients mit DHCP konfiguriert, bei dem anderen Standort sind die Clients fest eingestellt.
Hey, Du hast mit DHCP Renew angefangen ;)
Ich sehe definitiv, dass die Clients, die per DHCP ihre IP beziehen, beim Roaming sofort einen DHCP Request (Lease extend) rausschicken.
Der Trace des Clients mit fester IP zeigt ausser dem Roaming mit den APs keine Aktivitäten bezüglich TCP/IP.
Ping wäre das denkbar falsche Vorgehen. Es ist im Prinzip so ähnlich wie ein Rechner der bootet. Der schickt ja auch, wenn seine Lease-Time noch nicht abgelaufen ist, eine Anfrage an den DHCP-Server ob seine alte IP-Adresse immer noch gültig ist, sprich bin ich immer noch im gleichen Subnetz, wie vor dem Herunterfahren. Das ist im Prinzip ein Lease-Extend. Genau das scheint auch beim Roaming stattzufinden. Zumindest mit den Geräten die bei uns im Einsatz sind.
Roamen in dem Sinne den AP zu wechseln schon, natürlich gehen dann alle Sessions fliegen, wenn man in einem anderen Netz gelandet ist.
Ist doch so ähnlich wie bei GSM, wenn ich in Grenznähe telefoniere und mein Telefon sich plötzlich doch lieber beim Anbieter des Nachbarlandes anmeldet.
Das überlebt auch kein aktives Gespräch.
Ja, ich habe die Cisco Doku dazu überflogen. Controller sind nicht im Einsatz, nur reine autonome APs.
