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