Date: Tue, 20 Jun 2000 21:24:25 +0100 From: Brian Somers <brian@Awfulhak.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Brian Somers <brian@Awfulhak.org>, "Matthew N. Dodd" <winter@jurai.net>, Terry Lambert <tlambert@primenet.com>, arch@FreeBSD.ORG, brian@hak.lan.awfulhak.org Subject: Re: Software detection of link integrity Message-ID: <200006202024.VAA66394@hak.lan.Awfulhak.org> In-Reply-To: Message from Poul-Henning Kamp <phk@critter.freebsd.dk> of "Tue, 20 Jun 2000 22:02:32 %2B0200." <55570.961531352@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <200006201950.UAA65946@hak.lan.Awfulhak.org>, Brian Somers writes:
> >> On Tue, 20 Jun 2000, Terry Lambert wrote:
> >> > Would this be a useful thing to build into ifconfig?
> >>
> >> Ideally, network drivers shouldn't set the IFF_UP flag until the link is
> >> actually up.
> >
> >Unless of course the driver (or something behind it) wants to bring
> >the link up on demand.
>
> We actually have major suckage in this corner. I have tried to
> edge towards more intelligent behaviour:
>
> Look at if_up(), if_route() and IFF_SMART.
>
> Basically the idea is that an "IFF_SMART" interface will fiddle
> the up/down-ness of individual protocols as makes sense.
>
> I did this entirely for sppp, but it applies fully to any other
> interface: an ethernet should remain configured but remove the
> routes if the cable is unplugged.
No, I think the aim here is to keep the routes but to adjust them so
that they're via an interface rather than an IP number, something
like:
default tun0 UGSc 11 503 tun0
127.0.0.1 127.0.0.1 UH 0 12837 lo0
172.16/24 link#1 UC 0 0 de0 =>
172.16.0.1 0:0:c0:ff:e9:ce UHLW 5 7360 lo0
172.16.0.5 0:0:c0:b5:ca:ae UHLW 8 587157 de0 895
172.16.0.6 0:a0:24:4b:1f:51 UHLW 0 7840 de0 862
tun0 172.16.0.1 UH 11 63 tun0
172.16.0.9 0:0:c0:ff:e9:ce UHLS2 0 0 de0
172.16.0.10 link#1 UHLW 2 184 de0 =>
172.16.0.12 0:0:f4:5e:60:a9 UHLW 2 92225 de0 424
172.16.0.13 8:0:20:b:bf:72 UHLW 1 12455 de0 344
172.16.0.255 ff:ff:ff:ff:ff:ff UHLWb 2 711 de0
172.17/24 172.16.0.12 UGSc 0 3290 de0
194.242.139.171/32 212.140.212.135 UGSc 1 0 tun1
194.242.139.172/32 212.140.212.135 UGSc 0 0 tun1
212.140.212.135 62.7.116.163 UH 3 0 tun1
Where tun0's transport has disappeared, we want to be able to do a
connect() to say freefall, resulting in a sort of loose binding to
the tun0 interface rather than an IP number, and a packet going out
to the tun0 interface saying "please fix my source address quickly".
I haven't looked at the SMART stuff, but I guess that'll find some
way to assign numbers to the interface and adjust the outgoing
packet(s) along with any semi-bound socket(s).
Deleting routes would defeat the functionality IMHO.
I *think* Julian introduced code that will do this - so that you can
creating route entries that contain sockaddr_dl's rather than
sockaddr_in's, but I also *think* that's as far as it went.
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006202024.VAA66394>