Public Spot User mit Standard Budget

[Bernie137]

Hallo Jirka,

Unter 'Status/Public-Spot/Log-Table' steht ordentlich Finished Session, aber der Benutzerdatensatz wird im RADIUS mitunter nicht gelöscht. Hat jemand auch ähnliche Probleme?

Das sieht bei uns sauber aus. WLC-4006, LCOS 8.84.

vg Bernie

[Dr.Einstein]

Hallo Jirka,

WLC mit 8.84 gleiches Problem wie du. Ca. 1000-2000 Smart Ticket Accounts, die auf ihren absoluten Ablauf warten. Als wenn der Radius den Beginn der Session nicht mitbekommt, kA. Meine Theorie dahinter ist der Fehler bei der Weiterleitung nach erfolgtem AGB bestätigen auf http:/// statt des Originallinks. Vielleicht haut es deswegen nicht so hin? Eigentlich müsste ja jedes Ticket sofort starten, wenn AGBs bestätigt werden.

Gruß Dr.Einstein

[alf29]

Moin,

WLC mit 8.84 gleiches Problem wie du. Ca. 1000-2000 Smart Ticket Accounts, die auf ihren absoluten Ablauf warten. Als wenn der Radius den Beginn der Session nicht mitbekommt, kA.

Die Zeit des ersten Logins wird in der Accounting-Totals-Tabelle (Status/TCP-IP/RADIUS-Server/Accounting/Accounting-Totals) nachgehalten. Das 'gemeine' an der Sache: Damit der Inhalt dieser Tabelle auch einen Kaltstart überlebt, wird ihr Inhalt auch als CSV-Datei im Flash-Dateisystem abgelegt - und bei allen LANCOMs mit NOR-Flashes können diese Dateien maximal 64 KByte groß werden. Was noch dazukommt: Der Schalter, abgelaufene Accounts aus der Benutzertabelle zu löschen, tilgt die Accounts *nicht* aus dieser Tabelle - die wird also immer größer und irgendwann ist das 64K-Limit erreicht. Hier muß man im Augenblick (leider) gelegentlich selbst entmüllen...

Gruß Alfred

[Jirka]

Hallo Dr. Einstein,

Als wenn der Radius den Beginn der Session nicht mitbekommt, kA.

ich habe auch noch kein Ansatz, wo es genau hakt. Hatte heute viel getraced, bin aber am Ende von den vielen Daten und Status-Tabellen etwas erschlagen worden. Morgen werde ich mal einen Trace mitlaufen lassen und dann noch mal schauen.

Meine Theorie dahinter ist der Fehler bei der Weiterleitung nach erfolgtem AGB bestätigen auf http:/// statt des Originallinks.

Ich glaube nicht, dass es daran liegt. Aber wer weiß...
Weißt Du, was LANCOM zu dem http:///-Bug sagt? Der Bug nervt insofern am meisten, weil es der Kunde unmittelbar mitbekommt und man nichts gegen tun kann. Insofern wäre ich froh, wenn da möglichst bald die Ursache gefunden wird.

Hallo Alfred,

Die Zeit des ersten Logins wird in der Accounting-Totals-Tabelle (Status/TCP-IP/RADIUS-Server/Accounting/Accounting-Totals) nachgehalten.

oh Gott, was ist das für ein Ungetüm von Tabelle?!

Der Schalter, abgelaufene Accounts aus der Benutzertabelle zu löschen, tilgt die Accounts *nicht* aus dieser Tabelle - die wird also immer größer und irgendwann ist das 64K-Limit erreicht. Hier muß man im Augenblick (leider) gelegentlich selbst entmüllen...

Ich habe zwar wegen NAND-Speichers nicht das Problem, habe aber trotzdem mal entmüllt, weil diese Unmengen ja niemand mehr auswerten kann.
Wie eben schon geschrieben werde ich mal schauen, ob ich die Fehlerursache mit einigen Traces weiter eingrenzen kann. Danke soweit erst mal.

Viele Grüße,
Jirka

[alf29]

Moin,

