Date: Wed, 7 Sep 2005 15:30:57 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Jochen Gensch <incmc@gmx.de>, freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) Message-ID: <20050907223057.GA563@odin.ac.hmc.edu> In-Reply-To: <20050907211811.GA19570@odin.ac.hmc.edu> References: <20050901225346.0923E16A41F@hub.freebsd.org> <200509072128.04819.incmc@gmx.de> <20050907194130.GA2436@odin.ac.hmc.edu> <200509072223.20560.incmc@gmx.de> <20050907211811.GA19570@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 07, 2005 at 02:18:11PM -0700, Brooks Davis wrote: > On Wed, Sep 07, 2005 at 10:23:20PM +0200, Jochen Gensch wrote: > > Am Mittwoch 07 September 2005 21:41 schrieben Sie: > >=20 > > > I think I see what's going on. Your arp cache is posioning your rout= ing > > > table. Try doing an "arp -a -d" after flushing the routes and before > > > inserting the nic. It looks like we should add support to the arp(8) > > > command so -i can be used with -d and consider flushing cache entries > > > realted to an interface when it goes down. > >=20 > > Freshly booted system: > > Unplugging fxp0 > > route -n flush -inet > > arp -a -d > > inserting ath0 > > netstat -r says > > ------------------------- > > Destination Gateway Flags Refs Use Netif Exp= ire > > default 10.0.0.1 UGS 0 0 fxp0 > > 10/24 link#2 UC 0 0 fxp0 > > 10.0.0.1 link#2 UHRLW 2 4 fxp0 > > 10.0.0.103 localhost UGHS 0 0 lo0 > > localhost localhost UH 1 10 lo0 > >=20 > > So nothing changed :-(. Here's /var/log/messages > >=20 > > Sep 7 21:59:19 incmc kernel: fxp0: link state changed to DOWN > > Sep 7 22:01:04 incmc kernel: ath0: <Atheros 5212> mem 0xc0210000-0xc02= 1ffff=20 > > irq 9 at device 0.0 on cardbus0 > > Sep 7 22:01:04 incmc kernel: ath0: Ethernet address: 00:05:5d:9f:c5:0e > > Sep 7 22:01:04 incmc kernel: ath0: mac 5.9 phy 4.3 radio 3.6 > > Sep 7 22:01:12 incmc kernel: ath0: link state changed to UP > > Sep 7 22:01:20 incmc dhclient: New IP Address (ath0): 10.0.0.103 > > Sep 7 22:01:20 incmc dhclient: New Subnet Mask (ath0): 255.255.255.0 > > Sep 7 22:01:20 incmc dhclient: New Broadcast Address (ath0): 10.0.0.255 > > Sep 7 22:01:20 incmc dhclient: New Routers (ath0): 10.0.0.1 > > Sep 7 22:04:55 incmc kernel: arp: 10.0.0.1 is on fxp0 but got reply fr= om=20 > > 00:30:f1:e1:4b:4e on ath0 > >=20 > > > I think ifconfig fxp0 down delete instead of the flush will do what y= ou=20 > > > want. > >=20 > > Unplugging cable from fxp0 > > SU NB ~:ifconfig fxp0 down delete > > Inserting ath0 > > SU NB ~:ping 10.0.0.1 > > PING 10.0.0.1 (10.0.0.1): 56 data bytes > > ping: sendto: No route to host > > ping: sendto: No route to host > > ping: sendto: No route to host > > ping: sendto: No route to host > > 64 bytes from 10.0.0.1: icmp_seq=3D4 ttl=3D64 time=3D2.146 ms > > 64 bytes from 10.0.0.1: icmp_seq=3D5 ttl=3D64 time=3D1.647 ms > > ^C > > --- 10.0.0.1 ping statistics --- > > 6 packets transmitted, 2 packets received, 66% packet loss > > round-trip min/avg/max/stddev =3D 1.647/1.897/2.146/0.249 ms > > SU NB ~:ping 213.203.199.12 > > PING 213.203.199.12 (213.203.199.12): 56 data bytes > > 64 bytes from 213.203.199.12: icmp_seq=3D0 ttl=3D53 time=3D25.454 ms > > 64 bytes from 213.203.199.12: icmp_seq=3D1 ttl=3D53 time=3D25.223 ms > > 64 bytes from 213.203.199.12: icmp_seq=3D2 ttl=3D53 time=3D26.358 ms > > 64 bytes from 213.203.199.12: icmp_seq=3D3 ttl=3D53 time=3D32.673 ms > > 64 bytes from 213.203.199.12: icmp_seq=3D4 ttl=3D53 time=3D30.582 ms > > 64 bytes from 213.203.199.12: icmp_seq=3D5 ttl=3D53 time=3D32.536 ms > > 64 bytes from 213.203.199.12: icmp_seq=3D6 ttl=3D53 time=3D29.699 ms > > 64 bytes from 213.203.199.12: icmp_seq=3D7 ttl=3D53 time=3D25.617 ms > > ^C > > --- 213.203.199.12 ping statistics --- > > 8 packets transmitted, 8 packets received, 0% packet loss > > round-trip min/avg/max/stddev =3D 25.223/28.518/32.673/3.008 ms > > SU NB ~:netstat -r > > Routing tables > >=20 > > Internet: > > Destination Gateway Flags Refs Use Netif Exp= ire > > default UGS 0 14 ath0 > > 10/24 link#6 UC 0 0 ath0 > > 00:30:f1:e1:4b:4e UHLW 2 3 ath0 1= 187 > > 10.0.0.103 localhost UGHS 0 0 lo0 > > localhost localhost UH 1 12 lo0 > >=20 > > So that seems to work, dhclient is released from fxp0 and the default r= oute is=20 > > permanently deleted. However, now one needs to restart dhclient on fxp0= , when=20 > > it is supposed to come up again. Without the "delete" option dhclient t= ook=20 > > care of fxp0 automatically. Jesus, this isn't the wireless plug 'n play= I was=20 > > hoping to see in FreeBSD 6 :-). All one should need to do ist setting u= p=20 > > wireless networks in /etc/wpa_supplicant.conf and make entries in rc.co= nf=20 > > like > >=20 > > ifconfig_fxp0=3D"DHCP" > > ifconfig_ath0=3D"WPA DHCP" > > removable_interfaces=3D"ath0" > >=20 > > And whenever there is a wireless network available (where the system ca= n log=20 > > in an get a network connection) the default route should be switched to= that=20 > > wireless nic. Or even better, if both connections work, automatically c= hoose=20 > > the faster one :-). >=20 > That's the goal we're headed towards. Unfortunatly, it's not an instant > thing, particularly when people trying things like what you're doing > that don't map well into the old world view of static devices that don't > change networks. The old model is wrong and has been so for quite some > time, but that doesn't mean there aren't assumptions related to it all > over the place. >=20 > Hmm, upon further testing, I think there may be a problem with the > fxp(4) driver. I'm not 100% on this, but if I watch my ath0 interface, > attached arp entries, and default route, they all vanish completely when > I move out of range of my AP and reappear when link comes back. I need > to try something more like your configation. I've played with it a bit with my laptop which has am em(4) nic and a cardbus ath(4) nic. What I found was that there were two issues. First, we do need to be more agressing about cleaning up the interface when the link goes down, at least with some devices (this may be a symptom of a driver bug). I've been able to get that to work by adding "ifconfig $interface delete" to the EXPIRE|FAIL case in /sbin/dhclient-script. Second, the em0 on this machine completely fails to send link state messages so neither inserting nor removing the cable actually signals dhclient. I had to start dhclient by hand and stop it by issuing an "ifconfig em0 down". -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDH2ogXY6L6fI4GtQRAnmXAKDQ1QnS06gvi6lIBIBQ82VyZXLzLwCgzZDw oMiRTFAnLjWKX5hvR/8Bwow= =55j/ -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050907223057.GA563>