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 > [EMAIL PROTECTED] > http://chillispot.org/mailman/listinfo/chillispot_chillispot.org -- Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html