[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