[Chillispot] Lack of Accounting ON/OFF in ChiliSpot RADIUS implementation

[Peter Nixon]

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 at chillispot.org
> http://chillispot.org/mailman/listinfo/chillispot_chillispot.org



-- 

Peter Nixon
http://peternixon.net/