oh Gott, was ist das für ein Ungetüm von Tabelle?!

Das ist grob gesagt die Tabelle, die für alle Accounts summarisch den 'Resourcenverbrauch' (Zeit, Volumen) nachhält. Das braucht das Gerät, um bei Accounts mit
Zeit- oder Volumenbudget korrekte Restbudgets rauszugeben.

Gruß Alfred

[Dr.Einstein]

Weißt Du, was LANCOM zu dem http:///-Bug sagt? Der Bug nervt insofern am meisten, weil es der Kunde unmittelbar mitbekommt und man nichts gegen tun kann. Insofern wäre ich froh, wenn da möglichst bald die Ursache gefunden wird.

"Wir können den Fehler nicht reproduzieren" ... selbst mit zugeschickter, nicht funktionierender Konfig. Ich geb aber nicht auf

Gruß Dr.Einstein

[Dr.Einstein]

8.84.0172 behebt den Weiterleitungsfehler auf http:///

[Jirka]

Hallo Dr. Einstein,

nun wollte ich gerade auf Deinen Beitrag von heute morgen antworten, weil ich es heute Vormittag nicht auf die Reihe bekommen habe, und unsere weitere Vorgehensweise in diesem "worst case"-Fall besprechen und nun diese erfreuliche Meldung! Danke, große Klasse. Mich wundert zwar jetzt irgendwie noch, wie Du es nun hinbekommen hast, dass dieser Bug nun nicht nur nachgestellt werden konnte (alleine das wäre ja schon ein Erfolg) sondern auch gleich noch eine korrigierte Build-Version in Aussicht ist, aber da hast Du wohl nicht locker gelassen... Vielen Dank!

Viele Grüße,
Jirka

[Jirka]

Hallo Alfred,

ich hoffe, Du kannst uns mal ein wenig unter die Arme greifen und etwas zum nachfolgenden Trace sagen.
Bisher hatte ich die Fehlerursache ja blöderweise immer am Ende der relativen Ablaufzeit gesucht, aber da war schlicht nichts zu finden, die Traces blieben an der Stelle leer. Nun bin ich einen Schritt weiter, denn ich habe rausgefunden, dass das Problem bereits am Anfang der Session auftritt.

Zunächst die Kurzfassung der Geschichte als Syslog:

Code: Alles auswählen

22784	2014-05-01 16:59:32	KERN	Hinweis	DHCP: IP 172.20.20.221 assigned to MAC: 5c:f8:a1:d6:f4:36
22785	2014-05-01 16:59:41	AUTH	Hinweis	user 'freec63jb' automatically added to RADIUS user table (pubSpUser created by Smart Ticket on 05/01/2014 16:59:41 ())
22786	2014-05-01 16:59:41	AUTHPRIV	Info	Authen page Add User: freec63jb
22787	2014-05-01 16:59:41	AUTH	Hinweis	sent RADIUS accept for user id 'freec63jb' to 127.0.0.1
22788	2014-05-01 16:59:41	AUTH	Hinweis	Started session for user 'freec63jb' (IP address is 172.20.20.221, MAC address is 5c-f8-a1-d6-f4-36)
22789	2014-05-01 16:59:41	LOCAL1	Hinweis	handled RADIUS accounting request for user id 'freec63jb' from 127.0.0.1
22790	2014-05-01 16:59:44	LOCAL1	Hinweis	last message repeated 1 time
22791	2014-05-01 16:59:53	AUTH	Hinweis	user 'free1r634' automatically added to RADIUS user table (pubSpUser created by Smart Ticket on 05/01/2014 16:59:53 ())
22792	2014-05-01 16:59:53	AUTHPRIV	Info	Authen page Add User: free1r634

So, und nun zum eigentlichen Trace:

Code: Alles auswählen

[LANAUTH] 2014/05/01 16:59:35,057
Authen page request: URL=''
-->Welcome page


[RADIUS-Client] 2014/05/01 16:59:41,500
Send RADIUS Authentication Request Id 207 to 127.0.0.1 Backup-Step 1 Retry 0 Auth 4783e1d068b4daedd66b956a35ba5d8e


