Date: Thu, 4 Apr 2002 17:36:51 -0800 From: stephen macmanus <stephenm@bayarea.net> To: brian@freebsd-services.com, stephenm@bayarea.net Cc: 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 Subject: Re: Your change to in.c to limit duplicate networks is causing trouble Message-ID: <200204050136.RAA02010@shell4.bayarea.net>
next 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.
Stephen
------------------
Stephen Macmanus #include <std_disclaimer.h>
stephenm@bayarea.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204050136.RAA02010>