Radius-Accounting

[holgi03]

Hallo Alfred,

Ich melde mich morgen, wenn wir eine neue Firmware
haben.

hatten wir schon morgen?

Gruß Holger

[alf29]

Moin,

hatten wir schon morgen?

Das man man streng genommen nie Hatte bisher
den Eindruck, daß alle mit dem Workaround zufrieden wären...

Wer eine neuere 6.0x haben will, melde sich bitte, wo ich sie
hinschicken soll, ich kümmere mich am Montag drum.

Gruß Alfred

[schibulski]

Hallo Alf,

mit der neuen Firmware funktioniert das Radius-Accounting nun wunderbar.

Der Workaround mit der Eingabe der Schluessellaenge in der Radius Zugriffspruefung ist entfallen.

Der Lancom AP generiert nun direkt nach der Abmeldung Stop-Accounting Records. Dabei ist es egal, ob man intern auf eine andere SSID wechselt oder zu einem anderen AP.

Im Feld "Ausgeschlossenes VLAN" passen nun auch IDs ueber 255 rein.

Einfach Klasse. Noch einmal ein recht herzliches Dankeschoen und beste Gruesse

[stefan.winter]

beim Radius Accounting gibt es leider noch folgendes Problem:
Falls der AP per [Experten-Konfiguration]->Sonstiges->Kaltstart neu gestartet wird gehen alle offenen Accountings der eingebuchten Clients verloren.

Ist das so beabsichtigt?

Das ließe sich für diesen Fall vielleicht lösen, ist aber
allgemein nicht zu verhindern, daß beim
RADIUS-Accounting der NAS (also der AP in diesem
Fall) einfach 'wegbricht' und der RADIUS-Server bzw.
die Auswerte-Software dahinter mit den offenen Sessions
klarkommen muß. Damit möglichst wenig
Infos verloren gehen, gibt es ja die Interim-Updates.

Hmm... für solche Fälle sollte der AP zumindest nach dem Booten ein "Accounting-On" Paket an den konfigurierten RADIUS-Server schicken, damit der alle noch offenen Sessions dieses APs als geschlossen markiert. Sonst gibt es häßliche stale sessions auf dem Server. Und wenn es irgendwie geht, sollte auch vor dem Booten noch ein Accounting-Off Paket geschickt werden. Zumindest bei einem "kontrollierten" Reboot ließe sich das doch sicher implementieren, oder? Bei ner os_panic eher nicht...

Grüße,

Stefan Winter

[alf29]

Moin,

Hmm... für solche Fälle sollte der AP zumindest nach dem Booten ein "Accounting-On" Paket an den konfigurierten RADIUS-Server schicken, damit der alle noch offenen Sessions dieses APs als geschlossen markiert. Sonst gibt es häßliche stale sessions auf dem Server. Und wenn es irgendwie geht, sollte auch vor dem Booten noch ein Accounting-Off Paket geschickt werden.

Derlei Pakete sind mir nicht bekannt - ich kenne nur
Start, Stop und Interim-Update.

Zumindest bei einem "kontrollierten" Reboot ließe sich das doch sicher implementieren, oder? Bei ner os_panic eher nicht...

Es gibt im Moment im LCOS schlicht keine Aufrufkette von
Dingen, die noch vor einem Reboot erledigt werden sollen -
und wenn der RADIUS-Server gerade nicht erreichbar ist,
wie lange soll das Gerät dann warten und seinen Reboot
verzögern. Noch übler wird's, wenn der RADIUS-Server
nur über eine WAN-Verbindung zu erreichen ist, und dafür
erst eine Verbindung aufgebaut werden müßte - und das,
wenn man eigentlich nur rebooten wollte...

Gruß Alfred

[stefan.winter]

Hi,

Hmm... für solche Fälle sollte der AP zumindest nach dem Booten ein "Accounting-On" Paket an den konfigurierten RADIUS-Server schicken, damit der alle noch offenen Sessions dieses APs als geschlossen markiert. Sonst gibt es häßliche stale sessions auf dem Server. Und wenn es irgendwie geht, sollte auch vor dem Booten noch ein Accounting-Off Paket geschickt werden.

Derlei Pakete sind mir nicht bekannt - ich kenne nur
Start, Stop und Interim-Update.

Dann bin diesmal ich der, der ein RFC zitiert ;-)

RFC2866, Kapitel 5.1

5.1. Acct-Status-Type

Description

This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).

It MAY be used by the client to mark the start of accounting (for
example, upon booting) by specifying Accounting-On and to mark the
end of accounting (for example, just before a scheduled reboot) by
specifying Accounting-Off.

A summary of the Acct-Status-Type attribute format is shown below.
The fields are transmitted from left to right.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

40 for Acct-Status-Type.

Length

6

Value

The Value field is four octets.

1 Start
2 Stop
3 Interim-Update
7 Accounting-On
8 Accounting-Off
9-14 Reserved for Tunnel Accounting
15 Reserved for Failed

Und da sind halt Value 7 und 8 genau für solche Reboot-Fälle vorgesehen.

Grüße,

Stefan Winter