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@alfr01corad ~]$ radpwtst -trace -s 127.0.0.1 -auth_port 2645 -secret secret -noacct -dictionary cfg/dictionary -user user@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@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@newserver ~]$ radpwtst -trace -s 127.0.0.1 -auth_port 2645 -secret secret -noacct -dictionary ./dictionary -user user@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?
_______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator