Waere ja auch zu schoen, wenn alles auf Anhieb gehen wuerde.
Nachdem mein Radius nun brav die accounting-Pakete bekommt, sehe ich wunderbarerweise anhand des Usernamens (arp) die Volumina und Zeiten. Das ist schon mal eine ganze Menge.
Was aber nur sporadisch zum Radius gegeben wir ist die FramedIPAddress. Ich wuerde ja verstehen, wenn sie nie käme, da die Weitergabe nicht unterstuetzt wird.
Vorstellbar ist sicherlich auch, dass bei der WLAN-Anmeldung und dem eventl. ersten Accpacket noch gar keine IP beim Client ist...
Aber warum klappt es dann ab und zu?
Meine Clients sind alle annaehernd gleich konfiguriert und bekommen ihre IP ueber einen DHCP. Bei einigen Anmeldungen erhaelt der Radius die FramedIPAddress bei anderen nicht. Ich kann leider kein Schema erkennen.
Im Bereich von PPP Anmeldungen mit anderen NAS-Geräten loeppt dat seit Jahr und Tag. Es sieht auch nicht nach Packetlosses aus.
Hat jemand schon mal das gleiche beobachtet und evtl. sogar geloest?
Fuer Hilfe immer dankbar,
Norbert
Radius und FramedIPAddress
Moderator: Lancom-Systems Moderatoren
Moin,
da WLAN ein Layer-2-Protokol ist, gibt es keinen 'definierten'
Weg, die IP-Adresse eines WLAN-Clients zu bekommen.
Ein LANCOM-AP ermittelt die IP-Adresse eines Clients
deshalb dadurch, daß er gelegentlich (einmal pro Minute)
in das nächste, von diesem Client empfangene IP-Paket
reinschaut und die dort enthaltene IP-Quelladresse
speichert. Diese ist in der Stationtabelle zu sehen und wird
per RADIUS-Accounting als Framed-IP-Address übertragen,
sofern sie ungleich 0.0.0.0 ist.
Sofern die ermittelte Adresse sich geändert hat, so wird
zum einen ein WLAN-Event 'Determined IP-Address...'
erzeugt (z.B. in der Log-Tabelle oder per Syslog zu sehen),
zum anderen wird bei aktivem RADIUS-Accouting
unmittelbar ein Interim-Update geschickt.
Dabei auftauchende Null-Adressen werden ignoriert -
d.h. wenn Du keine Frame-IP-Adress bekommst, dann heißt
das letzten Endes, daß das LANCOM nie ein verwertbares
IP-Paket von diesem Client bekommen hat, aus dem es
die Adresse hätte ableiten können.
Die einzige Lösung wäre, per WLAN-Trace dem Verhalten
eines solchen Clients nachzuspüren - Unter Setup->WLAN
kann man mit der Trace-MAC den WLAN-Trace auf diesen
Client einschränken.
Gruß Alfred
da WLAN ein Layer-2-Protokol ist, gibt es keinen 'definierten'
Weg, die IP-Adresse eines WLAN-Clients zu bekommen.
Ein LANCOM-AP ermittelt die IP-Adresse eines Clients
deshalb dadurch, daß er gelegentlich (einmal pro Minute)
in das nächste, von diesem Client empfangene IP-Paket
reinschaut und die dort enthaltene IP-Quelladresse
speichert. Diese ist in der Stationtabelle zu sehen und wird
per RADIUS-Accounting als Framed-IP-Address übertragen,
sofern sie ungleich 0.0.0.0 ist.
Sofern die ermittelte Adresse sich geändert hat, so wird
zum einen ein WLAN-Event 'Determined IP-Address...'
erzeugt (z.B. in der Log-Tabelle oder per Syslog zu sehen),
zum anderen wird bei aktivem RADIUS-Accouting
unmittelbar ein Interim-Update geschickt.
Dabei auftauchende Null-Adressen werden ignoriert -
d.h. wenn Du keine Frame-IP-Adress bekommst, dann heißt
das letzten Endes, daß das LANCOM nie ein verwertbares
IP-Paket von diesem Client bekommen hat, aus dem es
die Adresse hätte ableiten können.
Die einzige Lösung wäre, per WLAN-Trace dem Verhalten
eines solchen Clients nachzuspüren - Unter Setup->WLAN
kann man mit der Trace-MAC den WLAN-Trace auf diesen
Client einschränken.
Gruß Alfred
So, ich habe es mal versucht ein wenig zu vertiefen:
Als Beispiel mal ein Fall, bei dem ich nicht mitbekomme welche IP er gehabt hat:
Fri Jan 19 13:07:40 2007
Acct-Status-Type = Start
User-Name = "000a59-f35604"
Calling-Station-Id = "00-0a-59-f3-56-04"
Acct-Session-Id = "000a59f35604-3300707327"
NAS-Identifier = "AP23"
NAS-IP-Address = 213. ...
NAS-Port = 15
Called-Station-Id = "02-0b-6b-37-c6-70:AIR-LC-AP23"
NAS-Port-Type = Wireless-802.11
Client-IP-Address = 213. ...
Acct-Unique-Session-Id = "afa1f8e26fcf655a"
Timestamp = 1169208460
Fri Jan 19 13:08:34 2007
Acct-Status-Type = Stop
User-Name = "000a59-f35604"
Calling-Station-Id = "00-0a-59-f3-56-04"
Acct-Session-Id = "000a59f35604-3300707327"
Acct-Session-Time = 54
Acct-Input-Octets = 35
Acct-Output-Octets = 1104
Acct-Input-Packets = 1
Acct-Output-Packets = 11
Acct-Terminate-Cause = Lost-Carrier
NAS-Identifier = "AP23"
NAS-IP-Address = 213. ...
NAS-Port = 15
Called-Station-Id = "02-0b-6b-37-c6-70:AIR-LC-AP23"
NAS-Port-Type = Wireless-802.11
Client-IP-Address = 213. ...
Acct-Unique-Session-Id = "afa1f8e26fcf655a"
Timestamp = 1169208514
OK, die Session Time ist kurz und die Verbindung offensichtlich brutal zusammengebrochen...
Dies unterstuetz eindeutig Deinen Hinweis, Alfred, wobei Packete ja uebertragen wurden. Sind das dann DHCP Requests?
Vorher und nachher ist aber eine gueltige IP nachvollziehbar und auch uebermittelt. Dann ist mir aufgefallen, dass oft bei Acct-Status-Type = Alive keine Framed-IP-Address uebermittelt wird.
Dies ist gerade bei den Updates die durch meine Freeradiusserver in der DB gemacht werden hinderlich gewesen. Eine evntl bereits uebermittelte und in der DB abgelegt Framed-IP-Address wurde dann duch das Update wieder auf '' gesetzt.
Wenn nun ein STOP ohne IP kommt ist die gesamte Session ohne IP.
Diesem kann man dann aber durch ein IF(... innerhalb des Statements in der SQL.conf vom Freeradius beheben. Seither habe ich auch zuverlaessiger die IPs zu den Sessions.
Auch habe ich den Eindruck, dass die Einstellung unter Wireless/Security "Stationen überwachen" hilft, zuverlaessiger die IP im Datensatz mit zu uebermitteln.
Das kann aber auch reine Einbildung sein
Schoenes Wocheende.
Hier noch mal ein ALIVE Packet:
Die Sessiontime ist ausreichen lange, der Durchsatz aber sehr gering...
Das Stop Packet fehlt mir komplett, ich habe nur ein Startpacket ebenso ohne IP.
Fri Jan 19 00:04:37 2007
Acct-Status-Type = Alive
User-Name = "000a59-f36aea"
Calling-Station-Id = "00-0a-59-f3-6a-ea"
Acct-Session-Id = "000a59f36aea-2047309015"
Acct-Session-Time = 354
Acct-Input-Octets = 1951
Acct-Output-Octets = 910
Acct-Input-Packets = 5
Acct-Output-Packets = 4
NAS-Identifier = "AP26"
NAS-IP-Address = 213. ...
NAS-Port = 1
Called-Station-Id = "02-0b-6b-2a-ff-1c:AIR-LC-AP26-2"
NAS-Port-Type = Wireless-802.11
Client-IP-Address = 213. ...
Acct-Unique-Session-Id = "725b724181316982"
Timestamp = 1169161477
Im Uebrigen habe ich leider Deinen Beitrag erst gelesen nachdem ich diesen hier gepastet hatte, sorry Alfred. Dehalb musste ich noch ein wenig nacheditieren... Meine eigene Bloedheit!
Als Beispiel mal ein Fall, bei dem ich nicht mitbekomme welche IP er gehabt hat:
Fri Jan 19 13:07:40 2007
Acct-Status-Type = Start
User-Name = "000a59-f35604"
Calling-Station-Id = "00-0a-59-f3-56-04"
Acct-Session-Id = "000a59f35604-3300707327"
NAS-Identifier = "AP23"
NAS-IP-Address = 213. ...
NAS-Port = 15
Called-Station-Id = "02-0b-6b-37-c6-70:AIR-LC-AP23"
NAS-Port-Type = Wireless-802.11
Client-IP-Address = 213. ...
Acct-Unique-Session-Id = "afa1f8e26fcf655a"
Timestamp = 1169208460
Fri Jan 19 13:08:34 2007
Acct-Status-Type = Stop
User-Name = "000a59-f35604"
Calling-Station-Id = "00-0a-59-f3-56-04"
Acct-Session-Id = "000a59f35604-3300707327"
Acct-Session-Time = 54
Acct-Input-Octets = 35
Acct-Output-Octets = 1104
Acct-Input-Packets = 1
Acct-Output-Packets = 11
Acct-Terminate-Cause = Lost-Carrier
NAS-Identifier = "AP23"
NAS-IP-Address = 213. ...
NAS-Port = 15
Called-Station-Id = "02-0b-6b-37-c6-70:AIR-LC-AP23"
NAS-Port-Type = Wireless-802.11
Client-IP-Address = 213. ...
Acct-Unique-Session-Id = "afa1f8e26fcf655a"
Timestamp = 1169208514
OK, die Session Time ist kurz und die Verbindung offensichtlich brutal zusammengebrochen...
Dies unterstuetz eindeutig Deinen Hinweis, Alfred, wobei Packete ja uebertragen wurden. Sind das dann DHCP Requests?
Vorher und nachher ist aber eine gueltige IP nachvollziehbar und auch uebermittelt. Dann ist mir aufgefallen, dass oft bei Acct-Status-Type = Alive keine Framed-IP-Address uebermittelt wird.
Dies ist gerade bei den Updates die durch meine Freeradiusserver in der DB gemacht werden hinderlich gewesen. Eine evntl bereits uebermittelte und in der DB abgelegt Framed-IP-Address wurde dann duch das Update wieder auf '' gesetzt.
Wenn nun ein STOP ohne IP kommt ist die gesamte Session ohne IP.
Diesem kann man dann aber durch ein IF(... innerhalb des Statements in der SQL.conf vom Freeradius beheben. Seither habe ich auch zuverlaessiger die IPs zu den Sessions.
Auch habe ich den Eindruck, dass die Einstellung unter Wireless/Security "Stationen überwachen" hilft, zuverlaessiger die IP im Datensatz mit zu uebermitteln.
Das kann aber auch reine Einbildung sein
Schoenes Wocheende.
Hier noch mal ein ALIVE Packet:
Die Sessiontime ist ausreichen lange, der Durchsatz aber sehr gering...
Das Stop Packet fehlt mir komplett, ich habe nur ein Startpacket ebenso ohne IP.
Fri Jan 19 00:04:37 2007
Acct-Status-Type = Alive
User-Name = "000a59-f36aea"
Calling-Station-Id = "00-0a-59-f3-6a-ea"
Acct-Session-Id = "000a59f36aea-2047309015"
Acct-Session-Time = 354
Acct-Input-Octets = 1951
Acct-Output-Octets = 910
Acct-Input-Packets = 5
Acct-Output-Packets = 4
NAS-Identifier = "AP26"
NAS-IP-Address = 213. ...
NAS-Port = 1
Called-Station-Id = "02-0b-6b-2a-ff-1c:AIR-LC-AP26-2"
NAS-Port-Type = Wireless-802.11
Client-IP-Address = 213. ...
Acct-Unique-Session-Id = "725b724181316982"
Timestamp = 1169161477
Im Uebrigen habe ich leider Deinen Beitrag erst gelesen nachdem ich diesen hier gepastet hatte, sorry Alfred. Dehalb musste ich noch ein wenig nacheditieren... Meine eigene Bloedheit!
Moin,
Auszug aus dem Accounting-Stop:
einmal *ein einziges* Paket von 35 Byte empfangen.
Mit 24 Byte WLAN-Header und 8 Byte SNAP-Header
kann das kein IP-Paket gewesen sein, da paßt ja nicht
einmal der IP-Header rein...daß da keine IP-Adresse
ermittelt wurde, wundert mich nicht wirklich.
Es mag sein, daß der Client ein IP-Adresse hatte, entweder
fest konfiguriert oder noch per DHCP in einem früheren
Connect erhalten - aber das kann der AP nicht ermitteln,
so lange er keine Pakete mit dieser (Quell)adresse bekommt.
ein Client seine IP-Adresse während der Session ändern
könnte...
Gruß Alfred
Auszug aus dem Accounting-Stop:
In dieser Session wurde von diesem Client also geradeAcct-Input-Octets = 35
Acct-Input-Packets = 1
einmal *ein einziges* Paket von 35 Byte empfangen.
Mit 24 Byte WLAN-Header und 8 Byte SNAP-Header
kann das kein IP-Paket gewesen sein, da paßt ja nicht
einmal der IP-Header rein...daß da keine IP-Adresse
ermittelt wurde, wundert mich nicht wirklich.
Es mag sein, daß der Client ein IP-Adresse hatte, entweder
fest konfiguriert oder noch per DHCP in einem früheren
Connect erhalten - aber das kann der AP nicht ermitteln,
so lange er keine Pakete mit dieser (Quell)adresse bekommt.
Tja, bei RADIUS hat eben niemand damit gerechnet, daßDies ist gerade bei den Updates die durch meine Freeradiusserver in der DB gemacht werden hinderlich gewesen. Eine evntl bereits uebermittelte und in der DB abgelegt Framed-IP-Address wurde dann duch das Update wieder auf '' gesetzt.
Wenn nun ein STOP ohne IP kommt ist die gesamte Session ohne IP.
Diesem kann man dann aber durch ein IF(... innerhalb des Statements in der SQL.conf vom Freeradius beheben. Seither habe ich auch zuverlaessiger die IPs zu den Sessions.
ein Client seine IP-Adresse während der Session ändern
könnte...
Die IP-Adreßermittlung ist davon unabhängig.Auch habe ich den Eindruck, dass die Einstellung unter Wireless/Security "Stationen überwachen" hilft, zuverlaessiger die IP im Datensatz mit zu uebermitteln.
Gruß Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015