SA query failed

Forum zu den aktuellen LANCOM Wireless Accesspoint Serien

Moderator: Lancom-Systems Moderatoren

Antworten
pherbert
Beiträge: 29
Registriert: 10 Jan 2012, 22:20
Wohnort: Alfter

SA query failed

Beitrag von pherbert »

Hallo,

was bedeutet diese Meldung ?

PACKET Alarm: Dst 172.26.0.104:11700, Src: 172.26.0.25:1813 connection refused
CONN-LOGIN Notice: disassciated wlan station 4c:32:75:xx:xx:xx due to supervision: SA query failed

Wlan Clients (ios) sind immer wieder offline.
Hängen die beiden Meldungen im Syslog zusammen ? Timestamp ist jedenfalls gleich.

Warum sollte der AP eine Anwort vom Radius ablehnen. (172.26.0.25 ist der Radius)

Vielen Dank, Philip Herbert
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: SA query failed

Beitrag von alf29 »

Moin,

das sind eine ganze Menge Punkte, die nicht unbedingt zusammenhängen und die sich ohne nähere Begleitumstände auch kaum nachvollziehen lassen. Was ich dazu sagen kann:

Du hast auf dem AP 802.11w (Protected Management Frames) eingeschaltet. In dieser Erweiterung sind eine Reihe von Maßnahmen enthalten, die verhindern sollen, daß ein Angreifer eine Verbindung durch gefakte Management-Frames stört. Die in der Meldung erwähnte SA Queries gehören zu diesen Maßnahmen. Wenn zum Beispiel ein AP der Meinung ist, daß ein bestimmter Client bei ihm noch angemeldet ist, und er erhält von diesem Client einen Association Request (d.h. der Client will sich erneut anmelden), dann weiß er erstmal nicht, ob dieser Request authentisch ist (d.h. der Client meint die Verbindung verloren zu haben) oder eine Fälschung von einem Angreifer ist. Er schickt in dem Fall ein verschlüsseltes Paket (eben diesen SA Query) an den Client. Antwortet der Client darauf (nur der echte Client ist im Besitz der Session Keys und kann ihn beantworten), dann war der Association Request gefälscht und wird ignoriert. Ist der Client wirklich "weg", dann bekommt der AP keine Antwort und beendet die laufende Verbindung, damit der Client sich neu anmelden kann. Das ist letzten Endes das, was die zweite Meldung aussagt.

Falls Du RADIUS-Accounting anhast, dann löst das Beenden der alten Session einen Accounting-Stop Richtung RADIUS-Server aus, Zumindest der UDP-Port 1813 spricht dafür, daß Du RADIUS-Accounting nutzt ;-) Warum die Antwort abgelehnt wird, darüber kann ich nur spekulieren. Steht der RADIUS-Server nicht im gleichen LAN und ist nur mit einer vergleichsweise hohen Latenz erreichbar? Dann kann es sein, daß das LANCOM den Accounting-Stop schon einmal wiederholt hat, bevor die Bestätigung vom RADIUS-Server ankommt. Wenn der RADIUS-Server auf die Wiederholung antwortet, dann ist aus Sicht des LANCOM der Request schon abgeschlossen und der entsprechende UDP-Listener-Port schon wieder geschlossen.

Was "WLAN-Client offline" bedeutet, darüber kann ich nur spekulieren...um irgendwelche Probleme zu untersuchen, müßte man erstmal sortieren, ob der Client in der Situation

(a) überhaupt eine WLAN-Verbindung hat (im AP als 'verbunden' geführt)
(b) eine IP-Adresse erhalten hat
(c) übers Gateway ins Internat heraus kommt

