[doch noch nicht gelöst] WLC-1000 kein SSH Zugriff aus Remote Netzen nach 88 Tagen Laufzeit

[tstimper]

Hallo Forum,

wir haben einen WLC-1000 mit aktuell 160 konfigurierten und davon ca 105 aktiven LX-6400 APs,
dazu noch einige LCOS APs zum Test.

Der WLC lief seit der letzen AP Optionserweiterung, bei der er (unverständlicherweise, was hat sich derjenige, der das spezifiziert hat nur dabei gedacht...(sorry, das musste sein...)) rebootet wurde, 88 Tage durch.

Sei einigen Tagen ist der SSH Zugriff auf den WLC aus Remote Netzen nicht mehr möglich.
Ein testweiser SSH Zugriff von einem Lancom Router im lokalen Netz des WLC funktionierte, führte aber kurz dannach zum Watchdog Reboot
und warf natürlich alle über WLC-Tunnel angebundenen Clients, also alle.... aus dem WLAN.
(Das passierte zum Glück live in der LANCOM Support Session)

Dannach funktionierter der SSH Zugriff vom Remote Netz nochmal kurz, aber seitdem nie wieder.

Der Watchdog passierte bei show Befehlen an der CLI, dummerweise hatten wir dabei das putty log nicht an. Über die WEB GUI kommt man weiter auf den WLC und kann bei Extras auch CLI Befehle ausführen.

Auch Lanconfig Zugriff per HTTPS geht noch, auch die APs sind angemeldet, die Devices sind im WLAN, die Public Spot Funktion ist aktiv und funktioniert.

Die einzige Auffälligkeit ist, das die Anzahl der angelegten Public Spot User bei 2021 steht.
Wir erzeugen die WLAN Voucher für die Public Spot User meist in 100er Batches, dazu greift unser ------ Management System per SSH auf den WLC und macht per CLI Befehle die passenden Änderungen.

Das geht natürlich jetzt auch nicht, da SSH nicht mehr geht.

Die Anzahl der angelegten Public Spot User (User in der internen Radius Tabelle) ist jetzt 2021.
Das heist, beim letzten Voucher Creation lauf haben wir wohl die 2000 überschritten.
Sollte das den WLC stören? Mir ist da keine Grenze bekannt beim WLC-1000.
Und warum geht seit dem kein SSH mehr aus Remote Netzen?
Und warum gibt es beim lokalen SSH Zugriff einen Watchdog?

Hier die Watchdog Daten:

Code: Alles auswählen

09/14/2022 14:07:14  LCOS-Watchdog


Task name = Message-Watchdog  Type=





IOS watchdog - msg timeout in HTTP-Worker (code is stack ptr)





 


Code=0x0e87b870 Thread=0000000107e70138 Task=0000000000000000 Nest=0x00000000





registers follow, m_p_area = 0000000107d33040


 R00=0x000000010343dd74  SP =0x0000000107e73f30  R02=0x0000000107d32cf0  R03=0x0000000107dc60b0 


 R04=0x000000010e87b870  R05=0x00000001051d4d70  R06=0x00000000000000e3  R07=0x0000000000000000 


 R08=0x000000000000000b  R09=0x0000000000000000  R10=0x0000000107dc60f1  R11=0x000000000000000b 


 R12=0x0000000040000224  R13=0x0000000107d40000  R14=0x0000000000000000  R15=0x0000000000000000 


 R16=0x0000000000000000  R17=0x0000000000000000  R18=0x0000000000000000  R19=0x0000000000000000 


 R20=0x0000000000000000  R21=0x0000000000000000  R22=0x0000000000000000  R23=0x0000000000000000 


 R24=0x0000000111629398  R25=0x0000000115671998  R26=0x0000000107e630f0  R27=0x0000000107dc6088 


 R28=0x0000000107dc6060  R29=0x0000000107dc6118  R30=0x000000010e8600b8  R31=0x0000000107dc60b0 





 CR  =0x0000000020000222  XER =0x0000000020000000  LR  =0x000000010343dd90  CTR =0x0000000104555a40 


 ESR =0x0000000000000000  DEAR=0x000000010040e004  HID0=0x0000000080000000  HID1=0x0000000000000000 


 MCSR=0x0000000000000000  PID0=0x0000000000000002  PID1=0x0000000000000000  PID2=0x0000000000000000 


 MAS0=0x0000000000014002  MAS1=0x0000000080020100  MAS2=0x000000010040e008  MAS3=0x000000000040e00f 


 MAS4=0x0000000000000100  MAS6=0x0000000000020000  MAS7=0x0000000000000001  MAS8=0x0000000000000000 


 MCTR=0x0000000000000000  SPR0=0x0000000107d332c0  SPR1=0x000000000000000b  SPR2=0x00000001051d4d70 


 SPR3=0x000000010e87b870  SPR4=0x0000000109dad998  SPR5=0x0000000000000000  SPR6=0x0000000000000000 


 SPR7=0x0000000000000000  SPR8=0x0000000000000000  SPR9=0x0000000000000000 


 MCAR   =0x0000000000000000:0000000000000000 


 SRR0(PC) =0x0000000000000000 


 SRR1(MSR)=0x0000000080029202 





 possible error location lcos/ios/common.src/IosMessageWatchDog.cpp : 227





 possible error location: [BT] 000000010343dd90 000000010343df20 00000001044e839c 00000001044e8598 000000010343dfb4 00000001044efb20 00000001044ef96c 00000001045029fc 0000000103434080





