Re: Default route doesn't change to wireless device (ath0)

From: Brooks Davis <brooks_at_one-eyed-alien.net>
Date: Wed, 7 Sep 2005 15:30:57 -0700
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:
> > 
> > > I think I see what's going on.  Your arp cache is posioning your routing
> > > 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.
> > 
> > Freshly booted system:
> > Unplugging fxp0
> > route -n flush -inet
> > arp -a -d
> > inserting ath0
> > netstat -r says
> > -------------------------
> > Destination        Gateway            Flags    Refs      Use  Netif Expire
> > 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
> > 
> > So nothing changed :-(. Here's /var/log/messages
> > 
> > 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-0xc021ffff 
> > 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 from 
> > 00:30:f1:e1:4b:4e on ath0
> > 
> > > I think ifconfig fxp0 down delete instead of the flush will do what you 
> > > want.
> > 
> > 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=4 ttl=64 time=2.146 ms
> > 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=1.647 ms
> > ^C
> > --- 10.0.0.1 ping statistics ---
> > 6 packets transmitted, 2 packets received, 66% packet loss
> > round-trip min/avg/max/stddev = 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=0 ttl=53 time=25.454 ms
> > 64 bytes from 213.203.199.12: icmp_seq=1 ttl=53 time=25.223 ms
> > 64 bytes from 213.203.199.12: icmp_seq=2 ttl=53 time=26.358 ms
> > 64 bytes from 213.203.199.12: icmp_seq=3 ttl=53 time=32.673 ms
> > 64 bytes from 213.203.199.12: icmp_seq=4 ttl=53 time=30.582 ms
> > 64 bytes from 213.203.199.12: icmp_seq=5 ttl=53 time=32.536 ms
> > 64 bytes from 213.203.199.12: icmp_seq=6 ttl=53 time=29.699 ms
> > 64 bytes from 213.203.199.12: icmp_seq=7 ttl=53 time=25.617 ms
> > ^C
> > --- 213.203.199.12 ping statistics ---
> > 8 packets transmitted, 8 packets received, 0% packet loss
> > round-trip min/avg/max/stddev = 25.223/28.518/32.673/3.008 ms
> > SU NB ~:netstat -r
> > Routing tables
> > 
> > Internet:
> > Destination        Gateway            Flags    Refs      Use  Netif Expire
> > default                               UGS         0       14   ath0
> > 10/24              link#6             UC          0        0   ath0
> >                    00:30:f1:e1:4b:4e  UHLW        2        3   ath0   1187
> > 10.0.0.103         localhost          UGHS        0        0    lo0
> > localhost          localhost          UH          1       12    lo0
> > 
> > So that seems to work, dhclient is released from fxp0 and the default route is 
> > permanently deleted. However, now one needs to restart dhclient on fxp0, when 
> > it is supposed to come up again. Without the "delete" option dhclient took 
> > care of fxp0 automatically. Jesus, this isn't the wireless plug 'n play I was 
> > hoping to see in FreeBSD 6 :-). All one should need to do ist setting up 
> > wireless networks in /etc/wpa_supplicant.conf and make entries in rc.conf 
> > like
> > 
> > ifconfig_fxp0="DHCP"
> > ifconfig_ath0="WPA DHCP"
> > removable_interfaces="ath0"
> > 
> > And whenever there is a wireless network available (where the system can log 
> > in an get a network connection) the default route should be switched to that 
> > wireless nic. Or even better, if both connections work, automatically choose 
> > the faster one :-).
> 
> 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.
> 
> 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

-- 
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

Received on Wed Sep 07 2005 - 20:31:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:43 UTC