RADIUS Accounting - Abweichungen vom Standard

stefan.winter · Beitrag von **stefan.winter** » 22 Mär 2006, 08:53

Hallo,

nach Aktivierung des RADIUS-Accountings für WPA Netze (super - danke!) sind mir die folgenden Punkte aufgefallen:

Acct-Session-Time ist immer 0, sollte aber die Anzahl der Sekunden die die Verbindung besteht enthalten (betrifft Interim-Update und Stop Pakete). Hiermit wird der Standard verletzt - entweder gar nicht schicken oder mit richtigem Inhalt.

Acct-Terminate-Cause ist bei Stop Paketen nicht enthalten. Ist zwar laut Standard optional, aber eine sehr wertvolle Information - die sollte in keinem Accounting-Paket fehlen.

Diese beiden Information sind schon ziemlich wichtig - da wäre es schön wenn das mal irgendwann implementiert wird. Ansonsten nur noch zwei kleine nitpicks:

NAS-IP-Address und NAS-Identifier sind beide im Paket. Laut Standard darf nur genau eins von beiden vorhanden sein.

Wenn schon Acct-(Input|Output)-Octets gezählt werden, dann könnte man auch gleich Acct-(Input|Output)-Packets zählen und mitschicken.

Grüße,

Stefan Winter

alf29 · Beitrag von **alf29** » 22 Mär 2006, 09:30

Moin,

Acct-Session-Time ist immer 0, sollte aber die Anzahl der Sekunden die die Verbindung besteht enthalten (betrifft Interim-Update und Stop Pakete). Hiermit wird der Standard verletzt - entweder gar nicht schicken oder mit richtigem Inhalt.

Kann ich hier nicht nachvollziehen. Bitte beachten, daß
der Wert aus der Assoc-Time in der Stationstabelle
abgeleitet wird und damit nur im Minutenrhythmus
aktualisiert wird - man muß also mindestens eine
Minute warten, bis etwas ungleich Null kommt.

Acct-Terminate-Cause ist bei Stop Paketen nicht enthalten. Ist zwar laut Standard optional, aber eine sehr wertvolle Information - die sollte in keinem Accounting-Paket fehlen.

Leider können nicht alle Gründe, aus denen eine
Assoziierung bei WLAN beendet wird, auf einen der
in RADIUS definierten Causes gemappt werden.
Momentan wird eine zugeschlagene Stationsüberwachung
(Client nicht mehr erreichbar) auf Lost Carrier gemappt
und eine Abmeldung des Clients per Deauthenticate oder
Diasassociate auf User-Request - alle anderen nicht.
Dafür könnte ich etwas a la 'unknown' reinschreiben, aber
wem würde das etwas nützen?

NAS-IP-Address und NAS-Identifier sind beide im Paket. Laut Standard darf nur genau eins von beiden vorhanden sein.

Zitat aus RFC2866:

Either NAS-IP-Address or NAS-Identifier MUST be present in a
RADIUS Accounting-Request.

Das lese ich so, daß *mindestens* eines der beiden
Attribute enthalten sein muß - ich lese daraus aber kein
Verbot, daß nicht beide gleichzeitig enthalten sein
dürfen. Wir haben auch schon bei Public Spot beide
Attribute reingeschrieben, und je nach Kunde wird mal
das eine oder das andere genutzt.

Wenn schon Acct-(Input|Output)-Octets gezählt werden, dann könnte man auch gleich Acct-(Input|Output)-Packets zählen und mitschicken.

Die werden im Moment im WLAN überhaupt nicht gezählt,
deshalb kann ich die auch nicht liefern.

Gruß Alfred

stefan.winter · Beitrag von **stefan.winter** » 22 Mär 2006, 09:46

alf29 hat geschrieben:
Acct-Session-Time ist immer 0, sollte aber die Anzahl der Sekunden die die Verbindung besteht enthalten (betrifft Interim-Update und Stop Pakete). Hiermit wird der Standard verletzt - entweder gar nicht schicken oder mit richtigem Inhalt.
Kann ich hier nicht nachvollziehen. Bitte beachten, daß
der Wert aus der Assoc-Time in der Stationstabelle
abgeleitet wird und damit nur im Minutenrhythmus
aktualisiert wird - man muß also mindestens eine
Minute warten, bis etwas ungleich Null kommt.

Ah. Zwar nicht gerade das, was ich erwartet habe, aber ok. Das heisst aber auch, dass immer nur vielfache von 60 in diesem Counter drinstehen?

alf29 hat geschrieben:
Acct-Terminate-Cause ist bei Stop Paketen nicht enthalten. Ist zwar laut Standard optional, aber eine sehr wertvolle Information - die sollte in keinem Accounting-Paket fehlen.
Leider können nicht alle Gründe, aus denen eine
Assoziierung bei WLAN beendet wird, auf einen der
in RADIUS definierten Causes gemappt werden.
Momentan wird eine zugeschlagene Stationsüberwachung
(Client nicht mehr erreichbar) auf Lost Carrier gemappt
und eine Abmeldung des Clients per Deauthenticate oder
Diasassociate auf User-Request - alle anderen nicht.
Dafür könnte ich etwas a la 'unknown' reinschreiben, aber
wem würde das etwas nützen?

