athn PCI card (AR9281) AP not found by scan on some devices
>Synopsis: athn PCI card (AR9281) AP not found by scan on some devices >Category: wifi driver? >Environment: System : OpenBSD 5.8 Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Architecture: OpenBSD.amd64 Machine : amd64 >Description: /etc/hostname.athn0 contains: inet 192.168.42.1 255.255.255.0 mediaopt hostap chan 56 nwid Testies wpakey insecure Most computers (2 Androids and a linux laptop with a broadcom 43xx device) cannot see the AP when scanning for networks although my main laptop - a Lenovo T410 with an Intel "Ultimate-N 6300 AGN" (in Linux) - can on some channels (eg. 56 works, 1 (the default) and 2 don't). Apart from that, various different channel, media and mediaopt settings made no difference. The hardware seems to not be a problem - it's brand new and The Other OS running hostapd could be found by all 4 devices. Of course it's quite possible that the software is working as it should and I've configured it incorrectly, in which case the bug is incomplete documentation if it's not just pebkac. ifconfig athn0 shows: athn0: flags=8843 mtu 1500 lladdr 04:f0:21:17:45:95 priority: 4 groups: wlan media: IEEE802.11 autoselect hostap (autoselect mode 11a hostap) status: active ieee80211: nwid Testies chan 56 bssid 04:f0:21:17:45:95 wpakey 0xa3740805d47fadbe51401073cdc11764a052ada555d4d19b3274e8aa3c48fdba wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip inet 192.168.42.1 netmask 0xff00 broadcast 192.168.42.255 >How-To-Repeat: Virgin 5.8 installation on a PC Engines apu1d4 with a wle200nx. /etc/hostname.athn0 created as above (and fiddle with media* settings to no avail). Scan for wifi networks on other devices. >Fix: Yes please. The machine is not anywhere close to production yet so I'm happy to poke at it in weird ways to facilitate debugging. dmesg: OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC RTC BIOS diagnostic error ff real mem = 4245995520 (4049MB) avail mem = 4113465344 (3922MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.14 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2 (PBR5) acpiprt4 at acpi0: bus 3 (PBR6) acpiprt5 at acpi0: bus 4 (PBR7) acpiprt6 at acpi0: bus 6 (PE20) acpiprt7 at acpi0: bus -1 (PE21) acpiprt8 at acpi0: bus -1 (PE22) acpiprt9 at acpi0: bus -1 (PE23) acpiprt10 at acpi0: bus 0 (PCI0) acpiprt11 at acpi0: bus 5 (PIBR) acpicpu0 at acpi0: !C2(0@100 io@0x841), C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:40:0a:88 rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:40:0a:89 rgephy1 at re
Re: athn PCI card (AR9281) AP not found by scan on some devices
On Sun, Mar 06, 2016 at 10:22:17PM +0200, cho...@jtan.com wrote:
> >Synopsis: athn PCI card (AR9281) AP not found by scan on some devices
> >Category:wifi driver?
> >Environment:
> System : OpenBSD 5.8
> Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> /etc/hostname.athn0 contains:
> inet 192.168.42.1 255.255.255.0
> mediaopt hostap chan 56
I'd recommend sticking to 11a "indoor channels" 36, 38, 40, 42, 44,
and 48, unless you have a good reason to do otherwise.
In most countries, channel 50 and above ("outdoor channels") require DFS
support for proper operation, which OpenBSD doesn't provide.
Many client devices won't support any of the "outdoor" channels.
> The hardware seems to not be a problem - it's brand new and The
> Other OS running hostapd could be found by all 4 devices.
Which channel does the other os use?
Re: athn PCI card (AR9281) AP not found by scan on some devices
Stefan Sperling writes:
> On Sun, Mar 06, 2016 at 10:22:17PM +0200, cho...@jtan.com wrote:
> > >Synopsis: athn PCI card (AR9281) AP not found by scan on some devices
> > >Category: wifi driver?
> > >Environment:
> > System : OpenBSD 5.8
> > Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/comp
> ile/GENERIC
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > /etc/hostname.athn0 contains:
> > inet 192.168.42.1 255.255.255.0
> > mediaopt hostap chan 56
>
> I'd recommend sticking to 11a "indoor channels" 36, 38, 40, 42, 44,
> and 48, unless you have a good reason to do otherwise.
>
> In most countries, channel 50 and above ("outdoor channels") require DFS
> support for proper operation, which OpenBSD doesn't provide.
> Many client devices won't support any of the "outdoor" channels.
I didn't even choose one until I found out that it didn't work. I'm
right in the middle of nowhere so I've not paid attention to the
regulatory settings yet. Choosing the right settings would have happened
right after I'd verified basic functionality on.
> > The hardware seems to not be a problem - it's brand new and The
> > Other OS running hostapd could be found by all 4 devices.
>
> Which channel does the other os use?
I ripped off a hostapd.conf that I found somewhere online. It sets the
country code to US and channel to 2.
I've been poking at it (and little more than poking in ignorance) and a
few more symptoms have cropped up:
* If I include any chan setting in hostname.athn0 and reboot, I can't
set the chan at runtime to anything between 1 and 11 though can to
(some) values >11: ifconfig: SIOCS80211CHANNEL: Invalid argument
Some values result in my 'good' laptop being able to find the AP and
some don't. Booting with anything <= 11 can't be seen; 36, 56 and 44
can.
* If I remove the chan option from hostname.athn0 ifconfig shows that
chan 1 was selected but nothing (not even my 'good' laptop) finds the
network. However I can now change the chan at runtime, and doing so
allows (all) the other devices to find the AP, even after switching
back to chan 1.
I don't know what either of these things means, but they're odd.
I would rather perform more rigorous tests but I don't know which tests
would be meaningful and which would be a massive waste of time so all
I'm doing now is playing with it.
Matthew
Re: athn PCI card (AR9281) AP not found by scan on some devices
On Mon, Mar 07, 2016 at 09:06:12AM +0200, cho...@jtan.com wrote: > I've been poking at it (and little more than poking in ignorance) and a > few more symptoms have cropped up: > > * If I include any chan setting in hostname.athn0 and reboot, I can't > set the chan at runtime to anything between 1 and 11 though can to > (some) values >11: ifconfig: SIOCS80211CHANNEL: Invalid argument > > Some values result in my 'good' laptop being able to find the AP and > some don't. Booting with anything <= 11 can't be seen; 36, 56 and 44 > can. > > * If I remove the chan option from hostname.athn0 ifconfig shows that > chan 1 was selected but nothing (not even my 'good' laptop) finds the > network. However I can now change the chan at runtime, and doing so > allows (all) the other devices to find the AP, even after switching > back to chan 1. > > I don't know what either of these things means, but they're odd. Apart from hardware support, available channels depend on the current "mode" of the interface. 11a mode allows 5GHz channels (36 and up), and 11g mode allows channels 1 to 11, or perhaps up to 14 depending on the regulatory domain that your athn card was set to during manufacturing. (OpenBSD doesn't support run-time switching of regulatory domains at present and will just use whatever the hardware has been set up for.) Since you're running the card in hostap mode you should specify a mode first and then a channel. If you don't specify either, the wireless stack will automatically select a channel and a mode when the athn0 interface is put up. If you try to set a channel that's not valid for the curret mode, you'll see the 'Invalid argument' error. You can change the mode to 11a or 11g with: ifconfig athn0 media autoselect mode 11a ifconfig athn0 media autoselect mode 11g (Yes, you need to type all of that. This has been fixed in 5.9, where just 'ifconfig athn0 mode 11a' and 'ifconfig athn0 mode 11g' will work). You can put either of these lines in /etc/hostname.athn0 to force a particular mode at boot time: media autoselect mode 11a media autoselect mode 11g I hope this helps. I realize this interface, and perhaps the documentation, may lack some general friendliness towards those who aren't aware of all the quirks.
Re: athn PCI card (AR9281) AP not found by scan on some devices
On Sun, Mar 06, 2016 at 10:22:17PM +0200, cho...@jtan.com wrote: > >Description: > /etc/hostname.athn0 contains: > inet 192.168.42.1 255.255.255.0 > mediaopt hostap chan 56 > nwid Testies > wpakey insecure Note that setting an address puts the interface UP implicitly. So you'll want to configure all the wireless bits first, and set the address afterwards! Otherwise, your wireless settings will race the automatic mode/channel selection I described in my other reply from a few minutes ago. So try this something like this instead: media autoselect mediaopt hostap mode 11g chan 1 inet 192.168.42.1 255.255.255.0 or: media autoselect mediaopt hostap mode 11a chan 36 inet 192.168.42.1 255.255.255.0
Re: athn PCI card (AR9281) AP not found by scan on some devices
Stefan Sperling writes: > On Sun, Mar 06, 2016 at 10:22:17PM +0200, cho...@jtan.com wrote: > > >Description: > > /etc/hostname.athn0 contains: > > inet 192.168.42.1 255.255.255.0 > > mediaopt hostap chan 56 > > nwid Testies > > wpakey insecure > > Note that setting an address puts the interface UP implicitly. > So you'll want to configure all the wireless bits first, and set the > address afterwards! Otherwise, your wireless settings will race the > automatic mode/channel selection I described in my other reply from > a few minutes ago. > > So try this something like this instead: > > media autoselect mediaopt hostap mode 11g > chan 1 > inet 192.168.42.1 255.255.255.0 > > or: > > media autoselect mediaopt hostap mode 11a > chan 36 > inet 192.168.42.1 255.255.255.0 That, and the process for switching mode at runtime in your other mail, clears things up a lot and the AP seems to be working as it should now. More testing will ensue. Note that I got the order of configuration lines directly from athn(4) and some other wireless driver manpages also have examples with inet lines prior to media settings. It does seem that the control tools will try and do things which are impossible but it looks like documentation can clear most of that up and at least they're easier to fix than mysterious driver bugs happening 2 continents away, which thankfully doesn't seem to be the case. Thanks, Matthew
Re: athn PCI card (AR9281) AP not found by scan on some devices
On Mon, Mar 07, 2016 at 03:12:33PM +0200, cho...@jtan.com wrote: > Note that I got the order of configuration lines directly from athn(4) > and some other wireless driver manpages also have examples with inet > lines prior to media settings. I"ve fixed this in CVS, thanks.
