From owner-freebsd-current Mon Sep 11 00:32:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA12243 for current-outgoing; Mon, 11 Sep 1995 00:32:59 -0700 Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA12232 for ; Mon, 11 Sep 1995 00:32:48 -0700 Received: from utis156.cs.utwente.nl by utrhcs.cs.utwente.nl (5.x/csrelayMX-SVR4_1.1tmp/RB) id AA29933; Mon, 11 Sep 1995 09:32:25 +0200 Received: by utis156.cs.utwente.nl (4.1/RBCS-1.0.1) id AA29516; Mon, 11 Sep 95 09:32:17 +0200 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@FreeBSD.org (FreeBSD-current users), kieber@sax.de (Ulf Kieber) Subject: Re: SLIP routing problem In-Reply-To: Your message of "Fri, 08 Sep 1995 21:16:56 +0200." <199509081916.VAA14347@uriah.heep.sax.de> Date: Mon, 11 Sep 1995 09:32:16 +0200 Message-Id: <29515.810804736@utis156.cs.utwente.nl> From: Andras Olah Sender: current-owner@FreeBSD.org Precedence: bulk Joerg, Sorry, I don't know the exact solution to your problem, but at least I know where you have to look further. The host specific route in your routing table is a cloned route. These are generated to enable TCP to store host-specific metrics in the routing table. This facility is used by T/TCP and is by the congestion control/avoidance algorithms in standard TCP. My guess for the solution is that cloned routes should be automatically discarded if they're in conflict with the new route being added instead of preventing adding the new route. Since I'm not really familiar with the details of the routing code, I may be wrong. The route cloning code is Garrett's work, so probably he's the one who may know the right solution to your problem. You can find the code in netinet/in_rmx.c. Andras PS: netstat -ra will show you the cloned routes as well, by default they are suppressed. On Fri, 08 Sep 1995 21:16:56 +0200, J Wunsch wrote: [ ... ] > Sep 8 20:16:55 sax pppd[2010]: pppd 2.1.2 started by ppufo, uid 68 > Sep 8 20:16:55 sax pppd[2010]: Connect: ppp0 <--> /dev/ttyd1 > Sep 8 20:16:59 sax pppd[2010]: local IP address 193.175.26.126 > Sep 8 20:16:59 sax pppd[2010]: remote IP address 193.175.26.117 > Sep 8 20:16:59 sax pppd[2010]: ioctl(SIOCAIFADDR): Address already exists > > 44 sax:~> /sbin/route get 193.175.26.117 > route to: ufo > destination: ufo > gateway: sax-gw1 > interface: ed0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 0 0 0 0 0 0 0 3597 > > The interesting fact here is that "sax-gw1" is the _ethernet_ interface. > So now i've got the following picture: > > o at startup time of any pointopoint interface, all routes to that > interface are being cleared, and everything is started from scratch > [in_ifscrub() is called] > > o the link breaks, and all routes to the interface are being cleared > immediately > > o anyway, since there have been active connections over that link, > further packets with the destination to that pointopoint interface > will arrive; since the link is down, the only route that does apply > to them is the _default_ route, which points back to the world via > the ethernet > > o this somehow (?) creates a routing table entry for this host, tagged > for the (default route) ethernet interface, with an expiration time > of 3600 seconds The default route is referenced which creates a host specific cloned route. > o the pointopoint link comes back after redialing, but somehow (?) > the bogus route through the ethernet interface will not be cleared > by in_ifscrub() as it ought to be, and the subsequent attempt to > create the interface route for this address fails since the routing > code claims a route would already exist