Date: Fri, 23 Jun 2000 17:17:03 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: archie@whistle.com (Archie Cobbs) Cc: brian@Awfulhak.org (Brian Somers), archie@whistle.com (Archie Cobbs), phk@critter.freebsd.dk (Poul-Henning Kamp), tlambert@primenet.com (Terry Lambert), winter@jurai.net (Matthew N. Dodd), arch@FreeBSD.org, brian@hak.lan.awfulhak.org Subject: Re: Software detection of link integrity Message-ID: <200006231717.KAA25727@usr01.primenet.com> In-Reply-To: <200006222239.PAA94706@bubba.whistle.com> from "Archie Cobbs" at Jun 22, 2000 03:39:36 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > >> But a dial on demand line is a layered concept. You have a transient > > > > >> physical line with a layer on top of it which pretends to be a > > > > >> permanent line. > > > > > > > > > >Which unfortunately doesn't work with a dynamically assigned IP > > > > >number. > > > > > > > > That is a different story alltogether... > > > > > > On the InterJet, if it's dynamic IP and there is no other IP address > > > to use, we actually make one up! Once connected, we renumber the > > > interface of course. > > > > How do you deal with the first connection problem - where that first > > packet that causes the dial ends up with an incorrect src address ? > > > > ppp(8) does it when NAT is enabled by keeping the old interface > > address as an alias and just NATing the first connection. > > That packet eventually gets dropped/ignored, and subsequent packets > will be correct, because when/if the interface gets renumbered we > restart whatever proceses need to be restarted. We can do this > because we "know" what's running and what needs a restart in this > case. Whacking helpless processes over the head with a billy club is precisely the reason I sugested a "bind-to-interface-not-IP" socket type in the first place: it removes the cached data, and the need to beat innocent processes to death is based not on the cached data of the process, but on the cached data of the kernel in the IP address socket bind. It is the job of the system, not of the daemons, to reconcile the problem. Otherwise you repeat a huge amount of code in each and every daemon to handle the same situation, or, as you note, you have to stop and restart the daemons. I know that this can be worked around by using a TUN device, and establishing a point to point link using a link.local (IPv4 stateless autoconfiguration) or other non-routable address, and then NATing the PPP link on the other end to the real interface address, when available. This would work evn for ping packets. I was looking for something a bit more elegant, however, since if you do it using a TUN interace, and the TUN interface is up all the time from the point of view of the processes bound to the other end of it, then you don't get the normal resource track cleanup that you would get when a link went down. I guess you could propogate the link down event to the TUN interface to make this work, but that's a real kludge, and I don't think that anyone has implemented that yet. Without a propagation of the link down, you'd gett errors, like, say, an "ETRN.pl" run that is currently in progress hanging forever in a read from the TUN socket, should the real link go away in the middle of an operation, since there would be no TCP disconnect notification. This isn't a problem for UDP and ICMP, since they would presumably be retransmitted (unless there was a restriction on who could send them based on layering an exterior retransmission protocol on top of them), but for TCP, it's a killer. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006231717.KAA25727>