HotSpot-Troubleshooting: Unterschied zwischen den Versionen

Version vom 2. Mai 2016, 11:30 Uhr

Diese FAQ beinhaltet Ursachen verschiedener Fehlerbilder eines Hotspot-Szenarios und Tipps zu deren Behebung.

Prinzipielle Funktionsweise des HotSpots

In den meisten Fällen meldet ein User sein Gerät am Gäste-WLAN an und bezieht eine IP-Adresse per DHCP. Anschließend muss im Browser eine beliebige Webseite geöffnet werden. Diesbezügliche DNS-Anfragen werden nur dann zugelassen, wenn diese an die IP-Adresse des Hotspot-Interfaces gerichtet sind. Über das Hotspot-Interface eingehende HTTP-Pakete (TCP/80) fängt der Router ab und leitet diese auf seinen internen HTTP-Dienst um. Der Client bekommt jetzt den Walled Garden (falls konfiguriert), sowie den Login-Frame angezeigt. Nachdem der Client Benutzername/Passwort bzw. Gutscheincode eingegeben und bestätigt hat, übernimmt der Router die Authentifizierung des Clients am externen Hotspot-Server.

Fehlerbild: Anmeldeseite wird nicht angezeigt

Ein angemeldeter WLAN-Client öffnet in seinem Browser eine beliebige Seite im Internet. Somit sollte der Redirect auf die Anmeldeseite des Hotspot-Gateways erfolgen. Sollte dies nicht passieren (z.B. weil der Browser in ein Timeout läuft), liegt das meist an folgenden Ursachen:

Der Client darf über das Hotspot-Interface nicht mit HTTP auf den Localhost des Routers zugreifen.

Zuerst sollte man im Menü "Systemverwaltung" > "Administrativer Zugriff" nachsehen, ob Clients über das Hotspot-Interface auf den Router zugreifen dürfen. Ist der Zugriff über den administrativen Zugriff eingeschränkt, blockt der Router die HTTP-Anfragen der Clients und redirected diese nicht auf seinen internen HTTP Dienst. Eine beispielhafte Debugmeldung sieht so aus:

INFO/INET: refuse TCP packet from if 1300, 192.168.0.1:xxxx->local:80

Folglich entsteht ein Timeout im Browser des Clients. Zusätzlich sollte die Stateful Inspection Firewall überprüft werden, ob dort der Zugriff über das Hotspot-Interface auf den internen HTTP-Dienst erlaubt wird.

Die DNS-Auflösung funktioniert nicht.

In diesem Fall sollte der DNS-Server der Hotspot-Clients auf seine Funktion überprüft werden. Wenn am DNS-Server keine DNS-Anfrage ankam, kann es ein Indiz dafür sein, dass der Client einen Proxy-Server eingetragen hat. Eine weitere Ursache könnte sein, dass im DHCP-Pool des Hotspot-Gateways ein DNS-Server angegeben ist, den der Client nicht direkt erreichen kann (z.B. im öffentlichen Internet).

Der Client ruft die beliebige Internetseite im Browser beginnend mit https:// auf.

Der Aufruf einer Seite mit HTTPS (TCP/443) resultiert in einem Timeout, da der Router nur HTTP-Anfragen (TCP/80) redirected.

Der Client hat keine IP-Adresse über den DHCP-Server des Hotspot-Gateway bezogen.

Im Menü "Lokale Dienste" > "Hotspot-Gateway" > 'Eintrag bearbeiten' > 'Erweiterte Einstellungen' gibt es eine Option, die sich "Zulässiger Hotspot-Client" nennt. Wenn hier "DHCP-Client" ausgewählt wurde, dürfen nur Clients über das Hotspot-Interface kommunizieren, die ihre IP-Adresse über den Hotspot-Gateway bezogen haben. Sollte ein Client eine statische IP-Adresse konfiguriert haben, werden dessen Pakete bereits am Hotspot-Interface geblockt.

Eine beispielhafte Debugmeldung sieht so aus:

INFO/INET: Barring host 192.168.0.2 (ipExtIfAllowedPeers = dhcpclients)

Fehlerbild: Mehrere Anmeldeframes im Walled Garden

Wenn der Client vom Router auf die Anmeldeseite redirected wird, erscheinen mehrere Anmeldeframes nebeneinander:

BILD EINFÜGEN

Grund dafür sind Redirects der Walled Garden URL. Sobald die angegebene Walled Garden URL einen Redirect auf eine andere Webseite beinhaltet (z.B. eine firmenspezifische Facebook Grafik mit Link auf www.facebook.com/firmenname), wird diese URL per DNS aufgelöst und über HTTP angefragt. Diese HTTP-Anfrage wird wiederum vom Hotspot-Gateway auf den Localhost redirected und erzeugt einen erneuten Aufruf der Anmeldeseite, da www.facebook.com nicht als Walled Garden konfiguriert ist.

Um dieses Verhalten zu umgehen, gibt es im Menü Hotspot-Menü die Option "Zusätzliche, frei zugängliche Domänennamen". Hier können Sie Domänennamen oder IP-Adressen jeglicher Seiten eintragen, die für unauthentifizierte Clients frei zugänglich sein sollten.