[LANAUTH] 2014/05/01 16:59:41,500
Login Request from station 5c:f8:a1:d6:f4:36 Username freec63jb
  recording IP address 172.20.20.221
  forwarding RADIUS request to provider LANCOM-RADIUS


[RADIUS-Server] 2014/05/01 16:59:41,501
Received RADIUS authentication request 207 from client 127.0.0.1:3072:
-->known attributes of request:
   User-Name           : freec63jb
   User-Password       : cztqxf
   Service-Type        : Login
   NAS-Identifier      : Glaes-Manufaktur
   NAS-IP-Address      : 127.0.0.1
   NAS-Port-Id         : LAN-1
   NAS-Port-Type       : Ethernet
   Called-Station-Id   : 00:a0:57:1e:a5:dc
   Calling-Station-Id  : 5c:f8:a1:d6:f4:36
   Framed-IP-Address   : 172.20.20.221
-->user name contains no realm, using empty realm
-->realm of user is ''
-->authenticating locally
-->found user 'freec63jb' in database(s)
-->setting session timeout of 31536000 seconds from expiry time
-->setting session timeout of 3600 seconds from expiry time relative to first login
-->authenticating via PAP
-->response type is Accept, response attributes:
   Session-Timeout     : 3600 s
   LCS-Account-End     : 05/01/2015 16:59:41
-->sending response


[RADIUS-Client] 2014/05/01 16:59:41,505
Received RADIUS Accept Id 207 from 127.0.0.1
-->found corr. request 207 to IP 127.0.0.1:1812, secret <xjZeHY6jrC5HUdYXzhBoK4qwtzWo4Ni6VHBsXceAtQ5jwFqH3FiuY4OU1BGscuk>, authenticator 4783e1d068b4daedd66b956a35ba5d8e
-->trigger requester


[LANAUTH] 2014/05/01 16:59:41,505
Started session for user 'freec63jb' (IP address is 172.20.20.221, MAC address is 5c-f8-a1-d6-f4-36)

[RADIUS-Client] 2014/05/01 16:59:41,505
Send RADIUS Accounting Request Id 71 to 127.0.0.1 Backup-Step 1 Retry 0 Auth 5852b90e73afad5df1a7f83389e929e4


[LANAUTH] 2014/05/01 16:59:41,499
Authen page request: URL='login/?UserName=freec63jb&Password=cztqxf'
-->Login (done) page
-->Login success page


[LANAUTH] 2014/05/01 16:59:41,461
Authen page request: Free login
Authen page Add User: 'freec63jb'


[RADIUS-Server] 2014/05/01 16:59:41,512
Received RADIUS accounting request 71 from client 127.0.0.1:3072:
-->known attributes of request:
   User-Name           : freec63jb
   NAS-Identifier      : Glaes-Manufaktur
   NAS-IP-Address      : 127.0.0.1
   NAS-Port-Id         : LAN-1
   NAS-Port-Type       : Ethernet
   Called-Station-Id   : 00:a0:57:1e:a5:dc
   Calling-Station-Id  : 5c:f8:a1:d6:f4:36
   Acct-Status-Type    : Start
   Acct-Session-Id     : 00a0571ea5dc-53627D7D-f7
   Framed-IP-Address   : 172.20.20.221
-->user name contains no realm, using empty realm
-->realm of user is ''
-->accounting locally
-->session does not exist so far
-->creating new session
-->assuming no interim update period, not starting dead session timer
-->updating session data
-->setting first login time of entry
-->creating and updating new total entry
-->not yet writing back accounting totals to flash to limit flash write rate
-->response type is Response, response attributes:
-->sending response


[RADIUS-Client] 2014/05/01 16:59:41,513
Received RADIUS Accounting Response Id 71 from 127.0.0.1
-->found corr. request 71 to IP 127.0.0.1:1813, secret <xjZeHY6jrC5HUdYXzhBoK4qwtzWo4Ni6VHBsXceAtQ5jwFqH3FiuY4OU1BGscuk>, authenticator 5852b90e73afad5df1a7f83389e929e4
-->trigger requester


