Fehler 503 bei Public-Spot nach Upgrade auf 9.0RU1

[HotSpott]

Hallo miteinander,

der Betreff sagt schon fast alles. Ich habe gerade auf meinem WLC-4006 das Upgrade von 8.82.0100RU1 auf 9.00.0212RU1 durchgeführt. Anschließend erschien jedoch beim Aufruf der Willkommens-/Loginseite für Public-Spot-Benutzer eine Fehlerseite mit Fehlercode 503.

Nach einem Downgrade auf 8.82.0100RU1 und Einspielen der vor dem Upgrade gesicherten Konfiguration läuft es nun wieder.

Hat jemand eine Idee, wie ich hier weiterkommen könnte? Die Willkommensseite ist nicht personalisiert.

Vielen Dank und viele Grüße,
HotSpott

[MariusP]

Hi,
Hast du ein Screenshot vom Fehlerfall?
Gruß

[HotSpott]

Hallo,

habe ich leider nicht. Aber das war nur eine Standard-Fehlerseite vom Lancom generiert für den HTTP-Statuscode 503 (Dienst nicht verfügbar). Wenn man eine nicht verfügbare Seite aufruft wie http://wlan-controller.intern/gibtsnicht bekommt man auch so eine Seite, nur mit Code 404.

Viele Grüße,
HotSpott

[MariusP]

Hi,
weist du denn ob der Fehler auch mit der 9.0 Release auftrat?
Sonst wird es schwer für mich zu suchen ob Lancom schon über diesen "Bug" bescheid weis.
Da du ein paar Releases übersprungen hast.

Wenn du möchtest kannst du entweder Lancom offiziell den Bug übermitteln.
Oder du testest erstmal aus ab welcher FW das Problem auftritt.
ftp://ftp.lancom.de/LANCOM-Archive/LC-WLC-4006/
Da zwischen der 8.82 und der 9.0 ca 1 Jahr liegt und das ist mir etwas zu aufwändig alle PublicSpot-Bugs zu durchsuchen.
Gruß

[maiki]

Hallo HotSpott,

das Public Spot Modul kann Gegenstellen überwachen.

Was steht bei Dir unter:
Konfiguration->Public-Spot->Server->Gegenstelle im Lanconfig ?

Im Zweifelsfall den Eintrag einfach auch leer setzten.

Grüße

Maik

[HotSpott]

Hallo MariusP und maiki,

erst mal vielen Dank für Eure Unterstützung! Ich habe jetzt schrittweise die Firmware aktualisiert.

1. Schritt: von 8.82.0100-RU1 auf 8.84.0193-RU3: OK
2. Schritt: von 8.84.0193-RU3 auf 9.00.0197-Rel: OK
3. Schritt: von 9.00.0197-Rel auf 9.00.0212-RU1: Fehler 503

Das Problem tritt bei mir also erst mit der neuesten Version auf. Vielleicht wirklich ein Bug? Einen Screenshot habe ich diesmal gemacht und hier angehängt.

Ich bin also zurück auf die 9.00.0197-Rel, musste jedoch feststellen, dass die APs den Controller nicht mehr finden wollten. Ein Trace auf CAPWAP-CTRL zeigte ständige "Denying new connection due to high CPU load"-Meldungen. Und tatsächlich, der LANMonitor zeigte 99% CPU-Last an.

Jetzt bin ich wieder auf die 8.82.0100-RU1 zurück. Es funktioniert soweit alles (kein Fehler 503 und die APs haben sofort wieder den Controller gefunden). Allerdings habe ich jetzt ständig 52% bis 55% CPU-Last. Ich denke, das war vor der ganzen Aktion nicht der Fall.

Diesen Eintrag "Konfiguration->Public-Spot->Server->Gegenstelle" finde ich nicht in LANConfig, bin jetzt aber wieder auf der 8.82. Ist das in einer späteren Version hinzugekommen?

Damit's nicht so schlimm klingt: Lancom-Geräte habe ich schon seit da noch ELSA drauf stand und das ist in der ganzen Zeit das erste Mal, dass ich so ein Fiasko erlebe.

Viele Grüße,
HotSpott

[maiki]

Hi,

diese Funktion ist mit der 8.84 gekommen. Damit kann das Public Spot Modul Gegenstellen (Internetzugänge) überwachen. Falls diese "down" sind, kommt dann halt die Fehlerseite Service nicht verfügbar.

Grüße

Maik

[HotSpott]

Habe mich heute nochmal drangesetzt und zu meiner Freude ist die CPU-Last über Nacht mit der 8.82 wieder auf 2% bis 10% gefallen.

Voller Übermut habe ich daher nochmal auf die 8.84 umgestellt. Die APs haben damit zwar nur zum Teil sofort, aber doch in endlicher Zeit alle den Controller gefunden.

Nur leider ist auch hier die CPU-Last in den erstem Betriebsminuten stetig bis auf 98% geklettert. Ein "show jobs" zeigte 60% Last durch einen der beiden Jobs KG, sowie TT mit 10%. Kann mir jemand sagen, was das für Jobs sind?

Jetzt gerade wo ich das tippe, sinkt nach etwa einer Stunde Betriebszeit die CPU-Last langsam aber stetig wieder. Bei 58% scheint es jetzt stehen zu bleiben. Interessanterweise ist jetzt der andere KG-Job aufgewacht und verursacht auch Last (37% und 15%). Die Latency-Werte der KG-Jobs sind auch viel höher (207257 und 146722) als aller anderen Jobs außer II.

Achja, warum ich überhaupt den Versuch mit der 8.84 gemacht habe: der Eintrag Konfiguration->Public-Spot->Server->Gegenstelle ist leer.

Viele Grüße,
HotSpott

[alf29]

Moin,

KG ist Teil des SSL/TLS-Stacks, in dem laufen die rechenintensiven Operationen einer SSL/TLS-Verbindung. Wenn Du einen Haufen Clients hast, die HTTPS-Verbindungen zu dem Gerät aufbauen (z.B. Public Spot), dann ist das völlig normal. Dazu paßt auch TT, das ist TCP, das HTTPS läuft über TCP.

Gruß Alfred

[HotSpott]

OK, vielen Dank! Da muss ich nur noch überlegen, wie mir das weiterhilft...

Die Lage ist jetzt gerade wieder völlig außer Kontrolle geraten: der WLC hat 100% CPU-Auslastung (die KG-Jobs: 60% und 29%) und es erscheint auf der Public-Spot-Willkommensseite der Fehler 503. Und das mit der Firmware 8.84! Der Fehler 503 hat also wohl doch nichts mit der 9.00.0212-RU1 zu tun, sondern vielleicht mit der CPU-Auslastung?

An einem "Haufen Clients" sollte es eigentlich nicht liegen. Der LANmonitor zeigt 5 aktive, 10 inaktive Public-Spot-Benutzer an. Für die Willkommensseite ich übrigens gar kein HTTPS.

Außer mir selbst dürfte eigentlich niemand den WLC mit HTTPS ansprechen. Wird SSL irgendwie intern verwendet? Vielleicht zwischen WLC und AP?

Viele Grüße,
HotSpott

[Christoph_vW]

Hängt der WLC im Internet? HTTPS für Management über eine öffentliche IP erreichbar?

[Christoph_vW]

Schalte man HTTPS für das Management aus, SSH ist eh die bessere Wahl, da LANconfig das Zertifikat bei SSL nicht prüft.

[HotSpott]

Ja, der WLC hängt im Internet, den verwende ich auch als Router. HTTPS sollte nicht von außen erreichbar sein. Nochmal ausprobiert: nein, ist es nicht.

Jetzt hatte ich aber noch eine Idee: ich hab in die Statistik des Switches geschaut und da gesehen, dass zwei der APs erheblich mehr Traffic verursachen als die anderen. Ich habe diese beiden abgeschaltet (POE off ) und siehe da, nach kurzer Zeit ist die CPU-Last des WLC auf 5% gefallen.

Anschließend Strom wieder angeschaltet: sie melden sich sehr schnell am WLC an und dessen CPU-Last klettert wieder bis auf 100%.

Beide APs wieder aus: erst mal hat sich nichts getan, erst ca. 6 Minuten nachdem der WLC den AP als vermisst meldet, sinkt die CPU-Last.

Tja, stimmt da was mit diesem APs nicht? Sind beides L-305 mit 8.80.0157RU1, wovon ich noch sechs weitere habe.

Christoph_vW: wo soll ich das abschalten? Gerät / Eigenschaften / Protokolle & Logins im LANmonitor?

Viele Grüße,
HotSpott

[alf29]

Außer mir selbst dürfte eigentlich niemand den WLC mit HTTPS ansprechen. Wird SSL irgendwie intern verwendet? Vielleicht zwischen WLC und AP?

'show tls sessions' auf der CLI zeigt Dir an, welche SSL/TLS-Sessions gerade laufen. 'HT' in der Caller-Spalte weist auf HTTPS hin, 'DT' auf DTLS-Verbindungen zwischen einem WLC und gemanagten APs, 'ET' auf EAP/TLS (802.1X im RADIUS-Server), 'RC' auf Telnet/SSL-Sitzungen (z.B. mit dem LANtracer).

Gruß Alfred

[MariusP]

Hi,
Kannst du bitte ein 'show jobs' ausführen während des Fehlerfalls und mir per PM oder ins Forum posten.
Gruß