Date: Fri, 05 Apr 2002 04:08:54 +0100 From: Brian Somers <brian@freebsd-services.com> To: stephen macmanus <stephenm@bayarea.net> Cc: brian@freebsd-services.com, alan@clegg.com, ambrisko@ambrisko.com, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, imp@village.org, j@uriah.heep.sax.de, luigi@FreeBSD.ORG, nsayer@FreeBSD.ORG, ryand-bsd@zenspider.com, brian@freebsd-services.com Subject: Re: Your change to in.c to limit duplicate networks is causing trouble Message-ID: <200204050308.g3538sq7044360@hak.lan.Awfulhak.org> In-Reply-To: Message from stephen macmanus <stephenm@bayarea.net> of "Thu, 04 Apr 2002 17:36:51 -0800." <200204050136.RAA02010@shell4.bayarea.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > The code now avoids adding a host route if the interface address is
> > > > 0.0.0.0, and always treats a failure to add a host route as fatal
> > > > (previously, it masked EEXIST for some reason - I guessed because it
> > > > was trying to handle address re-assignment, but that works ok with
> > > > this patch).
> > >
> > >
> > > One effect of the masked EEXIST is to suppress the spurious error
> > > which occurs when adding an alias IP address (SIOCAIFADDR) on the
> > > same logical subnet as an existing IP address. Users have no way
> > > of knowing that it's actually safe to simply ignore the error in
> > > that situation, so the masking should probably be preserved.
> >
> > Hmm, thanks for the pointer.
> >
> > I think this now works - where it didn't before (although see
> > the new patch posted in response to Joergs mention of the sppp
> > problem).
> >
> > The lack of the EEXIST hack in my patch means that this will work as
> > before:
> >
> > ifconfig dc0 inet 172.16.0.5 netmask 0xffffff00
> > ifconfig dc0 inet 172.16.0.11 netmask 0xfffffff8
> >
> > Where connections to 172.16.0.1-172.16.0.7 and 172.16.0.16-172.16.0.255
> > come from 172.16.0.5 and connections to 172.16.0.8-172.16.0.15 come from
> > 172.16.0.11.
> >
> > After the above however,
> >
> > ifconfig dc0 inet 172.16.0.14 netmask 0xfffffff8
> >
> > will (correctly) fail in the patched code. It fails because the
> > gateway/netmask combination produces a duplicate key in the routing
> > table, returning an error from rtinit(). Previously, this failure
> > was masked by the EEXIST hack, allowing the interface address update
> > without a corresponding host route.
>
> All true. However, this change just redefines the desired behavior
> in this situation. The current EEXIST hack prevents a "meaningless"
> error message (in the sense that it is still possible to use the
> 172.16.0.14 address due to the existence of the earlier route).
>
> This patch just restores the original behavior from earlier BSD
> versions which reported an error for the reasons you mention.
>
> I guess it's just a judgement call as to which one is more desirable.
>
> > I believe the old behaviour becomes obviously wrong when someone then
> > deletes the 172.16.0.11 interface address, blowing away the
> > associated host route and leaving no routing table entry to talk to
> > the 172.16.0.14 address.
> >
> > So I don't think the old was was really safe after all :-/
>
> Definitely true. An ideal solution would involve some type of
> reference count for the route entry to maintain connectivity
> without attempting to add a duplicate route which would always
> cause an error.
>
> It would be even easier if users didn't setup redundant addresses
> like this one which serve no purpose! ;-) The people who do it,
> however, are also the most likely to think the resulting error
> indicates an actual problem with the new address assignment.
Well, it does serve a purpose - it allows the machine to accept
tcp connections on the .14 address (although udp requests get nicely
confused) and to bind to the .14 address before connect().
The resulting error *does* indicate that there's a problem with the
new address assignment; adding that .14 address with a conflicting
netmask should be considered wrong (and is treated as an error when
the EEXIST hack is removed). If they want to add another address to
the 172.16/28 subnet, they must use a netmask of 0xffffffff to get
the desired result.
The EEXIST hack is just permitting people to confuse themselves.
> Stephen
>
>
> ------------------
> Stephen Macmanus #include <std_disclaimer.h>
> stephenm@bayarea.net
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204050308.g3538sq7044360>