[RADIUS-Client] 2014/05/01 16:59:44,060
Send RADIUS Accounting Request Id 130 to 127.0.0.1 Backup-Step 1 Retry 0 Auth b38a25665e47570421fd7fd44a0d9f39


[RADIUS-Server] 2014/05/01 16:59:44,061
Received RADIUS accounting request 130 from client 127.0.0.1:3072:
-->known attributes of request:
   User-Name           : freec63jb
   NAS-Identifier      : Glaes-Manufaktur
   NAS-IP-Address      : 127.0.0.1
   NAS-Port-Id         : LAN-1
   NAS-Port-Type       : Ethernet
   Called-Station-Id   : 00:a0:57:1e:a5:dc
   Calling-Station-Id  : 5c:f8:a1:d6:f4:36
   Acct-Status-Type    : Interim-Update
   Acct-Session-Id     : 00a0571ea5dc-53627D7D-f7
   Event-Timestamp     : 05/01/2014 16:59:44
   Acct-Session-Time   : 2 s
   Acct-Input-Octets   : 75384 bytes
   Acct-Output-Octets  : 112230 bytes
   Acct-Input-Packets  : 878
   Acct-Output-Packets : 795
   Framed-IP-Address   : 172.20.20.221
-->user name contains no realm, using empty realm
-->realm of user is ''
-->accounting locally
-->found existing accounting session
-->updating session data
-->storing current time stamp for interim update period detection
-->updating accounting totals in memory
-->not yet writing back accounting totals to flash to limit flash write rate
-->response type is Response, response attributes:
-->sending response


[RADIUS-Client] 2014/05/01 16:59:44,064
Received RADIUS Accounting Response Id 130 from 127.0.0.1
-->found corr. request 130 to IP 127.0.0.1:1813, secret <xjZeHY6jrC5HUdYXzhBoK4qwtzWo4Ni6VHBsXceAtQ5jwFqH3FiuY4OU1BGscuk>, authenticator b38a25665e47570421fd7fd44a0d9f39
-->trigger requester


[RADIUS-Server] 2014/05/01 16:59:44,120
Checking for dead accounting sessions:


[LANAUTH] 2014/05/01 16:59:53,959
Login Request from station 5c:f8:a1:d6:f4:36 Username free1r634


[LANAUTH] 2014/05/01 16:59:53,958
Authen page request: URL='login/?UserName=free1r634&Password=n5gz2v'
-->Login (done) page
-->Login success page


[LANAUTH] 2014/05/01 16:59:53,921
Authen page request: Free login
Authen page Add User: 'free1r634'


[RADIUS-Server] 2014/05/01 17:00:14,120
Checking for expired user accounts:


[RADIUS-Server] 2014/05/01 17:00:14,120
Checking for dead accounting sessions:


[RADIUS-Server] 2014/05/01 17:00:14,121
Checking for writeback of accounting totals:
-->not yet writing back accounting totals to flash to limit flash write rate


[RADIUS-Server] 2014/05/01 17:00:44,120
Checking for dead accounting sessions:


[RADIUS-Server] 2014/05/01 17:01:14,120
Checking for expired user accounts:


[RADIUS-Server] 2014/05/01 17:01:14,121
Checking for writeback of accounting totals:
-->not yet writing back accounting totals to flash to limit flash write rate


[RADIUS-Server] 2014/05/01 17:01:14,121
Checking for dead accounting sessions:


[LANAUTH] 2014/05/01 17:01:36,438
Authen page request: URL=''
-->Welcome page


[RADIUS-Server] 2014/05/01 17:01:44,120
Checking for dead accounting sessions:


[RADIUS-Server] 2014/05/01 17:02:14,120
Checking for dead accounting sessions:


[RADIUS-Server] 2014/05/01 17:02:14,121
Checking for expired user accounts:


[RADIUS-Server] 2014/05/01 17:02:14,121
Checking for writeback of accounting totals:
-->writing back accounting totals to flash
--->updated accounting totals in flash

