LX-6400 VPN

Forum zum LANCOM WLC-4100, WLC-4025+, WLC-4025 und WLC-4006 WLAN-Controller

Moderator: Lancom-Systems Moderatoren

Antworten
mhoess
Beiträge: 5
Registriert: 12 Aug 2020, 16:13

LX-6400 VPN

Beitrag von mhoess »

Hallo,
wir wollen einen LX-6400 mit einem WLC-4025+ verwalten, wenn beide im lokalen Netz sind, funktioniert das auch.
Wenn der AP in einem per VPN verbundenen Netz ist, dann wird der AP aber als "fehlender AP" im Lanmonitor angezeigt.
Die Konfiguration aber wird vom WLC auf den AP übertragen, das hat funktioniert.
Die Verbindung vom AP zum WLC, sowie vom WLC zum AP ist auch gegeben.
Andere APs (ältere Modelle) im VPN Netz funktionieren normal.
Irgendeine Idee? Die Firmware ist bei beiden aktuell.
Danke lg
Benutzeravatar
LoUiS
Site Admin
Site Admin
Beiträge: 5031
Registriert: 07 Nov 2004, 18:29
Wohnort: Aix la Chapelle

Re: LX-6400 VPN

Beitrag von LoUiS »

Hi,

es sollte in Kuerze eine 5.20 RU2 fuer den LX-6400 freigegeben werden, bzw. ist schon freigegeben.
Mit der kannst Du testen ob der AP sich noch immer so verhaelt.


Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: LX-6400 VPN

Beitrag von Jirka »

Mit der 5.20.0039-Rel hat der LX-6400 regelmäßig und immer wieder nach einigen Tagen die Verbindung zum WLC verloren (im lokalen LAN). Mitunter hilft ein Neustart, öfter hilft das aber auch nicht und es muss ein Gerät resettet werden. Danach funktionieren die Geräte ohne weiteres zutun wieder ein paar Tage, bis sie wieder die Verbindung zum WLC verlieren. Klassische LANCOM-APs (LN-1700 z. B.) funktionieren parallel ohne derartige Probleme.
Vielleicht löst die RU2 ja auch dieses Problem?

Viele Grüße,
Jirka
alexes
Beiträge: 175
Registriert: 27 Nov 2005, 18:09

Re: LX-6400 VPN

Beitrag von alexes »

Die LC-LX-6400-5.20.0075-RU2 ist auf dem FTP.

Das Problem mit dem verlieren der Verbindung zum WLC hatte ich auch. Bei mir sah es aber so aus als ob das Problem nur auftritt wenn es eine SSID mit Radius Authentifizierung auf dem Access Point gibt (bei nur einer SSID mit PSK trat das Problem nicht auf).

Mal sehen ob es mit der RU2 jetzt besser läuft.
alexes
Beiträge: 175
Registriert: 27 Nov 2005, 18:09

Re: LX-6400 VPN

Beitrag von alexes »

Läuft seit gestern problemlos.
mhoess
Beiträge: 5
Registriert: 12 Aug 2020, 16:13

Re: LX-6400 VPN

Beitrag von mhoess »

Ja, mit RU2 ist das Problem behoben.
mhoess
Beiträge: 5
Registriert: 12 Aug 2020, 16:13

Re: LX-6400 VPN

Beitrag von mhoess »

