[PATCH] kern/120958: no response to ICMP traffic on interface configured with a link-local address

James Snow snow at teardrop.org
Thu Mar 13 17:40:08 PDT 2008


On Fri, Feb 22, 2008 at 10:04:12PM +0000, Bruce M. Simpson wrote:
> I looked at this very briefly.
> 
> It's gnarly because in_canforward() is a candidate for inlining and is a 
> predicate which is being overloaded with different meanings by 
> ip_forward()/ip_input() and icmp_reflect().
> 
> So whilst the fix is most likely a 3 liner, it risks making the code 
> look crap. We genuinely don't want to forward 169.254.0.0/16 traffic, 
> however we genuinely need to reply to ICMP which originates from these 
> ranges.

Attached is a patch that fixes the failure to respond to ICMP for
link-local addresses.  I reworked the opening if statement in
icmp_reflect() to make it a touch more readable, and eliminated the call
to in_canforward() since its logic doesn't work in this context.

Also, I took a cue from the IN_LINKLOCAL() macro and added two new
macros to sys/netinet/in.h to perform checks for the loopback network
and the "zero" network.  IN_LOOPBACK() and IN_ZERONET(), respectively.

IN_ZERONET seems like a lousy name, but the only alternative I could
find in RFC3330 was "'this' net," and IN_THISNET wasn't an improvement.


-Snow

-------------- next part --------------
A non-text attachment was scrubbed...
Name: link-local-icmp.patch
Type: text/x-diff
Size: 1415 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080314/f20d693c/link-local-icmp.bin


More information about the freebsd-net mailing list