New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 835600 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

shill: does not add wlan0 on hotplugging, becuase of missing MAC address

Project Member Reported by kirtika@chromium.org, Apr 21 2018

Issue description

OS: R66

We rescan the pci bus and bring back the NIC when it goes missing. 
The 'add' udev event for wlan0 doesn't work for shill.
Why is the IFLA_ADDRESS missing?
Filed from the logs in https://b.corp.google.com/issues/35648315#comment348

2018-04-11T14:30:09.627187+02:00 DEBUG wpa_supplicant[706]: nl80211: Unsubscribe mgmt frames handle 0x8888d28e93b533e9 (deinit)
2018-04-11T14:30:09.627257+02:00 DEBUG wpa_supplicant[706]: dbus: Unregister interface object '/fi/w1/wpa_supplicant1/Interfaces/1'
2018-04-11T14:30:09.627449+02:00 ERR wpa_supplicant[706]: rmdir[ctrl_interface=/run/wpa_supplicant]: Permission denied
2018-04-11T14:30:09.636687+02:00 INFO shill[2579]: [INFO:device.cc(206)] Device destructed: wlan0 index 2
2018-04-11T14:30:09.637013+02:00 WARNING shill[2579]: [WARNING:nl80211_message.cc(711)] Unknown/unhandled netlink nl80211 message 0x04
2018-04-11T14:30:09.637341+02:00 INFO shill[2579]: [INFO:device_info.cc(320)] GetDeviceTechnology: device wlan0 has no uevent file
2018-04-11T14:30:09.637363+02:00 ERR shill[2579]: [ERROR:device_info.cc(735)] Add Link message for link 'wlan0' does not have IFLA_ADDRESS!
2018-04-11T14:30:09.638422+02:00 INFO shill[2579]: [INFO:manager.cc(1731)] Default physical service: 0 (not connected)
2018-04-11T14:30:09.638597+02:00 INFO shill[2579]: [INFO:service.cc(312)] Suppressed autoconnect to service 0 (no endpoints)
2018-04-11T14:30:09.638620+02:00 INFO shill[2579]: [INFO:service.cc(312)] Suppressed autoconnect to service 1 (no endpoints)
2018-04-11T14:30:09.638661+02:00 INFO shill[2579]: [INFO:service.cc(312)] Suppressed autoconnect to service 2 (no endpoints)

 
messages.1
3.7 MB Download
net.1.log
2.3 MB View Download
> 2018-04-11T14:30:09.637341+02:00 INFO shill[2579]: [INFO:device_info.cc(320)] GetDeviceTechnology: device wlan0 has no uevent file
> 2018-04-11T14:30:09.637363+02:00 ERR shill[2579]: [ERROR:device_info.cc(735)] Add Link message for link 'wlan0' does not have IFLA_ADDRESS!

I don't see this if I run `rmmod iwlmvm ; modprobe iwlmvm` on a samus.  Maybe there is something particular to the PCI rescan sequence that causes incomplete device information to propagate to userland?

I sniffed the netlink traffic during the rmmod/modprobe sequence per the instructions at http://go/netlink and saw the IFLA_ADDRESS field present.  To see RTM_NEWLINK and RTM_DELLINK use the wireshark filter:

    netlink-route.nltype == 16 or netlink-route.nltype == 17

Not sure what the empty RTM_NEWLINK message (packet #6) is all about...
nlmon.pcap
15.2 KB Download

Comment 2 by kirtika@google.com, Apr 23 2018

Can you try the following: 
echo 1 > /sys/bus/pci/devices/<figure out ID for wifi>/remove
echo 1 > /sys/bus/pci/rescan

That comes closest to the sequence the logs were obtained with. 

Testing on both samus + eve: wlan0 disappears, comes back up, and gets an IP address again when I run these comments:

    echo 1 > /sys/bus/pci/devices/0000:`lspci -mmd ::0280 | cut -f1 -d ' '`/remove
    echo 1 > /sys/bus/pci/rescan

Maybe it's not the rescan itself that's messing things up, but rather the original hardware failure?
Labels: Enterprise-Triaged

Sign in to add a comment