Radrelay: Zero Session length packets



Hello everyone.

I've been going a bit mad on this subject for a while. I am receiving proxied requests from my upstream provider and I am also doing authentication locally. The issue I've been experiencing has to do with this error handed to me from my upstream provider :

Tue Jan  2 09:47:05 2007 : Error: rlm_sql: Stop packet with zero session length.  (user 'celliott@<snip>', nas 'XXX.XXX.XXX.XXX')

It seems that this is always the second ISDN connection that has its session time set to zero.

Thu Dec 21 23:08:02 2006
        Acct-Session-Id = "00009F8B"
        Framed-Protocol = PPP
        Acct-Authentic = RADIUS
        X-Ascend-Connect-Progress = Call-Up
        X-Ascend-PreSession-Time = 1
        X-Ascend-Xmit-Rate = 64000
        X-Ascend-Data-Rate = 64000
        Acct-Session-Time = 0
        Acct-Input-Octets = 0
        Acct-Output-Octets = 0
        X-Ascend-Pre-Input-Octets = 233
        X-Ascend-Pre-Output-Octets = 102
        Acct-Input-Packets = 0
        Acct-Output-Packets = 0
        X-Ascend-Pre-Input-Packets = 6
        X-Ascend-Pre-Output-Packets = 4
        Acct-Terminate-Cause = Port-Unneeded
        X-Ascend-Disconnect-Cause = No-Reason
        Acct-Status-Type = Stop
        User-Name = "celliott@<cut>"
        Acct-Multi-Session-Id = "00005D0F"
        X-Ascend-Multilink-ID = 23823
        Acct-Link-Count = 2
        X-Ascend-Num-In-Multilink = 2
        Framed-IP-Address = XXX.XXX.XXX.XXX
        NAS-Port = 20423
        NAS-Port-Id = "Serial7/4:23"
        NAS-Port-Type = ISDN
        Calling-Station-Id = "0217624546"
        Connect-Info = "64000 HDLC"
        Called-Station-Id = "0000"
        Service-Type = Framed-User
        NAS-IP-Address = XXX.XXX.XXX.XXX
        Acct-Delay-Time = 30
        Vendor-1431-Attr-1 = 0x4449414c
        Proxy-State = 0x3936
        Client-IP-Address = QQQ.QQQ.QQQ.QQQ
        Hint = "KING"
        Acct-Unique-Session-Id = "2b29fa83d47585d9"
        Timestamp = 1166735282

What I would like, is to avoid radrelay for those packets as it only jams up the radrelay queue when this happens while the logging to sql works.
The config below is insuffiecient as this is what leads me up to a radrelay jam.

[root@CCCCC:/var/log/freeradius/radacct] ls -hal
total 6.4M
drwxr-xr-x 2 freerad freerad  120 2006-12-21 23:08 .
drwxr-xr-x 3 freerad freerad  872 2006-12-31 06:30 ..
-rw------- 1 freerad freerad 6.3M 2007-01-02 08:45 detail-radrelay
-rw------- 1 freerad freerad 1.2K 2006-12-21 23:08 detail-radrelay.work

BTW is there a way to specify an OR / AND operator below for acct_users? So that I can say something like

    DEFAULT [  Client-IP-Address == "XXX.XXX.XXX.XXX" ||
                          Client-IP-Address == "YYY.YYY.YYY.YYY" ||
                          Client-IP-Address == "ZZZ.ZZZ.ZZZ.ZZZ" &&
                           Acct-Session-Time == "0" ] , Acct-type := "REMOTE-AUTH"

acct_users
# Do not radrelay these packets:
DEFAULT Acct-Session-Time == "0", Acct-type := "REMOTE-AUTH"

# This Configuration prevents Accouting loops of a two-way radrelay sync
#  [o] Radrelay must be sending accounting info from IP(s) below
#       on the other Radius server(s)
DEFAULT Client-IP-Address == "XXX.XXX.XXX.XXX", Acct-type := "REMOTE-AUTH"
DEFAULT Client-IP-Address == "YYY.YYY.YYY.YYY", Acct-type := "REMOTE-AUTH"
DEFAULT Client-IP-Address == "ZZZ.ZZZ.ZZZ.ZZZ", Acct-type := "REMOTE-AUTH"
# Everyone else must still be radrelay'ed
DEFAULT Acct-type := "LOCAL-AUTH"

radiusd.conf
accounting {
        # 2006-09-27: EPP
        # If Acct-Type is LOCAL-AUTH then log to sql module AND to detail file
        # for radrelay - accounting sync daemon
        Acct-Type LOCAL-AUTH {
            radrelay
            sql
        }
        # 2006-11-24: EPP
        # If accounting packet is from one of our other radius servers, then
        # just log it to sql...otherwise we will end up with an Accouting packet
        # storm/loop.
        Acct-Type REMOTE-AUTH {
            sql
        }
[snip...]

-- 
Kind Regards
Etienne


This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.