lib/filters.c returning incorrect length filters

Mitchell, Michael J Michael.Mitchell at team.telstra.com
Wed May 3 06:32:34 CEST 2006


Hi freeRADIUS developers,

Firstly, a disclaimer/confession. The analysis below is based on
freeRADIUS version 1.0.1, however I can't see any significant
differences between this and CVS HEAD in relation to this issue. The
patch I have attached is based on CVS HEAD, but is unfortunately
untested. Please feel free to tell me its not an issue in CVS HEAD any
more due to other changes, or to go away and test it first, but with my
current work load I'm not sure when I will be able to do that.

While testing Ascend Data Filters (IP filters) it became apparent that
freeRADIUS was sending 32 byte long Ascend-Data-Filter attributes. In
our case our NAS's expect 24 byte IP filters (while some newer NAS's
apparently expect 26 bytes?) and complains when its gets something
longer.

Taking a look at lib/filters.c it became apparent that the code makes no
distinction between the various filter types when assigning the length
of the attribute.

The attached patch helps address this issue by assigning the length of
the string (or vp_filter) attribute based on the actual size of the
filter type (and corresponding changes for printing Ascend Data Filter
attributes).

A bit of reading on the web revealed that some other RADIUS servers
allow the fill size at the end of an IP filter to be configured (to
allow for 24 or 26 byte filters more easily). This looks a bit difficult
in freeRADIUS due to the code being in libradius rather than the core.
It is also something that would need to be configured on a per client
basis, which is rather nasty.

I believe there is also a bug in the print_abinary() function. It was
comparing the vp->length to sizeof(filter), but filter is now a pointer.
Also, it is not possible to do a "!=" comparison here, as different
filter types have different lengths. At worst we can do a ">"
comparison, a better solution would be to do the comparison based on the
actual filter type further down the code. My patch compares the length
of the attribute against the filter type.



regards,
Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filters.c.patch
Type: application/octet-stream
Size: 6345 bytes
Desc: filters.c.patch
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20060503/c3c0f2a1/attachment.obj>


More information about the Freeradius-Devel mailing list