L-321agn ARP-Problem Webconfig: Keine Wizards/Assistent mehr

[lancom_dau]

(Update: Screenshot entfernt)

Hallo zusammen,

ich habe einen LANCOM L-321agn Wireless, E 2014-06-30 MOD E0, 9.18.0026 / 28.01.2016.

Mein Problem:

Ich hatte mit diesem AP schon immer Probleme, dass er mit meinem Lenovo Thinkpad T520 (Ltd. RTL8188CE 802.11b/g/n WiFi) nicht richtig funktionierte.
WLAN Verbindung wird aufgebaut, alles funktioniert, man sieht ARP requests/response laufen.
Nach kurzer Zeit schickt das Thinkpad wieder ARP request, der L321 sieht diese auch, aber beantwortet diese nicht mehr.
(Der Thinkpad hat auch eine gültige MAC, keine "unerlaubte")

Das Problem haben andere Clients im WLAN allerdings nicht.

Die Einzige Abhilfe ist, dass man auf dem Thinkpad die ARP Einträge statisch setzt.

Da diese Workaround nicht tragbar ist, hoffte ich mit jeder neuen Firmware Version auf Abhilfe.

Ich habe mehrere Firwares eingespielt, die komplette Config resettet und wieder alles neu eingerichtet, aber das ARP Problem blieb.

Nun habe ich allerdings das Problem, dass beim Firmware Update über WebConfig keine Assistenten/Wizards mehr angezeigt werden.
Dort war nur noch "RollOut-Wizard", aber kein Wizards für Internetverbindung/WLAN etc....
Den habe ich dann mal gelöscht um zu sehen, ob der Rest dann wieder kommt. Nun sind gar keine Assistenten mehr da.

Somit kann ich den AP nicht mehr einfach über Web konfigurieren.
Auch ein erneutes Hochladen der Firmware und Config reset brachte nichts.

Wie bekomme ich die Wizards wieder zurück?

(Über Lanconfig unter Windows funktioniert noch alles)

Mfg,
lancom_dau

[alf29]

Moin,

AFAIK sind diese Wizards aus Platzgründen in neueren Firmwaren entfernt worden.

Das LCOS hat eine ARP-Trace, in dem kann man sich ansehen, ob dioe ARP-Requests für die IP-Adresse des LANCOM noch im IP-Stack ankommen und wenn ja, warum sie nicht beantwortet werden.

Gruß Alfred

[LoUiS]

Hi,

ja, die Assistenten sind aus Platzgruenden in diesem LCOS entfernt worden.
Siehe auch Releasenotes zum LCOS, unter
Korrekturen/Anpassungen.


Ciao
LoUiS

[lancom_dau]

Hallo zusammen,

Vielen Dank für die Erklärung warum die Wizards nicht mehr da sind. (Ich hatte bei den Releasenotes immer direkt nach ARP gesucht)
Allerdings finde ich diese Änderung sehr schade, da ich privat nur Linux/Solaris/BSD Systeme verwende und somit eine komfortable Konfigurationsmöglichkeit verloren habe.

Zu dem ARP Problem:

Das Netz ist wie folgt aufgebaut:

Thinkpad ( 192.168.11.88 / 60:d8:19:c4:f9:0e ) <--wlan--> LC-L321 (192.168.11.10 / 00:a0:57:1f:d3:0a) <-- netgear-switch --> router (ALIX Board/debian 192.168.11.1 / 00:0d:b9:34:63:f0)

Interessant ist, dass es (anscheinend) nur das Thinkpad betrifft. Alle andern Wlan Clients haben keine Probleme.
Habe auch schon alle möglichen ARP relevanten Einstellungen im AP durchprobiert, ohne eine Änderung festzustellen.

Zum Abschluss noch die aktuellen Statistiken des AP:

ARP-Requests-Answered 253
ARP-Requests-Discarded 0
ARP-Requests-not-Answered 807

