[VF West] Timeouts bei Android-Apps seit Wechsel der IP-Adresse

[floh667]

...oder du kannst seine macadresse spoofen 8was aber nich die feine Art ist).

Schlimmer noch, in diesem Fall würde es dazu führen, dass die Box vom CMTS wegen ungültiger (bzw. unpassender) Zertifikate abgelehnt wird. Das geht nur dann, wenn ein Router an einem Modem im Bridge Modus genutzt wird.

Danke für die Info. Daran hab ich nicht gedacht, dass im fall einer fritzbox das itnegrierte Modem sozusagen eins ist mit der router MAC. Dann ist das mac spoofen natürlich ausgeschlossen.

na dann haste schon mal den total verkehrten Inetanbieter, denn bei Koaxinet is der Ping schon mal viel höher als bei DSL oder bei Glas, aber ob 15ms oder 30 ist völlig egal, 30 und 200 ms sind da was anderes!

Kann mich jetzt nicht über einen Jitter beklagen, wie du ihn hier beschreibst. Da du hier siehst wie gut die leitung gut läuft, habe ich keinen grund, auf die 4ms zu verzichten wenn ich weiß wie ichs sie vermeiden kann.

Code: Alles auswählen

>ping heise.de -t

Ping wird ausgeführt für heise.de [193.99.144.80] mit 32 Bytes Daten:
Antwort von 193.99.144.80: Bytes=32 Zeit=11ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=11ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=11ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=11ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=13ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=11ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=12ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=11ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=11ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=12ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=11ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=12ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=13ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=10ms TTL=247

Ping-Statistik für 193.99.144.80:
    Pakete: Gesendet = 28, Empfangen = 28, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 10ms, Maximum = 13ms, Mittelwert = 10ms

Da also das mac spoofen wegfällt, bleibt nur noch den rotuer für mehrere Stunden offline setzen und hoffen, dass die IP gewechselt wird.

[abacus]

Leute, danke für die Diskussion, aber ich muss zum eigentlichen Thema nochmal nachlegen

Ich hab jetzt herausgefunden, woher die Timeouts kommen und was da passiert, aber ich muss noch verstehen, warum das so ist. Kurz gesagt ist es so: bei aktiviertem IPv6 in der FB (Internet/Zugangsart/Haken gesetzt bei "IPv6-Unterstützung aktiv") funktionieren beide Stacks (IPv4 und IPv6) zunächst problemlos (DS eben). Allerdings hört nach ca. 3 Stunden der IPv6-Stack auf zu funktionieren. Will heißen: die FB verteilt munter weiter Advertisements nach innen zu den Endgeräten, die dann natürlich auch IPv6 verwenden wollen. Es geht aber nach außen nix mehr durch per IPv6. Die betroffenen Android-Apps versuchen, per IPv6 zu kommunizieren, und je nachdem, ob und wie ein IPv4-Fallback implementiert ist, funktionieren sie halt sporadisch oder gar nicht.

Ich konnte das nachvollziehen mit einem dauerhaften IPv6-Ping auf heise.de. Der lief drei Stunden lang, und dann war schlagartig Ende, kein Paket ging mehr durch. Man kann IPv6 dann wiederbeleben, indem man den besagten Haken entfernt und damit den IPv6-Support der FB komplett ausschaltet und anschließend den Haken wieder setzt. Nachdem die FB wieder verbunden ist, geht auch IPv6 wieder - einige Stunden lang, und dann das Ganze von vorn.

Kann sich darauf jemand einen Reim machen? Ich erinnere mich, dass ich genau dieses Verhalten vor langer Zeit schon mal hatte, als (damals) Unitymedia mir erstmals DS aktiviert hat. Auch da konnte ich das eigentliche Problem nicht wirklich finden, und eines Tages ist das Problem einfach nicht wieder aufgetreten.