Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Mar 2007 17:11:52 -0400
From:      drgerlists@gmail.com (Dr. Gary E. RAFE)
To:        freebsd-questions@freebsd.org
Subject:   Trouble with wi0 address/route in 6.2-R ?
Message-ID:  <46004e18.9JdjfbIHPgXTE4XkMNzTzvTw@lmrmac.uhw.utoledo.edu>

next in thread | raw e-mail | index | archive | help
I posted this to freebsd-mobile a few weeks back.
After not getting any response there,
I'll try here now...

I recently set up a new FreeBSD notebook
(a used Toshiba Satellite Pro 6100) for a friend,
running 6.2-RELEASE, and am encountering an odd problem
with the wi(4) networking setup.

Essentially, the inet4 address information "goes away" for
the connected wi0 interface after some random period,
and the external network connection stops working.

*** Following "dhclient wi0":

# ifconfig wi0
wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet 192.168.0.17 netmask 0xffffff00 broadcast 192.168.0.255
	ether xx:xx:xx:yy:yy:yy
	media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
	status: associated
	ssid mynetwork channel 11 bssid yy:yy:yy:zz:zz:zz
	stationname myhostname
	authmode OPEN privacy MIXED deftxkey 3 wepkey 1:104-bit
	wepkey 2:104-bit wepkey 3:104-bit wepkey 4:104-bit txpowmax 100
	bmiss 7 bintval 100
# netstat -r
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.0.1        UGS         0       22    wi0
localhost          localhost          UH          0       11    lo0
192.168.0          link#3             UC          0        0    wi0
192.168.0.1        yy:yy:yy:zz:zz:zz  UHLW        2        0    wi0    262

Internet6:
Destination        Gateway            Flags      Netif Expire
localhost          localhost          UHL         lo0
fe80::%lo0         fe80::1%lo0        U           lo0
fe80::1%lo0        link#2             UHL         lo0
ff01:2::           fe80::1%lo0        UC          lo0
ff02::%lo0         fe80::1%lo0        UC          lo0

*** OK, all is well until external network traffic stops...
# ifconfig wi0
wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether xx:xx:xx:yy:yy:yy
	media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
	status: associated
	ssid mynetwork channel 11 bssid yy:yy:yy:zz:zz:zz
	stationname myhostname
	authmode OPEN privacy MIXED deftxkey 3 wepkey 1:104-bit
	wepkey 2:104-bit wepkey 3:104-bit wepkey 4:104-bit txpowmax 100
	bmiss 7 bintval 100
# netstat -r
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.0.1        UGS         0       25    wi0
localhost          localhost          UH          0       11    lo0
netstat: kvm_read: Bad address
192.168.0.1        link#3             HW          0        0    wi0

Internet6:
Destination        Gateway            Flags      Netif Expire
localhost          localhost          UHL         lo0
fe80::%lo0         fe80::1%lo0        U           lo0
fe80::1%lo0        link#2             UHL         lo0
ff01:2::           fe80::1%lo0        UC          lo0
ff02::%lo0         fe80::1%lo0        UC          lo0

Note the missing address line in the ifconfig output,
and the "kvm_read: Bad address" in the netstat output.

Occasionally, I'll see this kernel message, too:
	wi0: link state changed to DOWN

No other messages are seen with a verbose boot.
dhclient continues to run (and the device stays
associated to the AP in the other room).

When this happens, I have a simple shell script that
brings the interface down, stopping dhclient,
then reassociates to the AP before restarting dhclient,
and the network is back up
(until it goes away again, that is).

The firmware on the miniPCI card appears to be relatively up-to-date,
from dmesg:

wi0: <TOSHIBA Wireless LAN Card> at port 0xd000-0xd03f irq 11 function 0 config 1 on pccard0
wi0: using Lucent Embedded WaveLAN/IEEE
wi0: Lucent Firmware: Station (8.10.1)
wi0: Ethernet address: 00:02:2d:xx:xx:xx

I tried this with another miniPCI card with more recent firmware,
and encountered the same problem.

Suggestions on what might be causing this/how to debug it/
how to fix will be appreciated.
--
Dr Gary E RAFE: drgerlists at gmail dot com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46004e18.9JdjfbIHPgXTE4XkMNzTzvTw>