So ganz sauber läuft das auch mit RU3 noch nicht, die Konfiguration wird zwar korrekt vom WLC übernommen, nach einem AP Neustart wird er auch im Lanmonitor als aktiver AP angezeigt, aber nach einiger Zeit wird er fehlend, im Log kommt immer wieder die Meldung capwap[1746]: Got station event from hostapd ignore it we are not in run state or we are anonymous. Offenbar gibt es Probleme bei der PMTU Discovery, wo der AP dann in ein Timeout rennt.
2020-10-07 13:35:44debug
capwap[1746]: WTP got data: r: -1
2020-10-07 13:35:44debug
capwap[1746]: Receive CAPWAP Control Channel message
2020-10-07 13:35:44debug
capwap[1746]: Discovery Response with invalid sequence (116 != 115)
2020-10-07 13:35:44debug
capwap[1746]: Stop PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Received PMTU discovery response
2020-10-07 13:35:44debug
capwap[1746]: MESSAGE ELEMENT: 52
2020-10-07 13:35:44debug
capwap[1746]: WTP got data: r: 872
2020-10-07 13:35:44debug
capwap[1746]: Receive CAPWAP Control Channel message
2020-10-07 13:35:44debug
capwap[1746]: WTP got data: r: -1
2020-10-07 13:35:44debug
capwap[1746]: Receive CAPWAP Control Channel message
2020-10-07 13:35:44debug
capwap[1746]: Discovery Response with invalid sequence (116 != 114)
2020-10-07 13:35:44debug
capwap[1746]: Stop PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Received PMTU discovery response
2020-10-07 13:35:44debug
capwap[1746]: MESSAGE ELEMENT: 52
2020-10-07 13:35:44debug
capwap[1746]: WTP got data: r: 972
2020-10-07 13:35:44debug
capwap[1746]: Receive CAPWAP Control Channel message
2020-10-07 13:35:44debug
capwap[1746]: WTP got data: r: -1
2020-10-07 13:35:44debug
capwap[1746]: Receive CAPWAP Control Channel message
2020-10-07 13:35:44debug
capwap[1746]: Discovery Response with invalid sequence (116 != 112)
2020-10-07 13:35:44debug
capwap[1746]: Stop PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Received PMTU discovery response
2020-10-07 13:35:44debug
capwap[1746]: MESSAGE ELEMENT: 52
2020-10-07 13:35:44debug
capwap[1746]: WTP got data: r: 1172
2020-10-07 13:35:44debug
capwap[1746]: Receive CAPWAP Control Channel message
2020-10-07 13:35:44debug
capwap[1746]: Start PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Count 1 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Count 0 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Add mtu discovery element 752 1500 8 8
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU seq number 116
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU increment seq number 116
2020-10-07 13:35:44debug
capwap[1746]: No discovery response received try again 6
2020-10-07 13:35:44debug
capwap[1746]: PMTU process/timeout 256
2020-10-07 13:35:44debug
capwap[1746]: Start PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Count 1 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Count 0 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Add mtu discovery element 852 1500 8 8
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU seq number 115
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU increment seq number 115
2020-10-07 13:35:44debug
capwap[1746]: No discovery response received try again 5
2020-10-07 13:35:44debug
capwap[1746]: PMTU process/timeout 256
2020-10-07 13:35:44debug
capwap[1746]: Start PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Count 1 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Count 0 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Add mtu discovery element 952 1500 8 8
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU seq number 114
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU increment seq number 114
2020-10-07 13:35:44debug
capwap[1746]: No discovery response received try again 4
2020-10-07 13:35:44debug
capwap[1746]: PMTU process/timeout 256
2020-10-07 13:35:44debug
capwap[1746]: Start PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Count 1 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Count 0 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Add mtu discovery element 1052 1500 8 8
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU seq number 113
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU increment seq number 113
2020-10-07 13:35:44debug
capwap[1746]: No discovery response received try again 3
2020-10-07 13:35:44debug
capwap[1746]: PMTU process/timeout 256
2020-10-07 13:35:44debug
capwap[1746]: Start PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Count 1 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Count 0 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Add mtu discovery element 1152 1500 8 8
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU seq number 112
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU increment seq number 112
2020-10-07 13:35:44debug
capwap[1746]: No discovery response received try again 2
2020-10-07 13:35:44debug
capwap[1746]: PMTU process/timeout 256
2020-10-07 13:35:44debug
capwap[1746]: Start PMTU discovery timer
2020-10-07 13:35:44debug
capwap[1746]: Count 1 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Count 0 Fragment 0
2020-10-07 13:35:44debug
capwap[1746]: Add mtu discovery element 1252 1500 8 8
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU seq number 111
2020-10-07 13:35:44debug
capwap[1746]: Discovery PMTU increment seq number 111
2020-10-07 13:35:44debug
capwap[1746]: No discovery response received try again 1
2020-10-07 13:35:44debug
capwap[1746]: PMTU process/timeout 256
2020-10-07 13:35:42debug
capwap[1746]: Start PMTU discovery timer
2020-10-07 13:35:42debug
capwap[1746]: Count 1 Fragment 0
2020-10-07 13:35:42debug
capwap[1746]: Count 0 Fragment 0
2020-10-07 13:35:42debug
capwap[1746]: Add mtu discovery element 1352 1500 8 8
2020-10-07 13:35:42debug
capwap[1746]: Discovery PMTU seq number 110
2020-10-07 13:35:42debug
capwap[1746]: Enter PMTU discovery state
2020-10-07 13:35:42debug
capwap[1746]: WTP change state from DISCOVERY to PMTU_DISCOVERY
2020-10-07 13:35:27debug
capwap[1746]: WTP got data: r: -1
2020-10-07 13:35:27debug
capwap[1746]: Receive CAPWAP Control Channel message
2020-10-07 13:35:27debug
capwap[1746]: Discovery response set wlc timestamp [2020/10/07 13:35:37] current [2020/10/07 13:35:27]
2020-10-07 13:35:27debug
capwap[1746]: Discovery response get wlc timestamp [1602070537][2020/10/07 13:35:37] local [1602070527][2020/10/07 13:35:27]
2020-10-07 13:35:27debug
capwap[1746]: wlc priority name [WCWPK][1]
2020-10-07 13:35:27debug
capwap[1746]: Discovery increment seq number 110
2020-10-07 13:35:27debug
capwap[1746]: vendor read_ops: 0x4e7fb8
2020-10-07 13:35:27debug
capwap[1746]: VENDOR MESSAGE ELEMENT: 2356:1
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 37
2020-10-07 13:35:27debug
capwap[1746]: vendor read_ops: 0x4e7f90
2020-10-07 13:35:27debug
capwap[1746]: VENDOR MESSAGE ELEMENT: 2356:2
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 37
2020-10-07 13:35:27debug
capwap[1746]: no data to read empty
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 1
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 10
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 6
2020-10-07 13:35:27debug
capwap[1746]: vendor read_ops: 0x4e7b30
2020-10-07 13:35:27debug
capwap[1746]: VENDOR MESSAGE ELEMENT: 2356:49
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 37
2020-10-07 13:35:27debug
capwap[1746]: vendor read_ops: 0x4e7b58
2020-10-07 13:35:27debug
capwap[1746]: VENDOR MESSAGE ELEMENT: 2356:48
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 37
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 5
2020-10-07 13:35:27debug
capwap[1746]: MESSAGE ELEMENT: 33
2020-10-07 13:35:27debug
capwap[1746]: WTP got data: r: 167
2020-10-07 13:35:27debug
capwap[1746]: Receive CAPWAP Control Channel message
2020-10-07 13:35:27debug
capwap[1746]: Discovery seq number 109
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: LX-6400 VPN

