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 > [email protected] > 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. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