Thinkpad
No. Time Source Destination Protocol Length Info
20 2016-02-13 20:29:13.957135 PcEngine_34:63:f0 Broadcast ARP 60 Who has 192.168.11.88? Tell 192.168.11.1
24 2016-02-13 20:29:14.956340 PcEngine_34:63:f0 Broadcast ARP 60 Who has 192.168.11.88? Tell 192.168.11.1
31 2016-02-13 20:29:15.956333 PcEngine_34:63:f0 Broadcast ARP 60 Who has 192.168.11.88? Tell 192.168.11.1
54 2016-02-13 20:29:21.032353 HonHaiPr_c4:f9:0e Broadcast ARP 42 Who has 192.168.11.1? Tell 192.168.11.88
55 2016-02-13 20:29:21.042069 PcEngine_34:63:f0 HonHaiPr_c4:f9:0e ARP 60 192.168.11.1 is at 00:0d:b9:34:63:f0
77 2016-02-13 20:29:26.063816 PcEngine_34:63:f0 HonHaiPr_c4:f9:0e ARP 60 Who has 192.168.11.88? Tell 192.168.11.1
78 2016-02-13 20:29:26.063864 HonHaiPr_c4:f9:0e PcEngine_34:63:f0 ARP 42 192.168.11.88 is at 60:d8:19:c4:f9:0e
83 2016-02-13 20:29:27.887474 HonHaiPr_c4:f9:0e Broadcast ARP 42 Who has 192.168.11.10? Tell 192.168.11.88
84 2016-02-13 20:29:28.889018 HonHaiPr_c4:f9:0e Broadcast ARP 42 Who has 192.168.11.10? Tell 192.168.11.88
86 2016-02-13 20:29:29.890997 HonHaiPr_c4:f9:0e Broadcast ARP 42 Who has 192.168.11.10? Tell 192.168.11.88
87 2016-02-13 20:29:30.893142 HonHaiPr_c4:f9:0e Broadcast ARP 42 Who has 192.168.11.10? Tell 192.168.11.88
88 2016-02-13 20:29:31.895014 HonHaiPr_c4:f9:0e Broadcast ARP 42 Who has 192.168.11.10? Tell 192.168.11.88
90 2016-02-13 20:29:32.897014 HonHaiPr_c4:f9:0e Broadcast ARP 42 Who has 192.168.11.10? Tell 192.168.11.88


TRACE auf AccessPoint


[ARP] 2016/02/13 20:29:19,337
ARP RX (LAN-1, INTRANET): ARP-REQ
SrcIp=192.168.11.1 @ 00:0d:b9:34:63:f0 (PC-Engines 34:63:f0)
DstIp=192.168.11.88 @ 00:00:00:00:00:00 (Xerox 00:00:00)
Response discarded

[ARP] 2016/02/13 20:29:20,337
ARP RX (LAN-1, INTRANET): ARP-REQ
SrcIp=192.168.11.1 @ 00:0d:b9:34:63:f0 (PC-Engines 34:63:f0)
DstIp=192.168.11.88 @ 00:00:00:00:00:00 (Xerox 00:00:00)
Response discarded

[ARP] 2016/02/13 20:29:21,337
ARP RX (LAN-1, INTRANET): ARP-REQ
SrcIp=192.168.11.1 @ 00:0d:b9:34:63:f0 (PC-Engines 34:63:f0)
DstIp=192.168.11.88 @ 00:00:00:00:00:00 (Xerox 00:00:00)
Response discarded

[ARP] 2016/02/13 20:29:26,422
ARP RX (WLAN-1, INTRANET): ARP-REQ
SrcIp=192.168.11.88 @ 60:d8:19:c4:f9:0e (Hon-Hai c4:f9:0e)
DstIp=192.168.11.1 @ 00:00:00:00:00:00 (Xerox 00:00:00)
Response discarded

[ARP] 2016/02/13 20:29:31,440
ARP RX (LAN-1, INTRANET): ARP-REQ
SrcIp=192.168.11.3 @ 00:27:0e:07:d4:eb
DstIp=192.168.11.10 @ 00:00:00:00:00:00 (Xerox 00:00:00)

Cache-192.168.11.3 @ 00:27:0e:07:d4:eb
Response Fwd to LAN-1, INTRANET


Router
No. Time Source Destination Protocol Length Info
3 2016-02-13 20:29:14.307623 PcEngine_34:63:f0 ARP 44 Who has 192.168.11.88? Tell 192.168.11.1
6 2016-02-13 20:29:15.307314 PcEngine_34:63:f0 ARP 44 Who has 192.168.11.88? Tell 192.168.11.1
9 2016-02-13 20:29:16.307316 PcEngine_34:63:f0 ARP 44 Who has 192.168.11.88? Tell 192.168.11.1
13 2016-02-13 20:29:21.393511 HonHaiPr_c4:f9:0e ARP 62 Who has 192.168.11.1? Tell 192.168.11.88
14 2016-02-13 20:29:21.393572 PcEngine_34:63:f0 ARP 44 192.168.11.1 is at 00:0d:b9:34:63:f0
15 2016-02-13 20:29:26.415304 PcEngine_34:63:f0 ARP 44 Who has 192.168.11.88? Tell 192.168.11.1
18 2016-02-13 20:29:26.425953 HonHaiPr_c4:f9:0e ARP 62 192.168.11.88 is at 60:d8:19:c4:f9:0e