Memory dump (1024 bytes):


Adr:= 000000010e87b870


Len:= 0000000000000400


000000010E87B870:  00 00 00 01 0E 87 BA 50  00 00 00 00 00 00 53 00 | .......P ......S.

(Rest vom Memory Dump gelöscht, kommt auf Anfrage per PN)


largest available memory block: 1073741824 bytes








DEVICE:                LANCOM WLC-1000


HW-RELEASE:            B


VERSION:               10.42.0889RU7 / 06.04.2022





****





09/14/2022 14:07:28  System boot after LCOS-Watchdog





DEVICE:                LANCOM WLC-1000


HW-RELEASE:            B


VERSION:               10.42.0889RU7 / 06.04.2022





****

Hat hier die Radius Tabelle einen Überlauf?
An den SSH Keys kanns auch nicht liegen, lokal geht ja SSH.

Alle Firewalls zeigen, das die Remote SSH Pakete bis zum WLC kommen.

Wer kann da helfen vom LCOS Team ? Lancom Case ist seit gestern offen, aber noch keine Lösung.

Hat jemand was ähnlich Merkwürdiges erlebt und wenn ja wie konnte er das fixen?

Vielen Dank und Grüße

ts

[tstimper]

Update:

Wir sind einer Lösung näher gekommen, vielen Dank an den Lancom Support

Unser ------ liest die Config des WLC aus bzw. ergänzt Public Spot Radius User und erzeugt schöne Kunden WLAN Voucher mit Logo und QR-Code.
Die Konfiguration passiert im Hintergrund per SSH auf der CLI des WLC.
Dabei kommen letzendlich immer 24 Zeilen (die Standard Screen- Height aus /Setup/Config/Screen-Height) angeflogen.
Wenn nun aber die config sehr viele Zeilen hat, bei uns sind es mittlerweise ca 67000, hat ------ die Zeilen nicht mehr entgegen genommen.
Diesen Zustand hatten wir ab ca. 2000 eingetragenen Public Spot Usern im WLC.
Die Folge war, das die SSH Session hing und dannach keine weitere SSH Session aufgebaut wurde.
So wie es aussieht beendet LCOS eine solche hängende Session in der größten Not dann eben irgendwann mit einem Watchdog.
Merkwürdigerweise auch z.B. im HTTP Stack.

Zumindest wissen wir jetzt, wie wir das Problem bei großen Configs umschiffen können.

Viele Grüße

ts

[tstimper]

Das Problem ist gelöst, vielen Dank an den Lancom Support und die Programmierer.

Der Pufferspeicher in der Paramiko Python SSH Library, die wir nutzen, um per SSH auf den WLC zuzugreifen,
ist standardmäßig nur 2 MB groß. Bei Lancom Konfigs über 2 MB konnte der Puffer voll laufen, bevor wir ihn leeren konnten.
Dann hing die SSH Session.

Wir haben unser Programm angepasst, das künftig keine SSH Session Kanäle mehr hängen können, auch wenn mehr as 2 MB Daten kommen.

Viele Grüße

ts

[mh1]

Das Problem ist gelöst, vielen Dank an den Lancom Support und die Programmierer.

Der Pufferspeicher in der Paramiko Python SSH Library, die wir nutzen, um per SSH auf den WLC zuzugreifen,
ist standardmäßig nur 2 MB groß. Bei Lancom Konfigs über 2 MB konnte der Puffer voll laufen, bevor wir ihn leeren konnten.
Dann hing die SSH Session.

Wir haben unser Programm angepasst, das künftig keine SSH Session Kanäle mehr hängen können, auch wenn mehr as 2 MB Daten kommen.

Viele Grüße

ts

Das mit dem Pufferspeicher ist ja sehr interessant!
Danke fürs Posten der Lösung

[tstimper]

Das mit dem Pufferspeicher ist ja sehr interessant!
Danke fürs Posten der Lösung

Gerne, nur das bringt uns weiter ....

Das Thema ist allerdings doch noch nicht ganz ausgestanden, auf dem Kunden Server geht unsere neue ------ Version wieder nicht.
Oder es liegt wieder an "Was Auch Immer", vermutlich doch irgendwie doch an der Datenmeng?

Zumindest geht der SSH Zugriff weiterhin, das Blockieren ist weg, das mit denn 88 Tagen war Zufall

Wenn es endgültig gelöst ist, poste ich es.

Viele Grüße

ts