Beitrag von tstimper »

Hi
Offenbar gibt es Probleme bei der PMTU Discovery, wo der AP dann in ein Timeout rennt.
Konntest Du das Problem bei Dir lösen? Das scheint mit der Firmware v5.34.0027-su1 besser geworden zu sein.
ICh sehe aber immer noch seltene Abbrüche der Kommunikation der APs zum WLC

Im Normalberieb im log des LX-6400 z.B. sowas

Code: Alles auswählen

capwap[1709]: send echo mtu [1252] allowed length [1204]
Ok, man einigt sich auf die passende kleine MTU von 1204

Unter Last sehen wir einen Kernel Reset und der AP fliegt vom WLC

Code: Alles auswählen

2021-09-22 19:44:28debug
capwap[1709]: WTP change state from RUN to DTLS_TEARDOWN
2021-09-22 19:44:28debug
capwap[1709]: result 0
2021-09-22 19:44:28debug
capwap[1709]: nl_recvmsgs 0
2021-09-22 19:44:28debug
capwap[1709]: Netlink Ack
2021-09-22 19:44:28debug
capwap[1709]: Kmod sendrecv
2021-09-22 19:44:28debug
capwap[1709]: Kernel module cmd reset
2021-09-22 19:44:28debug
capwap[1709]: Reset kernel session
2021-09-22 19:44:28debug
capwap[1709]: Stop EV_IO on socket 27
2021-09-22 19:44:28debug
capwap[1709]: CAPWAP decrypt packet
2021-09-22 19:44:28debug
capwap[1709]: CAPWAP process packet
2021-09-22 19:44:22debug
hostapd: RX ctrl_iface - hexdump(len=8): 57 50 41 5f 53 54 41 54
2021-09-22 19:44:22debug
hostapd: RX ctrl_iface - hexdump(len=8): 57 50 41 5f 53 54 41 54
2021-09-22 19:44:07debug
hostapd: RX ctrl_iface - hexdump(len=8): 57 50 41 5f 53 54 41 54
2021-09-22 19:44:07debug
hostapd: RX ctrl_iface - hexdump(len=8): 57 50 41 5f 53 54 41 54
2021-09-22 19:44:02debug
capwap[1709]: station callback done
2021-09-22 19:44:02debug
capwap[1709]: wait for WTP event response or wlan timer
2021-09-22 19:44:02debug
capwap[1709]: We get all informations remove station [xx:xx:xx:xx:xx:xx] from event list
2021-09-22 19:44:02info
capwap[1709]: Send Echo request station event thread id 1709 g_wtp.localseqnumber 85 self 548105895504
2021-09-22 19:44:02debug
capwap[1709]: Send echo request increment seq number 85
2021-09-22 19:44:02debug
capwap[1709]: report pmk
2021-09-22 19:44:02debug
capwap[1709]: Authtype [1]
2021-09-22 19:44:02debug
capwap[1709]: Interface name [ath1] got from driver
2021-09-22 19:44:02debug
capwap[1709]: station found [xx:xx:xx:xx:xx:xx]
2021-09-22 19:44:02debug
capwap[1709]: station [xx:xx:xx:xx:xx:xx]
2021-09-22 19:44:02debug
capwap[1709]: Check wlan stations timeout
2021-09-22 19:43:55debug
capwap[1709]: station callback done
2021-09-22 19:43:55debug
capwap[1709]: re-start station wlan timer
2021-09-22 19:43:55debug
capwap[1709]: wait for WTP event response or wlan timer
2021-09-22 19:43:55debug
capwap[1709]: Ready to send pmk
2021-09-22 19:43:55info
capwap[1709]: Send Echo request station event thread id 1709 g_wtp.localseqnumber 84 self 548105895504
2021-09-22 19:43:55debug
capwap[1709]: Send echo request increment seq number 84
2021-09-22 19:43:55debug
capwap[1709]: Send station event (ip ready)
2021-09-22 19:43:55debug
capwap[1709]: station found [xx:xx:xx:xx:xx:xx]
2021-09-22 19:43:55debug
capwap[1709]: station [xx:xx:xx:xx:xx:xx]
2021-09-22 19:43:55debug
capwap[1709]: Check wlan stations timeout
Stabilität sieht anders aus...

