From owner-freebsd-arch Thu Apr 4 19: 9:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 5EC9B37B41D; Thu, 4 Apr 2002 19:09:11 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.2/8.11.6) with ESMTP id g3538xCu002757; Fri, 5 Apr 2002 04:08:59 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.2/8.12.2) with ESMTP id g3538sq7044360; Fri, 5 Apr 2002 04:08:54 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200204050308.g3538sq7044360@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: stephen macmanus 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 In-Reply-To: Message from stephen macmanus of "Thu, 04 Apr 2002 17:36:51 -0800." <200204050136.RAA02010@shell4.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Apr 2002 04:08:54 +0100 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > 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 > stephenm@bayarea.net -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message