L-54(a)g Radius Accounting

_Flo_ · Beitrag von **_Flo_** » 04 Nov 2006, 02:59

Hi zusammen,

zu Authentifizierung, Autorisierung und Abrechnungszwecken verwenden wir seit Firmware 6.xx einen FreeRadius Server mit SQL Datenbankanbindung.

Seit Firmware 6.06 besteht unter Setup->WLAN->RADIUS-Accounting die Möglichkeit für die eingebuchten W-LAN Stationen regelmäßige "Interim-Updates" mit den aktuellen Traffic-Daten zu senden.

Für W-LAN Stationen, welche jedoch dauerhaft ohne Unterbrechung eingebucht sind, bleiben die entsprechenden Accounting Einträge monatelang offen, so dass keine monatliche Abrechnung des übertragenen Volumens sinnvoll möglich ist.

Besteht eine Möglichkeit die Konfiguration so zu verändern, dass der AP die Radius-Accounting Einträge für eingebuchte W-LAN Stationen regelmäßig – z.B. täglich um 0 Uhr - "abschließt" und "neu eröffnet" ohne die Clients per Zwangstrennung "rausschmeißen" zu müssen?

Am günstigsten wäre wohl so eine Art Radius Start/Stop Interval Period, also eine Zeitangabe, nach welcher der AP einen Accounting Stop und Start für einen eingebuchten Client sendet: z.B. jeweils nach 24h.

Tipps, Tricks und Ideen sind herzlich willkommen

-Flo

alf29 · Beitrag von **alf29** » 04 Nov 2006, 11:22

Moin,

Für W-LAN Stationen, welche jedoch dauerhaft ohne Unterbrechung eingebucht sind, bleiben die entsprechenden Accounting Einträge monatelang offen, so dass keine monatliche Abrechnung des übertragenen Volumens sinnvoll möglich ist.

Hm, also von anderen Kunden habe ich von derartigen Problemen bisher nichts
gehört - die lösen das mit passenden Skripten auf dem RADIUS-Server. Eine
einstellbare Zwangstrennung im WLAN gibt es nicht, man könnte höchstens versuchen,
das über den Idle-Timeout zu lösen - der greift allerdings nicht, wenn die
Stationsüberwachung aktiv ist.

Am günstigsten wäre wohl so eine Art Radius Start/Stop Interval Period, also eine Zeitangabe, nach welcher der AP einen Accounting Stop und Start für einen eingebuchten Client sendet: z.B. jeweils nach 24h.

Für eine zukünftige Firmware wäre denkbar, den Idle-Timeout von der Stationsüberwachung
zu trennen bzw. das Session-Timeout-Attribut vorzusehen.

Gruß Alfred

_Flo_ · Beitrag von **_Flo_** » 04 Nov 2006, 13:13

Hallo Alfred,

Für eine zukünftige Firmware wäre denkbar, den Idle-Timeout von der Stationsüberwachung
zu trennen bzw. das Session-Timeout-Attribut vorzusehen.

ja genau, dass wäre ein nettes Feature ohne am Radius Server "rumbasteln" zu müssen

Der Timer sollte aber nur einen Radius Accounting Stop/Start statt ein Accounting Update auslösen und die Clients nicht disassociaten...

Viele Grüße,
-Flo

alf29 · Beitrag von **alf29** » 04 Nov 2006, 18:08

Moin,

Der Timer sollte aber nur einen Radius Accounting Stop/Start statt ein Accounting Update auslösen und die Clients nicht disassociaten...

Das wäre dann aber nicht die Funktion, für die ein Session-Timeout normalerweise da ist - ich
verstehe ehrlich gesagt immer noch nicht, wieso das bei Euch auf dem RADIUS-Server so
ein Problem ist.

Gruß Alfred

_Flo_ · Beitrag von **_Flo_** » 05 Nov 2006, 18:48

Hallo,

...wieso das bei Euch auf dem RADIUS-Server so ein Problem ist.

Der RADIUS-Server verarbeitet doch nur die Accounting Werte, welche er von den APs erhält. Wie soll der RADIUS-Server zu festen Zeiten, z.B. täglich um Mitternacht alle offenen Einträge abschließen, neue aufmachen und gleichzeitig die "fehlenden Accounting-Werte" ergänzen, welcher er erst irgendwann später als Accounting Interim-Update Paket erhält.

Wäre es nicht einfacher und sinnvoller gleich an der Quelle, also den LANCOM APs, eine Funktion einzubauen, welche zu einer festen Zeit für die "offenen" W-LAN Clientverbindungen einen Accounting Stop und Start schickt. Also sprich einfach einen neuen Accounting Eintrag generiert...

