[RADIATOR] radpwtst changes from v4.9 to v.14 (or Starent atributes?)

Fri Feb 13 09:59:28 CST 2015

Hi everyone

We've been running v4.9 on some of our production systems for quite a while
now. The authentication instance is receiving packets from a Starent device
forwarded to a Radiator instance on 4.9 and the authentication packet I get
on my side looks something like this:

Code:       Access-Request
Identifier: 105
Authentic:  xxxxxxxxx
Attributes:
        Calling-Station-Id = "xxxxxx"
        User-Name = ""
        NAS-IP-Address = xx.xx.xx.xx
        SN-Software-Version = "15.0 (xxxx)"
        Service-Type = Framed-User
        Framed-Protocol = 7
        NAS-Port-Type = 18
        SN1-GTP-Version = GTP_VERSION_1
        3GPP-IMSI = "xxxxxxxxxxxxxxx"
        3GPP-IMSI-MCC-MNC = "xxxxx"
        3GPP-NSAPI = "5"
        3GPP-Selection-Mode = "0"
        3GPP-Charging-Id = 211231230
        3GPP-GPRS-QoS-Profile = "05-13921F7396D1FE7482FFFF004F00"
        3GPP-Charging-Characteristics = "0800"
        Called-Station-Id = "apn_name_here"
        3GPP-SGSN-Address = xx.xx.xx.xx
        3GPP-SGSN-MCC-MNC = "xxxx"
        3GPP-GGSN-Address = xx.xx.xx.xx
        3GPP-GGSN-MCC-MNC = "xxxx"
        3GPP-Negotiated-DSCP = ""
        3GPP-RAT-TYPE = 1
        3GPP-User-Location-Information = <1>b<248><16><0><11>8<18>
        3GPP-MS-Timezone = ""
        3GPP-IMEISV = "35899xxxxxxx"
        3GPP-PDP-Type = 0
        CHAP-Challenge = xyzxyz
        CHAP-Password = xyzxyz
        SN1-Service-Type = GGSN
        NAS-Port = 167985
        3GPP2-Carrier-ID = "xxxx"
        3GPP2-GMT-Timezone-Offset = ""
        NAS-Identifier = "NAS1GG"

On the configuration file, this kind of authentication requests is handled
by a <Handler SN-Software-Version = /\d/> which, well, does its magic.

I managed to narrow down the configuration to the following:

# begin config

LogDir          /tmp/
DbDir           /app/users/radiusd
PidFile         %L/pid
LogFile         %L/debug

AuthPort                2645
AcctPort

DictionaryFile          %D/dictionary

<Client DEFAULT>
        Secret                  secret
        DupInterval             0
</Client>

<AuthBy INTERNAL>
        Identifier      YES
        AuthResult      ACCEPT
</AuthBy>

<Handler SN-Software-Version = /\d/ >
        RewriteUsername         s/^([^@]+)@(\S+)$/$2/
        RewriteUsername         tr/A-Z/a-z/
        AuthBy                          YES
</Handler>

# end config file

Perhaps one of the relevant bits here is the SN-Software-Version attribute.
I haven't seen it described anywhere else, it's not on the standard
Radiator dictionary (not even on the new one with Starent attributes on
4.14). It's defined on the source RADIUS server and on the target RADIUS
server dictionaries  as:

VENDORATTR      8164    SN-Software-Version     288     string

So on 4.9, with a minimal request like the following, I get the following:

[radiusd at alfr01corad ~]$ radpwtst -trace -s 127.0.0.1 -auth_port 2645
-secret secret -noacct -dictionary cfg/dictionary -user user at domain
 -password 6325698514 SN-Software-Version=1
Fri Feb 13 15:45:23 2015: DEBUG: Reading dictionary file 'cfg/dictionary'
sending Access-Request...
Fri Feb 13 15:45:23 2015: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 2645 ....
Code:       Access-Request
Identifier: 98
Authentic:  <18>|<237><11><170><154><128><129><21><3><255>#@l<205><29>
Attributes:
        User-Name = "user at domain"
        Service-Type = Framed-User
        NAS-IP-Address = 203.63.154.1
        NAS-Identifier = "203.63.154.1"
        NAS-Port = 1234
        Called-Station-Id = "123456789"
        Calling-Station-Id = "987654321"
        NAS-Port-Type = Async
        User-Password = "<229>nJ<161>D*<133>!0<9>4Q<171><237><147>!"
        SN-Software-Version = "1"

Fri Feb 13 15:45:23 2015: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 2645 ....
Code:       Access-Accept
Identifier: 98
Authentic:  i<237>E<127>:w<248><184><253><189><215><<22><139>F<24>
Attributes:

OK

Now the real issue began when we tried to replicate the setup on 4.14 - we
tried to replicate the real requests using radpwtst.
But for some reason the requests are not being handled as supposed so we
dug further.

Narrowing it down to the same configuration I described above, on 4.14, the
same radpwtst requests dies immediately, not reaching the RADIUS server,
with the following looks:

[radiusd at newserver ~]$ radpwtst -trace -s 127.0.0.1 -auth_port 2645 -secret
secret -noacct -dictionary ./dictionary -user user at domain  -password
6325698514 SN-Software-Version=1
Fri Feb 13 15:52:15 2015: DEBUG: Reading dictionary file './dictionary'
Can't use an undefined value as an ARRAY reference at
/usr/lib64/perl5/vendor_perl/Radius/RDict.pm line 271.

By changing the vendorByNum function at RDict.pm we managed to get it
working, but it doesn't feel right to be changing the code for something
that oughta be backwards compatible.

sub vendorByNum
{
    my ($self, $num) = @_;
#    return @{$self->{VendorNum}->{$num}};
    return {$self->{VendorNum}->{$num}};
}

The release notes mention something about changes on the way Starent
attributes are handled, but it doesn't make sense, since all we're doing is
using the dictionary to convert the textual attribute to a attribute
number, encoding it and sending it through radpwtst. It wasn't supposed to
be broken.

Any thoughts on this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20150213/4fb9dee8/attachment.html 