Hallo,
ich habe hier einen WLAN Stern bestehend aus 4 OAP-54. Bis zum Update des Masters auf FW 8.00 von FW 6.22 durch einen übereifrigen Kollegen lief alles rund.
Folgende Konstellation:
Slave1 --- Master ---Slave2 an WLAN1
Slave 3 --- Master an WLAN2
Das Ganze ist gebridged.
Problem:
Ping
slave1 an Master: ok
slave1 an slave3: ok
slave1 an slave2 und dahinter liegende Netze: NIX
umgekehrt von slave2 das gleiche Ergebnis.
Vor dem Update der FW ging alles.
Ich habe schon versucht mit ein paar TRACES Licht ins Dunkle zu bringen, aber keine erhellenden Treffer gelandet.
Kennt jemand eine Lösung oder einen schicken TRACE der mir weiterhilft?
Beste Grüße
Stefan
Ausfall Bridging am OAP-54 nach Update auf FW 8.00
Moderator: Lancom-Systems Moderatoren
Hallo Alfred,
hab ich am Master gemacht und versucht draus schlau zu werden. Ich poste mal ein paar Schnipsel
Das ist das Ergebnis des nicht funktionierenden Pings Slave1 --> Slave2
Für mich sieht das so aus:
Slave1 an P2P-1-1 macht ein ARP, Slave2 antwortet korrekt auf P2P-1-2 und der Master schiebt es korrekt zu P2P-1-1.
Bei dem scheint es aber nicht anzukommen, denn danach passiert nichts mehr.
Im Gegenteil dazu der funktionierende Ping von Slave1 --> Slave3 an P2P-2-1 des Masters
Da findet kein ARP statt. Das Ping geht auf Anhieb durch.
Offensichtlich hat Slave1 Probleme mit dem ARP.
Irgend eine Idee?
Grüße
Stefan
hab ich am Master gemacht und versucht draus schlau zu werden. Ich poste mal ein paar Schnipsel
Code: Alles auswählen
[Bridge] 2010/11/10 18:08:12,260
Bridge frame coming from ifc P2P-1-1:
00:07:d5:01:12:0f (3e 01:12:0f) to ff:ff:ff:ff:ff:ff (Broadcast), 42 bytes
-->multi/broadcast
-->forwarding into own LSL stack
-->forwarding 42 bytes to ifc LAN-1
-->forwarding 42 bytes to ifc P2P-1-2
-->forwarding 42 bytes to ifc P2P-2-1
[Bridge] 2010/11/10 18:08:12,270
Bridge frame coming from ifc P2P-1-2:
00:07:d5:01:0e:59 (3e 01:0e:59) to 00:07:d5:01:12:0f (3e 01:12:0f), 42 bytes
-->unicast to address on interface P2P-1-1
-->forwarding 42 bytes to ifc P2P-1-1Für mich sieht das so aus:
Slave1 an P2P-1-1 macht ein ARP, Slave2 antwortet korrekt auf P2P-1-2 und der Master schiebt es korrekt zu P2P-1-1.
Bei dem scheint es aber nicht anzukommen, denn danach passiert nichts mehr.
Im Gegenteil dazu der funktionierende Ping von Slave1 --> Slave3 an P2P-2-1 des Masters
Code: Alles auswählen
[Bridge] 2010/11/10 18:08:15,580
Bridge frame coming from ifc P2P-1-1:
00:07:d5:01:12:0f (3e 01:12:0f) to 00:07:d5:01:0c:9d (3e 01:0c:9d), 98 bytes
-->unicast to address on interface P2P-2-1
-->forwarding 98 bytes to ifc P2P-2-1
...die Antwort
[Bridge] 2010/11/10 18:08:15,580
Bridge frame coming from ifc P2P-2-1:
00:07:d5:01:0c:9d (3e 01:0c:9d) to 00:07:d5:01:12:0f (3e 01:12:0f), 98 bytes
-->unicast to address on interface P2P-1-1
-->forwarding 98 bytes to ifc P2P-1-1
Offensichtlich hat Slave1 Probleme mit dem ARP.
Irgend eine Idee?
Grüße
Stefan
Moin,
Der ARP ist im im zweiten Fall evtl. schon irgenwann vorher
gelaufen und der Sender hat den ARP-Eintrag noch gecacht.
Aber im nicht funktionierenden Fall wissen wir also, daß der
ARP-Request (Broadcast) korrekt am Slave 2 ankam,
beantwortet wurde und bis zum Master gekommen ist. Der
nächste Schritt wäre, in einem WLAN-Data-Trace zu prüfen,
ob der ARP-Response vom Master an Slave 1 wirklich
verschickt wird. Also ein
auf dem Master. ACHTUNG: Dies nicht über eine
unverschlüsselte Verbindung (Telnet), sondern eine SSH-
Sitzung machen, sonst baut man sich u.U. einen Elektronen-
beschleuniger, sofern man auf den Master auch übers WLAN
zugreift.
Gruß Alfred
Der ARP ist im im zweiten Fall evtl. schon irgenwann vorher
gelaufen und der Sender hat den ARP-Eintrag noch gecacht.
Aber im nicht funktionierenden Fall wissen wir also, daß der
ARP-Request (Broadcast) korrekt am Slave 2 ankam,
beantwortet wurde und bis zum Master gekommen ist. Der
nächste Schritt wäre, in einem WLAN-Data-Trace zu prüfen,
ob der ARP-Response vom Master an Slave 1 wirklich
verschickt wird. Also ein
Code: Alles auswählen
trace # wlan-data @ ARP
unverschlüsselte Verbindung (Telnet), sondern eine SSH-
Sitzung machen, sonst baut man sich u.U. einen Elektronen-
beschleuniger, sofern man auf den Master auch übers WLAN
zugreift.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo Alfred,
trace # wlan-data @ ARP brachte folgendes
Was ja eigentlich korrekt aussieht.
Das Problem ist nur, dass der gleiche trace auf slave1 nur den ausgehenden arp request anzeigt und danach nichts mehr passiert.
Auch ARP request anderer Nodes hinter Slave1 liefern keine eingehenden Pakete.
Am Master hängen ja sowohl Slave 1 als auch Slave2 beide an WLAN-1, an das 2 Antennen angeschlossen sind. Kann es sein, dass der Master zwar logisch auf WLAN-1 sendet, das Paket aber nur auf einer Antenne rausgeht?
Das wäre zwar eine Erklärung, aber meines Wissens hängen die beiden Antennen ja am selben Funkmodul, bekommen also die gleichen Daten oder?
Grüße
Stefan
trace # wlan-data @ ARP brachte folgendes
Code: Alles auswählen
[WLAN-DATA] 2010/11/11 10:10:29,970
Received frame from address 00:07:d5:01:12:0f (3e 01:12:0f) on WLAN-1:
-->Orig Length: 76 bytes
-->Full Length: 76 Bytes
-->Rate(s): T-48M
-->Antenna: 1
-->Signal: -59 dBm
-->Noise: -89 dBm
-->IEEE 802.11 Header
Protocol Version : 0
Flags : ToDS FromDS Protected
Type : Data
Subtype : Data
Duration : 0026
Address1 [RA ] : 00:07:d5:01:0e:3f (3e 01:0e:3f)
Address2 [TA ] : 00:07:d5:01:12:0f (3e 01:12:0f)
Address3 [DA ] : ff:ff:ff:ff:ff:ff (Broadcast)
Sequence Number : 902
Fragment Number : 0
Address4 [SA ] : 00:07:d5:01:12:0f (3e 01:12:0f)
Header Padding : d5 0f
IV : 46 04 00
KeyIndex : 0 ExtIV
Extended IV : 00 00 00 00
-->LLC Header
DSAP : SNAP [I]
SSAP : SNAP [C]
Frame type : U P/F=0 M=0
SNAP Manufacturer : 00:00:00
Type : ARP
-->ARP packet:
Hardware Type : Ethernet
Type : ARP request
Sender HA : 00:07:d5:01:12:0f (3e 01:12:0f)
Sender IA : 192.168.200.2
Receiver HA : ff:ff:ff:ff:ff:ff (Broadcast)
Receiver IA : 192.168.200.3
[WLAN-DATA] 2010/11/11 10:10:29,980
Send frame to address 00:07:d5:01:0c:9d (3e 01:0c:9d) on WLAN-2:
-->Orig Length: 76 bytes
-->Full Length: 76 Bytes
-->Rate(s): T-24M/T-18M/T-12M
-->Antenna: 1
-->IEEE 802.11 Header
Protocol Version : 0
Flags : ToDS FromDS Protected
Type : Data
Subtype : Data
Duration : 0026
Address1 [RA ] : 00:07:d5:01:0c:9d (3e 01:0c:9d)
Address2 [TA ] : 00:07:d5:01:0e:3e (3e 01:0e:3e)
Address3 [DA ] : ff:ff:ff:ff:ff:ff (Broadcast)
Sequence Number : 91
Fragment Number : 0
Address4 [SA ] : 00:07:d5:01:12:0f (3e 01:12:0f)
Header Padding : 00 00
IV : f5 5c 00
KeyIndex : 0 ExtIV
Extended IV : 03 00 00 00
-->LLC Header
DSAP : SNAP [I]
SSAP : SNAP [C]
Frame type : U P/F=0 M=0
SNAP Manufacturer : 00:00:00
Type : ARP
-->ARP packet:
Hardware Type : Ethernet
Type : ARP request
Sender HA : 00:07:d5:01:12:0f (3e 01:12:0f)
Sender IA : 192.168.200.2
Receiver HA : ff:ff:ff:ff:ff:ff (Broadcast)
Receiver IA : 192.168.200.3
[WLAN-DATA] 2010/11/11 10:10:29,980
Send frame to address 00:07:d5:01:0e:59 (3e 01:0e:59) on WLAN-1:
-->Orig Length: 76 bytes
-->Full Length: 76 Bytes
-->Rate(s): T-48M/T-36M/T-12M
-->Antenna: 1
-->IEEE 802.11 Header
Protocol Version : 0
Flags : ToDS FromDS Protected
Type : Data
Subtype : Data
Duration : 0026
Address1 [RA ] : 00:07:d5:01:0e:59 (3e 01:0e:59)
Address2 [TA ] : 00:07:d5:01:0e:3f (3e 01:0e:3f)
Address3 [DA ] : ff:ff:ff:ff:ff:ff (Broadcast)
Sequence Number : 417
Fragment Number : 0
Address4 [SA ] : 00:07:d5:01:12:0f (3e 01:12:0f)
Header Padding : 00 00
IV : 71 6b 00
KeyIndex : 0 ExtIV
Extended IV : 01 00 00 00
-->LLC Header
DSAP : SNAP [I]
SSAP : SNAP [C]
Frame type : U P/F=0 M=0
SNAP Manufacturer : 00:00:00
Type : ARP
-->ARP packet:
Hardware Type : Ethernet
Type : ARP request
Sender HA : 00:07:d5:01:12:0f (3e 01:12:0f)
Sender IA : 192.168.200.2
Receiver HA : ff:ff:ff:ff:ff:ff (Broadcast)
Receiver IA : 192.168.200.3
[WLAN-DATA] 2010/11/11 10:10:29,980
Received frame from address 00:07:d5:01:0e:59 (3e 01:0e:59) on WLAN-1:
-->Orig Length: 76 bytes
-->Full Length: 76 Bytes
-->Rate(s): T-48M
-->Antenna: 2
-->Signal: -61 dBm
-->Noise: -89 dBm
-->IEEE 802.11 Header
Protocol Version : 0
Flags : ToDS FromDS Protected
Type : Data
Subtype : Data
Duration : 0026
Address1 [RA ] : 00:07:d5:01:0e:3f (3e 01:0e:3f)
Address2 [TA ] : 00:07:d5:01:0e:59 (3e 01:0e:59)
Address3 [DA ] : 00:07:d5:01:12:0f (3e 01:12:0f)
Sequence Number : 665
Fragment Number : 0
Address4 [SA ] : 00:07:d5:01:0e:59 (3e 01:0e:59)
Header Padding : d5 59
IV : ef f6 00
KeyIndex : 0 ExtIV
Extended IV : 03 00 00 00
-->LLC Header
DSAP : SNAP [I]
SSAP : SNAP [C]
Frame type : U P/F=0 M=0
SNAP Manufacturer : 00:00:00
Type : ARP
-->ARP packet:
Hardware Type : Ethernet
Type : ARP reply
Sender HA : 00:07:d5:01:0e:59 (3e 01:0e:59)
Sender IA : 192.168.200.3
Receiver HA : 00:07:d5:01:12:0f (3e 01:12:0f)
Receiver IA : 192.168.200.2
[WLAN-DATA] 2010/11/11 10:10:29,980
Send frame to address 00:07:d5:01:12:0f (3e 01:12:0f) on WLAN-1:
-->Orig Length: 76 bytes
-->Full Length: 76 Bytes
-->Rate(s): T-36M/T-24M/T-12M
-->Antenna: 2
-->IEEE 802.11 Header
Protocol Version : 0
Flags : ToDS FromDS Protected
Type : Data
Subtype : Data
Duration : 0026
Address1 [RA ] : 00:07:d5:01:12:0f (3e 01:12:0f)
Address2 [TA ] : 00:07:d5:01:0e:3f (3e 01:0e:3f)
Address3 [DA ] : 00:07:d5:01:12:0f (3e 01:12:0f)
Sequence Number : 419
Fragment Number : 0
Address4 [SA ] : 00:07:d5:01:0e:59 (3e 01:0e:59)
Header Padding : 00 00
IV : cd 7f 00
KeyIndex : 0 ExtIV
Extended IV : 01 00 00 00
-->LLC Header
DSAP : SNAP [I]
SSAP : SNAP [C]
Frame type : U P/F=0 M=0
SNAP Manufacturer : 00:00:00
Type : ARP
-->ARP packet:
Hardware Type : Ethernet
Type : ARP reply
Sender HA : 00:07:d5:01:0e:59 (3e 01:0e:59)
Sender IA : 192.168.200.3
Receiver HA : 00:07:d5:01:12:0f (3e 01:12:0f)
Receiver IA : 192.168.200.2
Das Problem ist nur, dass der gleiche trace auf slave1 nur den ausgehenden arp request anzeigt und danach nichts mehr passiert.
Auch ARP request anderer Nodes hinter Slave1 liefern keine eingehenden Pakete.
Am Master hängen ja sowohl Slave 1 als auch Slave2 beide an WLAN-1, an das 2 Antennen angeschlossen sind. Kann es sein, dass der Master zwar logisch auf WLAN-1 sendet, das Paket aber nur auf einer Antenne rausgeht?
Das wäre zwar eine Erklärung, aber meines Wissens hängen die beiden Antennen ja am selben Funkmodul, bekommen also die gleichen Daten oder?
Grüße
Stefan
Moin,
die beiden Antennen sind Diversity-Antennen, d.h. es ist nur
ein Radio-Teil da, und ein Umschalter schaltet ihn beim Senden
bzw. Empfangen auf die eine oder andere Antenne. Beim
Empfang probiert das Modul während des Empfangs der
Präambel, auf welcher Antenne der bessere Empfang zu
bekommen ist, und ddas ist die Antenne, die im Trace
gemeldet wird. Was ich *vermute*: diese Antenne wird
im Paket als eine Art Meta-Information mitgeführt und auch
beim Senden für die Auswahl der Antenne benutzt. Der
Fehler dürfte jetzt sein, daß beim Forwarding des Paketes
von P2P-1-2 an P2P-1-1 diese Meta-Information nicht
gelöscht wird. Ich vermute, Du hast Rx- und Tx-Diversity
eingeschaltet, d.h. das Paket an Slave 1 sollte auf der
Antenne rausgehen, auf der das letzte Paket empfangen
wurde - und das war eigentlich der ARP-Request auf
Antenne 1...
Ich schaue mal, wo das Löschen fehlt. In der 8.00 hatte
es Bugfixes bezüglich Tx-Diversity zu Clients auf anderen
SSIDs als der ersten gegeben, von daher wäre ein Problem
an der Stelle plausibel.
Generell ist so ein Aufbau aber eine 'heiße' Sache, weil
eben nur ein Empfänger vorhanden ist - solange das
Funkmedium idle ist, 'hört' das Funkmodul nur auf der
ersten Antenne, und wenn ein reinkommendes Signal so
schwach ist, daß man es nur über die zweite Antenne
hören könnte, dann kann es passieren, daß es ganz
'überhört' wird. Derartige Aufbauten funktionieren in
der Praxis häufig, weil die Separation beider Antennen
weder von ihrer Richtwirkung noch von der Dämpfung des
Umschalters perfekt ist - also 'hört' man immer auch ein
bißchen auf der ersten Antenne, so daß die Rx-Diversity
greifen kann.
Ich schaue mal, ob ich Dir kurzfristig eine Testfirmware
geben kann. Du kannst mir schon mal per PM scheiben,
wohin ich sie dann schicken soll.
Gruß & Dank
Alfred
die beiden Antennen sind Diversity-Antennen, d.h. es ist nur
ein Radio-Teil da, und ein Umschalter schaltet ihn beim Senden
bzw. Empfangen auf die eine oder andere Antenne. Beim
Empfang probiert das Modul während des Empfangs der
Präambel, auf welcher Antenne der bessere Empfang zu
bekommen ist, und ddas ist die Antenne, die im Trace
gemeldet wird. Was ich *vermute*: diese Antenne wird
im Paket als eine Art Meta-Information mitgeführt und auch
beim Senden für die Auswahl der Antenne benutzt. Der
Fehler dürfte jetzt sein, daß beim Forwarding des Paketes
von P2P-1-2 an P2P-1-1 diese Meta-Information nicht
gelöscht wird. Ich vermute, Du hast Rx- und Tx-Diversity
eingeschaltet, d.h. das Paket an Slave 1 sollte auf der
Antenne rausgehen, auf der das letzte Paket empfangen
wurde - und das war eigentlich der ARP-Request auf
Antenne 1...
Ich schaue mal, wo das Löschen fehlt. In der 8.00 hatte
es Bugfixes bezüglich Tx-Diversity zu Clients auf anderen
SSIDs als der ersten gegeben, von daher wäre ein Problem
an der Stelle plausibel.
Generell ist so ein Aufbau aber eine 'heiße' Sache, weil
eben nur ein Empfänger vorhanden ist - solange das
Funkmedium idle ist, 'hört' das Funkmodul nur auf der
ersten Antenne, und wenn ein reinkommendes Signal so
schwach ist, daß man es nur über die zweite Antenne
hören könnte, dann kann es passieren, daß es ganz
'überhört' wird. Derartige Aufbauten funktionieren in
der Praxis häufig, weil die Separation beider Antennen
weder von ihrer Richtwirkung noch von der Dämpfung des
Umschalters perfekt ist - also 'hört' man immer auch ein
bißchen auf der ersten Antenne, so daß die Rx-Diversity
greifen kann.
Ich schaue mal, ob ich Dir kurzfristig eine Testfirmware
geben kann. Du kannst mir schon mal per PM scheiben,
wohin ich sie dann schicken soll.
Gruß & Dank
Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo KaGo,KaGo hat geschrieben:Hallo,
wir haben das selbe Problem.
Haben mehrere P2P Strecken mit L54ag dual von FW 7.8 auf 8.0 upgedatet und nun bricht die Verbindung zu verschiedensten Zeiten komplett ab.
Nach Neustart der Geräte funktioniert es wieder einige Zeit.
Wer weiß Rat ?
ich glaube nicht, daß es das selbe Problem ist, denn bei uns stand die Funkstrecke stabil. Das (dank Alfred gelöste) Problem bestand darin, daß der Algorithmus des Funkmoduls auf der falschen Antenne sendete und die ARP-Antwortpaket nicht am anfragenden OAP-54 ankamen.
Mach am besten mal einen neuen Thread auf.
Grüße
Stefan