After receiving your mail, I decided to do a little more ChilliSpot testing. a) Chillispot does not send an accounting ON packet on startup b) Chillispot does not send an accounting OFF packet on shutdown c) Chillispot does send an accounting Stop packet with "Acct-Terminate-Cause = NAS-reboot" for active sessions when shutdown cleanly. Now, c) is usefull in situations when you cleanly shutdown chillispot as it gives a proper stop record with the most information of the 3 options including final data counters. Instead of c) it would actually have been much easier to implement b) so I congratulate the chillispot author for his efforts. I still recommend that b) also be implemented however as it allows easy reporting of when the NAS was last shutdown. HOWEVER, If I only had the choice of ONE of the three options, I would pick option a) as it guarantees that the RADIUS server's idea of the active sessions will always be reset when the NAS boots. It is also the only one of the three options which (network conditions allowing) is always going to be delivered to the RADIUS server, as both b) and c) will not be sent in the case of a power outage or lockup of the NAS. To recap, ChilliSpot SHOULD send an accounting ON packet to the RADIUS server when it boots, and probably should send an OFF packet upon shutdown, although this is not critical given that it cleanly closes the sessions anyway. IF an accounting OFF packet is sent upon shutdown, it should be sent LAST, after all the session Stop packets are sent, otherwise the OFF packet will close all the active sessions on the RADIUS server, and the session Stop packets will generate duplicate SQL records as the radius server will err on the side of caution and prefer to duplicate records in the DB instead of possibly losing a session for which it did not receive a Start record. Regards Peter On Tue 17 Jul 2007, sophana wrote:

I'm receiving sometimes radius session stop requests with the terminate cause "NAS-reboot". Isn't it what you want? I don't know why it doesn't always work. The problem is that it can't work reliably. If there is a power off or whatever other reason, you don't get your information. Only the "on" information would be useful.

Personally, I use trigger a periodic task that check open sessions which haven't received alive requests since some time and close them. If the user logs back before, you can detect that based on the calling/called mac addresses and nasId and force the shutdown.

Peter Nixon a écrit :

...

Hi Guys

I am one of the FreeRADIUS developers, as well as the openSUSE network:AAA project founder. As part of that project I also maintain ChilliSpot rpms.

Over that last 6-9 months we have been getting increasing numbers of queries regarding ChilliSpot on the FreeRADIUS mailing list. One of the common queries we get is how to make FreeRADIUS "understand" when a chillispot NAS has been rebooted and all the users have been kicked off, but no accounting stop records have been received.

I have taken a look at ChilliSpot and it generates an Auth packet similar to the following on initial start:

rad_recv: Access-Request packet from host 192.168.2.67 port 2050, id=0, length=113 User-Name = "chillispot" User-Password = "chillispot" NAS-IP-Address = 192.168.1.7 Service-Type = Administrative-User NAS-Identifier = "demo" Called-Station-Id = "00:11:70:4f:01:aa" NAS-Port-Type = Wireless-802.11 Message-Authenticator = 0xdb58714687848c2c42bc8f5e91069891

However it does not generate an Accounting OFF record when it is shut down, nor an Accounting ON record when it is started. If these 2 features could be added to chillispot (10 or 20 lines of code at most given that you already generate an Auth packet on boot) then FreeRADIUS will know to automatically clear all active sessions from the accounting table (With its default configuration). Even if the power is lost from the device running chillispot if it sends an Accounting ON record on boot FreeRADIUS runs the following query on the accounting table:

accounting_onoff_query = "UPDATE ${acct_table1} \ SET AcctStopTime = ('%S'::timestamp - '%{Acct-Delay-Time:-0}'::interval), \ AcctSessionTime = (EXTRACT(EPOCH FROM ('%S'::timestamp with time zone - AcctStartTime::timestamp with time zone \ - '%{Acct-Delay-Time:-0}'::interval)))::BIGINT, \ AcctTerminateCause='%{Acct-Terminate-Cause}', AcctStopDelay = 0 \ WHERE AcctSessionTime IS NULL AND AcctStopTime IS NULL AND NASIPAddress= '%{NAS-IP-Address}' AND AcctStartTime <= '%S'::timestamp"

And this query on the IP lease table:

on-clear = "UPDATE ${ippool_table} \ SET nasipaddress = '', pool_key = 0, callingstationid = '', \ expiry_time = 'now'::timestamp(0) - '1 second'::interval \ WHERE nasipaddress = '%{Nas-IP-Address}'"

If the chillispot developers could add this basic feature, it would: a) be usefull to chillispot users b) reduce some questions to the FR mailing list which we can currently do nothing about :-)

I would be happy to help in any way necessary if you have any questions about this RADIUS feature.

Regards

_______________________________________________ ChilliSpot mailing list ChilliSpot@chillispot.org http://chillispot.org/mailman/listinfo/chillispot_chillispot.org

-- Peter Nixon http://peternixon.net/