Sollten die Frames immer noch nebeneinander erscheinen, kann es auch daran liegen, dass die Walled Garden URL (z.B. http://www.bintec.de) komplett auf eine andere URL redirected wird (in diesem Fall auf http://www.bintec-elmeg.com). Es kann auch vorkommen, dass URLs mit vorangestellem "www." in andere IP-Adressen aufgelöst werden als URLs ohne "www.". Da Clients zu guter Letzt die Adresse grundsätzlich mit www. aufrufen, sollte in der Walled Garden URL das "www." mit angegeben werden.

Fehlerbild: Anmeldung der Clients schlägt fehl

Ein Client gibt seine Account-Daten in den Anmeldeframe ein, akzeptiert die AGB und klickt auf "Anmelden". Allerdings bekommt er auf der nächsten Seite den Hinweis "Anmeldung fehlgeschlagen". Dies kann u.A. folgende Gründe haben:

Der Client darf über das Hotspot-Interface nicht mit HTTPS auf den Localhost des Routers zugreifen.

Ähnlich wie bei Fehlerbild 2 sollte man im Menü "Systemverwaltung" > "Administrativer Zugriff" nachsehen, ob Clients mit HTTPS (TCP/443) über das Hotspot-Interface auf den Router zugreifen dürfen. Ist der Zugriff über den administrativen Zugriff eingeschränkt, blockt der Router die HTTPS-Anfragen der Clients, welche dadurch in einen Timeout laufen. Zusätzlich sollte die Stateful Inspection Firewall überprüft werden, ob dort der Zugriff über das Hotspot-Interface auf den internen HTTP-Dienst erlaubt wird.

Es existiert ein dritter RADIUS-Server Eintrag mit dem Typ "Login-Authentifizierung".

Wenn neben den zwei Einträgen des verwendeten Hotspot-RADIUS-Servers ein weiterer Eintrag existiert, der den Authentifizierungstyp "Login-Authentifizierung", die selbe Gruppenbeschreibung (Defaultwert: "Standardgruppe 0"), die selbe Priorität besitzt und nicht aktiv ist, bekommt der Client die Fehlermeldung, dass die Authentifizierung fehl schlägt. Dieses Verhalten äußert sich im Debug des Routers folgendermaßen:

HACC: RADIUS-daemon not ready for processing login-request (192.168.0.1 on ifc 1300)

Der dritte inaktive / veraltete / nicht mehr verwendete RADIUS-Eintrag sollte entweder gelöscht werden oder dessen Gruppenbeschreibung im Falle einer geplanten Verwendung neu angelegt werden.

Der RADIUS-Server-Eintrag ist fehlerhaft konfiguriert.

Wenn z.B. das Passwort für den RADIUS-Server falsch hinterlegt ist, wird dieser Server als "inaktiv" deklariert. Eine beispielhafte Debugmeldung sieht so aus:

NOTICE/RADIUS: server <62.245.165.180:1812> changed state to INACTIVE

Der RADIUS-Server sollte wie folgt konfiguriert werden:

BILD EINFÜGEN

Der Eintrag für den Accounting-Server sollte analog dazu konfiguriert sein.

Ein NAS-Identifier wurde am Hotspot-Server erzeugt und nicht im Hotspot-Gateway eingetragen.

Standardmäßig ist kein NAS-Identifier hinterlegt. Der NAS-Identifier hat den Zweck, Hotspot-Gateways verschiedener Standorte am Hotspot-Server zu unterscheiden. Pro Standort kann z.B. ein NAS-Identifier angegeben werden, welcher ebenfalls im Hotspot-Gateway konfiguriert wird (Option: Host für mehrere Standorte). Wenn der NAS-Identifier am Server nicht mit dem NAS-Identifier des Hotspot-Gateways übereinstimmt, können Clients nicht authentifiziert werden. Auf dem Hotspot-Server findet man den NAS-Identifier in folgendem Menü:

Standort Übersicht -> In der Spalte "Host" -> Übersicht:

BILD EINFÜGEN

Der NAS-Identifier sollte nur dann angelegt werden, wenn Hotspot-Gateways in verschiedene Standorte eingegliedert werden müssen, z.B. wenn jedem Standort eigene Tarife / Accounts zugewiesen werden sollen. Ansonsten sollten keine Einträge in diesem Menü existieren.

Fehlerbild: Angemeldete Clients werden abgemeldet

Hierbei sollte man zwischen zwei Verhalten unterscheiden.

Der Client wird nach einer bestimmten Zeitspanne abgemeldet.

Das kann an der Option "Timeout nach Inaktivität" des Hotspot-Gateways liegen. Standardmäßig beträgt dieser Timeout 600 Sekunden. Das bedeutet, dass ein Client, welcher zehn Minuten lang keinen Datenverkehr erzeugt hat, automatisch vom System abgemeldet wird. Folglich ist eine erneute Authentifizierung notwendig, um wieder Surfen zu können. Ab der Softwareversion 9.1.5 ist dieser Wert über die erweiterten Einstellungen des Hotspot-Gateways konfigurierbar. Nach Möglichkeit sollte diese Option nicht deaktiviert werden, da ansonsten angemeldete Hotspot-Client, die sich nicht selbstständig abgemeldet haben, im System verbleiben bis ein Neustart des Gateways vollzogen wurde. Um interne Ressourcen zu sparen, sollte die Option aktiviert bleiben.

Der Client wird sporadisch abgemeldet.

Wenn ein Client mitten beim Surfen abgemeldet wird, können mehrere Ursachen vorliegen:

1. Pro Account kann immer nur ein einziger Client angemeldet werden (MAC-Adressen-basierend). Wenn sich ein anderer Client mit den selben Anmeldeinformationen anmeldet, wird der bisher angemeldete Client abgemeldet und auf die Anmeldeseite umgeleitet.
2. Das Zeit- bzw. Datenvolumen des zugewiesenen Tarifes ist erschöpft.
3. Die Re-Authentifizierung des Clients am RADIUS-Server schlägt fehl. Standardmäßig re-authentifiziert das Hotspot-Gateway angemeldete Clients alle 5 Minuten am RADIUS-Server. Sollte der RADIUS-Server nicht mehr erreichbar sein, schlägt die Re-Authentifizierung fehl und angemeldete Clients werden abgemeldet.