From owner-freebsd-net Wed Nov 17 13:38:39 1999 Delivered-To: freebsd-net@freebsd.org Received: from titanic.medinet.si (titanic.medinet.si [212.18.32.66]) by hub.freebsd.org (Postfix) with ESMTP id E491414C8D for ; Wed, 17 Nov 1999 13:38:34 -0800 (PST) (envelope-from blaz@amis.net) Received: by titanic.medinet.si (Postfix, from userid 1000) id 06ECC55EE; Wed, 17 Nov 1999 22:38:32 +0100 (CET) Date: Wed, 17 Nov 1999 22:38:31 +0100 (CET) From: Blaz Zupan To: Brian Somers Cc: freebsd-net@FreeBSD.org Subject: Re: rinit: wrong ifa (0xc09ba580) was (0xc0854880) - candidate for removal In-Reply-To: <199911172128.VAA02251@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Nov 1999, Brian Somers wrote: > Nothing's changed of late here. Ppp will use whatever ``hostname'' > resolves to as a default local address unless a ``set ifaddr'' is > done. As you've got a ``set ifaddr'', I find it surprising that > you see this message. Actually, I guess you probably did not notice the rest of my message. IMHO the behaviour change in ppp is, that now when ppp receives an IP address (assigned by the dialup server it is dialing to), it does NOT replace the IP address on the tunX interface, but simply adds it as an alias on the interface. So every time you dial the internet, the interface receives another IP address as an alias. In our case, after a day or two, there are about 60 IP aliases assigned on the tunX interface. Previous versions of ppp simply _replaced_ the IP address that was present on the interface before a new IP was assigned by the ppp peer. For example, after the machine is freshly rebooted, we see this: gatekeeper# ifconfig tun0 tun0: flags=8051 mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffffff After we dial the internet, the above addresses are _not_ replaced, but the new addresses are added as an alias to the interface: gatekeeper# ifconfig tun0 tun0: flags=8051 mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xffffffff inet 212.18.37.102 --> 212.18.32.20 netmask 0xffffff00 As time goes on, those secondary addresses pile up on the interface. I believe that's why I get the "wrong ifa" message. Is there any reasoning behind the secondary addresses or is this behaviour a bug? Regards, Blaz Zupan, blaz@amis.net, http://home.amis.net/blaz/ Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message