Wie haben das andere hier im Forum gelöst, wenn die W-LAN Clients ununterbrochen online sind? Vielleicht hat ja zufällig jemand ein Beispielskript für'n Freeradius

Viele Grüße,
-Flo

alf29 · Beitrag von **alf29** » 05 Nov 2006, 19:41

Moin,

wie die anderen das im Detail machen weiß ich nicht. Letzten Endes enthält aber jeder
Interim-Update wie das Accounting-Stop die Zeit und Datenmenge, die in der Session bisher
aufgelaufen sind, und ein RADIUS-Server muß eigentlich auch mit Sessions klarkommen, bei
denen das Stop nie kommt - wenn z.B. beim AP mal Stromausfall war (um ein aktuelles
Beispiel zu nehmen

).

Wie man genau um RADIUS-Accounting Skripte baut, weiß ich nicht (noch nie gemacht...),
grob würde ich es aber so lösen, daß bei noch nicht abgeschlossenen Sessions eben der
Wert im letzten Interim Update in Rechnung gestellt wird, umd man merkt sich diesen Wert
als Delta für die nächste Abrechnung. Sessions sind über die Session-Id ja eindeutig
zuordenbar.

Gruß Alfred

_Flo_ · Beitrag von **_Flo_** » 06 Nov 2006, 01:58

Hallo Alfred,

...ein RADIUS-Server muß eigentlich auch mit Sessions klarkommen, bei denen das Stop nie kommt - wenn z.B. beim AP mal Stromausfall...

Da bleibt der Accounting Eintrag einfach ohne AcctStopTime "offen". Wie soll der RADIUS-Server da auch einen Stop dazubauen, wenn die dazu nötigen Daten fehlen.

Habe die gesamte radiusd.conf mit den ganzen Modulen noch mal durchgeschaut; zu dem Problem aber nix passendes gefunden. Wen jemand hier im Forum eine Idee hat, wie sich das mit einfachen Radius "Bordmitteln" lösen lässt, dann lasse ich mich gerne aufklären ... vielleicht hab ich ja was übersehen

Ansonsten wär's schon super praktisch, wenn die Datenquelle gleich selber regelmäßig einen Accouting Stop und Start schickt. z.B. jeden Tag um 0h

Viele Grüße,
-Flo

alf29 · Beitrag von **alf29** » 06 Nov 2006, 09:59

Moin,

Da bleibt der Accounting Eintrag einfach ohne AcctStopTime "offen". Wie soll der RADIUS-Server da auch einen Stop dazubauen, wenn die dazu nötigen Daten fehlen.

Das habe ich auch nicht bestritten, daß die Session aus der Sicht des RADIUS-Servers
erstmal offen bleibt (bis eventuell zu irgendeinerm Timeout, der RADIUS-Server kann ja
prinzipiell wissen, wann das nächste Update/Stop kommen muß...), aber daß so etwas
dann u.U. gar nicht abgerechnet wird, würde glaube ich kein Provider ernsthaft akzeptieren.

Sinn der Interim-Updates ist es ja gerade, daß bei einem 'Wegbrechen' des NAS die
Session bis zu diesem Zeitpunkt abgerechnet werden kann, dafür enthält ja auch jeder
Interim-Update die vollständinge Accounting-Daten, wie sie auch der Stop enthalten
würde.

Gruß Alfred

_Flo_ · Beitrag von **_Flo_** » 08 Nov 2006, 19:50

Hallo Alfred,

...aber daß so etwas dann u.U. gar nicht abgerechnet wird, würde glaube ich kein Provider ernsthaft akzeptieren.

Bei Abrechnung solcher "halboffener" Einträge würde man sich aus meiner Sicht rechtlich schon ziemlich auf Glatteis begeben; denn im Zweifelsfall hält so ein nicht korrekt abgeschlossener Radius Eintrag wahrscheinlich keiner gerichtlichen Überprüfung stand.

Das ist sicherlich auch ein Grund, weshalb in der DTAG Backbone für die DSL Zugänge die Zwangstrennung nach 24h eingeführt wurde. Im Zweifelsfall ist höchstens ein Tag verloren.

Eine Zwangstrennung ist aber meiner Ansicht nach gar nicht nötig, wenn der LANCOM AP einfach nur nach 24h oder einmal am Tag zu einer festen Uhrzeit statt einem Interim-Update automatisch ein Accounting-Stop und -Start für alle verbundenen W-LAN Clients senden würde.

Das hat zudem den weiteren Vorteil, dass "halboffene" Radius Einträge, welche älter als ein Tag sind, automatisch auch auf einen Fehler im Netz hinweisen. Solange wie bislang Radius Einträge für W-LAN Clients teils über Monate "halboffen" sind, ist keine sinnvolle Auswertung möglich.

