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

[arr2036]

Issue type

.

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

Defect

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

[alandekok]

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.