Hallo,
ich habe in einer Public-Spot Installation ein Problem auf das ich nicht so recht eine Lösung weiss
Immer wieder kommen Gäste deren Voucher defakto gültig ist, d.h. die Zeiten Stimmen und es ist auch in der Radius Tabell noch drin, aber ein Einloggen ist damit nicht möglich.
Etwas Background: Der Hotspot besteht aus mehreren AP´s die am Lan Kabel hängen. Jeder Ap hat die Public-Spot Option drauf und einer der AP´s ist der Master an dem die Voucher erstellt werden und der von den anderen abgefragt wird, dort wid auch der LC interne Radius benutzt.
Einige AP´s sind etwas abgesetzt installiert - die werden über eine P2P Funkstrecke versorgt. Die P2P Strecke läuft auf 5 GHz und ist auch ausreichend flott - so das ich das mal Fehlerquelle ausschliesse.
Die AP´s senden Syslogmeldungen an einen Protokollrechner, da sehe ich wie die Loginversuche rejected werden. Das einzige was mit auffällt ist - dass WENN rejected wird - der Radius sich auch nicht vom Gegenteil überzeugen lässt. d.H. nur ein neues Voucher hilft dann weiter.
ARP-Behandlung ist EIN
WLAN ist auf 802.11g limitiert
Alle AP´s laufen auf unterschiedlichen Kanälen, sie SID ist gleich
Es gibt 3 SSID auf jedem AP
Kein Datenverkehr zwischen den Mobilstationen
Stationsüberwachung ist EIN
Roming über INTRANET ist aktiv und funktioniert auch
WLAN Idle Timeout steht auf 600
Die Leerlaufzeitüberschreitung im Puplic-Spot ist auf 540 Sekunden gestellt
Der Accounting Updatezyklus steht auf 60 Sekunden
Es wird nur der Radius Server im zentralen AP genutzt der auch die Voucher druckt.
Im LCOS Bereich Radius sind 2 Optionen drin, Auth-Timeout = 5000 und Auth-Wiederholungen = 3, könnte es damit zusammenhängen? Da sind die Default Werte. Eventuell sind die zu knapp? Kann das sein ?
Voucher Benutzername ungültig
Moderator: Lancom-Systems Moderatoren
Voucher Benutzername ungültig
Pengiun
Moin,
da wäre ein RADIUS-Server-Trace mal der erste Ansatz. Ein gängiges Problem ist, daß
der RADIUS-Server meint, daß eine Session dieses Benutzers noch läuft, weil irgendwo
ein Accounting-Stop verloren gegengen ist und für diesen Account Mehrfach-Logins nicht
erlaubt sind.
Gruß Alfred
da wäre ein RADIUS-Server-Trace mal der erste Ansatz. Ein gängiges Problem ist, daß
der RADIUS-Server meint, daß eine Session dieses Benutzers noch läuft, weil irgendwo
ein Accounting-Stop verloren gegengen ist und für diesen Account Mehrfach-Logins nicht
erlaubt sind.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Hallo Alf,
bist mal wieder der schnellste;=)
Ich hab gestern noch nen Radius Trace aufgemacht und bis jetzt laufen lassen. Aber wie immer, ist man erstmal beim Zahnarzt dann tut es nicht mehr weh;=) - sprich im Moment rennt alles tadellos.
Ich hab allerdings Gestern an 2 Werten etwas gespielt - vielleicht liegt es ja auch daran. Ich bin bei den Radius Wiederholungen der Authentifizierung von 3 auf 30 gegangen und bei der Leerlaugzeitüberschreitung im PS von 120 auf 540.
Ich mach jetzt noch einen Radius-Client Trace auf die Access-Points. Die 3/30 wirken sich ja nur am Client aus der das weiterleitet. Gestern waren zumindest bei einem flüchtigen Blick keine Retries bei den Anfragen drin.
Die Server Meldungen sind alle wie es sein soll. LOGIN / neue Session, Interim-Updates und und ENDE. Wenn man ein Warining mit einem Recejt kommt dann nur weil der Voucher vor einigen Minuten über die Tabellenpflege gelöscht wurde.
Ich bin alle Warnings durchgegangen und da war nix komisches drin.
Abgesehen von den den Versuchen die Mehrfachanmeldungs-Sperre durch Hartnäckigkeit zu übergehen;=)
Wie neulich ein Kollege mal meinte - wie soll ich es dem aufgebrachten Gast nur sagen: Das WLAN muss man im Notebook schon einschalten, sonst geht es nicht;=)
bist mal wieder der schnellste;=)
Ich hab gestern noch nen Radius Trace aufgemacht und bis jetzt laufen lassen. Aber wie immer, ist man erstmal beim Zahnarzt dann tut es nicht mehr weh;=) - sprich im Moment rennt alles tadellos.
Ich hab allerdings Gestern an 2 Werten etwas gespielt - vielleicht liegt es ja auch daran. Ich bin bei den Radius Wiederholungen der Authentifizierung von 3 auf 30 gegangen und bei der Leerlaugzeitüberschreitung im PS von 120 auf 540.
Ich mach jetzt noch einen Radius-Client Trace auf die Access-Points. Die 3/30 wirken sich ja nur am Client aus der das weiterleitet. Gestern waren zumindest bei einem flüchtigen Blick keine Retries bei den Anfragen drin.
Die Server Meldungen sind alle wie es sein soll. LOGIN / neue Session, Interim-Updates und und ENDE. Wenn man ein Warining mit einem Recejt kommt dann nur weil der Voucher vor einigen Minuten über die Tabellenpflege gelöscht wurde.
Ich bin alle Warnings durchgegangen und da war nix komisches drin.
Abgesehen von den den Versuchen die Mehrfachanmeldungs-Sperre durch Hartnäckigkeit zu übergehen;=)
Wie neulich ein Kollege mal meinte - wie soll ich es dem aufgebrachten Gast nur sagen: Das WLAN muss man im Notebook schon einschalten, sonst geht es nicht;=)
Pengiun