[RADIATOR] unpackRadiusAttrs eating useful data

[Hugh Irvine]

Hello Tarko -

Thanks for your mail.

The problem here is due to "00" being used in an ASCII string.

RFC4679 (http://www.ietf.org/rfc/rfc4679.txt) indicates that this attribute should be a printable string - hence our definition as "string".

If you want to get at the binary data you should change the dictionary definition to "binary".

Although a better solution would be to get the attribute sent in the fashion indicated by the RFC.

hope that helps

regards

Hugh


On 17 Aug 2010, at 02:27, Tarko Tikan wrote:

> hey,
> 
> We've just hit a strange issue and wondering if we are to blame or is unpackRadiusAttrs in Radius.pm really eating useful data in vendor-specific VSAs. We are sending Cisco DHCP circuit ID in ADSL-Agent-Circuit-Id (3561.1, described in dictionary as string). This is unpacked in preauth hook like this: unpack("CCCCCC", $cid) and then used in SQL queries and there doesn't seem to be any problems with this. Until today :)
> 
> Specific example:
> Sending 000405DC010A in CID works but sending 000405DC000A is turned into 000405DC0A (5th octet 00 missing). Unfortunately last 2 octets contain the most useful data, 00 being the card number and 0a the port.
> 
> I added some debugging into Radius.pm method unpackRadiusAttrs into the "else { # Other vendor-specific" part around "$value =~ s/\0+$//" like this:
> 
> &main::log($main::LOG_WARNING, "pre strip: " . join(' ', map {sprintf "%02x", $_} unpack('C16', $value)), $self);
> $value =~ s/\0+$// if $atype eq 'string';
> &main::log($main::LOG_WARNING, "post strip: " . join(' ', map {sprintf "%02x", $_} unpack('C16', $value)), $self);
> 
> and when sending request, following is logged:
> Mon Aug 16 16:09:46 2010: WARNING: pre strip: 00 04 05 dc 00 0a
> Mon Aug 16 16:09:46 2010: WARNING: post strip: 00 04 05 dc 0a
> 
> This doesn't look something that should be happening, I've also verified the "fix" by uncommenting the line and everything magically works. Anyone has idea or explanation why is this happening?
> 
> Radiator version is 4.7 (this happened with old versions aswell and there hasn't been any code change regarding this). I've also attached a radiator tracelevel 5 packet dump and wireshark radius package dump. Just to make sure, this part of the code is ran before any user hooks so I don't think we have a way to screw things up ourselves (later we actually do rewrite the attributes into more useful format and throw away the trash).
> 
> -- 
> tarko
> <raddebug.txt>_______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB: 

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets), 
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.