So, das Problem entsteht hier genau um 16:59:53 Uhr mit der Erstellung des zweiten Users free1r634, der anschließend nicht rausaltert. (Noch mal zur Klarstellung: Ein (WLAN-)Client identifiziert durch seine MAC bekommt hier zwei Usernamen.)

Das ganze wirft nun mehrere Fragen auf... Wie kommt es überhaupt dazu? Was kann die Ursache dafür sein? Warum geht der LANAUTH-Trace zeitlich gesehen manchmal rückwärts? Warum kommt hier zweimal ein 'Authen page request: Free login'?

Falls auch noch Infos zu den Status-Tabellen benötigt werden, ich habe relativ viele gesichert. Der User free1r634 ist da aber nicht wirklich zu finden.
Ich bin sehr froh, dass ich nun soweit gekommen bin, mit Deiner Hilfe könnte man der Sache evt. weiter auf den Grund gehen.

P.S.: Es ist übrigens schade, dass es bei LANCOM keine Konvention darüber gibt, wie MAC-Adressen angegeben werden (also ob mit Doppelpunkt oder Bindestrich). Das erschwert die Suche im Fehlerfall. Das wäre mal ein Feature-Wunsch von mir...

Viele Grüße,
Jirka

[alf29]

Moin,

OK, eins nach dem anderen:

So, das Problem entsteht hier genau um 16:59:53 Uhr mit der Erstellung des zweiten Users free1r634, der anschließend nicht rausaltert.

Aus Sicht des RADIUS-Servers hat es nie einen Accounting-Start für die zweite Benutzerkennung gegeben, deshalb gibt es für diesen Account keinen Zeitpunkt des ersten Logins und deshalb läuft auch relative Ablauf nie los.

(Noch mal zur Klarstellung: Ein (WLAN-)Client identifiziert durch seine MAC bekommt hier zwei Usernamen.)

Das könnte schon Dein Problem sein. Das Public-Spot-Modul hat AFAIK irgendwann 'nach meiner Zeit' eine Option bekommen, daß es sich die MAC-Adressen von Clients merkt, die sich schon einmal erfolgreich angemeldet haben, und diese kommen für eine gewisse Zeit ohne neue Anmeldung direkt wieder rein. In diesem Fall läuft ja sogar noch eine Session für die erste Benutzerkennung, ich sehe im Trace dafür jedenfalls keinen Accounting-Stop. Ich gehe davon aus, die Meldung 'free login' soll genau diesen Umstand ausdrücken. Ob das ein Bug oder ein Feature ist, daß beim 'freien Login' mit der zweiten Benutzerkennung die Accounting-Session für den ersten Benutzer einfach weiterläuft, anstatt sie zu beenden und einen Accounting-Start für die neue Benutzerkennung zu schicken, kann ich nicht beurteilen, das mußt Du mit dem Support klären. Ich habe mich irgendwann vor ~2 Jahren aus der Public-Spot-Entwicklung zurückgezogen, zu allen Sachen, die danach gekommen sind, kann ich wenig bis gar nichts sagen, ich kann nur das Verhalten des RADIUS-Servers erläutern, den betreue ich noch.

Warum geht der LANAUTH-Trace zeitlich gesehen manchmal rückwärts?

Das Tracing-System im LCOS funktioniert dergestalt, daß irgendein Modul (hier Public-Spot bzw. der RADIUS-Server) eine Trace-Meldung beginnt, die Sachen reinschreibt und wenn es fertig ist, die Meldung en-bloc abschickt. Der Zeitstempel in der Meldung ist der Zeitpunkt, zu dem die Meldung begonnen wird, eine Ausgabe auf der Konsole erfolgt aber erst, wenn die Meldung komplett ist. Nun kann z.B. folgendes passieren:

- Ein Modul im LCOS beginnt eine Trace-Meldung, z.B. anläßlich der Verarbeitung einer Anmeldung am Public Spot.
- Während dieser Verarbeitung ruft es ein anderes Modul auf, das erzeugt selber eine weitere Trace-Meldung und schließt sie direkt ab.
- Rücksprung ins erste Modul, das schließt seinerseits seine Trace-Meldung (die zeitlich früher begonnen hat) ab und schickt sie ab.

Im Ergebnis taucht die Trace-Meldung, die später begonnen wurde, früher im Trace auf, weil sie als erste abgeschlossen wurde. Wir haben intern schon mal über den Effekt diskutiert, aber ein Umsortieren der Meldungen nach Zeitstempel würde zusätzlichen Aufwand bedeuten, Trace-Meldungen zurückzuhalten (und irgendwo zu speichern) und man könnte mit dem Verhalten genauso Fälle konstruieren, wo die Abfolge der Trace-Meldungen für den Kunden unlogisch erscheint.

P.S.: Es ist übrigens schade, dass es bei LANCOM keine Konvention darüber gibt, wie MAC-Adressen angegeben werden (also ob mit Doppelpunkt oder Bindestrich). Das erschwert die Suche im Fehlerfall. Das wäre mal ein Feature-Wunsch von mir...

Im Prinzip gibt's noch eine dritte, nämlich die ganz ohne Trennzeichen, wie MAC-Adressen in den LCOS-Menüs stehen. Die Schreibweise mit Bindestrichen ist - wenn man sich päpstlicher als der Papst gibt - die korrektere, weil diese anzeigt, daß die MAC-Adresse in kanonischer Darstellung ist, nur bei Ethernet und WLAN gibt es keinen Unterschied zwischen kanonischer und nicht-kanonischer Darstellung (in Gegensatz z.B. zu Token Ring oder FDDI). An manchen Stellen gibt ein Standard auch eine Schreibweise explizit vor, z.B. sind für die Called/Calling-Station-Id in RFC3580 explizit Bindestriche und Großbuchstaben (!) vorgeschrieben. Für Trace/Syslog-Meldungen könnte man das mal diskutieren, eine einheitliche Schreibweise zu benutzen, aber in den Menüs wird uns die Schreibweise ohne Trennzeichen auf absehbare Zeit erhalten bleiben. Der potentielle Ärger mit Kunden, die Konfig-Skripte zwischen verschiedenen LCOS-Versionen dann nicht mehr hin- und herjonglieren könnten, wäre einfach zu groß. Die kommt wohl noch aus IPX-Zeiten (das konnte LCOS ja auch mal routen), wo die 'Node-Id' gleich der MAC-Adresse ist, und in alten LCOS-Versionen wird an vielen Stellen auch noch dieser Begriff für MAC-Adressen benutzt...

Gruß Alfred