Je nachdem was fehlt, müßte man an ganz unterschiedlichen Stellen suchen. Und ja, ich weiß, gerade Apple-Client s sind nicht besonders gut, was aussagekräftige Fehlermeldungen angeht :-(

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
pherbert
Beiträge: 29
Registriert: 10 Jan 2012, 22:20
Wohnort: Alfter

Re: SA query failed

Beitrag von pherbert »

Hallo Alfred,

vielen Dank für die ausführliche Antwort. Das hilft mir zumindest etwas zu verstehen, wie ich hier weiter suchen kann.

Protected Management Frames stehen seit einiger Zeit auf optional (waren früher aus), in einigen Hallen gibt es keine oder sehr wenig Probleme mit Ipads ohne Verbindung (die Geräte laufen im Dauerbetrieb).

In einer von 5 Hallen 'verlieren' die Geräte die WLAN Verbindung, diese kann einfach (sobald der Kiosk Mode beendet ist) durch Auswahl des WLANs wieder hergestellt werden.

Es gibt sowohl Disconnects 'Lost Carrier' im Radius Log, als auch 'User Request' bzw. NAS Request (durch Band Steering).

Warum auch immer verbinden sich die Geräte nicht mehr automatisch.
Verlagert man ein solches Gerät in eine andere Halle (anderer Standort, gleicher AP Typ, gleiche Firmware) funktioniert das Gerät dort
einwandfrei und verbindet automatisch wieder.

Zum Radius Thema:
ich sehe auf dem Radius in der Tat duplicate requests vom Client, diese werden dann vom Radius ignoriert.
Kann man das Intervall ab wann der retransmit vom AP gesendet wird beeinflussen ?
Radius Server stehen in diesem Fall im gleichen VLAN, haben ca. 1-8 requests pro Sekunde zu verarbeiten.

Leider gibt es schon lange beim Radius Accounting das Problem, dass irgendwann keine Alive Meldungen mehr gesendet werden, obwohl der
Client schon stundenlang oder tagelang verbunden ist. Das wäre wirklich super, wenn man das Problem mal wegbekommen könnte.

Ich poste einfach mal einen Logauszug eines solchen Clients, der aktuell noch verbunden ist, aber keine Accouning Meldungen mehr kommen.
Alive 2017-12-19 18:58:41 HW/HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 0 0 1 CONNECT 144 Mbps 802.11g/n
Start 2017-12-19 18:58:40 HW/HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 0 0 1 CONNECT 144 Mbps 802.11g/n
AUTHSUCCESS 2017-12-19 18:58:40 HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 Mittelkreis 0 0 1 LC_ACCESSPOINT PC VLAN-Konfiguration fuer NAS [HCKC5251] und Client [HCKC5591] uebernommen
Stop 2017-12-19 18:55:33 HW/HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 0 0 1 Lost-Carrier CONNECT 144 Mbps 802.11g/n
Alive 2017-12-19 18:52:08 HW/HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 0 0 1 CONNECT 144 Mbps 802.11g/n
Start 2017-12-19 18:52:07 HW/HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 0 0 1 CONNECT 144 Mbps 802.11g/n
AUTHSUCCESS 2017-12-19 18:52:07 HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 Mittelkreis 0 0 1 LC_ACCESSPOINT PC VLAN-Konfiguration fuer NAS [HCKC5251] und Client [HCKC5591] uebernommen
Stop 2017-12-19 18:50:53 HW/HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 0 0 1 Lost-Carrier CONNECT 144 Mbps 802.11g/n
Alive 2017-12-19 14:49:04 HW/HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 0 0 1 CONNECT 144 Mbps 802.11g/n
Start 2017-12-19 14:49:03 HW/HCKC5591 EC-AD-B8-xx-xx-xx Wireless-IEEE-802-11 HCKC5251 0 0 1 CONNECT 144 Mbps 802.11g/n


---Philip
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: SA query failed

Beitrag von alf29 »

Moin,
Kann man das Intervall ab wann der retransmit vom AP gesendet wird beeinflussen ?
Auf der CLI unter Setup/RADIUS/Auth.-Timeout. Ob und wenn ja wo das im LANconfig abgebildet ist, weiß ich aktuell nicht.
Leider gibt es schon lange beim Radius Accounting das Problem, dass irgendwann keine Alive Meldungen mehr gesendet werden, obwohl der
Client schon stundenlang oder tagelang verbunden ist. Das wäre wirklich super, wenn man das Problem mal wegbekommen könnte.
Also von so einem Problem höre ich zum allerersten Mal. Hattest Du das dem Support gemeldet?
Ich poste einfach mal einen Logauszug eines solchen Clients, der aktuell noch verbunden ist, aber keine Accouning Meldungen mehr kommen.
Da sehe ich genau einen Interim-Update kurz nach dem Connect, der (vermutlich) dadurch ausgelöst wird, daß der AP die IP-Adresse des Clients ermittelt hat. Danach aber gar keine Updates mehr, so als wären sie nicht konfiguriert. Über welchen Weg stellst Du das Interim Intervall ein?

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
pherbert
Beiträge: 29
Registriert: 10 Jan 2012, 22:20
Wohnort: Alfter

Re: SA query failed

Beitrag von pherbert »

Hallo Alfred,

das Thema LC Accounting Interval ist zumindest z.T nachvollziehbar. Wir hatten kein Intervall im Radius Response mitgesendet, dennoch kamen von eiigen WLAN Stationen
immer mal wieder Alive Meldungen der APs, nicht nur die erste. Warum ist allerdings noch nicht ganz klar.

Nun kommen zumindest die Alive Meldungen regelmaessig.

Zum Thema disconnect sa query failed und den 'verlorenen' IOS Clients:
In diesem Fall nach einem DFS Scan, habe ich aber auch schon ohne diesen Zusammenhang gesehen.


lt syslog des AP:
Authenticated WLAN station, nach 1 Sekunde disassociated wlan station due to supervsion: SA query failed.
Im Radius Accounting wird daraus 'Lost Carrier'. Wäre das dann nicht eigentlich ein 'NAS Request' disconnect ?

2017-12-22 02:03:46;4;5;[WLAN-1] Disassociated WLAN station f4:5c:89:3e:83:05 due to supervision: SA query failed;
2017-12-22 02:03:45;4;5;[WLAN-2] Authenticated WLAN station f4:5c:89:3e:83:05: algorithm is open-system;
2017-12-22 02:00:17;4;5;[WLAN-1] Determined IPv6 address for station f4:5c:89:3e:83:05: fe80::882:90f:1870:c328;
2017-12-22 02:00:17;4;5;[WLAN-1] Determined IPv4 address for station f4:5c:89:3e:83:05: 172.26.6.156;
2017-12-22 02:00:17;4;5;[WLAN-1] Connected WLAN station f4:5c:89:3e:83:05;
2017-12-22 02:00:17;4;5;[WLAN-1] Key handshake with peer f4:5c:89:3e:83:05 successfully completed;
2017-12-22 02:00:17;4;5;[WLAN-1] WLAN station f4:5c:89:3e:83:05 has cached PMK, skip 802.1x;
2017-12-22 02:00:17;4;5;[WLAN-1] Reassociated WLAN station f4:5c:89:3e:83:05;
2017-12-22 02:00:17;4;5;[WLAN-1] Authenticated WLAN station f4:5c:89:3e:83:05: algorithm is open-system;
2017-12-22 02:00:17;4;5;[WLAN-1] Authenticated WLAN station f4:5c:89:3e:83:05: algorithm is open-system;
2017-12-22 02:00:14;0;5;[WLAN-2] Starting DFS channel availability check: channel 60 (5300 MHz);
2017-12-22 02:00:14;0;5;[WLAN-2] Channel change due to manually forced scan;
2017-12-22 01:26:26;0;5;Local time set to 2017-12-22 00:26:26(UTC) received by 172.26.3.200;
2017-12-22 00:26:26;0;5;Local time set to 2017-12-21 23:26:26(UTC) received by 172.26.3.200;
2017-12-21 23:26:26;0;5;Local time set to 2017-12-21 22:26:26(UTC) received by 172.26.3.200;
2017-12-21 22:26:26;0;5;Local time set to 2017-12-21 21:26:26(UTC) received by 172.26.3.200;
2017-12-21 21:51:15;19;1;Dst: 172.26.0.113:9738 {HCKC5269.intern}, Src: 172.26.0.25:1813 (UDP): connection refused;


--Philip Herbert
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: SA query failed

Beitrag von alf29 »

Moin,
das Thema LC Accounting Interval ist zumindest z.T nachvollziehbar. Wir hatten kein Intervall im Radius Response mitgesendet, dennoch kamen von eiigen WLAN Stationen
immer mal wieder Alive Meldungen der APs, nicht nur die erste. Warum ist allerdings noch nicht ganz klar.
Das LANCOM verschickt immer dann einen Interim-Update, wenn es eine neue IP-Adresse des Clients 'gelernt' hat. Das kann auch eine IPv6-Adresse sein, von denen hat ein Client ja mehr als eine und die können sich auch im Betrieb ändern. Das ist unabhängig davon, ob ein Interim-Update-intervall gesetzt wurde oder nicht.
Authenticated WLAN station, nach 1 Sekunde disassociated wlan station due to supervsion: SA query failed.
Das ist genua die Situation bei PMF, die ich oben beschrieben habe. Der Authenticate Request/Response ist ungeschützt (der bedeutet eigentlich auch erst bei 802.11r und Fast Roaming wieder etwas). auf den Associate Request von einem Client, der als bereits angemeldet gilt, wird der SA Query ausgelöst (und dem Client wird gesagt, er möge den Association Request später wiederholen), und wenn geklärt ist, daß der Client nicht mehr da ist, wird die noch auf AP-Seite bestehende Session bzw. Verbindung gelöscht.
Im Radius Accounting wird daraus 'Lost Carrier'. Wäre das dann nicht eigentlich ein 'NAS Request' disconnect ?
Darüber kann man sich jetzt herrlich streiten, insbesondere weil der 802.11-Standard da keine Vorgaben macht. Aus meiner Sicht hat der AP in der Situation eine Verbindung gelöscht, die schon gar nicht mehr bestanden hat, der Client war also eigentlich schon "weg".

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
pherbert
Beiträge: 29
Registriert: 10 Jan 2012, 22:20
Wohnort: Alfter

Re: SA query failed

Beitrag von pherbert »

Bedeutet SA query failed, dass der Client in jedem Fall nicht (mehr) geantwortet hat, oder aber könnte er sich auch einfach fehlerhaft verhalten / falsch geantwortet haben ?

Ich suche irgendwie einen Strohhalm zum Verständnis, warum die iOS Clients immer wieder offline sind.

Könnten derartige Probleme durch Signalstörungen / fremdbelegte WLAN Kanäle (Frequenzüberlagerungen) etc. verursacht werden ?
Das Problem ist scheinbar örtlich beschränkt.


--Danke, Philip
Antworten