> > > > 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>
> [EMAIL PROTECTED]
--
Brian <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
