While programming the radius stuff I followed the RFC as much as
possible.

 

Apparently following it that strictly gives a negative backside
especially in the session-timeout.

 

From the RFC2866

 

5.7.  Acct-Session-Time
 
   Description
 
      This attribute indicates how many seconds the user has received
      service for, and can only be present in Accounting-Request records
      where the Acct-Status-Type is set to Stop.
 
   A summary of the Acct-Session-Time 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
 
      46 for Acct-Session-Time.
 
   Length
 
      6
 
   Value
 
      The Value field is four octets.
 
According to the RFC its only allowed to specify a Session-Time
attribute into the latest STOP packet.
This removes the 'easy' configuration of implementing prepaid cards
(since you add complexity to the SQL query needed)
 
Testing in real life situations using freeradius gives tells me the
radius server doesn't complain when you DO add it to an interim update
package.
Although RFC2869 (radius extensions) doesn't tell anything about changes
in Acct-Session-Time I'm still wondering if other radius servers used
around here do any protocol sanity checks. If not I'm going to change
the current behaviour from only sending session-time in a stop packet to
every interim/stop packet.
 
 
J.

 

 

--
Jonathan De Graeve
Network/System Engineer

Imelda vzw
Informatica Dienst
015/50.52.98
Jonathan dot de dot graeve at imelda dot be