[ previous ] [ next ] [ threads ]
 From:  "Jonathan De Graeve" <Jonathan dot DeGraeve at imelda dot be>
 To:  <m0n0wall at lists dot m0n0 dot ch>, <m0n0wall dash dev at lists dot m0n0 dot ch>
 Subject:  M0N0wall & RFC2866 compliance
 Date:  Tue, 22 Aug 2006 20:01:32 +0200
While programming the radius stuff I followed the RFC as much as


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


From the RFC2866


5.7.  Acct-Session-Time
      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)         |
      46 for Acct-Session-Time.
      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
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.



Jonathan De Graeve
Network/System Engineer

Imelda vzw
Informatica Dienst
Jonathan dot de dot graeve at imelda dot be