Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

radclient reports success where the filter is empty except for Response-Packet-Type, even if the response packet from FreeRADIUS contains attributes #3086

arr2036 opened this issue Oct 30, 2019 · 1 comment


Copy link

@arr2036 arr2036 commented Oct 30, 2019

Issue type


  • Defect - Unexpected behaviour (obvious or verified by project member).


How to reproduce the issue

Create a radclient filter containing only Response-Packet-Type == Access-Accept.

Pass it to radclient with -f <input_file>:<filter_file>.

Configure FreeRADIUS to include a Reply-Message attribute in its response.

Observe how the response packet passes the filter even though there's no line accounting for the Reply-Message.

This could just be a documentation issue, and we could allow all attributes by default, and only perform matching on the ones specified.

Unsure whether this is truly in v4.0.x. It was originally observed in v3.0.x HEAD

Copy link

@alandekok alandekok commented Oct 31, 2019

It's likely that the filter is matching things, and there's no default saying "anything which isn't in the filter is not a match"

I think it works that way by intention, even if it is surprising here. i.e. filtering packets in radsniff, even when the packets contain other attributes which aren't in the filter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants