WLC-1000 und LX-6400 Instabilität
Moderator: Lancom-Systems Moderatoren
WLC-1000 und LX-6400 Instabilität
Hi,
wir haben das Problem, das LX-6400 APs am WLC-1000 sich sehr instabil verhalten.
WLC-1000 Firmware: 10.42.0612-ru5
LX-6400 Firmware: 5.34.0010-rel
Die LX-6400 sind frisch ausgepackt, haben keine weitere Konfiguration bekommen, nur die Firmware v5.32.0029-rel bekommen, damit der WLC-Tunnel geht.
Später wurden die dann upgedated auf v5.32.0035-ru1 und dann auf v5.34.0010-rel.
Das Instabiltätsverhalten war immer gleich.
Ein LX-6400 AP bekommt vom DHCP Server auf einem LC1906VA eine IP, fragt dann nach der WLC IP Adresse (DNS Name wlc-address) des WLC,
verbindet sich zum WLC, bekommt die WLAN Konfig und spannt die SSIDs auf.
Nach einer Weile (einige Stunden oder Tage und je nach Last) ist der AP zwar noch verbunden, aber im WLAN gehen einige Dienste nicht mehr.
Wir sehen zum Beispiel das DNS Replies, die der WLC vom Internet Router bekommt, vom WLC sporadisch verworfen werden und damit vermutlich nicht ins WLAN Netz zum Client weitergeleitet werden.
Wenn dieser Fehlerfall eintritt, also so alle zwei bis drei Tage, reicht es manchmal, diesen einen AP zu rebooten.
Das beste scheint aber zu sein, den WLC zu rebooten.
Jetzt grade sehen wir, das konfigurierte LX-6400, die gestern ausgeschaltet waren, sich nicht am WLC registrieren können.
WLC Lizenzen sind genug frei (20 genutzt, 30 frei)
Das heist, jetzt grade, nach einigen Tagen Last auf dem WLC, kann sich kein konfigurierter LC-6400 wieder mit dem WLC verbinden.
Ein konfigurierter LC-1700, der ausgeschaltet war, verbindet sich sofort zum WLC und läuft gleich stabil.
Vermutlich wird alles wieder funktionieren, wenn ich den WLC neu starte.
Hat das auch jemand so beobachtet?
Weclhe Abhilfe gibt es?
Welcher Trace wäre hier hilfreich?
Viele Grüße
ts
wir haben das Problem, das LX-6400 APs am WLC-1000 sich sehr instabil verhalten.
WLC-1000 Firmware: 10.42.0612-ru5
LX-6400 Firmware: 5.34.0010-rel
Die LX-6400 sind frisch ausgepackt, haben keine weitere Konfiguration bekommen, nur die Firmware v5.32.0029-rel bekommen, damit der WLC-Tunnel geht.
Später wurden die dann upgedated auf v5.32.0035-ru1 und dann auf v5.34.0010-rel.
Das Instabiltätsverhalten war immer gleich.
Ein LX-6400 AP bekommt vom DHCP Server auf einem LC1906VA eine IP, fragt dann nach der WLC IP Adresse (DNS Name wlc-address) des WLC,
verbindet sich zum WLC, bekommt die WLAN Konfig und spannt die SSIDs auf.
Nach einer Weile (einige Stunden oder Tage und je nach Last) ist der AP zwar noch verbunden, aber im WLAN gehen einige Dienste nicht mehr.
Wir sehen zum Beispiel das DNS Replies, die der WLC vom Internet Router bekommt, vom WLC sporadisch verworfen werden und damit vermutlich nicht ins WLAN Netz zum Client weitergeleitet werden.
Wenn dieser Fehlerfall eintritt, also so alle zwei bis drei Tage, reicht es manchmal, diesen einen AP zu rebooten.
Das beste scheint aber zu sein, den WLC zu rebooten.
Jetzt grade sehen wir, das konfigurierte LX-6400, die gestern ausgeschaltet waren, sich nicht am WLC registrieren können.
WLC Lizenzen sind genug frei (20 genutzt, 30 frei)
Das heist, jetzt grade, nach einigen Tagen Last auf dem WLC, kann sich kein konfigurierter LC-6400 wieder mit dem WLC verbinden.
Ein konfigurierter LC-1700, der ausgeschaltet war, verbindet sich sofort zum WLC und läuft gleich stabil.
Vermutlich wird alles wieder funktionieren, wenn ich den WLC neu starte.
Hat das auch jemand so beobachtet?
Weclhe Abhilfe gibt es?
Welcher Trace wäre hier hilfreich?
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Nachtrag:
Soeben getestet, nach dem Reboot des WLC-1000 funktioniert alles wieder, sowohl die LX-6400 als auch die LN-1700 verbinden sich zum WLC.
D.h , ein WLC-1000 mit Firmware v10.42.0612-ru5 hält mit 20* LX-6400 grademal ca. 1,5 Tage stabil durch.
Wir könnten als Workarround den WLC natürlich nachts booten, dann verlieren wir aber auch die aktiven Public Spot Sessions der angemeldeten User.
Also ein no go...
Wieso oder womit treiben die LX-6400 den WLC in den Wahnsinn?
Viele Grüße
ts
Soeben getestet, nach dem Reboot des WLC-1000 funktioniert alles wieder, sowohl die LX-6400 als auch die LN-1700 verbinden sich zum WLC.
D.h , ein WLC-1000 mit Firmware v10.42.0612-ru5 hält mit 20* LX-6400 grademal ca. 1,5 Tage stabil durch.
Wir könnten als Workarround den WLC natürlich nachts booten, dann verlieren wir aber auch die aktiven Public Spot Sessions der angemeldeten User.
Also ein no go...
Wieso oder womit treiben die LX-6400 den WLC in den Wahnsinn?
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Nachtrag;
Auffällig ist im capwap Trace auf den LX-6400, das die nach einer Weile (einige Stunden) einfach aufhören, mit dem WLC zu sprechen.
Wenn ich mich remote in einen LX-6400 einlogge und ihn reboote, sind dannach im capwap Trace wieder Kommunikationsversuche mit dem WLC zu sehen.
Ein Reboot des WLC scheint das auch zu triggern...
Ebenso merkwürdig:
Als würde der LX-6400 zwar die richtige MTU (1392) mitbekommen, dannach aber dennoch zu große Pakete senden (sendto return -1 with error '90' 'Message too large')
Damit wäre dann also die Kommunikation im WLC-Tunel gestört bzw. die würde garnicht erst zustande kommen.
Soeben getestet: Nach Restart des WLC melden sich wieder fast alle LX-6400 am WLC an.
Ein testweise mit aufgestellter LN-1700 geht auch.
Alles sehr rätselhaft ...
Bin für jeden Hinweis dankbar.
Viele Grüße
ts
Auffällig ist im capwap Trace auf den LX-6400, das die nach einer Weile (einige Stunden) einfach aufhören, mit dem WLC zu sprechen.
Wenn ich mich remote in einen LX-6400 einlogge und ihn reboote, sind dannach im capwap Trace wieder Kommunikationsversuche mit dem WLC zu sehen.
Ein Reboot des WLC scheint das auch zu triggern...
Ebenso merkwürdig:
Code: Alles auswählen
[Syslog] 2021/09/17 11:54:37,851 : capwap[1585]: Send PMTU discovery 10.xxx.xxx.255 port 1027
[Syslog] 2021/09/17 11:54:39,818 : capwap[1585]: PMTU process/timeout 256
[Syslog] 2021/09/17 11:54:39,818 : capwap[1585]: No discovery response received try again 1
[Syslog] 2021/09/17 11:54:39,818 : capwap[1585]: Discovery PMTU seq number 2
[Syslog] 2021/09/17 11:54:39,819 : capwap[1585]: Add mtu discovery element 1352 1500 8 8
[Syslog] 2021/09/17 11:54:39,819 : capwap[1585]: Count 0 Fragment 0
[Syslog] 2021/09/17 11:54:39,819 : capwap[1585]: Count 1 Fragment 0
[Syslog] 2021/09/17 11:54:39,819 : capwap[1585]: Start PMTU discovery timer
[Syslog] 2021/09/17 11:54:39,819 : capwap[1585]: Unable to send packet, sendto return -1 with error '90' 'Message too large'
[Syslog] 2021/09/17 11:54:39,819 : capwap[1585]: Unable to send fragment, sentto return error -90
[Syslog] 2021/09/17 11:54:39,819 : capwap[1585]: Warning: error to send PMTU discovery request packet
Damit wäre dann also die Kommunikation im WLC-Tunel gestört bzw. die würde garnicht erst zustande kommen.
Soeben getestet: Nach Restart des WLC melden sich wieder fast alle LX-6400 am WLC an.
Ein testweise mit aufgestellter LN-1700 geht auch.
Alles sehr rätselhaft ...
Bin für jeden Hinweis dankbar.
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Nachtrag:
Es gibt seit heute Nachmittag eine neue Firmware 5.34.0027-SU1 für die LX-6400
siehe: https://ftp.lancom.de/LANCOM-Releases/L ... 27-SU1.upx
Mit dieser Firmware verbinden sich die LX-6400 fast sofort mit dem WLC und scheinen wesentlich länger stabil zu laufen.
Viele Grüße
ts
Es gibt seit heute Nachmittag eine neue Firmware 5.34.0027-SU1 für die LX-6400
siehe: https://ftp.lancom.de/LANCOM-Releases/L ... 27-SU1.upx
Mit dieser Firmware verbinden sich die LX-6400 fast sofort mit dem WLC und scheinen wesentlich länger stabil zu laufen.
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Nachtrag:
wir lassen jetzt einen LC-6400 an einen Syslog Server loggen.
Beim Abbruch der Verbindung des LC-6400 zum WLC-1000 sehen wir folgendes (zeitlich rückwärts..)
Zusammengefasst in richtiger Reigenfolge alle Emmergancy calls
Also es sieht sehr dannach aus, als wenn der LX Linux Kernel unter Last auf dem LC-6400 abstürzt und dann neu bootet.
Viele Grüße
ts
wir lassen jetzt einen LC-6400 an einen Syslog Server loggen.
Beim Abbruch der Verbindung des LC-6400 zum WLC-1000 sehen wir folgendes (zeitlich rückwärts..)
Code: Alles auswählen
09/23/2021
14:05
Info
lx-6400-lab
user
LX-6400-LAB-59
d9:1a iappd[895]: Resending handover for station
09/23/2021
14:05
Info
lx-6400-lab
user
LX-6400-LAB-59
d9:1a iappd[895]: Resending handover for station
09/23/2021
14:05
Info
lx-6400-lab
user
LX-6400-LAB-59
d9:1a iappd[895]: Resending handover for station
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916594]
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916591] x1 : 0000007fe0ccd5d0 x0 : 0000000000000000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916588] x3 : 0000000000000008 x2 : 0000000000000000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916585] x5 : 0000000000000000 x4 : 0000000000000000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916581] x7 : 00000000fffffff6 x6 : 0000000000000000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916578] x9 : 000000000000000a x8 : 0000000000000087
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916575] x11: 00000000ffffffff x10: 0000007fe0ccd56b
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916572] x13: ffffffff9eb3955c x12: 0000000000000018
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916569] x15: 003b9aca00000000 x14: 000d90a4c2000000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916566] x17: 0000007f93e7d548 x16: 00000000004cffa8
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916562] x19: 0000007fe0ccd5d0 x18: 0000000000000011
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916559] x21: 0000007f93bbf514 x20: 0000000000000000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916556] x23: 0000000000080800 x22: 0000000000000000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916553] x25: 00000000004d0260 x24: 0000007f93bbeee4
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916549] x27: 00000000000006b9 x26: 0000007f9378b3c0
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916545] x29: 0000007fe0ccd5b0 x28: 0000007f93ed2000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916543] sp : 0000007fe0ccd5b0
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916541] pc : [<0000007f93e908ec>] lr : [<0000007f93e90aa0>] pstate: 00000000
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916538] LR is at 0x7f93e90aa0
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916535] PC is at 0x7f93e908ec
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916530] task: ffffffc03d3a4980 ti: ffffffc03d3a4980 task.ti: ffffffc03d3a4980
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916526] Hardware name: Lancom LX-6400 (DT)
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916523] CPU: 0 PID: 1721 Comm: lxwtp Tainted: P 4.4.60 #0
09/23/2021
14:05
Emergency
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916515]
09/23/2021
14:05
Info
lx-6400-lab
kern
LX-6400-LAB-59
d9:1a kernel: [ 731.916503] potentially unexpected fatal signal 6.
09/23/2021
14:05
Info
lx-6400-lab
user
LX-6400-LAB-59
d9:1a iappd[895]: Resending handover for station
09/23/2021
14:05
Info
lx-6400-lab
user
LX-6400-LAB-59
d9:1a iappd[895]: Resending handover for station
09/23/2021
14:05
Debug
lx-6400-lab
daemon
LX-6400-LAB-59
d9:1a capwap[1721]: station callback done
09/23/2021
14:05
Debug
lx-6400-lab
daemon
LX-6400-LAB-59
d9:1a capwap[1721]: re-start station wlan timer
09/23/2021
14:05
Debug
lx-6400-lab
daemon
LX-6400-LAB-59
d9:1a capwap[1721]: wait for WTP event response or wlan timer
Zusammengefasst in richtiger Reigenfolge alle Emmergancy calls
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
d9:1a kernel: [ 731.916545] x29: 0000007fe0ccd5b0 x28: 0000007f93ed2000
d9:1a kernel: [ 731.916549] x27: 00000000000006b9 x26: 0000007f9378b3c0
d9:1a kernel: [ 731.916553] x25: 00000000004d0260 x24: 0000007f93bbeee4
d9:1a kernel: [ 731.916556] x23: 0000000000080800 x22: 0000000000000000
d9:1a kernel: [ 731.916559] x21: 0000007f93bbf514 x20: 0000000000000000
d9:1a kernel: [ 731.916562] x19: 0000007fe0ccd5d0 x18: 0000000000000011
d9:1a kernel: [ 731.916566] x17: 0000007f93e7d548 x16: 00000000004cffa8
d9:1a kernel: [ 731.916569] x15: 003b9aca00000000 x14: 000d90a4c2000000
d9:1a kernel: [ 731.916572] x13: ffffffff9eb3955c x12: 0000000000000018
d9:1a kernel: [ 731.916575] x11: 00000000ffffffff x10: 0000007fe0ccd56b
d9:1a kernel: [ 731.916578] x9 : 000000000000000a x8 : 0000000000000087
d9:1a kernel: [ 731.916581] x7 : 00000000fffffff6 x6 : 0000000000000000
d9:1a kernel: [ 731.916585] x5 : 0000000000000000 x4 : 0000000000000000
d9:1a kernel: [ 731.916588] x3 : 0000000000000008 x2 : 0000000000000000
d9:1a kernel: [ 731.916591] x1 : 0000007fe0ccd5d0 x0 : 0000000000000000
d9:1a kernel: [ 731.916594]
d9:1a iappd[895]: Resending handover for station
d9:1a iappd[895]: Resending handover for station
d9:1a iappd[895]: Resending handover for station
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Nachtrag:
Wir sehen teilweise sehr hohe Memory Nutzung unter Last auf den LX-6400
Wir sehen teilweise sehr hohe Memory Nutzung unter Last auf den LX-6400
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Nachtrag:
gestern haben wir fast 10 GB Trace / WireShark Daten mit sichtbaren Abbrüchen erzeugt und an Lancom übergeben.
Im capwap trace des APs sehen wir:
Im Syslog des APs sehen wir (in umgekehrter Reihenfolge)
Also es kommt eine PMTU message, der AP sendet ein Paket in der Länge von 1252, es ist aber nur ein Paket in der Länge von 1204 erlaubt.
Dannach kommen eine Retransmition Versuche.
Dannach resetted der Linux kernel auf dem LX-6400
Der AP verliert die Verbindung zum WLC, das WLAN schaltet ab, der AP verbindet neu zum WLC,bekommt die Config und WLANist wieder da.
Das passierte im Test im LAB unter Last ca. alle 10 Minuten.
In der Produktiv Installation hängen die APS an verschiedenen Switches, teils auch über DSL / VPN angebunden.
Das Verhalten ist überall gleich.
Viele Grüße
ts
gestern haben wir fast 10 GB Trace / WireShark Daten mit sichtbaren Abbrüchen erzeugt und an Lancom übergeben.
Im capwap trace des APs sehen wir:
Code: Alles auswählen
Syslog] 2021/09/27 19:35:46,805 : capwap[1722]: Receive CAPWAP Control Channel message
[Syslog] 2021/09/27 19:35:46,806 : capwap[1722]: WTP got data: r: -1
[Syslog] 2021/09/27 19:35:46,806 : capwap[1722]: try again...
[Syslog] 2021/09/27 19:35:46,806 : capwap[1722]: Leave capwap control
Code: Alles auswählen
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: WTP change state from RUN to DTLS_TEARDOWN
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: result 0
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: nl_recvmsgs 0
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Netlink Ack
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Kmod sendrecv
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Kernel module cmd reset
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Reset kernel session
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Stop EV_IO on socket 27
2021-09-27,19:35:38,Information,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Retransmition request packet timeout
2021-09-27,19:35:35,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Retransmition request packet
2021-09-27,19:35:32,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Retransmition request packet
2021-09-27,19:35:30,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a hostapd: RX ctrl_iface - hexdump(len=8): 57 50 41 5f 53 54 41 54
2021-09-27,19:35:30,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a hostapd: RX ctrl_iface - hexdump(len=8): 57 50 41 5f 53 54 41 54
2021-09-27,19:35:29,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Retransmition request packet
2021-09-27,19:35:26,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Retransmition request packet
2021-09-27,19:35:23,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: send echo mtu [1252] allowed length [1204]
Code: Alles auswählen
2021-09-27,19:35:23,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: send echo mtu [1252] allowed length [1204]
Code: Alles auswählen
2021-09-27,19:35:26,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Retransmition request packet
Code: Alles auswählen
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Kernel module cmd reset
2021-09-27,19:35:38,Debug,lx-6400-lab-xxxxxx.xx.tld.org,daemon,LX-6400-LAB,d9:1a capwap[1722]: Reset kernel session
Das passierte im Test im LAB unter Last ca. alle 10 Minuten.
In der Produktiv Installation hängen die APS an verschiedenen Switches, teils auch über DSL / VPN angebunden.
Das Verhalten ist überall gleich.
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Ich habe seit gestern Nacht ein ähnliches Problem. Hier ist ein vRouter von 10.42.0473RU3 auf 10.50.0235RU1 aktualisiert worden und die APs vom Typ LX-600 und LX-6402 von 5.34.0010Rel auf 5.34.0027SU1.
Das Update klappte problemlos und die APs waren am WLC angemeldet. Heute Morgen waren einige der APs, nicht alle, im LAN Monitor als fehlend markiert. Ich konnte sie aber noch direkt ansprechen und habe die Firmware auf den alten Stand gebracht (5.34.0010Rel erneut hochgeladen). Da haben sich die APs direkt wieder verbunden. Vor meinem Update liefen die Verbindungen mit dem alten Firmwarestand absolut problemlos.
Im Protokoll des vRouter habe ich dann gesehen, das er wohl seit heute morgen, als sich die ganzen Geräte wieder am Wlan angemeldet haben, öfters einen Reboot gemacht hat (alle 30-45 Minuten). Das würde zu dem gemeldeten Lastproblem passen.
System boot after LCOS-Watchdog
Jetzt läuft der Controller nach einem Rollback wieder mit 10.42.0473RU3 / 13.04.2021 stabil
Andere ältere Accesspoint mit Firmware 10.34.x waren nicht betroffen.
Ich sitze jetzt hier und beobachte was mit den anderen APs passiert, die noch die neue Firmware drin haben. Ein Muster kann ich noch nicht entdecken und so tief in der Materie stecke ich nicht drin, das ich da jetzt so umfangreich debuggen könnte. Irgendetwas ist aber faul und ich warte auf böse Anrufe vom Kunden.
Gruß Andreas
Das Update klappte problemlos und die APs waren am WLC angemeldet. Heute Morgen waren einige der APs, nicht alle, im LAN Monitor als fehlend markiert. Ich konnte sie aber noch direkt ansprechen und habe die Firmware auf den alten Stand gebracht (5.34.0010Rel erneut hochgeladen). Da haben sich die APs direkt wieder verbunden. Vor meinem Update liefen die Verbindungen mit dem alten Firmwarestand absolut problemlos.
Im Protokoll des vRouter habe ich dann gesehen, das er wohl seit heute morgen, als sich die ganzen Geräte wieder am Wlan angemeldet haben, öfters einen Reboot gemacht hat (alle 30-45 Minuten). Das würde zu dem gemeldeten Lastproblem passen.
System boot after LCOS-Watchdog
Jetzt läuft der Controller nach einem Rollback wieder mit 10.42.0473RU3 / 13.04.2021 stabil
Andere ältere Accesspoint mit Firmware 10.34.x waren nicht betroffen.
Ich sitze jetzt hier und beobachte was mit den anderen APs passiert, die noch die neue Firmware drin haben. Ein Muster kann ich noch nicht entdecken und so tief in der Materie stecke ich nicht drin, das ich da jetzt so umfangreich debuggen könnte. Irgendetwas ist aber faul und ich warte auf böse Anrufe vom Kunden.
Gruß Andreas
Re: WLC-1000 und LX-6400 Instabilität
Hi Andreas,
Hintergrund: Es gab ab der 10.40 bis zur v10.42.0473-ru3 einen Bug, der mit v10.42.0611-ru4 gefixt wurde.
v10.42.0612-ru5 fixte noch einen HTTPS Script Upload Error.
Viele Grüße
ts
Na das ist ja interessant...Wäre es Dir möglich, auf dem WLC /vRouter Firmware v10.42.0612-ru5 zu testen?Jetzt läuft der Controller nach einem Rollback wieder mit 10.42.0473RU3 / 13.04.2021 stabil
Hintergrund: Es gab ab der 10.40 bis zur v10.42.0473-ru3 einen Bug, der mit v10.42.0611-ru4 gefixt wurde.
Das hatten wir Lancom gemeldet und deshalb auch erst die v10.42.0611-ru4 auf dem WLC eingesetzt.Mit dem Konsolenbefehl ‚passwd -n‘ kann eine Passwortänderung ohne Abfrage durchgeführt werden. Dabei
wurde die Änderung nicht für den SNMP-Zugriff übernommen, sodass ein SNMP-Zugriff mit dem alten Passwort
möglich war.
v10.42.0612-ru5 fixte noch einen HTTPS Script Upload Error.
Bei und laufen LCOS APs problemlos, jetzt gerade mit Firmware v10.42.0740-ru6.Andere ältere Accesspoint mit Firmware 10.34.x waren nicht betroffen.
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Hallo,
der vRouter (virtuelle Maschine unter ESXi) ist ein Produktiv System mit ~150 APs ... Da ist es für mich schwierig einen Test mit einer anderen Firmware zu machen. Ich werde aber die Firmware mal bereit legen und möglicherweise am Sonnabend einen Test machen. Da sind nicht so viele Geräte unterwegs. Sicher ist es aber noch nicht. Ich werde berichten wenn ich es ausprobieren konnte.
Gruß Andreas
PS: ich sehe, das es bereits einen LCOS, Version 10.42 RU6 gibt ...
der vRouter (virtuelle Maschine unter ESXi) ist ein Produktiv System mit ~150 APs ... Da ist es für mich schwierig einen Test mit einer anderen Firmware zu machen. Ich werde aber die Firmware mal bereit legen und möglicherweise am Sonnabend einen Test machen. Da sind nicht so viele Geräte unterwegs. Sicher ist es aber noch nicht. Ich werde berichten wenn ich es ausprobieren konnte.
Gruß Andreas
PS: ich sehe, das es bereits einen LCOS, Version 10.42 RU6 gibt ...
Re: WLC-1000 und LX-6400 Instabilität
Hi Andreas,
das wäre cool. Ich habe hier 50 LX-6400, weitere 50 kommen gerade dazu, also ähnliche Größenordnung.
Auf dem WLC-1000 habe ich auch schon die v10.42.0740-ru6, die LC-6400 haben gerade einen Test Build vom Support bekommen...
So richtig besser ist es damit nicht.
Viele Grüße
ts
das wäre cool. Ich habe hier 50 LX-6400, weitere 50 kommen gerade dazu, also ähnliche Größenordnung.
Auf dem WLC-1000 habe ich auch schon die v10.42.0740-ru6, die LC-6400 haben gerade einen Test Build vom Support bekommen...
So richtig besser ist es damit nicht.
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
Kurze Rückmeldung:
Bei mir läuft es mit 3x 6400 und 1x LW600 (alle 5.34.0027 SU19) und 1906VA (10.50.0235RU1) als WLC zur Zeit recht gut.
Keine Abbrüche, keine Reboots.
VG
Bei mir läuft es mit 3x 6400 und 1x LW600 (alle 5.34.0027 SU19) und 1906VA (10.50.0235RU1) als WLC zur Zeit recht gut.
Keine Abbrüche, keine Reboots.
VG
... das Netz ist der Computer ...
n* LC und vieles mehr...
n* LC und vieles mehr...
Re: WLC-1000 und LX-6400 Instabilität
Nutzt du WLC Tunnel?
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
Re: WLC-1000 und LX-6400 Instabilität
noch nicht...
mir fehlt noch eine Idee für LEPS über den Tunnel mit Zuweisung eines VLAN am WLC in Richtung LAN
mir fehlt noch eine Idee für LEPS über den Tunnel mit Zuweisung eines VLAN am WLC in Richtung LAN
... das Netz ist der Computer ...
n* LC und vieles mehr...
n* LC und vieles mehr...
Re: WLC-1000 und LX-6400 Instabilität
Über LEPS habe ich noch nicht nachgedacht .....mir fehlt noch eine Idee für LEPS über den Tunnel mit Zuweisung eines VLAN am WLC in Richtung LAN
Wollte grad in der Lancom KB nachschauen -> The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Support Portal ist auch down ....
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
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de