P.S.: Ich habe das mit Volumina > 4 GiB mal bei uns eingekippt. Da so eine Änderung aber auch Änderungen im LANconfig/LANmonitor nach sich zieht, kann ich sie nicht 'im Alleingang' durchziehen (auch wenn's mich jucken würde...), sondern muß darauf warten, daß das Produktmanagement sein 'go' gibt, daß auch die Kollegen dafür Zeit bekommen. Und da gilt leider das 'übliche Spielchen': Solange kein größerer Kunde das für sein Projekt haben möchte, passiert nichts...

[Update]

Ich habe das Thema mit dem Format für MAC-Adressen mal eingekippt, evtl. diskutieren wir das auf dem nächsten Entwicklermeeting.

[Jirka]

Hallo Alfred,

erst mal ganz vielen Dank.

Nach dem ersten Lesen Deines Postings zitiere ich mal das Referenzmanual:

Die Trace-Ausgaben sind leicht zeitverzögert zum tatsächlichen Ereignis, jedoch immer in der richtigen Reihenfolge. Das stört im Regelfall die Interpretation der Anzeigen nicht, sollte aber bei genaueren Analysen berücksichtigt werden.

Das hat sich bei mir so sehr eingeprägt, dass ich jetzt extrem stutzig wurde...

Ja, das Accounting startet für die zweite Benutzerkennung nicht. Deswegen schrieb ich ja auch, dass die entsprechenden Tabellen da keine Einträge für diesen Namen enthalten. Außer der Anlage des Namens passiert da sozusagen nichts.

Zu dem 4-GiB-Feature-Wunsch: Danke. Ich hätte es wie gesagt brauchen können, aber so dringend ist das auch wieder nicht. Es gibt ja noch QoS-Firewall-Regeln. Über kurz oder lang kommt da ein größerer Kunde, da bin ich mir sicher...

Viele Grüße,
Jirka

[alf29]

Moin,

Nach dem ersten Lesen Deines Postings zitiere ich mal das Referenzmanual:
Zitat:
Die Trace-Ausgaben sind leicht zeitverzögert zum tatsächlichen Ereignis, jedoch immer in der richtigen Reihenfolge. Das stört im Regelfall die Interpretation der Anzeigen nicht, sollte aber bei genaueren Analysen berücksichtigt werden.

Das hat sich bei mir so sehr eingeprägt, dass ich jetzt extrem stutzig wurde...

Zum einen versteht der Handbuchschreiber (leider) auch nicht immer alle Details, zum anderen ist eine 'Reihenfolge' ja immer definiert durch ein bestimmtes Sortierkriterium. Und das Sortierkriterium im LCOS ist aktuell die Zeit, zu der eine Trace-Meldung *abgeschlossen* wird, nicht wann sie begonnen wurde...

Gruß Alfred

[Jirka]

Hallo Alfred,

so, ich habe es gestern an den LANCOM-Support gegeben, mal sehen, was nun daraus wird.

Noch mal zwei Kleinigkeiten:

Unter /Status/TCP-IP/RADIUS-Server/Accounting/Accounting-Total kommt bei einem 'del *' 'Not practicable', gelöscht wird aber trotzdem.

Unter /Status/TCP-IP/RADIUS-Server/Accounting führt ein 'do Delete-Accounting-Total' zu:
usage: Delete-Accounting-Total <expression>
Not practicable
Warum löscht er nicht die ganze Tabelle, wenn man nichts angibt? Zu gefährlich? Was wäre außer einem '*' noch so sinnvoll denkbar?

Vielen Dank und viele Grüße,
Jirka

[alf29]

Moin,

Zu dem 4-GiB-Feature-Wunsch: Danke. Ich hätte es wie gesagt brauchen können, aber so dringend ist das auch wieder nicht.

Das hat es immerhin schon in die Feature-Planung zur 9.10 geschafft.Was nicht heißt, daß es auch wirklich in dieser Release umgesetzt wird...

Unter /Status/TCP-IP/RADIUS-Server/Accounting/Accounting-Total kommt bei einem 'del *' 'Not practicable', gelöscht wird aber trotzdem.

Ist für LCOS 9.00 behoben.

Unter /Status/TCP-IP/RADIUS-Server/Accounting führt ein 'do Delete-Accounting-Total' zu:
usage: Delete-Accounting-Total <expression>
Not practicable
Warum löscht er nicht die ganze Tabelle, wenn man nichts angibt? Zu gefährlich?

Sehe ich zumindest so.

Was wäre außer einem '*' noch so sinnvoll denkbar?

Ein Benutzername, dann wird nur der Eintrag für den jeweiligen Benutzer gelöscht.

Gruß Alfred

[Bernie137]

Hallo allerseits,

ich habe nun inzwischen Antwort vom Support erhalten:

Das Eingestellte Volumen-Budget unter WEBconfig -> Setup -> Public-Spot-Modul -> Authentifizierungs-Module den Wert -> Volumen-Budget, gilt nur für die "neuen" Authentifizierungsarten sprich SMS, E-Mail und Login nach Einverständniserklärung.

Bei der Voucher-Methode, muss der Wert manuell beim Anlegen der Voucher eingetragen werden.

Allerdings gibt es für diese Konfiguration auch schon ein Feature-Request, damit man das Volumen-Budget auch für die Voucher-Authentifizierung vordefinieren kann.

Dann hoffe ich gerne auf ein neues Release, welches diese Funktion einmal enthalten wird.

vg Bernie