As documented in the code,
* We prioritize the matches by using bit length of the
* matches. mask_match() and user-supplied matching function
* should return the bit length of the matches (for example,
* if both src/dst are matched for IPv4, 64 should be returned).
* 0 or negative return value means "it did not match".
But in mask_match(), it use "struct sockaddr" to do byte-array comparison
when applying the network mask. The problem is that this mask is applied to
the whole 'struct sockaddr' data structure. Because 'struct sockaddr' includes
both sa_len and sa_family, the result match_len will not be 0 even when the
network mask is 0.0.0.0. And, if both src/dst are matched for IPv4, 88 instead
of 64 is returned.
This causes problem for protocols which want to set 0.0.0.0 netmask on the
When doing byte-array comparison, use sockaddr.sa_data instead of sockaddr.
How-To-Repeat: Just read the code.
I don't quite get this. Test case attached.
I guess a patch for the desired behaviour would look something like this?
More detail needed...
Can you confirm the issue still exists in RELENG_6?
I see no code changes but I can't seem to reproduce it with the
test case I wrote, and more information would be very welcome!
over to net for more discussion
move w/ the others...
Note that feedback was received some time ago.
Provided feedback is missing from the PR. Can someone add that?
Is this still valid?
As I see, the described problem is still there. But currently there are no consumers of the encap_attach KPI in the tree.
For bugs that match the following
- Status Is In progress
- Untouched since 2018-01-01.
- Affects Base System OR Documentation
Reset to open status.
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.