Wäre deshalb schön, wenn ihr in der nächsten FW diesbezüglich eine kleine Zusatzfunktion im "RADIUS-Accounting" Menüpunkt mit einbauen könntet.

Viele Grüße,
Florian

alf29 · Beitrag von **alf29** » 08 Nov 2006, 22:31

Moin,

Bei Abrechnung solcher "halboffener" Einträge würde man sich aus meiner Sicht rechtlich schon ziemlich auf Glatteis begeben; denn im Zweifelsfall hält so ein nicht korrekt abgeschlossener Radius Eintrag wahrscheinlich keiner gerichtlichen Überprüfung stand.

Ein RADIUS Accounting Stop ist kryptographisch genauso gut oder schlecht abgesichert
wie ein Interim Update - wenn es wirklich vor Gericht mal zu Streitigkeiten kommen sollte,
wirst Du für die abgeschlossenen Sessions genauso deren Korrektheit beweisen müssen.
Wie gesagt, ein Accounting Stop ist eigentlich auch nur ein Interim Update, der sagt, daß
keine weiteren Updates mehr kommen

Der einzige rechtlich relevante Unterschied bei einem Accounting Stop, den ich erkennen
kann, ist daß ein bestimmter Benutzer ab diesen Zeitpunkt eine bestimmte IP-Adresse
offensichtlich nicht mehr benutzt hat.

Das ist sicherlich auch ein Grund, weshalb in der DTAG Backbone für die DSL Zugänge die Zwangstrennung nach 24h eingeführt wurde. Im Zweifelsfall ist höchstens ein Tag verloren.

Da geht es mit ziemlicher Sicherheit eher darum, daß die Leute nicht quasi eine feste
IP-Adresse bekommen.

Das hat zudem den weiteren Vorteil, dass "halboffene" Radius Einträge, welche älter als ein Tag sind, automatisch auch auf einen Fehler im Netz hinweisen. Solange wie bislang Radius Einträge für W-LAN Clients teils über Monate "halboffen" sind, ist keine sinnvolle Auswertung möglich.

Wie gesagt, ich sehe nicht, welche Probleme so ein Feature lösen würde, wenn die dahinter
stehende Abrechnungssoftware die Fehlersituationen, die sie ohnehin abfangen muß, auch
abfängt...

Gruß Alfred

_Flo_ · Beitrag von **_Flo_** » 09 Nov 2006, 01:45

Hallo Alfred,

ich sehe nicht, welche Probleme so ein Feature lösen würde, wenn die dahinter stehende Abrechnungssoftware die Fehlersituationen, die sie ohnehin abfangen muß, auch abfängt...

Mit welcher SQL-Abfrage möchtest du aus der radacct Tabelle (RADIUS Accounting Tabelle) das Volumen auslesen, welches ein W-LAN Client z.B. im Monat Oktober generiert hat, wenn dieser bereits seit irgendwann im August eine "halboffene" Radius Session hat?

Viele Grüße,
Florian

alf29 · Beitrag von **alf29** » 09 Nov 2006, 10:03

Moin,

Mit welcher SQL-Abfrage möchtest du aus der radacct Tabelle (RADIUS Accounting Tabelle) das Volumen auslesen, welches ein W-LAN Client z.B. im Monat Oktober generiert hat, wenn dieser bereits seit irgendwann im August eine "halboffene" Radius Session hat?

Wenn in dieser Tabelle die Session als seit August offen vermerkt steht und man alle
Interim Updates hat (als Optimierung braucht man ja nur die aufzuheben, die unmittelbar
vor Ende eines Abrechnungszeitraumes gekommen sind), dann sehe ich da kein
grundsätzliches Problem. Wenn das, was Ihr als 'Backend' für RADIUS-Accounting
benutzt, solche Situationen nicht berücksichtigt, dann taugt diese Lösung m.E. nichts.

Wie man das im Detail realisiert, kann ich Dir nicht sagen, weil ich mich in dieser Ecke
nicht auskenne, ich weiß nur, daß es reihenweise Kunden gibt, die RADIUS-Accounting
zusammen mit WLAN und auch schon länger mit Public Spot einsetzen (wo man das
gleiche Problem hat), und ich habe noch von keinem gehört, der dieses Problem hätte.
Also muß es offensichtlich eine Lösung geben, wobei die meisten ihre Abrechnungssysteme
evtl. selber schreiben, d.h. die über den RADIUS-Server kommenden Accounting-Requests
werden as-is in die Datenbank geschrieben und das Abrechnen macht eine komplett
eigene Applikation.

Gruß Alfred

_Flo_ · Beitrag von **_Flo_** » 09 Nov 2006, 17:01

Hallo Alfred,

...daß es reihenweise Kunden gibt, die RADIUS-Accounting zusammen mit WLAN und auch schon länger mit Public Spot einsetzen...

Ich glaube bei einem Hotspot hat man einfach nicht das Problem, dass W-LAN Clients über Monate hinweg ohne Unterbrechung eingebucht sind

Wenn ich die Resonanz zu dem Thema im Forum so beobachte, dann könnte man ja fast auf den Gedanken kommen, dass das RADIUS Feature entweder kaum genutzt wird, oder die Betreiber mit anderen Problemen kämpfen...

als Optimierung braucht man ja nur die aufzuheben, die unmittelbar
vor Ende eines Abrechnungszeitraumes gekommen sind

Der RADIUS aktualisiert bei Interim-Updates nur die vorhandenen "halboffenen" Einträge per SQL Update. Es existiert also nur ein einziger "halboffener" Eintrag in der SQL-Accounting Tabelle, solange ein Client ohne Unterbrechung eingebucht bleibt.

Wenn ich deinen Lösungsvorschlag von oben aufgreife, dann müssten wir für die Abrechnung eine weitere Accounting Tabelle anlegen, welche regelmäßig aus der Standard RADIUS Accounting Tabelle aktualisiert wird und damit mehr Zwischenwerte zur Verfügung stellt. Das wiederum hätte aber den Nachteil, dass die Kunden in der eigenen Volumenübersicht nicht mehr auf die aktuellen Daten, sondern nur noch auf die Daten zugreifen könnten, welche in den Intervallen aktualisiert wurden.

Schätzt du den Aufwand eine Funktion - wie von mir oben vorgeschlagen - in die LANCOM Firmware mit einzubauen so groß ein? Ich dachte, dass wäre nur eine Dreizeiler-Ergänzung zu den Interim-Updates und damit wäre das Problem vom Tisch.

Ciao,
Florian

schibulski · Beitrag von **schibulski** » 10 Nov 2006, 20:48

Hallo Florian,

_Flo_ hat geschrieben: Wenn ich die Resonanz zu dem Thema im Forum so beobachte, dann könnte man ja fast auf den Gedanken kommen, dass das RADIUS Feature entweder kaum genutzt wird, oder die Betreiber mit anderen Problemen kämpfen...

Nein. Radius-Accounting laueft bei uns seit Einfuehrung mit der FW 6.06. Wir haben damit ueberhaupt keine Probleme, ganz im Gegenteil, uns half es Probleme zu beseitigen ;-)

Die derzeitige standardkonforme Umsetzung von Lancom halte ich fuer gut. Basierend auf diesen Standard, kann je nach Gusto eine eigene Loesung zusammengebastelt oder gekauft werden, fuer jede praeferierte Geschmacksrichtung, ob nun die Records als Plain-Text weggeschrieben werden oder in eine SQL Datenbank verschoben werden. Ein taegliches Stop Record waere aus meiner Sicht grober Unfug. Was machen beispielsweise Nutzer die ihren Radius Server heterogen nutzen, sprich darueber auch die VPN-, Telefon-Einwahl oder Port Authentifizierung an Switchen realisieren? Natuerlich koennte man das Feature optional gestalten, aber dann hat man immer noch den Beratungs- und Fehlbedienungsaufwand; wofuer ist denn das? Der Obskuritaetsfaktor darf auch nicht unterschaetzt werden... naja bei einer Ausschreibung waere es ein Alleinstellungsmerkmal :-)

Gruss, Schibulski

alf29 · Beitrag von **alf29** » 11 Nov 2006, 09:24

Moin,

Schätzt du den Aufwand eine Funktion - wie von mir oben vorgeschlagen - in die LANCOM Firmware mit einzubauen so groß ein? Ich dachte, dass wäre nur eine Dreizeiler-Ergänzung zu den Interim-Updates und damit wäre das Problem vom Tisch

Etwas mehr als drei Zeilen Aufwand waren auch die schon...und bei so etwas kommt noch
hinzu, daß man eine neue Session-Id auswürfeln muß. plus evtl. eine State-Machine, die
dafür sorgt, daß der neue Accounting-Start erst verschickt wird, wenn der RADIUS-Server
den Erhalt des Accounting-Stop bestätigt hat. Plus man hat einen weiteren Menüpunkt,
an dem u.U. herumgespielt wird und der dann Supportaufwand verursacht. Solange ich
nicht überzeugt bin, daß das wirklich nötig ist, kommt so etwas nicht rein - und in diesem
Punkt bin ich nunmal bisher nicht davon überzeugt, daß er wirklich notwendig wäre...

Gruß Alfred