ath, wpa_supplicant and ioctl(SIOCS80211)

[Stephen Borrill]

I'm having a problem on some machines with ath(4) (5.0_STABLE). The
symptoms are that the interface connects to the network well enough to get
an IP address, but then communication ceases even though wpa_supplicant
claims it is connected. If I stop wpa_supplicant and restart it will not
reconnnect. At another site, it generally seems to work, but if
wpa_supplicant needs to re-associate (e.g. moving between access points),
it will not reconnect until the machine is rebooted.

/etc/wpa_supplicant.conf contains:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
ssid="woodland"
scan_ssid=1
priority=1
key_mgmt=NONE
wep_tx_keyidx=0
wep_key0=XXXXXXXXXX
}

wpa_supplicant says:

State: DISCONNECTED -> SCANNING
Starting AP scan (broadcast SSID)
ioctl[SIOCS80211, op 23, arg 0x0]: Invalid argument
Failed to initiate AP scan.
Setting scan request: 10 sec 0 usec
RTM_IFINFO: Interface 'ath0' UP
Starting AP scan (specific SSID)
Scan SSID - hexdump_ascii(len=8):
77 6f 6f 64 6c 61 6e 64 woodland
ioctl[SIOCS80211, op 23, arg 0x0]: Invalid argument
Failed to initiate AP scan.
Setting scan request: 10 sec 0 usec
^CCTRL-EVENT-TERMINATING - signal 2 received
Removing interface ath0
State: SCANNING -> DISCONNECTED

dmesg says:
ath0: ath_chan_set: unable to reset channel 12 (2467 MHz, flags 0x2e0 hal flags 0xc0)
ath0: setting keyix 0 w/o power
ath0: ath_chan_set: unable to reset channel 12 (2467 MHz, flags 0x2e0 hal flags 0xc0)
ath0: deleting keyix 0 w/o power
ath0: unable to reset hardware; hal status 3

The device is:
ath0 at pci2 dev 0 function 0
ath0: interrupting at ioapic1 pin 0
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: mac 14.2 phy 7.0 radio 10.2
Skipping broken PCI header on 2:0:0

I have my own identical machine here for testing (the others are at a
customer's site) and I'm unable to get it to go wrong.

I noticed that on my (working) machine, because of power management
the output of "pcictl pci2 list" alters as I ifconfig up and down the
interface. ifconfig ath0 down makes it return nothing. ifconfig ath0 up
gives:
002:00:0: Atheros Communications product 0x001c (ethernet network, revision 0x01)

This behaviour is independent of the kill switch.

[Stephen Borrill]

I'm having a problem on some machines with ath(4) (5.0_STABLE). The symptoms
are that the interface connects to the network well enough to get an IP
address, but then communication ceases even though wpa_supplicant claims it
is connected. If I stop wpa_supplicant and restart it will not reconnnect. At
another site, it generally seems to work, but if wpa_supplicant needs to
re-associate (e.g. moving between access points), it will not reconnect until
the machine is rebooted.

[snip]

ath0 at pci2 dev 0 function 0
ath0: interrupting at ioapic1 pin 0
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps
36Mbps 48Mbps 54Mbps
ath0: mac 14.2 phy 7.0 radio 10.2
Skipping broken PCI header on 2:0:0
I noticed that on my (working) machine, because of power management the
output of "pcictl pci2 list" alters as I ifconfig up and down the interface.
Atheros Communications product 0x001c (ethernet network, revision 0x01)

For laughs, I commented out the power handler lines in if_ath_pci.c:
if (!pmf_device_register(self, ath_pci_suspend, ath_pci_resume))
aprint_error_dev(self, "couldn't establish power handler\n");
else {
pmf_class_network_register(self, &sc->sc_if);
pmf_device_suspend_self(self);
}

On my machine, this stopped the device disappearing in pcictl output (and
also removed the "Skipping broken PCI header on 2:0:0" line - perhaps
normally the device is being powered down too aggressively).

On the test machine, nothing is listed in "pcictl pci2 list". It is as
though the device is present throughout autoconf, but then disappears.
There is nothing in dmesg regarding this.

[Steven Bellovin]

Post by Stephen Borrill

Post by Stephen Borrill
I'm having a problem on some machines with ath(4) (5.0_STABLE). The
symptoms are that the interface connects to the network well enough
to get an IP address, but then communication ceases even though
wpa_supplicant claims it is connected. If I stop wpa_supplicant and
restart it will not reconnnect. At another site, it generally seems
to work, but if wpa_supplicant needs to re-associate (e.g. moving
between access points), it will not reconnect until the machine is
rebooted.

[snip]

Post by Stephen Borrill
ath0 at pci2 dev 0 function 0
ath0: interrupting at ioapic1 pin 0
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps
18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ath0: mac 14.2 phy 7.0 radio 10.2
Skipping broken PCI header on 2:0:0
I noticed that on my (working) machine, because of power management
the output of "pcictl pci2 list" alters as I ifconfig up and down
the interface. ifconfig ath0 down makes it return nothing. ifconfig
ath0 up gives: 002:00:0: Atheros Communications product 0x001c
(ethernet network, revision 0x01)

if (!pmf_device_register(self, ath_pci_suspend,
ath_pci_resume))
aprint_error_dev(self, "couldn't establish power handler\n");
else {
pmf_class_network_register(self, &sc->sc_if);
pmf_device_suspend_self(self);
}
On my machine, this stopped the device disappearing in pcictl output
(and also removed the "Skipping broken PCI header on 2:0:0" line -
perhaps normally the device is being powered down too aggressively).
On the test machine, nothing is listed in "pcictl pci2 list". It is
as though the device is present throughout autoconf, but then
disappears. There is nothing in dmesg regarding this.

What is the effect on suspend/resume of deleting those lines?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stephen Borrill]

On Mon, 28 Sep 2009, Steven Bellovin wrote:
[snip]

Post by Steven Bellovin

Post by Stephen Borrill
if (!pmf_device_register(self, ath_pci_suspend, ath_pci_resume))
aprint_error_dev(self, "couldn't establish power handler\n");
else {
pmf_class_network_register(self, &sc->sc_if);
pmf_device_suspend_self(self);
}
On my machine, this stopped the device disappearing in pcictl output (and
also removed the "Skipping broken PCI header on 2:0:0" line - perhaps
normally the device is being powered down too aggressively).
On the test machine, nothing is listed in "pcictl pci2 list". It is as
though the device is present throughout autoconf, but then disappears.
There is nothing in dmesg regarding this.

What is the effect on suspend/resume of deleting those lines?

I've not tried, but I guess it will fail to suspend because of the driver
no longer registering a suspend handler.