Viele Grüße

st
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
mhoess
Beiträge: 5
Registriert: 12 Aug 2020, 16:13

Re: LX-6400 VPN

Beitrag von mhoess »

Mit der neuesten Firmware läuft mittlerweile alles relativ stabil, wir haben in der Zwischenzeit auch unseren WLAN Controller auf einen WLC-1000 getauscht, vielleicht kann der auch mit den neuen Access Point Modellen besser umgehen. Einzig die APs, die per VPN angebunden sind, verlieren manchmal kurzzeitig die Verbindung, also werden im Lanmonitor als fehlende APs angezeigt, verbinden sich dann aber automatisch wieder.
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: LX-6400 VPN

Beitrag von tstimper »

wir haben in der Zwischenzeit auch unseren WLAN Controller auf einen WLC-1000 getauscht, vielleicht kann der auch mit den neuen Access Point Modellen besser umgehen
Ich habe hier auch einen WLC-1000. Gefühlt gibt es die wenigsten Probleme, wenn wier den WLC-1000 jede Nacht rebooten.
Es sieht auch sehr nach Lastverhalten auf dem WLC aus. Aktuell sind ca. 30 LX-6400 auf dem WLC.
Keiner hält mehr als einen Tag durch, ohne vom WLC zu fliegen. Die LN-1700 laufen dabei ohne Probleme weiter.
Einzig die APs, die per VPN angebunden sind, verlieren manchmal kurzzeitig die Verbindung, also werden im Lanmonitor als fehlende APs angezeigt, verbinden sich dann aber automatisch wieder.
Unsere per VPN verbundenen LX-6400 fliegen viel häufuger vom WLC. die LX-1700 laufen fast durch...

Wir lassen die LX-6400 jetzt direkt zum Syslog Serven logggen, da sieht es dann so aus:

Code: Alles auswählen

d9:1a kernel: [ 731.916503] potentially unexpected fatal signal 6.
d9:1a kernel: [ 731.916515]
d9:1a kernel: [ 731.916523] CPU: 0 PID: 1721 Comm: lxwtp Tainted: P 4.4.60 #0
d9:1a kernel: [ 731.916526] Hardware name: Lancom LX-6400 (DT)
d9:1a kernel: [ 731.916530] task: ffffffc03d3a4980 ti: ffffffc03d3a4980 task.ti: ffffffc03d3a4980
d9:1a kernel: [ 731.916535] PC is at 0x7f93e908ec
d9:1a kernel: [ 731.916538] LR is at 0x7f93e90aa0
d9:1a kernel: [ 731.916541] pc : [<0000007f93e908ec>] lr : [<0000007f93e90aa0>] pstate: 00000000
d9:1a kernel: [ 731.916543] sp : 0000007fe0ccd5b0
Alles emergency logs, es sieht so aus, als ob der kernel der LX-6400 bei hoher Last neu bootet.
Ebenso sehen wir, das machmal fast 90 % des Rams des LX genutzt wird.

Bild

Wieviele APs habt Ihr auf dem WLC?

Und nutzt Ihr WLC-Tunnel?

Viele Grüße

ts
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
mhoess
Beiträge: 5
Registriert: 12 Aug 2020, 16:13

Re: LX-6400 VPN

Beitrag von mhoess »

Also Abstürze haben wir nicht, es hängen 94 APs auf dem WLC, davon 26 LX-6400.
Habe jetzt bei 2 APs nachgesehen, wo die meisten Clients dranhängen, da ist der Ram nur knapp über 30%
WLC Tunnel können bei den LX-6400 nicht mehr genutzt werden.
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: LX-6400 VPN

Beitrag von tstimper »

WLC Tunnel können bei den LX-6400 nicht mehr genutzt werden.
Ok, das erklärt möglicherweise, das Euer System stabil läuft und unser nicht.
Seit Firmware v5.32.0029-rel können die LX-6400 auch WLC Tunnel,
Wir hatten das mit Lancom als PoC getestet mit einer vor Release Firmware.
Mit jedem weiteren Release wurde es besser, aber gut ist es noch nicht bei uns.
Leider können wir in die Fläche keine VLANs verteilen, deshalb müssen wir die SSIDs per WLC-Tunnel am WLC konnekten.

Zur Zeit sieht es so aus, als ob PMTU nicht richtig ermittelt wird, wenn VPN und WLC-Tunnel gleichzeitig genutzt wird.

Code: Alles auswählen

capwap[7088]: send echo mtu [1252] allowed length [1204]
Dann kommt etwas Last und AP fliegt vom WLC
Ebenso sehen wir im WLC und AP log viele DTLS Errors

Code: Alles auswählen

DTLS connection failed: Handshake failure, state RcvClientHello
Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Antworten

Zurück zu „Alles zum LANCOM WLC-4100, WLC-4025+, WLC-4025 und WLC-4006 WLAN-Controller“