On 4 Jul 2006, at 17:01, Alan DeKok wrote:
Graeme Hinchliffe <[EMAIL PROTECTED]> wrote:
Further to this, I have just noticed that this doesn't seem to just
be restricted to the IP address, but also the Session ID field.
Instead of displaying the session ID as say
0202FFFF68001A6C-44A618FF
I am seeing:
0x303230324646464636383030314136432d3434413631384646
Which is the hex dump of the ASCII string. 0x30 == '0'.
indeed.
I think the dictionaries from 1.1.2 didn't get installed, so many of
the attributes default to type "octets".
I have found entries which indicate this has happened prior to my
upgrade to 1.1.2, and also checking I can see that all the dictionary
files are the versions that came with the 1.1.2 code.
What would cause FreeRADIUS to output in this manner, we have
summized that if it sees a none ASCII byte in the field it would
convert the whole field into a hex representation to stop trying to
write binary to the db. If this is the case then it could well be a
bug with the hardware and we can chase the vendor and apply a patch
to the code in freeradius until we get it fixed.
Also, when I ran the code in debug mode (-X switch) I never saw one
occurence of this problem in the screen output or the postgres logs.
Of course computers being what they are it's most likley that it was
just a fluke, but at what point would FreeRADIUS decide to convert
the output to a hex representation?
our NASes are all Redbacks, SE400's and SMS10K's
Thanks
Graeme
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