Vielen Dank für eure Hilfe!
Mfg,
lancom_dau

[Jirka]

Hallo zusammen,

Siehe auch Releasenotes zum LCOS, unter
Korrekturen/Anpassungen.

da steht aber "nur" was vom L-322agn...

Viele Grüße,
Jirka

[alf29]

Moin,

Habe auch schon alle möglichen ARP relevanten Einstellungen im AP durchprobiert, ohne eine Änderung festzustellen.

Mit dem ARP-Handling auf dem LANCOM-AP kannst Du nur beeinflussen, ob der AP an einen seiner Clients gerichtete ARP-Requests beantworten soll (woanders auch als ARP-Proxying bezeichnet). Hier geht's aber um einen ARP-Request von einem Client, darauf hat der Schalter keinen Einfluß, es sei denn der ARP-Request wäre an einen anderen Client in der gleichen Funkzelle gerichtet.

Zu den Traces, ich sehe den ARP-Request auf dem Thinkpad, aber nicht im ARP-Trace auf dem LANCOM, und auch nicht auf dem Server, da hätte der LANCOM-AP sie als Broadcast prinzipiell auch hin weiterleiten können. Der nächste Schritt wäre, auf dem LANCOM im WLAN-Data-Trace zu schauen, ob die ARP-Requests überhaupt auf dem WLAN hereinkommen. Achtung, der WLAN-Data-Trace erzeugt viele Daten, sinnvollerweise auf einer CLI-Session vom LAN her starten und die Ausgaben auf ARP-Pakete beschränken, z.B. so:


trace # wlan-data @ ARP

Wenn die ARP-Requests vom Thinkpad da noch auftauchen, müssen wir weiter überlegen, wo sie im LANCOM verloren gehen könnten. Ansosten hat das LANCOM sie gar nicht bekommen...

Gruß Alfred

[lancom_dau]

Moin,

Habe auch schon alle möglichen ARP relevanten Einstellungen im AP durchprobiert, ohne eine Änderung festzustellen.

Mit dem ARP-Handling auf dem LANCOM-AP kannst Du nur beeinflussen, ob der AP an einen seiner Clients gerichtete ARP-Requests beantworten soll (woanders auch als ARP-Proxying bezeichnet). Hier geht's aber um einen ARP-Request von einem Client, darauf hat der Schalter keinen Einfluß, es sei denn der ARP-Request wäre an einen anderen Client in der gleichen Funkzelle gerichtet.

entschuldige,da habe ich mich etwas ungenau ausgedrückt. Ich meinte diese Einstellung (WLAN):

Code: Alles auswählen

ARP handling Mobile stations in the wireless network that are on standby do not answer the ARP requests from other network stations reliably. If 'ARP handling' is activated, the access point takes over this task and answers the ARP requests on behalf of stations that are on standby. 

Zu den Traces, ich sehe den ARP-Request auf dem Thinkpad, aber nicht im ARP-Trace auf dem LANCOM, und auch nicht auf dem Server, da hätte der LANCOM-AP sie als Broadcast prinzipiell auch hin weiterleiten können. Der nächste Schritt wäre, auf dem LANCOM im WLAN-Data-Trace zu schauen, ob die ARP-Requests überhaupt auf dem WLAN hereinkommen. Achtung, der WLAN-Data-Trace erzeugt viele Daten, sinnvollerweise auf einer CLI-Session vom LAN her starten und die Ausgaben auf ARP-Pakete beschränken, z.B. so:


trace # wlan-data @ ARP

Wenn die ARP-Requests vom Thinkpad da noch auftauchen, müssen wir weiter überlegen, wo sie im LANCOM verloren gehen könnten. Ansosten hat das LANCOM sie gar nicht bekommen...

Gruß Alfred

