problems associating to an AP
Hello,
I have in the company I'm working for problems to associate to an AP;
the entry in the /etc/wpa_supplicant.conf is:
network={
ssid=OCLCPublic
psk=XXX
key_mgmt=WPA-PSK
}
with the correct psk given from our local admin; when it tries to
associate, in most of the times it fails; I have below some part of the
/var/log/messages with a failing assoc, but some secs later it
associates successful, but disconnects again. What could be the reason
for this and what does mean the message 'wpa_supplicant[2787]: FT:
Invalid key management type (2)'?
Thanks
matthias
Dec 22 11:39:25 unixarea wpa_supplicant[2787]: wlan0: Trying to associate with
00:26:0b:4b:b8:44 (SSID='OCLCPublic' freq=2412 MHz)
Dec 22 11:39:25 unixarea kernel: wlan0: macaddr bssid chan
rssi rate flag wep essid
Dec 22 11:39:25 unixarea kernel: - bc:05:43:f6:da:65 bc:05:43:f6:da:651
61 54M ess wep FRITZ!Box WLAN 3370!
Dec 22 11:39:25 unixarea kernel: - 00:1b:11:e4:98:b4 00:1b:11:e4:98:b46
60 54M ess wep DLINK!
Dec 22 11:39:25 unixarea kernel: - 00:26:0b:4b:b8:44 00:26:0b:4b:b8:441
62 54M ess wep OCLCPublic!
Dec 22 11:39:25 unixarea kernel: - 00:26:0b:4b:b8:42 00:26:0b:4b:b8:421
62 54M ess wep 0x00!
Dec 22 11:39:25 unixarea kernel: wlan0: scan_task: done, [ticks 16263443, dwell
min 20 scanend 2163745019]
Dec 22 11:39:25 unixarea kernel: wlan0: notify scan done
Dec 22 11:39:25 unixarea wpa_supplicant[2787]: FT: Invalid key management type
(2)
Dec 22 11:39:27 unixarea kernel: wlan0: [00:26:0b:4b:b8:44]
ieee80211_scan_assoc_fail: reason 1
Dec 22 11:39:27 unixarea kernel: wlan0: [00:26:0b:4b:b8:44] sta_assoc_fail:
reason 1 fails 1
Dec 22 11:39:35 unixarea wpa_supplicant[2787]: wlan0: Authentication with
00:26:0b:4b:b8:44 timed out.
Dec 22 11:39:35 unixarea wpa_supplicant[2787]: wlan0: CTRL-EVENT-DISCONNECTED
bssid=00:26:0b:4b:b8:44 reason=3 locally_generated=1
Dec 22 11:39:35 unixarea kernel: wlan0: ieee80211_scan_flush
Dec 22 11:39:36 unixarea kernel: wlan0: ieee80211_scanreq: flags 0x20052
duration 0x7fff mindwell 0 maxdwell 0 nssid 1
Dec 22 11:39:36 unixarea kernel: wlan0: ieee80211_check_scan: active scan,
append, nojoin, once
Dec 22 11:39:36 unixarea kernel: wlan0: sta_pick_bss: no scan candidate
Dec 22 11:39:36 unixarea kernel: wlan0: start_scan_locked: active scan,
duration 2147483647 mindwell 0 maxdwell 0, desired mode auto, append, nojoin,
once
Dec 22 11:39:36 unixarea kernel: wlan0: scan set 1g, 6g, 11g, 7g, 2g, 3g, 4g,
5g, 8g, 9g, 10g dwell min 20ms max 200ms
Dec 22 11:39:36 unixarea kernel: wlan0: scan_task: chan 1g - 1g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:36 unixarea kernel: [bc:05:43:f6:da:65] new probe_resp on chan 1
(bss chan 1) FRITZ!Box WLAN 3370 rssi 62
Dec 22 11:39:36 unixarea kernel: [bc:05:43:f6:da:65] caps 0x431 bintval 100 erp
0x100 country [DE 1-13,20]
Dec 22 11:39:36 unixarea kernel: [bc:05:43:f6:da:65] new beacon on chan 1 (bss
chan 1) FRITZ!Box WLAN 3370 rssi 58
Dec 22 11:39:36 unixarea kernel: [bc:05:43:f6:da:65] caps 0x431 bintval 100 erp
0x100 country [DE 1-13,20]
Dec 22 11:39:36 unixarea kernel: wlan0: ieee80211_add_scan: chan 1g min dwell
met (16274495 16274484)
Dec 22 11:39:36 unixarea kernel: wlan0: scan_task: chan 1g - 6g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:36 unixarea kernel: [00:1b:11:e4:98:b4] new probe_resp on chan 6
(bss chan 6) DLINK rssi 62
Dec 22 11:39:36 unixarea kernel: [00:1b:11:e4:98:b4] caps 0x411 bintval 100 erp
0x102
Dec 22 11:39:36 unixarea kernel: wlan0: scan_task: chan 6g - 11g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:36 unixarea kernel: wlan0: scan_task: chan 11g - 7g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:36 unixarea kernel: wlan0: scan_task: chan 7g - 2g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:37 unixarea kernel: wlan0: scan_task: chan 2g - 3g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:37 unixarea kernel: wlan0: scan_task: chan 3g - 4g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:37 unixarea kernel: wlan0: scan_task: chan 4g - 5g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:37 unixarea kernel: wlan0: scan_task: chan 5g - 8g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:37 unixarea kernel: wlan0: scan_task: chan 8g - 9g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:38 unixarea kernel: wlan0: scan_task: chan 9g - 10g [active,
dwell min 20ms max 200ms]
Dec 22 11:39:38 unixarea kernel: wlan0: macaddr bssid chan
rssi rate flag wep essid
Dec 22 11:39:38 unixarea kernel: - bc:05:43:f6:da:65 bc:05:43:f6:da:651
62 54M ess wep FRITZ!Box WLAN 3370!
Dec 22 11:39:38 unixarea kernel: - 00:1b:11:e4:98:b4 00:1b:11:e4:98:b46
62 54M ess wep DLINK!
Dec 22 11:39:38 unixarea kernel: wlan0: scan_task: done, [ticks 16276537, dwell
min 20 scanend 2163758109]
Dec 22 11:39:38 unixarea kernel: wlan0: notify scan done
Re: Atheros AR9565 detected, not working
Will do. I'm actually thinking about reverting my changes just to see if stock
ath(4) works (it's been a looong while since I played with bringing it up). I
still occasionally see the same behavior I saw before my changes.
I'm using a recent Linux kernel (which works out of the box) to get it working
in FreeBSD - the keyboard wi-fi LED and hotkey work perfectly there.
Thanks,
Anthony
From: Adrian Chadd adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com
Cc: wirel...@freebsd.org wirel...@freebsd.org
Sent: Sunday, December 21, 2014 9:39 PM
Subject: Re: Atheros AR9565 detected, not working
Hi!
ok, how'd you build things? a module, or in the kernel?
You need to (a) build it using 'make buildkernel / make installkernel'
and (b) ensure ATH_ENABLE_11N is in your kernel configuration.
The GPIO bits are a bit odd - let me check the other chipset drivers.
Can you compile the tools in src/tools/tools/ath/ - then run this:
ath_prom_dump -i ath0 -d /tmp/ath.dump
ath_ee_9300_print /tmp/ath.dump /tmp/ath.txt
then email the contents of ath.txt . It'll include the GPIO pin id.
Thanks!
-adrian
On 18 December 2014 at 11:53, Anthony Jenkins scoobi_...@yahoo.com wrote:
The attached patch seems to get my rfkill GPIO working. It seems
ar9300_enable_rf_kill() is never called. I added a call to it after
ath_hal_enable_rfkill(), but this is probably not the right place (I see it
called several times while the interface is up).
I also found several spots in the GPIO handling code which give up if the
GPIO pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B). I
commented these out:
if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
(gpio == AR9382_GPIO_PIN_11_RESERVED) ||
(gpio == AR9382_GPIO_9_INPUT_ONLY))
{
return AH_FALSE;
}
if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
(gpio == AR9382_GPIO_PIN_11_RESERVED) ||
(gpio AR9382_MAX_GPIO_INPUT_PIN_NUM))
{
return;
}
Haven't narrowed down which is responsible for me being able to send this
email using my AR9565. Also I'm getting flooded with these messages since
moving ath wlan out of the kernel...my patch broke something, no?
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
Anthony
From: Adrian Chadd adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com
Cc: freebsd-wireless@freebsd.org freebsd-wireless@freebsd.org
Sent: Monday, July 29, 2013 10:44 AM
Subject: Re: Atheros AR9565 detected, not working
Cool, thanks.
Please make sure you post patches for all the things you fix. I'd love
to see this kind of thing work out of the box. :)
-adrian
On 29 July 2013 07:36, Anthony Jenkins scoobi_...@yahoo.com wrote:
Thanks Adrian,
I've managed to fix a few things on this laptop, the remaining stuff is
BIOS/ACPI related. acpi_hp(4) isn't working, has something to do with WMI.
Hoping if I fix the ACPI stuff I can
have me AR9565 working. I'll poke
around and report back; the RFKill suggestion is a good place to start
looking.
Thanks,
Anthony
On 07/29/13 10:30, Adrian Chadd wrote:
Hm, maybe rfkill is set?
The AR9565 is supported. I have the reference NICs from Atheros; they
work just fine.
It may be some kind of ACPI setting to enable/disable RFKill so the
radio side is actually enabled.
I'm sorry, I don't have much more than that to offer without having
the laptop here.
If someone's willing to send me one, I'll get 10 + wireless working on
it and then hand it over to ixsystems to join the 'stuff we really
should get pcbsd running smoothly on' pile. They're about $500 off of
amazon.com.
Thanks,
-adrian
On 29 July 2013 07:21, Anthony Jenkins scoobi_...@yahoo.com wrote:
I just got an HP ENVY Sleekbook 6z-1100 laptop hoping it came with a
FreeBSD-supported wireless NIC. It has an Atheros AR9565 and looking at
the
logs it _seems_ like it should be working, but I get no network traffic.
I
haven't started the Atheros debugging procedure yet, save to compile in
option AH_DEBUG and move ath(4) out of the kernel to a module to
facilitate changes. Works (of course) in Win8 which came with laptop.
Wireless enabled LED is amber (disabled) in FreeBSD, goes from amber
to
white (enabled) when I boot the Win8 HDD.
Here's various logs and misc. system info. What should I try next?
Thanks
in advance!
[root@laptop /usr/src]# uname -a n
FreeBSD laptop.qtchat.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Jul
27
23:45:30 EDT 2013
Re: Atheros AR9565 detected, not working
See, that's where it's odd:
| EepromWriteGpio: 16, WlanDisableGpio: 0, WlanLedGpio: 8
RxBandSelectGpio: 255 |
.. how'd you figure out it's GPIO 11?
-adrian
On 22 December 2014 at 11:39, Anthony Jenkins scoobi_...@yahoo.com wrote:
Logs attached.
Thanks,
Anthony
On 12/22/2014 11:21, Adrian Chadd wrote:
Yeah, there's no GPIO check like there is in the reference code.
The fact it says AR9382 is pretty telling. That's like it's asking for
a very specific NIC with very specific GPIO mappings. :(
-adrian
On 22 December 2014 at 06:03, Anthony Jenkins scoobi_...@yahoo.com wrote:
Will do. I'm actually thinking about reverting my changes just to see if
stock ath(4) works (it's been a looong while since I played with bringing
it up). I still occasionally see the same behavior I saw before my changes.
I'm using a recent Linux kernel (which works out of the box) to get it
working in FreeBSD - the keyboard wi-fi LED and hotkey work perfectly there.
Thanks,
Anthony
From: Adrian Chadd adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com
Cc: wirel...@freebsd.org wirel...@freebsd.org
Sent: Sunday, December 21, 2014 9:39 PM
Subject: Re: Atheros AR9565 detected, not working
Hi!
ok, how'd you build things? a module, or in the kernel?
You need to (a) build it using 'make buildkernel / make installkernel'
and (b) ensure ATH_ENABLE_11N is in your kernel configuration.
The GPIO bits are a bit odd - let me check the other chipset drivers.
Can you compile the tools in src/tools/tools/ath/ - then run this:
ath_prom_dump -i ath0 -d /tmp/ath.dump
ath_ee_9300_print /tmp/ath.dump /tmp/ath.txt
then email the contents of ath.txt . It'll include the GPIO pin id.
Thanks!
-adrian
On 18 December 2014 at 11:53, Anthony Jenkins scoobi_...@yahoo.com wrote:
The attached patch seems to get my rfkill GPIO working. It seems
ar9300_enable_rf_kill() is never called. I added a call to it after
ath_hal_enable_rfkill(), but this is probably not the right place (I see
it called several times while the interface is up).
I also found several spots in the GPIO handling code which give up if the
GPIO pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B).
I commented these out:
if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
(gpio == AR9382_GPIO_PIN_11_RESERVED) ||
(gpio == AR9382_GPIO_9_INPUT_ONLY))
{
return AH_FALSE;
}
if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
(gpio == AR9382_GPIO_PIN_11_RESERVED) ||
(gpio AR9382_MAX_GPIO_INPUT_PIN_NUM))
{
return;
}
Haven't narrowed down which is responsible for me being able to send this
email using my AR9565. Also I'm getting flooded with these messages since
moving ath wlan out of the kernel...my patch broke something, no?
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
Anthony
From: Adrian Chadd adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com
Cc: freebsd-wireless@freebsd.org freebsd-wireless@freebsd.org
Sent: Monday, July 29, 2013 10:44 AM
Subject: Re: Atheros AR9565 detected, not working
Cool, thanks.
Please make sure you post patches for all the things you fix. I'd love
to see this kind of thing work out of the box. :)
-adrian
On 29 July 2013 07:36, Anthony Jenkins scoobi_...@yahoo.com wrote:
Thanks Adrian,
I've managed to fix a few things on this laptop, the remaining stuff is
BIOS/ACPI related. acpi_hp(4) isn't working, has something to do with
WMI.
Hoping if I fix the ACPI stuff I can
have me AR9565 working. I'll poke
around and report back; the RFKill suggestion is a good place to start
looking.
Thanks,
Anthony
On 07/29/13 10:30, Adrian Chadd wrote:
Hm, maybe rfkill is set?
The AR9565 is supported. I have the reference NICs from Atheros; they
work just fine.
It may be some kind of ACPI setting to enable/disable RFKill so the
radio side is actually enabled.
I'm sorry, I don't have much more than that to offer without having
the laptop here.
If someone's willing to send me one, I'll get 10 + wireless working on
it and then hand it over to ixsystems to join the 'stuff we really
should get pcbsd running smoothly on' pile. They're about $500 off of
amazon.com.
Thanks,
-adrian
On 29 July 2013 07:21, Anthony Jenkins scoobi_...@yahoo.com wrote:
I just got an HP ENVY Sleekbook 6z-1100 laptop hoping it came with a
FreeBSD-supported wireless NIC. It has an Atheros AR9565 and looking at
the
logs
Re: Atheros AR9565 detected, not working
I'll have to re-add the printf()s, but I'm pretty sure I saw 0x0B (of course it
could have been 0x08 I saw, but neither of those would make it through the
function - both 0x0B and 0x08 are blocked).
Anthony
On 12/22/2014 14:51, Adrian Chadd wrote:
See, that's where it's odd:
| EepromWriteGpio: 16, WlanDisableGpio: 0, WlanLedGpio: 8
RxBandSelectGpio: 255 |
.. how'd you figure out it's GPIO 11?
-adrian
On 22 December 2014 at 11:39, Anthony Jenkins scoobi_...@yahoo.com wrote:
Logs attached.
Thanks,
Anthony
On 12/22/2014 11:21, Adrian Chadd wrote:
Yeah, there's no GPIO check like there is in the reference code.
The fact it says AR9382 is pretty telling. That's like it's asking for
a very specific NIC with very specific GPIO mappings. :(
-adrian
On 22 December 2014 at 06:03, Anthony Jenkins scoobi_...@yahoo.com wrote:
Will do. I'm actually thinking about reverting my changes just to see if
stock ath(4) works (it's been a looong while since I played with bringing
it up). I still occasionally see the same behavior I saw before my
changes.
I'm using a recent Linux kernel (which works out of the box) to get it
working in FreeBSD - the keyboard wi-fi LED and hotkey work perfectly
there.
Thanks,
Anthony
From: Adrian Chadd adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com
Cc: wirel...@freebsd.org wirel...@freebsd.org
Sent: Sunday, December 21, 2014 9:39 PM
Subject: Re: Atheros AR9565 detected, not working
Hi!
ok, how'd you build things? a module, or in the kernel?
You need to (a) build it using 'make buildkernel / make installkernel'
and (b) ensure ATH_ENABLE_11N is in your kernel configuration.
The GPIO bits are a bit odd - let me check the other chipset drivers.
Can you compile the tools in src/tools/tools/ath/ - then run this:
ath_prom_dump -i ath0 -d /tmp/ath.dump
ath_ee_9300_print /tmp/ath.dump /tmp/ath.txt
then email the contents of ath.txt . It'll include the GPIO pin id.
Thanks!
-adrian
On 18 December 2014 at 11:53, Anthony Jenkins scoobi_...@yahoo.com wrote:
The attached patch seems to get my rfkill GPIO working. It seems
ar9300_enable_rf_kill() is never called. I added a call to it after
ath_hal_enable_rfkill(), but this is probably not the right place (I see
it called several times while the interface is up).
I also found several spots in the GPIO handling code which give up if the
GPIO pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B).
I commented these out:
if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
(gpio == AR9382_GPIO_PIN_11_RESERVED) ||
(gpio == AR9382_GPIO_9_INPUT_ONLY))
{
return AH_FALSE;
}
if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
(gpio == AR9382_GPIO_PIN_11_RESERVED) ||
(gpio AR9382_MAX_GPIO_INPUT_PIN_NUM))
{
return;
}
Haven't narrowed down which is responsible for me being able to send this
email using my AR9565. Also I'm getting flooded with these messages
since moving ath wlan out of the kernel...my patch broke something, no?
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
Anthony
From: Adrian Chadd adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com
Cc: freebsd-wireless@freebsd.org freebsd-wireless@freebsd.org
Sent: Monday, July 29, 2013 10:44 AM
Subject: Re: Atheros AR9565 detected, not working
Cool, thanks.
Please make sure you post patches for all the things you fix. I'd love
to see this kind of thing work out of the box. :)
-adrian
On 29 July 2013 07:36, Anthony Jenkins scoobi_...@yahoo.com wrote:
Thanks Adrian,
I've managed to fix a few things on this laptop, the remaining stuff is
BIOS/ACPI related. acpi_hp(4) isn't working, has something to do with
WMI.
Hoping if I fix the ACPI stuff I can
have me AR9565 working. I'll poke
around and report back; the RFKill suggestion is a good place to start
looking.
Thanks,
Anthony
On 07/29/13 10:30, Adrian Chadd wrote:
Hm, maybe rfkill is set?
The AR9565 is supported. I have the reference NICs from Atheros; they
work just fine.
It may be some kind of ACPI setting to enable/disable RFKill so the
radio side is actually enabled.
I'm sorry, I don't have much more than that to offer without having
the laptop here.
If someone's willing to send me one, I'll get 10 + wireless working on
it and then hand it over to ixsystems to join the 'stuff we really
should get pcbsd running smoothly on' pile. They're about $500 off
Re: Atheros AR9565 detected, not working
On 22 December 2014 at 11:59, Anthony Jenkins scoobi_...@yahoo.com wrote: I'll have to re-add the printf()s, but I'm pretty sure I saw 0x0B (of course it could have been 0x08 I saw, but neither of those would make it through the function - both 0x0B and 0x08 are blocked). Please do. I'd like to fix up the HAL and driver to use the EEPROM provided LED and RFKILL GPIO fields if they're populated and valid. Thanks! -adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Atheros AR9565 detected, not working
On 12/22/2014 15:22, Adrian Chadd wrote:
On 22 December 2014 at 11:59, Anthony Jenkins scoobi_...@yahoo.com wrote:
I'll have to re-add the printf()s, but I'm pretty sure I saw 0x0B (of course
it could have been 0x08 I saw, but neither of those would make it through
the function - both 0x0B and 0x08 are blocked).
Please do. I'd like to fix up the HAL and driver to use the EEPROM
provided LED and RFKILL GPIO fields if they're populated and valid.
Here's the chunk of boot messages for ath(4) on my laptop; it was 0x0B as I
originally thought:
Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: allocated memory range
(0xf010-0xf017) for rid 10 of pci0:2:0:0
Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: matched entry for 2.0.INTA
Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: slot 0 INTA hardwired to IRQ 17
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Qualcomm Atheros AR9565 mem
0xf010-0xf017 irq 17 at device 0.0 on pci2
Dec 22 16:47:59 ajenkins-hplaptop kernel: ioapic0: routing intpin 17 (PCI IRQ
17) to lapic 16 vector 53
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: WB335 1-ANT card detected
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_attach: calling
ar9300_hw_attach
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_hw_attach: calling
ar9300_eeprom_attach
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_flash_map: unimplemented for
now
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from DRAM
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from EEPROM
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from Flash
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from Flash
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from OTP
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_hw_attach:
ar9300_eeprom_attach returned 0
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info:
ah_rfsilent=0x2d
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info:
ah_gpio_select=0x0b
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info:
ah_polarity=0x00
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: RX status length: 48
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: RX buffer size: 4096
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX descriptor length: 128
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX status length: 36
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX buffers per descriptor: 4
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: ath_edma_setup_rxfifo: type=0,
FIFO depth = 16 entries
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: ath_edma_setup_rxfifo: type=1,
FIFO depth = 128 entries
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] enabling HT modes
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] enabling short-GI in 20MHz
mode
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] 1 stream STBC receive
enabled
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] 1 RX streams; 1 TX streams
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps
11Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps
11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 1T1R
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 20MHz
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 6.5Mbps - 65Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 20MHz SGI
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 7Mbps - 72Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 40MHz:
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 13.5Mbps - 135Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 40MHz SGI:
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 15Mbps - 150Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: AR9565 mac 704.0 RF5110 phy
1638.6
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 2GHz radio: 0x; 5GHz radio:
0x
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 1 for WME_AC_BE
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 0 for WME_AC_BK
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 2 for WME_AC_VI
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 3 for WME_AC_VO
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 8 for CAB traffic
Here's the printf()s in the code:
/*
* Fill all software cached or static hardware state information.
* Return failure if capabilities are to come from EEPROM and
* cannot be read.
*/
HAL_BOOL
ar9300_fill_capability_info(struct ath_hal *ah)
{
...
ahpriv-ah_rfsilent = ar9300_eeprom_get(ahp, EEP_RF_SILENT);
ath_hal_printf(ah, %s: ah_rfsilent=0x%02x\n, __func__,
ahpriv-ah_rfsilent);
if (ahpriv-ah_rfsilent EEP_RFSILENT_ENABLED) {
ahp-ah_gpio_select = MS(ahpriv-ah_rfsilent, EEP_RFSILENT_GPIO_SEL);
ath_hal_printf(ah, %s:
Re: Atheros AR9565 detected, not working
On 22 December 2014 at 13:59, Anthony Jenkins scoobi_...@yahoo.com wrote:
On 12/22/2014 15:22, Adrian Chadd wrote:
On 22 December 2014 at 11:59, Anthony Jenkins scoobi_...@yahoo.com wrote:
I'll have to re-add the printf()s, but I'm pretty sure I saw 0x0B (of
course it could have been 0x08 I saw, but neither of those would make it
through the function - both 0x0B and 0x08 are blocked).
Please do. I'd like to fix up the HAL and driver to use the EEPROM
provided LED and RFKILL GPIO fields if they're populated and valid.
Here's the chunk of boot messages for ath(4) on my laptop; it was 0x0B as I
originally thought:
Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: allocated memory range
(0xf010-0xf017) for rid 10 of pci0:2:0:0
Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: matched entry for 2.0.INTA
Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: slot 0 INTA hardwired to IRQ
17
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Qualcomm Atheros AR9565 mem
0xf010-0xf017 irq 17 at device 0.0 on pci2
Dec 22 16:47:59 ajenkins-hplaptop kernel: ioapic0: routing intpin 17 (PCI IRQ
17) to lapic 16 vector 53
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: WB335 1-ANT card detected
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_attach: calling
ar9300_hw_attach
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_hw_attach: calling
ar9300_eeprom_attach
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_flash_map: unimplemented for
now
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from DRAM
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from EEPROM
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from Flash
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from Flash
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from OTP
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_hw_attach:
ar9300_eeprom_attach returned 0
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info:
ah_rfsilent=0x2d
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info:
ah_gpio_select=0x0b
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info:
ah_polarity=0x00
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: RX status length: 48
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: RX buffer size: 4096
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX descriptor length: 128
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX status length: 36
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX buffers per descriptor: 4
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: ath_edma_setup_rxfifo:
type=0, FIFO depth = 16 entries
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: ath_edma_setup_rxfifo:
type=1, FIFO depth = 128 entries
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] enabling HT modes
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] enabling short-GI in
20MHz mode
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] 1 stream STBC receive
enabled
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] 1 RX streams; 1 TX
streams
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11b rates: 1Mbps 2Mbps
5.5Mbps 11Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11g rates: 1Mbps 2Mbps
5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 1T1R
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 20MHz
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 6.5Mbps - 65Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 20MHz SGI
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 7Mbps - 72Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 40MHz:
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 13.5Mbps - 135Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 40MHz SGI:
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 15Mbps - 150Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: AR9565 mac 704.0 RF5110 phy
1638.6
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 2GHz radio: 0x; 5GHz
radio: 0x
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 1 for WME_AC_BE
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 0 for WME_AC_BK
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 2 for WME_AC_VI
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 3 for WME_AC_VO
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 8 for CAB traffic
Here's the printf()s in the code:
/*
* Fill all software cached or static hardware state information.
* Return failure if capabilities are to come from EEPROM and
* cannot be read.
*/
HAL_BOOL
ar9300_fill_capability_info(struct ath_hal *ah)
{
...
ahpriv-ah_rfsilent = ar9300_eeprom_get(ahp, EEP_RF_SILENT);
ath_hal_printf(ah, %s: ah_rfsilent=0x%02x\n, __func__,
[Bug 193826] iwn does not scan channels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193826 --- Comment #3 from Henry Hu henry.hu...@gmail.com --- (In reply to Adrian Chadd from comment #2) Hi! I just fixed it in -HEAD. Please update and give it a whirl! Thanks! -adrian I updated iwn and net80211 directory, and rebuilt the kernel. I keep wlandebug scan on. After one day, when I came back, the system is disconnected. ifconfig says wlan0: flags=8c43UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST metric 0 mtu 1500 ether c4:85:08:82:da:5c inet 192.168.1.110 netmask 0xff00 broadcast 192.168.1.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet MCS mode 11ng (autoselect) status: no carrier ssid channel 60 (5300 MHz 11a) country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF powersavemode CAM powersavesleep 100 txpower 14 bmiss 10 mcastrate 6 mgmtrate 6 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 12 wme roaming MANUAL groups: wlan and in messages, I see Dec 22 19:28:40 pepsi kernel: [88:1f:a1:3e:9f:a9] new beacon on chan 60 (bss chan 60) Overbreaker5G rssi 9 Dec 22 19:28:40 pepsi kernel: [88:1f:a1:3e:9f:a9] caps 0x1511 bintval 100 erp 0x0 country [US 36-43,30 100-104,30 132-134,30 149-153,30] repeating over and over. wpa_cli status Selected interface 'wlan0' wpa_state=SCANNING ip_address=192.168.1.110 address=c4:85:08:82:da:5c I tried the old workaround: ifconfig wlan0 mode auto wlan0: flags=8c43UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST metric 0 mtu 1500 ether c4:85:08:82:da:5c inet 192.168.1.110 netmask 0xff00 broadcast 192.168.1.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet MCS (autoselect) status: no carrier ssid channel 60 (5300 MHz 11a) country US authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF powersavemode CAM powersavesleep 100 txpower 14 bmiss 10 mcastrate 6 mgmtrate 6 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 12 wme roaming MANUAL groups: wlan But nothing changed. Then I tried ifconfig wlan0 scan. I see this: Dec 22 19:30:27 pepsi kernel: wlan0: ieee80211_scanreq: flags 0x1b duration 0x7fff mindwell 0 maxdwell 0 nssid 0 Dec 22 19:30:27 pepsi kernel: wlan0: start_scan_locked: active scan already in progress Finally, I tried ifconfig wlan0 down; ifconfig wlan0 up, and it returns to normal: Dec 22 19:32:43 pepsi kernel: wlan0: ieee80211_cancel_scan: cancel active scan Dec 22 19:32:43 pepsi kernel: wlan0: scan_task: loop start; scandone=1 Dec 22 19:32:43 pepsi kernel: wlan0: scan_task: out Dec 22 19:32:43 pepsi kernel: wlan0: scan_task: done, [ticks 86384585, dwell min 20 scanend 2214685618] Dec 22 19:32:43 pepsi kernel: wlan0: ieee80211_cancel_scan: called; F_SCAN=0, vap=match, CANCEL=0 Dec 22 19:32:43 pepsi kernel: wlan0: ieee80211_scan_flush Dec 22 19:32:43 pepsi wpa_supplicant[412]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Dec 22 19:32:43 pepsi wpa_supplicant[412]: ioctl[SIOCS80211, op=26, val=0, arg_len=0]: Operation not supported Dec 22 19:32:43 pepsi wpa_supplicant[412]: wlan0: CTRL-EVENT-TERMINATING Dec 22 19:32:43 pepsi dhclient[628]: connection closed Dec 22 19:32:43 pepsi dhclient[628]: exiting. . So it seems to stuck in the scan. I checked the older logs, and found that there was a firmware error. You can find the relevant log at: http://pastebin.com/c1TA26sh -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
[Bug 193826] iwn does not scan channels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193826 --- Comment #4 from Adrian Chadd adr...@freebsd.org --- ok, this is a different bug. It seems like you hit an interesting corner case: * the vap was scanning; * you hit a firmware crash; * the min dwell time was met - so the interface should've moved onto the next scan; * .. but since the firmware crashed, ieee80211_scan_next() would never be called as it didn't know it was supposed to be scanning. So you would've just kept receiving that beacon over and over again; but if_iwn would've never called ieee80211_scan_next(). It's odd that the net80211 stack with all of the work I did over the weekend still got stuck without finishing a scan. It should've moved onto the next channel. Odd. So, there's two issues: * iee80211_scan_next() shouldn't be a requirement to move to the next channel - the whole scan framework should just sleep for a while, fire off a timer and then move channels; * then the iwn driver restarted OK but it didn't restart the firmware scan or tell net80211 that it was over so it could move to the next channel. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
