Radrelay: Zero Session length packets

[Etienne Pretorius]

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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20070102/249ae249/attachment.html>