|Summary:||[netinet] [patch] IP Encapsulation mask_match() returns wrong results|
|Product:||Base System||Reporter:||Qiao Yang <qyang>|
|Component:||kern||Assignee:||freebsd-net mailing list <net>|
|Severity:||Affects Only Me||CC:||ae|
Description Qiao Yang 2006-04-03 19:40:16 UTC
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 tunnel end. Fix: When doing byte-array comparison, use sockaddr.sa_data instead of sockaddr. How-To-Repeat: Just read the code.
Comment 1 Bruce M Simpson 2006-09-28 18:07:34 UTC
I don't quite get this. Test case attached.
Comment 2 Bruce M Simpson 2006-09-28 18:22:46 UTC
I guess a patch for the desired behaviour would look something like this? More detail needed...
Comment 3 Bruce M Simpson 2006-09-28 18:25:33 UTC
State Changed From-To: open->feedback 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!
Comment 4 Bruce M Simpson 2006-09-28 18:30:09 UTC
Responsible Changed From-To: freebsd-bugs->net over to net for more discussion
Comment 5 John-Mark Gurney 2006-10-03 00:14:49 UTC
Responsible Changed From-To: net->freebsd-net move w/ the others...
Comment 6 Mark Linimon 2008-03-02 02:44:10 UTC
State Changed From-To: feedback->open Note that feedback was received some time ago.
Comment 7 Hiren Panchasara 2017-01-05 22:07:37 UTC
Provided feedback is missing from the PR. Can someone add that? Is this still valid?
Comment 8 Andrey V. Elsukov 2017-01-06 13:47:30 UTC
As I see, the described problem is still there. But currently there are no consumers of the encap_attach KPI in the tree.
Comment 9 Eitan Adler 2018-05-28 19:41:52 UTC
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: 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.