Hi James, meem,

This seems a common issue with WiFi interface, I can reproduce this with other wifi adapters.

After boot,

# ifconfig ath2
ath2: flags=201000803<UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ether 0:f:b5:a8:6b:8c
--> flag <UP> seems not correct here, since it has never connected to any AP until now.

# dladm scan-wifi ath2
LINK ESSID BSSID/IBSSID SEC STRENGTH MODE SPEED
...
ath2 DWL-2000AP 0:13:46:35:8d:3 none good g 54Mb
...

# dladm connect-wifi -e DWL-2000AP ath2
# ifconfig ath2 dhcp
--> Timeout always, no success

Check output of snoop, there are "DHCPREQUEST" packets out, but no response, looks like driver's problem, but by wireless sniffer tool, in section of ieee80211 frame header, the BSSID field is all zero, not BSSID of DWL-2000AP, this is not correct. This mean when ath2 connected to AP, driver calling "mac_pdata_update()" has no effect
to IP's fastpath header, it keeps old one.

# ifconfig ath2 dhcp drop
# dladm disconnect-wifi ath2
# ifconfig ath2
ath2: flags=201000803<UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ether 0:f:b5:a8:6b:8c
--> flag should be <DOWN>, but is <UP> here, check /var/adm/messages, there is "ath2 link down".

So, do

# ifconfig ath2 down (or #ifconfig ath2 unplumb/plumb as UWE did)
# ifconfig ath2
ath2: flags=201000802<BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ether 0:f:b5:a8:6b:8c
--> flag is <DOWN> now.

# dladm connect-wifi -e DWL-2000AP ath2
# ifconfig ath2 dhcp
This time, can get IP, that means mac_pdata_update() works, and out packet has
correct frame header.

There are another similar case when switch between two different APs
# dladm scan-wifi ath2
LINK ESSID BSSID/IBSSID SEC STRENGTH MODE SPEED
ath2 DWL-2000AP 0:13:46:35:8d:3 none good g 54Mb
ath2 ap7-3 0:f:24:19:b:60 none weak g 54Mb

# ifconfig ath2
ath2: flags=201000802<BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ether 0:f:b5:a8:6b:8c
--> flag is <DOWN>
# dladm connect-wifi -e DWL-2000AP ath2
# ifconfig ath2 dhcp
--> Successfully

# ifconfig ath2 dhcp release
# dladm disconnect-wifi ath2

# ifconfig ath2
ath2: flags=201000803<UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ether 0:f:b5:a8:6b:8c
--> flag keeps <UP>

# dladm connect-wifi -e ap7-3 ath2
# ifconfig ath2 dhcp
--> Timeout always, since no reponse from DHCP server
By sniffer tool, we can see, BSSID field of frame header is always old one (DWL-2000AP), NOT ap7-3's.
This means mac_pdata_update() has no effect to flush IP's fastpath header.

Thoughs?

Thanks,

--
Quaker

James Carlson wrote:
Uwe Dippel writes:
I have been having this problem with rum1 for several versions of Nevada 
(actually, since it kind of works):

Which builds exactly?

rum1: flags=201004803<UP,BROADCAST,MULTICAST,DHCP,IPv4,CoS> mtu 1500 index 2
        inet 0.0.0.0 netmask ff000000 broadcast 255.255.255.255
ether 0:21:27:c0:a8:9b

If this is something prior to build 106, then CR 6730161 could be at
fault here.

There are other possibilities, so please do look for errors in
/var/adm/messages.

It's possible to run dhcpagent (the DHCP client) in a debug mode that
will print a _large_ amount of data to the system log file.  To do
this, set up syslogd to log daemon.debug to a file, and then add lines
like this to your /etc/default/dhcpagent file:

        .DEBUG_LEVEL=3
        .VERBOSE=yes

(If dhcpagent is running, just pkill it to get rid of it.  That
configuration file is just read at start-up.)

# dladm connect-wifi -e wlan -k psk rum1
# dladm show-wifi LINK STATUS ESSID SEC STRENGTH MODE SPEED
rum1       connected         wlan                wpa    excellent  g      36Mb
# ifconfig rum1 dhcp
^C
(times out, never connects)

Does a snoop show any traffic on the rum1 interface?  It should show
the DHCP messages going out, but if it shows no response, then that
points to a driver failure of some sort (perhaps something wrong with
the way WPA is used).


_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to