Also zumindest die Values
1 - User Request (ordentlich disassociated)
4 - Idle Timeout
5 - Session Timeout (unterstützt LCOS 6.x eigentlich Session-Time Begrenzungen?)

sind ja sehr eindeutig. Und bei anderen Implementierungen wird meiner Erfahrung nach einfach alles auf
2 - Lost Carrier
gemappt. Das ist zumindest mal für die große Mehrheit an Fällen genau genug.

alf29 hat geschrieben:
NAS-IP-Address und NAS-Identifier sind beide im Paket. Laut Standard darf nur genau eins von beiden vorhanden sein.
Zitat aus RFC2866:

Either NAS-IP-Address or NAS-Identifier MUST be present in a
RADIUS Accounting-Request.

Das lese ich so, daß *mindestens* eines der beiden
Attribute enthalten sein muß - ich lese daraus aber kein
Verbot, daß nicht beide gleichzeitig enthalten sein
dürfen. Wir haben auch schon bei Public Spot beide
Attribute reingeschrieben, und je nach Kunde wird mal
das eine oder das andere genutzt.

Ja, mea culpa. Ich hatte mich auf das O'Reilly RADIUS Buch verlassen, dort steht dass nur eins vorhanden sein darf (S. 53). RFC ist natürlich ein gutes Argument :-)

alf29 hat geschrieben:
Wenn schon Acct-(Input|Output)-Octets gezählt werden, dann könnte man auch gleich Acct-(Input|Output)-Packets zählen und mitschicken.
Die werden im Moment im WLAN überhaupt nicht gezählt,
deshalb kann ich die auch nicht liefern.

Okay, dann nicht. Wäre nur nice-to-have.

Grüße,

Stefan

alf29 · Beitrag von **alf29** » 22 Mär 2006, 13:40

Hi,

Ah. Zwar nicht gerade das, was ich erwartet habe, aber ok. Das heisst aber auch, dass immer nur vielfache von 60 in diesem Counter drinstehen?

Ja. Einmal pro Sekunde über die ganze Stationstabelle
zu rennen, war mir zu viel Overhead. Zumal ich keinen
Provider kenne, der im WLAN-Fall mehr als minutengenau
abrechnet (wenn er überhaupt minutengenau rechnet).

4 - Idle Timeout
5 - Session Timeout (unterstützt LCOS 6.x eigentlich Session-Time Begrenzungen?)

Stimmt, den Idle Timeout könnte man bei Gelegenheit noch
mappen. Einen Session Timeout gibt's im WLAN selber
nicht, nur im Zusammenhang mit Public Spot, wo es für
Voucher-basierte Zugänge auch gebraucht wird. Im
reinen WLAN-Umfeld habe ich's nur einmal im
Zusammenhang mit 802.1x und Reauthentifizierung gehört,
das handhabt das 1x-Modul im LANCOM die Intervalle
aber selber.

Okay, dann nicht. Wäre nur nice-to-have.

Abwarten.

Gruß Alfred

stefan.winter · Beitrag von **stefan.winter** » 22 Mär 2006, 13:51

alf29 hat geschrieben:
Ah. Zwar nicht gerade das, was ich erwartet habe, aber ok. Das heisst aber auch, dass immer nur vielfache von 60 in diesem Counter drinstehen?
Ja. Einmal pro Sekunde über die ganze Stationstabelle
zu rennen, war mir zu viel Overhead. Zumal ich keinen
Provider kenne, der im WLAN-Fall mehr als minutengenau
abrechnet (wenn er überhaupt minutengenau rechnet).

Einmal pro Sekunde drüberrennen? Also mein Ansatz wäre eher: in dem Moment wo das Acct-Paket erstellt wird, das Diff zwischen timstamp(association) und now() in das Attribut reinschreiben. Ist doch viel effizienter.

Grüße,

Stefan

alf29 · Beitrag von **alf29** » 26 Mär 2006, 21:02

Moin,

für die 6.1x kann ich zusagen:

(1) sekundengenaue Session-Zeit
(2) Paketzähler
(3) Abbruch-Gründe: Lost-Carrier, User-Request, Idle-Timeout, NAS-Request

Gruß Alfred

stefan.winter · Beitrag von **stefan.winter** » 27 Mär 2006, 08:04

Hallo,

alf29 hat geschrieben: (1) sekundengenaue Session-Zeit
(2) Paketzähler
(3) Abbruch-Gründe: Lost-Carrier, User-Request, Idle-Timeout, NAS-Request

Wow! Bei Cisco reagiert man nicht so schnell auf Feature Requetss :-)

Stefan