Danke für die Anregung.
Ich werde das Szenario asap nochmal sauber nachstellen (nach zu vielen Tests/Resets/FirmwareUpgrades laufen auf z.B.die im Netz verwendetet NTP Server auseinander.)

Ich melde mich wieder,

lancom_dau

[lancom_dau]

Also:


Wenn das Thinkpad sich initial per WLAN verbunden hat, sehe ich kurz ARP request über den LC AP auf den router und zurück und alles ist gut.
Ping auf router funktioniert.

z.B.:

[ARP] 2016/02/15 20:58:29,114
ARP RX (WLAN-1, INTRANET): ARP-REQ
SrcIp=192.168.11.88 @ 60:d8:19:c4:f9:0e (Hon-Hai c4:f9:0e)
DstIp=192.168.11.10 @ 00:00:00:00:00:00 (Xerox 00:00:00)

Cache-192.168.11.88 @ 60:d8:19:c4:f9:0e (Hon-Hai c4:f9:0e)
Response Fwd to WLAN-1, INTRANET

[ARP] 2016/02/15 20:58:29,127
ARP RX (WLAN-1, INTRANET): ARP-REQ
SrcIp=192.168.11.88 @ 60:d8:19:c4:f9:0e (Hon-Hai c4:f9:0e)
DstIp=192.168.11.1 @ 00:00:00:00:00:00 (Xerox 00:00:00)

Cache-192.168.11.88 @ 60:d8:19:c4:f9:0e (Hon-Hai c4:f9:0e)
Response discarded

Versuche ich dann ein ping auf eine gerade nicht existente IP im LAN (z.b. 192.168.11.99), sehe ich ARPs auf dem Thinkpad WLAN interface.
Diese werden zurecht nicht beantwortet, tauchen aber auch nicht im ARP Trace des LC AP (wo ich sie vermuten würde).

Pinge ich dann wieder auf den router, sehe ich im thinkpad wieder ARP request, der ARP trace zeigt nichts und es kommen keine Antworten mehr...
Ab diesem Punkt funktioniert eigentlich nichts mehr.

Daraus könnte man deuten, dass es ein Problem des Thinkpads ist, da die ARP Requests es nicht in den ARP Trace des LC schafft und somit eventuell nie über WLAN gesendet wurden.
Damit wäre klar, warum es nicht funktioniert...

Nur: Leider besteht das Problem mit dem Thinkpad ausschliesslich im WLAN mit dem LC AP.
Alle anderen AccessPoints funktionieren mit dem Thinkpad.

Andererseits funktionieren auch alle anderen WLAN-Clients mit dem LC-AP... also kann es auch kein generelles Problem im LC AP sein..

Gibt es noch eine Idee, was ich nachsehen könnte?

Mfg,

lancom_dau

[alf29]

Moin,

ich hatte eigentlich nach dem WLAN-Data-Trace gefragt (siehe oben), der setzt layermäßig noch 1..2 Stufen niedriger an und man sieht auf MAC-Ebene,
was von den Clients reinkommt. Einfach mal folgendes machen:

Code: Alles auswählen

set /setup/wlan/trace-mac 60d819c4f90e

damit schränkt man den folgenden Trace auf Pakete von/zu dieser MAC-Adresse ein. Dann ein

Code: Alles auswählen

trace # wlan-data

eingeben und den Thinkpad sich einbuchen lassen. Da wird eine ganze Menge kommen, erst Probe Requests/Responses, dann Authenticates, dann Associate Request/Response, dann EAPOL-Pakete vom WPA-Key-Handshake und dann ist der Client erstmal verbunden. Danach wird's interessant...

entschuldige,da habe ich mich etwas ungenau ausgedrückt. Ich meinte diese Einstellung (WLAN):

Code: Alles auswählen

ARP handling Mobile stations in the wireless network that are on standby do not answer the ARP requests from other network stations reliably. If 'ARP handling' is activated, the access point takes over this task and answers the ARP requests on behalf of stations that are on standby. 

Genau das meinte ich auch. Diese Funktion behandelt nur ARP-Requests die *vom LAN* her kommen und an einen Client im WLAN gerichtet sind, in dem Sinne, daß der AP diese Requests nicht ins WLAN weiterleitet, sondern selber mit der MAC-Adresse des jeweiligen Clients beantwortet. An ARP-Requests, die *von einem Client im WLAN* kommen und ans LAN gerichtet sind, ändert diese Funktion gar nichts.

Gruß Alfred