Date: Sat, 12 Jul 2003 14:03:13 +0200 (CEST) From: Dirk-Willem van Gulik <dirkx@webweaving.org> To: freebsd-hackers@freebsd.org Cc: techniek@lijst.WirelessLeiden.NL Subject: icmp-redirect and wi(4) Message-ID: <20030712135226.O96627-100000@foem>
next in thread | raw e-mail | index | archive | help
I am trying to track down the source of lots of icmp-redirect confusion.
And if possible get confirmed that my understanding of the IP fundamentals
is lacking.
In www.wirelessleiden.nl on wi(4) - we've got interfaces like this on the
HostAPI side:
wi0: flags=8088843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 172.16.0.38 netmask 0xfffffffc broadcast 172.16.0.39
inet 172.16.0.41 netmask 0xfffffffc broadcast 172.16.0.43
inet 172.16.0.34 netmask 0xfffffffc broadcast 172.16.0.35
inet 172.16.0.53 netmask 0xfffffffc broadcast 172.16.0.55
inet 172.16.0.81 netmask 0xfffffffc broadcast 172.16.0.83
....
on some of the bigger central nodes (i.e. those on top of churches which
see large part of the city).
Now a ping from
172.16.0.37 --> 172.16.0.42
i.e leaves on either side of these central-ish nodes elicts lots if icmp
redirects. Now from sys/netinet/ip_input.c I gather:
/*
* If forwarding packet using same interface that it came in on,
* perhaps should send a redirect to sender to shortcut a hop.
* Only send redirect if source is sending directly to us,
* and if packet was not source routed (or has any options).
* Also, don't send redirect if forwarding using a default route
* or a route modified by a redirect.
*/
if (rt->rt_ifp == m->m_pkthdr.rcvif &&
(rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 &&
satosin(rt_key(rt))->sin_addr.s_addr != 0 &&
ipsendredirects && !srcrt && !next_hop)
{....
So should this not be tightened further to take into account aliased
subnets on the same interfaces ? Or is there some fundamental reason why
what I am doing is wrong - and do I have to switch off redirect ?
Now I can get around this issue with a
sysctl -w net.inet.ip.redirect=0
(as opposed to a /etc/rc.conf:icmp_drop_redirect=YES) but then things
(still) go haywire as soon as the sending, middle or receiving interface
is in promisc mode (i.e. after a traceroute); as either interface realized
there is a shorter route possible.
Now why is this, or rather, is this intended behaviour; or should the
ip(4) or wi(4) be made ware of promisc mode on the iface and be taught to
behave differently ?
This is well past the end of my limited understanding of IP - so any and
all education welcome !
Dw
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030712135226.O96627-100000>