Hi,
auch L-54ag Xscales ? Eine halbe Stunde ist schon zu lang. Ich brauche keine 3 Minuten ... (nach etwa 50000 flood pings gibt die Strecke meistens auf)
Vielleicht mußt du den Abstand zwischen den Geräten ein bißchen erhöhen. Zur Unterstützung des Absturzes war es bei mir manchmal hilfreich tcp traffic zu generien und dann parallel dazu zu flodden.
Ansonsten gebe ich dir mal den Zugang zu meiner Strecke.
Gruß,
Nils
L-54ag <-> L-54ag Verbindungsabbruch ohne Absturz
Moderator: Lancom-Systems Moderatoren
Moin,
ich habe jetzt hier parallel in der anderen Richtung ein NetIO draufgelegt, aber immer
noch keine Probleme. Das eine ist kein L-54, sondern ein 1511, aber die nehmen sich von
WLAN-Teil her nichts (gleicher XScale, gleiches Funkmodul, gleicher WLAN-Stack).
Abstand ist so weit, wie ich ihn eben hier in dem Zimmer bekomme
Gruß Alfred
ich habe jetzt hier parallel in der anderen Richtung ein NetIO draufgelegt, aber immer
noch keine Probleme. Das eine ist kein L-54, sondern ein 1511, aber die nehmen sich von
WLAN-Teil her nichts (gleicher XScale, gleiches Funkmodul, gleicher WLAN-Stack).
Abstand ist so weit, wie ich ihn eben hier in dem Zimmer bekomme
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo,
nach ein paar Mails mit Alf29 ist mir aufgefallen, dass sich die Testfirmware scheinbar doch anders verhält. Der Floodping führt beim Master zu falschen Radarerkennungen und irgendwann sind keine Kanäle mehr frei, die Verbindung bricht also für bis zu 30 min regulär ab.
Da ein solcher Fall real nicht auftreten sollte, kann das Problem also bereits gelöst sein (d.h. mit der Testfirmware). Zur Zeit ist aufgrund der vielen Feiertage kaum ein Nutzer in unserem Netz online. Ich werde dann neue Testergebnisse Anfang bis Mitte Januar hier posten.
@steti: Hast du schon die Testfirmware drauf und etwas damit experimentiert ?
Gruß,
Nils
nach ein paar Mails mit Alf29 ist mir aufgefallen, dass sich die Testfirmware scheinbar doch anders verhält. Der Floodping führt beim Master zu falschen Radarerkennungen und irgendwann sind keine Kanäle mehr frei, die Verbindung bricht also für bis zu 30 min regulär ab.
Da ein solcher Fall real nicht auftreten sollte, kann das Problem also bereits gelöst sein (d.h. mit der Testfirmware). Zur Zeit ist aufgrund der vielen Feiertage kaum ein Nutzer in unserem Netz online. Ich werde dann neue Testergebnisse Anfang bis Mitte Januar hier posten.
@steti: Hast du schon die Testfirmware drauf und etwas damit experimentiert ?
Gruß,
Nils
-
thomasgiger
- Beiträge: 109
- Registriert: 28 Mai 2005, 15:00
- Wohnort: Oberursel
Nur so als Ergänzung: Das hier beschriebene Problem gibt es m.E. bereits seit der 4.0x Version und hatte schon im Juli 05 zu einem Thread "P2P Link Abbruch mit 4.02 und 4.12" geführt.
Damals war als Erklärung ein "versteckter Warm Up Event" ins Auge gefasst worden, aber mittlerweile hat sich auch in unserem Netz gezeigt, dass die Wahrscheinlichkeit eines Verbindungsverlusts mit größerer Last deutlich wächst. Recht schön kann man das an einem Backup Link sehen, das ohne Last nie ein Problem macht. Wenn es dann aber mal Traffic transportieren muss, ist es recht bald weg.
Der einzige Workaround war bis jetzt ein Downgrade auf WEP-Verschlüsselung ... ich hoffe, dass Alfred nun des Pudels Kern gefunden hat oder noch finden wird und WPA im P2P Betrieb endlich stabil wird.
PS: Das Ganze hat übrigens definitiv nichts mit Radar oder Kanalwechsel zu tun, weil es auch in einem Land ohne DFS zu Abbrüchen kommt. Und wenn es doch so scheint, dann sollte man das als ein eigenständiges Problem behandeln: Hohe Last erhöht ja auch die Wahrscheinlichkeit einer falschen Radarerkennung im eigenen Kanal, wobei dann ein dem Kanalwechsel nicht folgender Slave nicht wegen des IV-Zählers abgehängt wird, sondern zu lange am falschen Kanal sitzt.
Damals war als Erklärung ein "versteckter Warm Up Event" ins Auge gefasst worden, aber mittlerweile hat sich auch in unserem Netz gezeigt, dass die Wahrscheinlichkeit eines Verbindungsverlusts mit größerer Last deutlich wächst. Recht schön kann man das an einem Backup Link sehen, das ohne Last nie ein Problem macht. Wenn es dann aber mal Traffic transportieren muss, ist es recht bald weg.
Der einzige Workaround war bis jetzt ein Downgrade auf WEP-Verschlüsselung ... ich hoffe, dass Alfred nun des Pudels Kern gefunden hat oder noch finden wird und WPA im P2P Betrieb endlich stabil wird.
PS: Das Ganze hat übrigens definitiv nichts mit Radar oder Kanalwechsel zu tun, weil es auch in einem Land ohne DFS zu Abbrüchen kommt. Und wenn es doch so scheint, dann sollte man das als ein eigenständiges Problem behandeln: Hohe Last erhöht ja auch die Wahrscheinlichkeit einer falschen Radarerkennung im eigenen Kanal, wobei dann ein dem Kanalwechsel nicht folgender Slave nicht wegen des IV-Zählers abgehängt wird, sondern zu lange am falschen Kanal sitzt.
Mit freundlichen Grüßen,
true global communications GmbH (TGNET/wireless, ca. 300x L54ag/L54dual)
Thomas Giger
true global communications GmbH (TGNET/wireless, ca. 300x L54ag/L54dual)
Thomas Giger
Hallo,
mit Sicherheit kann ich es noch nicht sagen, aber die Testfirmware scheint die Probleme mit den Verbindungsabbrüchen nicht zu haben.
Wenn es nun zu einem Verbindungsabbruch kommt, waren beim Master (108er Modus) alle 4 Kanäle auf blocked. (Dies war mit der 5.20er Firmware nicht der Fall!) Allerdings tritt der Status bei sehr hoher Last relativ häufig auf. Prinzipiell kommen nun keine grundlosen Abbrüche mehr vor, aber die Radarerkennung muss in jedem Fall überarbeitet werden. Ich hoffe, dass sich dies per Firmware lösen läßt und nicht Chip abhängig ist.
Gruß,
Nils
@Alf: Die Testfirmware ist schon mal guter Fortschritt!! Danke! (Der Fix wird doch in zukünftigen Versionen drinn sein, oder?)
mit Sicherheit kann ich es noch nicht sagen, aber die Testfirmware scheint die Probleme mit den Verbindungsabbrüchen nicht zu haben.
Wenn es nun zu einem Verbindungsabbruch kommt, waren beim Master (108er Modus) alle 4 Kanäle auf blocked. (Dies war mit der 5.20er Firmware nicht der Fall!) Allerdings tritt der Status bei sehr hoher Last relativ häufig auf. Prinzipiell kommen nun keine grundlosen Abbrüche mehr vor, aber die Radarerkennung muss in jedem Fall überarbeitet werden. Ich hoffe, dass sich dies per Firmware lösen läßt und nicht Chip abhängig ist.
Gruß,
Nils
@Alf: Die Testfirmware ist schon mal guter Fortschritt!! Danke! (Der Fix wird doch in zukünftigen Versionen drinn sein, oder?)
Moin,
Wieso nur vier Kanäle? Machst Du Turbo?
An der Radarerkennung schrauben wir schon länger, aber die Hardware hat nunmal
die Unart, alles, was nicht OFDM ist, als Radarpuls zu melden, ich habe die Mustererkannung
schon soweit strenger gemacht, wie die Normen das zulassen. Da kann ich nicht viel
Hoffnung für die nähere Zukunft machen.
Die Testfirmware ist auf 5.2x-Stand, bezüglich Radarerkennung unterscheidet sie sich
nicht von einer regulären 5.20. Ich vermute eher, die Strecker lebt etwas länger als
vorher und läuft eben jetzt in das nächste Problem.
Die Korrektur wird in einer 5.22 enthalten sein, sofern es eine solche geben sollte, und
natürlich auch in der 6.00
Gruß Alfred
Wieso nur vier Kanäle? Machst Du Turbo?
An der Radarerkennung schrauben wir schon länger, aber die Hardware hat nunmal
die Unart, alles, was nicht OFDM ist, als Radarpuls zu melden, ich habe die Mustererkannung
schon soweit strenger gemacht, wie die Normen das zulassen. Da kann ich nicht viel
Hoffnung für die nähere Zukunft machen.
Die Testfirmware ist auf 5.2x-Stand, bezüglich Radarerkennung unterscheidet sie sich
nicht von einer regulären 5.20. Ich vermute eher, die Strecker lebt etwas länger als
vorher und läuft eben jetzt in das nächste Problem.
Die Korrektur wird in einer 5.22 enthalten sein, sofern es eine solche geben sollte, und
natürlich auch in der 6.00
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Moin,
die Strecke läuft jetzt länger und schaltet sich lediglich regulär wegen Radarerkennung ab. Das ist schon mal prima.
Richtig - Ich mache Turbo. Die Strecke ist relativ oft mit knapp 5 Mbyte /sec unter Last.
Das Transfervolumen im Januar war bisher repräsentativ für die ersten beiden Dezemberwochen. Im Dezember gab es etwas 10 Abbrüche. Im Januar bisher keinen außer 2 wegen Radar. Das ist eine erhebliche Verbesserung.
Gruß,
Nils
die Strecke läuft jetzt länger und schaltet sich lediglich regulär wegen Radarerkennung ab. Das ist schon mal prima.
Richtig - Ich mache Turbo. Die Strecke ist relativ oft mit knapp 5 Mbyte /sec unter Last.
Das Transfervolumen im Januar war bisher repräsentativ für die ersten beiden Dezemberwochen. Im Dezember gab es etwas 10 Abbrüche. Im Januar bisher keinen außer 2 wegen Radar. Das ist eine erhebliche Verbesserung.
Gruß,
Nils
Hallo,
mittlerweile habe ich Log-Daten über 2 Wochen und es hat mit der Testfirmware keinen außergewöhnlichen Verbindungsabbruch mehr gegeben, d.h. die Testfirmware ist in sofern prima!
Einzige Sache, die ich bereits schon erwähnt hatte, ist das Problem mit hoher Last und Radarfehlererkennung. Die beiden APs erkennen sich ab Transferraten > 2.5Mbyte/sec (z.B. tcp/udp Traffic parallel) ganz gerne als gegenseitige Radarstörung. Dies führt leider zu oft zu wilden Channelwechseln bis eben eine Pause (max.30min) folgt.
Wenn dies ohne die Vorschriften zu verletzen noch verbessert werden könnte, (gerade bei P2P mit zwei APs sind die Pegel bekannt) wäre das Ganze perfekt.
Gruß,
Nils
mittlerweile habe ich Log-Daten über 2 Wochen und es hat mit der Testfirmware keinen außergewöhnlichen Verbindungsabbruch mehr gegeben, d.h. die Testfirmware ist in sofern prima!
Einzige Sache, die ich bereits schon erwähnt hatte, ist das Problem mit hoher Last und Radarfehlererkennung. Die beiden APs erkennen sich ab Transferraten > 2.5Mbyte/sec (z.B. tcp/udp Traffic parallel) ganz gerne als gegenseitige Radarstörung. Dies führt leider zu oft zu wilden Channelwechseln bis eben eine Pause (max.30min) folgt.
Wenn dies ohne die Vorschriften zu verletzen noch verbessert werden könnte, (gerade bei P2P mit zwei APs sind die Pegel bekannt) wäre das Ganze perfekt.
Gruß,
Nils