Re: athn0: device timeout with AR9271

2018-02-05 Thread Stefan Sperling
On Mon, Feb 05, 2018 at 11:07:18AM +, Kevin Chadwick wrote:
> On Mon, 5 Feb 2018 11:21:27 +0100
> > However, I can still reproduce device timeouts easily by running
> > tcpbench through an AR9271 in hostap mode. I don't know yet what's
> > causing the problem.
> 
> (Not using these for production btw)
> 
> I have unplugged my AR9271 due to these timeouts. Due to the chromecast
> (below) I have a so far unneeded script now to bring it down and up
> via a cronjob every minute upon a timeout in /var/log/messages. Pretty
> simple but I can provide it if anyone wants it.
> 
> I get very few timeouts on AR5008-3NG (AR5416+AR2133) but seemed to get
> many suddenly with a chromecast and the athn would not recover like
> usual. It seems to have stopped and since Google update chromecasts
> silently I can't tell why or test further and so haven't said anything.
> 
> The AR9271 has TxR:S of 1:1:1 compared to 3x3:2, perhaps it has a
> smaller buffer or just a more constrained power supply like you
> previously mentioned that struggles with many RX/TX?
> 
> The unconfirmed possible cause was a flood of UDP MDNS packets.

Our athn(4) driver is not running periodic calibration.
Which is very bad and can result in problems at the PHY layer such
as eventual deafness and inability to transmit.
That's the one problem to solve before looking for other causes.



Re: athn0: device timeout with AR9271

2018-02-05 Thread Kevin Chadwick
On Mon, 5 Feb 2018 11:21:27 +0100


> However, I can still reproduce device timeouts easily by running
> tcpbench through an AR9271 in hostap mode. I don't know yet what's
> causing the problem.

(Not using these for production btw)

I have unplugged my AR9271 due to these timeouts. Due to the chromecast
(below) I have a so far unneeded script now to bring it down and up
via a cronjob every minute upon a timeout in /var/log/messages. Pretty
simple but I can provide it if anyone wants it.

I get very few timeouts on AR5008-3NG (AR5416+AR2133) but seemed to get
many suddenly with a chromecast and the athn would not recover like
usual. It seems to have stopped and since Google update chromecasts
silently I can't tell why or test further and so haven't said anything.

The AR9271 has TxR:S of 1:1:1 compared to 3x3:2, perhaps it has a
smaller buffer or just a more constrained power supply like you
previously mentioned that struggles with many RX/TX?

The unconfirmed possible cause was a flood of UDP MDNS packets.

https://www.theregister.co.uk/2018/01/15/router_vendors_update_firmware_to_protect_against_google_chromecast_traffic_floods/



Re: athn0: device timeout with AR9271

2018-02-05 Thread Stefan Sperling
On Sat, Jan 27, 2018 at 12:59:12PM +0300, Denis wrote:
> I would like to add some test conditions to a previous post.
> 
> AR9271 USB stick's antenna  line of sight to AP antenna ~10m.
> 
> It that case I usually receive
> 
> athn0: device timeout

You might have better luck with -current from today, where this driver
now uses newer and actively maintained open source firmware.

However, I can still reproduce device timeouts easily by running tcpbench
through an AR9271 in hostap mode. I don't know yet what's causing the problem.

I could not yet trigger this problem on my AR7010 device.

An AR9271 device with firmware serial console would be useful for debugging,
for instance: https://wikidevi.com/wiki/ALFA_Network_AWUS036NHA



Re: athn0: device timeout with AR9271

2018-01-27 Thread Denis
I would like to add some test conditions to a previous post.

AR9271 USB stick's antenna  line of sight to AP antenna ~10m.

It that case I usually receive

athn0: device timeout

As man(4) athn diagnostic message shows. 'A frame dispatched to the
hardware for transmission did not complete in time. The driver will
reset the hardware. Make sure the laptop radio switch is on.'

When I connected AR9271 USB stick to 6.2amd64 host I usually got these
messages but not always

athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out

Full dmesg is below

OpenBSD 6.2 (GENERIC.MP) #1: Thu Jan 18 11:09:28 UTC 2018
r...@machine.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8451125248 (8059MB)
avail mem = 8192278528 (7812MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries)
bios0: vendor LENOVO version "8DET72WW (1.42 )" date 02/18/2016
bios0: LENOVO 5491C51
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF!
TCPA SSDT SSDT DMAR UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4)
EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2791.33 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2791332320 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.93 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.93 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2790.93 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 5 (EXP4)
acpiprt5 at acpi0: bus 13 (EXP5)
acpiprt6 at acpi0: bus 14 (EXP7)
acpicpu0 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu1 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu2 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu3 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"LEN0020" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "45N1172" serial 14231 type LION oem "SANYO"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
"IBM0079" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpidock0 at acpi0: GDCK docked (15)
acpivideo0 at acpi0: VID_
acpivout at acpivideo0 not configured
acpivideo1 at acpi0: VID_
cpu0: Enhanced SpeedStep 2791 MHz: speeds: 2801, 2800, 2600, 2400, 2200,
2000, 1800, 1600, 1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1366x768, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 6 

Re: athn0: device timeout with AR9271

2018-01-24 Thread Denis
Encountered the same errors with AR9271 dongle (athn driver) as in
previous posts:

athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out
athn0 device timeout

Kernel determined it as:

athn0 at uhub1 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 
2.00/1.08 addr 4
athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c4:e9:84:xx:xx:xx


Thank you for attention to a problem.

Denis

On 7/25/2016 12:57 PM, ML mail wrote:
> Hi,
>
> I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time to 
> time there are timeouts which prevents any access to it anymore until I 
> either plug out and in the Wifi dongle again or reboot.
>
> Here is the hardware details of that Wifi USB dongle:
>
>
> athn0 at uhub1 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 
> 2.00/1.08 addr 4
> athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c4:e9:84:xx:xx:xx
>
>
> There error is the following (many of these messages are repeated):
>
>
> athn0: device timeout
>
>
> My /etc/hostname.athn0 is the following:
>
> inet 172.16.20.1 255.255.255.0
> media autoselect
> mediaopt hostap
> mode 11b
> chan 6
> nwid 
> wpakey 
>
> So I was wondering what is going on here... Is my Wifi USB dongle crap? or am 
> I maybe doing something wrong?
>
> Let me know if I should provide any other infos...
>
>
> Regards
> ML
>



Re: athn0: device timeout and network hanging with AR9285

2017-10-15 Thread Stefan Sperling
On Sun, Oct 15, 2017 at 12:38:56AM -0500, Ax0n wrote:
> Frequently -- several times per hour when I'm actively doing stuff on my
> laptop, the network hangs for perhaps 30-60 seconds. This coincides with
> athn0 timeout messages on the console. I don't have much data to back up my
> claim that it feels like it's more frequent since the upgrade to 6.2, but
> it was happening under 6.1 Stable as well. I notice it more if I am moving
> large-ish files around, but that could simply be because my work gets
> interrupted.

athn can indeed stall and be generally slow on channels where other
access point are active as well. The first thing to check is to see
if you can find an empty channel to move it to.



Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)

2017-01-25 Thread Adam Wolk
On Wed, Jan 25, 2017 at 07:48:18PM +1000, Martin Pieuchot wrote:
> On 25/01/17(Wed) 10:36, Stefan Sperling wrote:
> > On Tue, Jan 24, 2017 at 03:10:34PM -0500, mabi wrote:
> > > Hi Stefan
> > > Thanks for your input. It looks like the g2k16 modifications to the athn 
> > > code from awolk@ did not make it into the 6.0 release. So there is still 
> > > hope for 6.1 ;-)
> > 
> > There was a rabbit hole this diff by Adam fell into. I don't know what
> > the current status of this is. Adam might know more.
> 
> The diff should go in, it doesn't make things worse.
> 

Changes from g2k16 will not prevent the timeouts but will help by removing the
need to manually kick the netstart scripts when the timeout happens.

I recall the diff was put on hold as we still found it crashing in some cases,
from the undeadly report:

---
The fourth one was in the athn driver itself. The interface was half cleaned up
(the fields of the ifp data structure were freed but not the interface itself)
so when the watchdog tried to access it caused the crash.
---

One of the diff from testing had this guard in place:
$ cat /home/mulander/athn-watchdog.6.diff
Index: if_athn_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v
retrieving revision 1.42
diff -u -p -r1.42 if_athn_usb.c
--- if_athn_usb.c   11 Dec 2015 16:07:02 -  1.42
+++ if_athn_usb.c   4 Sep 2016 18:48:14 -
@@ -2098,13 +2098,17 @@ void
 athn_usb_watchdog(struct ifnet *ifp)
 {
struct athn_softc *sc = ifp->if_softc;
+   struct ieee80211com *ic = >sc_ic;

ifp->if_timer = 0;

if (sc->sc_tx_timer > 0) {
if (--sc->sc_tx_timer == 0) {
printf("%s: device timeout\n", sc->sc_dev.dv_xname);
-   /* athn_usb_init(ifp); XXX needs a process context! */
+   if (ic->ic_bss == NULL)
+   return;
+   athn_usb_stop(ifp);
+   athn_usb_init(ifp);
ifp->if_oerrors++;
return;
}


the ic->ic_bss being null doing stop resulted in further crashing. Though it was
agreed that adding guards likes that in the watchdog is not wanted in the
watchdog handler. The final diff is just a athn_usb_stop/athn_usb_init in the
watchdog itself, it got mixed feedback. Don't remember who exactly took which
stance but the general opinions were;

- it should go in, doesn't make things worse
- let's wait for other changes in the stack

I decided to wait out and I guess the diff just bit rotted on my disk :)

Here is the final one that just restarts the interface. I have been running it
since September on most of my snapshots, stopped applying it around December
when I was travelling with a different usb dongle (ural0).

OK's to commit?
Index: if_athn_usb.c
===
RCS file: /cvs/src/sys/dev/usb/if_athn_usb.c,v
retrieving revision 1.45
diff -u -p -r1.45 if_athn_usb.c
--- if_athn_usb.c   22 Jan 2017 10:17:39 -  1.45
+++ if_athn_usb.c   25 Jan 2017 22:52:10 -
@@ -2104,7 +2104,8 @@ athn_usb_watchdog(struct ifnet *ifp)
if (sc->sc_tx_timer > 0) {
if (--sc->sc_tx_timer == 0) {
printf("%s: device timeout\n", sc->sc_dev.dv_xname);
-   /* athn_usb_init(ifp); XXX needs a process context! */
+   athn_usb_stop(ifp);
+   athn_usb_init(ifp);
ifp->if_oerrors++;
return;
}



Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)

2017-01-25 Thread Martin Pieuchot
On 25/01/17(Wed) 10:36, Stefan Sperling wrote:
> On Tue, Jan 24, 2017 at 03:10:34PM -0500, mabi wrote:
> > Hi Stefan
> > Thanks for your input. It looks like the g2k16 modifications to the athn 
> > code from awolk@ did not make it into the 6.0 release. So there is still 
> > hope for 6.1 ;-)
> 
> There was a rabbit hole this diff by Adam fell into. I don't know what
> the current status of this is. Adam might know more.

The diff should go in, it doesn't make things worse.



Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)

2017-01-25 Thread Stefan Sperling
On Tue, Jan 24, 2017 at 03:10:34PM -0500, mabi wrote:
> Hi Stefan
> Thanks for your input. It looks like the g2k16 modifications to the athn code 
> from awolk@ did not make it into the 6.0 release. So there is still hope for 
> 6.1 ;-)

There was a rabbit hole this diff by Adam fell into. I don't know what
the current status of this is. Adam might know more.

> I suppose here that running a wifi host access point from a USB key is not a 
> good idea. What a shame my firewall does not have any PCI or miniPCI 
> interfaces...

Well, in general this can be made to work. But our driver has bugs with it.

For example, when I last tested this, an athn(4) USB AP was not actually
sending any beacons. It only answered to probe requests sent by clients. 
Which makes it work like it had a "hidden" SSID, but it does not work
like a normal AP.

Do you see beacons from your AP when you run something like this on an
associated client? 'tcpdump -n -y IEEE802_11_RADIO -i iwn0'
If that command does not show beacons, the athn driver is still broken.



Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)

2017-01-24 Thread mabi
Hi Stefan
Thanks for your input. It looks like the g2k16 modifications to the athn code 
from awolk@ did not make it into the 6.0 release. So there is still hope for 
6.1 ;-)
I suppose here that running a wifi host access point from a USB key is not a 
good idea. What a shame my firewall does not have any PCI or miniPCI 
interfaces...
Regards
M.





 Original Message 
Subject: Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)
Local Time: January 23, 2017 11:28 PM
UTC Time: January 23, 2017 10:28 PM
From: s...@stsp.name
To: mabi <m...@protonmail.ch>, misc@openbsd.org <misc@openbsd.org>

On Mon, Jan 23, 2017 at 11:19:31PM +0100, Stefan Sperling wrote:
> On Mon, Jan 23, 2017 at 04:27:32PM -0500, mabi wrote:
> > Hi,
> > I have an Atheros AR9271 Wifi USB 2.0 key on my OpenBSD 6.0 firewall in 
> > order to use as an access point. Unfortunately it happens nearly every day 
> > that the athn0 device times out, kernel log:
> >
> > athn0: device timeout
> >
> > and the only way to make the wireless work again is to reboot the firewall. 
> > I was told this would get better with 6.0 but I can't see any difference. 
> > Any ideas what's wrong? Below I post my hostname.athn0 and dmesg.
> >
> > Cheers,
> > Mabi
>
> These are known issues with athn on USB and hostap.
> I have already spent a lot of time digging into this and never got anywhere.
> Eventually I decided to document this in the man page which you apparently
> missed:
>
> [[[
> ATHN(4) Device Drivers Manual ATHN(4)
>
> NAME
> athn Atheros IEEE 802.11a/b/g/n wireless network device
> [...]
> BUGS
> Host AP mode does not work with USB devices.
> ]]]
>
> Sorry. Anybody, please let me know if you find a way to fix it.

I now recall that awolk@ was working on a patch for a similar problem.
See http://undeadly.org/cgi?action=article=20160906004915 and
https://marc.info/?l=openbsd-misc=144895556213390=2 which I had
already forgotten about ever having written.

Not sure what happened to the patch and if it is ready by now.
Also not sure if it will actually fix your problem or if Adam's problem
was caused by something else. Hard to tell without actually testing things.



Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)

2017-01-23 Thread Stefan Sperling
On Mon, Jan 23, 2017 at 11:19:31PM +0100, Stefan Sperling wrote:
> On Mon, Jan 23, 2017 at 04:27:32PM -0500, mabi wrote:
> > Hi,
> > I have an Atheros AR9271 Wifi USB 2.0 key on my OpenBSD 6.0 firewall in 
> > order to use as an access point. Unfortunately it happens nearly every day 
> > that the athn0 device times out, kernel log:
> > 
> > athn0: device timeout
> > 
> > and the only way to make the wireless work again is to reboot the firewall. 
> > I was told this would get better with 6.0 but I can't see any difference. 
> > Any ideas what's wrong? Below I post my hostname.athn0 and dmesg.
> > 
> > Cheers,
> > Mabi
> 
> These are known issues with athn on USB and hostap.
> I have already spent a lot of time digging into this and never got anywhere.
> Eventually I decided to document this in the man page which you apparently
> missed:
> 
> [[[
> ATHN(4)Device Drivers Manual 
> ATHN(4)
> 
> NAME
>  athn  Atheros IEEE 802.11a/b/g/n wireless network device
> [...]
> BUGS
>  Host AP mode does not work with USB devices.
> ]]]
> 
> Sorry. Anybody, please let me know if you find a way to fix it.

I now recall that awolk@ was working on a patch for a similar problem.
See http://undeadly.org/cgi?action=article=20160906004915 and
https://marc.info/?l=openbsd-misc=144895556213390=2 which I had
already forgotten about ever having written.

Not sure what happened to the patch and if it is ready by now.
Also not sure if it will actually fix your problem or if Adam's problem
was caused by something else. Hard to tell without actually testing things.



Re: athn0: device timeout (AR9271 USB 2.0 Wifi-key as hostap)

2017-01-23 Thread Stefan Sperling
On Mon, Jan 23, 2017 at 04:27:32PM -0500, mabi wrote:
> Hi,
> I have an Atheros AR9271 Wifi USB 2.0 key on my OpenBSD 6.0 firewall in order 
> to use as an access point. Unfortunately it happens nearly every day that the 
> athn0 device times out, kernel log:
> 
> athn0: device timeout
> 
> and the only way to make the wireless work again is to reboot the firewall. I 
> was told this would get better with 6.0 but I can't see any difference. Any 
> ideas what's wrong? Below I post my hostname.athn0 and dmesg.
> 
> Cheers,
> Mabi

These are known issues with athn on USB and hostap.
I have already spent a lot of time digging into this and never got anywhere.
Eventually I decided to document this in the man page which you apparently
missed:

[[[
ATHN(4)  Device Drivers Manual ATHN(4)

NAME
 athn  Atheros IEEE 802.11a/b/g/n wireless network device
[...]
BUGS
 Host AP mode does not work with USB devices.
]]]

Sorry. Anybody, please let me know if you find a way to fix it.



Re: athn0: device timeout with AR9271

2016-08-09 Thread Kapfhammer, Stefan
http://man.openbsd.org/usb.4

Go through all the manpages and look at "bugs",
mostly at the end of all manpages. I have no
recommen‎dation right now. Have no USB network
device‎. Good luck.

‎Wireless network interfaces
athn(4)
Atheros IEEE 802.11a/b/g/n wireless network device
atu(4)
Atmel AT76C50x IEEE 802.11b wireless network device
otus(4)
Atheros USB IEEE 802.11a/b/g/n wireless network device
rsu(4)
Realtek RTL8188SU/RTL8192SU USB IEEE 802.11b/g/n wireless network device
rum(4)
Ralink Technology/MediaTek USB IEEE 802.11a/b/g wireless network device
run(4)
Ralink Technology/MediaTek USB IEEE 802.11a/b/g/n wireless network device
uath(4)
Atheros USB IEEE 802.11a/b/g wireless network device
upgt(4)
Conexant/Intersil PrismGT SoftMAC USB IEEE 802.11b/g wireless network device
ural(4)
Ralink Technology/MediaTek USB IEEE 802.11b/g wireless network device
urtw(4)
Realtek RTL8187L/RTL8187B USB IEEE 802.11b/g wireless network device
urtwn(4)
Realtek RTL8188CU/RTL8188EU/RTL8192CU USB IEEE 802.11b/g/n wireless network 
device
wi(4)
Intersil PRISM 2-3 IEEE 802.11b wireless network device
zyd(4)
ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless network device


Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht
Von: ML mail
Gesendet: Dienstag, 9. August 2016 10:13
An: Miscellaneous OBSD
Antwort an: ML mail
Betreff: Re: athn0: device timeout with AR9271


Uh oh, now it all makes sense with AP mode is not working propery with my
athn...

Can anyone recommend me a USB wireless adapter which does work as host AP on
OpenBSD?


On Monday, August 8, 2016 9:34 PM, "Kapfhammer, Stefan" <sk...@skapf.de>
wrote:



http://man.openbsd.org/OpenBSD-current/man4/athn.4

Last line "Bugs":

‎Host AP mode does not work with USB devices.

Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht

Von: ML mail
Gesendet: Montag, 25. Juli 2016 12:00
An: Miscellaneous OBSD
Antwort an: ML mail
Betreff: athn0: device timeout with AR9271


Hi,

I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time to
time there are timeouts which prevents any access to it anymore until I either
plug out and in the Wifi dongle again or reboot.

Here is the hardware details of that Wifi USB dongle:


athn0 at uhub1 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev
2.00/1.08 addr 4
athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c4:e9:84:xx:xx:xx


There error is the following (many of these messages are repeated):


athn0: device timeout


My /etc/hostname.athn0 is the following:

inet 172.16.20.1 255.255.255.0
media autoselect
mediaopt hostap
mode 11b
chan 6
nwid 
wpakey 

So I was wondering what is going on here... Is my Wifi USB dongle crap? or am
I maybe doing something wrong?

Let me know if I should provide any other infos...


Regards
ML



Re: athn0: device timeout with AR9271

2016-08-09 Thread ML mail
Uh oh, now it all makes sense with AP mode is not working propery with my
athn...

Can anyone recommend me a USB wireless adapter which does work as host AP on
OpenBSD?


On Monday, August 8, 2016 9:34 PM, "Kapfhammer, Stefan" 
wrote:



http://man.openbsd.org/OpenBSD-current/man4/athn.4

Last line "Bugs":

‎Host AP mode does not work with USB devices.

Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht

Von: ML mail
Gesendet: Montag, 25. Juli 2016 12:00
An: Miscellaneous OBSD
Antwort an: ML mail
Betreff: athn0: device timeout with AR9271


Hi,

I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time to
time there are timeouts which prevents any access to it anymore until I either
plug out and in the Wifi dongle again or reboot.

Here is the hardware details of that Wifi USB dongle:


athn0 at uhub1 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev
2.00/1.08 addr 4
athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c4:e9:84:xx:xx:xx


There error is the following (many of these messages are repeated):


athn0: device timeout


My /etc/hostname.athn0 is the following:

inet 172.16.20.1 255.255.255.0
media autoselect
mediaopt hostap
mode 11b
chan 6
nwid 
wpakey 

So I was wondering what is going on here... Is my Wifi USB dongle crap? or am
I maybe doing something wrong?

Let me know if I should provide any other infos...


Regards
ML



Re: athn0: device timeout with AR9271

2016-08-08 Thread Kapfhammer, Stefan
http://man.openbsd.org/OpenBSD-current/man4/athn.4

Last line "Bugs":

‎Host AP mode does not work with USB devices.

Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht
Von: ML mail
Gesendet: Montag, 25. Juli 2016 12:00
An: Miscellaneous OBSD
Antwort an: ML mail
Betreff: athn0: device timeout with AR9271


Hi,

I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time to 
time there are timeouts which prevents any access to it anymore until I either 
plug out and in the Wifi dongle again or reboot.

Here is the hardware details of that Wifi USB dongle:


athn0 at uhub1 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev 
2.00/1.08 addr 4
athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c4:e9:84:xx:xx:xx


There error is the following (many of these messages are repeated):


athn0: device timeout


My /etc/hostname.athn0 is the following:

inet 172.16.20.1 255.255.255.0
media autoselect
mediaopt hostap
mode 11b
chan 6
nwid 
wpakey 

So I was wondering what is going on here... Is my Wifi USB dongle crap? or am I 
maybe doing something wrong?

Let me know if I should provide any other infos...


Regards
ML



Re: athn0: device timeout with AR9271

2016-08-08 Thread ML mail
Some news here... I upgraded the BIOS from a version from 2014 to 2016. 
Unfortunately that did not change anything to the timeouts. I will now wait 
until beginning of September to upgrade to OpenBSD 6.0 and see if that helps.
I will keep you guys posted.
 

On Tuesday, July 26, 2016 11:25 PM, Stefan Sperling  wrote:
 

 On Tue, Jul 26, 2016 at 07:57:46PM +, ML mail wrote:
> Should I upgrade to -CURRENT?

Yes!



Re: athn0: device timeout with AR9271

2016-07-26 Thread Stefan Sperling
On Tue, Jul 26, 2016 at 07:57:46PM +, ML mail wrote:
> Should I upgrade to -CURRENT?

Yes!



Re: athn0: device timeout with AR9271

2016-07-26 Thread Kapfhammer, Stefan
Hi ML,

in which machine is the usb dongle plugged in?
Alix/Apu1/Apu2? Other?


Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht
Von: ML mail
Gesendet: Dienstag, 26. Juli 2016 21:59
An: Adam Wolk; Miscellaneous OBSD
Antwort an: ML mail
Betreff: Re: athn0: device timeout with AR9271


Hi Adam,


I upgraded yesterday from 5.8 to 5.9 and already encountered this morning the
same issue. In the kernel log I get a ton of these messages:

athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out


Now what would be the next step? Should I upgrade to -CURRENT?

or is there any patches I can try from you?

Regards,
ML


On Tuesday, July 26, 2016 11:38 AM, Adam Wolk <adam.w...@tintagel.pl> wrote:



On Mon, Jul 25, 2016 at 01:31:13PM +0200, Stefan Sperling wrote:

> On Mon, Jul 25, 2016 at 09:57:38AM +, ML mail wrote:
> > Hi,
> >
> > I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time
to time there are timeouts which prevents any access to it anymore until I
either plug out and in the Wifi dongle again or reboot.
> >
>
> Please upgrade from 5.8 to 5.9 and then to -current. Last week, bugs
> in the wifi stack were fixed in -current which might affect this.
>

The issue might also be what I encountered with my athn0 usb dongle.
  https://marc.info/?l=openbsd-misc=144895556213390=2

I do plan on implementing the process context for this specific driver (even
started during pkgsrcon in the beginning of this month). Let me know if the
issue persists after upgrading, would be nice to have more than one person to
test the changes when I get around to finishing it up.

Regards,
Adam



Re: athn0: device timeout with AR9271

2016-07-26 Thread Kapfhammer, Stefan
Yeah,

But answer to list and Adam as well, sorry pressed wrong button on my
BlackBerry.


Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht  
Von: ML mail
Gesendet: Dienstag, 26. Juli 2016 22:34
An: Kapfhammer, Stefan
Antwort an: ML mail
Betreff: Re: AW: athn0: device timeout with AR9271

Thanks for the tip regarding the BIOS. The machine was bought autumn 2015 so I
will check with the hardware vendor see if he has a newer firmware for this
BIOS and get back to you.


On Tuesday, July 26, 2016 10:28 PM, "Kapfhammer, Stefan" <sk...@skapf.de>
wrote:

Have latest bis firmware upgrade?
That was the issue on apu2.
After upgrading workes like a charm.


Freundliche Grüße / Regards
-stefan kapfhammer
Originalnachricht

Von: ML mail
Gesendet: Dienstag, 26. Juli 2016 22:26
An: Kapfhammer, Stefan; Adam Wolk; Miscellaneous OBSD
Antwort an: ML mail
Betreff: Re: AW: athn0: device timeout with AR9271


Hi Stefan,

It's a Nexcom network application NSA 1150, you will find the exact specs
here:


http://www.nexcom.com/Products/network-and-communication-solutions/entry-leve
l-appliance/entry-level-appliance/network-communication-nsa-1150

Regards,
ML



On Tuesday, July 26, 2016 10:05 PM, "Kapfhammer, Stefan" <sk...@skapf.de>
wrote:
Hi ML,

in which machine is the usb dongle plugged in?
Alix/Apu1/Apu2? Other?


Freundliche Grüße / Regards
-stefan kapfhammer
Originalnachricht

Von: ML mail
Gesendet: Dienstag, 26. Juli 2016 21:59
An: Adam Wolk; Miscellaneous OBSD
Antwort an: ML mail
Betreff: Re: athn0: device timeout with AR9271


Hi Adam,


I upgraded yesterday from 5.8 to 5.9 and already encountered this morning the
same issue. In the kernel log I get a ton of these messages:

athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out


Now what would be the next step? Should I upgrade to -CURRENT?

or is there any patches I can try from you?

Regards,
ML


On Tuesday, July 26, 2016 11:38 AM, Adam Wolk <adam.w...@tintagel.pl> wrote:



On Mon, Jul 25, 2016 at 01:31:13PM +0200, Stefan Sperling wrote:

> On Mon, Jul 25, 2016 at 09:57:38AM +, ML mail wrote:
> > Hi,
> >
> > I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time
to time there are timeouts which prevents any access to it anymore until I
either plug out and in the Wifi dongle again or reboot.
> >
>
> Please upgrade from 5.8 to 5.9 and then to -current. Last week, bugs
> in the wifi stack were fixed in -current which might affect this.
>

The issue might also be what I encountered with my athn0 usb dongle.
https://marc.info/?l=openbsd-misc=144895556213390=2

I do plan on implementing the process context for this specific driver (even
started during pkgsrcon in the beginning of this month). Let me know if the
issue persists after upgrading, would be nice to have more than one person to
test the changes when I get around to finishing it up.

Regards,
Adam



Re: athn0: device timeout with AR9271

2016-07-26 Thread ML mail
Hi Stefan,

It's a Nexcom network application NSA 1150, you will find the exact specs
here:


http://www.nexcom.com/Products/network-and-communication-solutions/entry-leve
l-appliance/entry-level-appliance/network-communication-nsa-1150

Regards,
ML



On Tuesday, July 26, 2016 10:05 PM, "Kapfhammer, Stefan" <sk...@skapf.de>
wrote:
Hi ML,

in which machine is the usb dongle plugged in?
Alix/Apu1/Apu2? Other?


Freundliche Grüße / Regards
-stefan kapfhammer
  Originalnachricht

Von: ML mail
Gesendet: Dienstag, 26. Juli 2016 21:59
An: Adam Wolk; Miscellaneous OBSD
Antwort an: ML mail
Betreff: Re: athn0: device timeout with AR9271


Hi Adam,


I upgraded yesterday from 5.8 to 5.9 and already encountered this morning the
same issue. In the kernel log I get a ton of these messages:

athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out


Now what would be the next step? Should I upgrade to -CURRENT?

or is there any patches I can try from you?

Regards,
ML


On Tuesday, July 26, 2016 11:38 AM, Adam Wolk <adam.w...@tintagel.pl> wrote:



On Mon, Jul 25, 2016 at 01:31:13PM +0200, Stefan Sperling wrote:

> On Mon, Jul 25, 2016 at 09:57:38AM +, ML mail wrote:
> > Hi,
> >
> > I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time
to time there are timeouts which prevents any access to it anymore until I
either plug out and in the Wifi dongle again or reboot.
> >
>
> Please upgrade from 5.8 to 5.9 and then to -current. Last week, bugs
> in the wifi stack were fixed in -current which might affect this.
>

The issue might also be what I encountered with my athn0 usb dongle.
  https://marc.info/?l=openbsd-misc=144895556213390=2

I do plan on implementing the process context for this specific driver (even
started during pkgsrcon in the beginning of this month). Let me know if the
issue persists after upgrading, would be nice to have more than one person to
test the changes when I get around to finishing it up.

Regards,
Adam



Re: athn0: device timeout with AR9271

2016-07-26 Thread ML mail
Hi Adam,


I upgraded yesterday from 5.8 to 5.9 and already encountered this morning the 
same issue. In the kernel log I get a ton of these messages:

athn0: firmware command 0x17 timed out
athn0: firmware command 0x18 timed out


Now what would be the next step? Should I upgrade to -CURRENT?

or is there any patches I can try from you?

Regards,
ML


On Tuesday, July 26, 2016 11:38 AM, Adam Wolk  wrote:



On Mon, Jul 25, 2016 at 01:31:13PM +0200, Stefan Sperling wrote:

> On Mon, Jul 25, 2016 at 09:57:38AM +, ML mail wrote:
> > Hi,
> > 
> > I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time 
> > to time there are timeouts which prevents any access to it anymore until I 
> > either plug out and in the Wifi dongle again or reboot.
> > 
> 
> Please upgrade from 5.8 to 5.9 and then to -current. Last week, bugs
> in the wifi stack were fixed in -current which might affect this.
> 

The issue might also be what I encountered with my athn0 usb dongle.
  https://marc.info/?l=openbsd-misc=144895556213390=2

I do plan on implementing the process context for this specific driver (even
started during pkgsrcon in the beginning of this month). Let me know if the
issue persists after upgrading, would be nice to have more than one person to
test the changes when I get around to finishing it up.

Regards,
Adam



Re: athn0: device timeout with AR9271

2016-07-26 Thread Adam Wolk
On Mon, Jul 25, 2016 at 01:31:13PM +0200, Stefan Sperling wrote:
> On Mon, Jul 25, 2016 at 09:57:38AM +, ML mail wrote:
> > Hi,
> > 
> > I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time 
> > to time there are timeouts which prevents any access to it anymore until I 
> > either plug out and in the Wifi dongle again or reboot.
> > 
> 
> Please upgrade from 5.8 to 5.9 and then to -current. Last week, bugs
> in the wifi stack were fixed in -current which might affect this.
> 

The issue might also be what I encountered with my athn0 usb dongle.
  https://marc.info/?l=openbsd-misc=144895556213390=2

I do plan on implementing the process context for this specific driver (even
started during pkgsrcon in the beginning of this month). Let me know if the
issue persists after upgrading, would be nice to have more than one person to
test the changes when I get around to finishing it up.

Regards,
Adam



Re: athn0: device timeout with AR9271

2016-07-25 Thread Stefan Sperling
On Mon, Jul 25, 2016 at 09:57:38AM +, ML mail wrote:
> Hi,
> 
> I installed a USB Wifi card on my OpenBSD 5.8 firewall as AP and from time to 
> time there are timeouts which prevents any access to it anymore until I 
> either plug out and in the Wifi dongle again or reboot.
> 

Please upgrade from 5.8 to 5.9 and then to -current. Last week, bugs
in the wifi stack were fixed in -current which might affect this.



Re: athn0: device timeout

2015-11-30 Thread Stefan Sperling
On Sun, Nov 29, 2015 at 02:52:15PM +0100, Adam Wolk wrote:
> Now to be precise. I can use this dongle quite fine. It sometimes goes
> up to 1 hour of usage without any timeouts. When it does timeout it's
> usually in rapid succession (like 2-3 times in next 10 minutes). Each
> time after a timeout I can restart the connection with netstart
> *without* unplugging the device.

If transmission of a frame times out (e.g. because of environmental
reasons like distortion or like parts moving out of radio range), the
hardware doesn't signal "transfer complete" and a watchdog handler
is triggered to handle the situation.

Usually, this watchdog will reset the hardware (down/up the interface)
and hope that things will work afterwards.
However, this is currently not implemented for most USB drivers where
you'll find an XXX comment in the watchdog code:

if (--sc->sc_tx_timer == 0) {
printf("%s: device timeout\n", sc->sc_dev.dv_xname);
/* urtwn_init(ifp); XXX needs a process context! */
ifp->if_oerrors++;
return;
}

So... USB drivers don't recover from transmit errors :(
This needs to be fixed to solve your issue.
Most drivers for PCI devices already do the right thing here.

Note that the watchdog runs in interrupt context and filesystem access
(ie. loading firmware) is impossible in this context. One PCI driver which
has the same problem is iwm(4). Look there for an approach that should also
work for USB drivers: Using the task API (task_add(9), task_del(9), etc.)
to reset the hardware from process context.

All other people in this thread had attachment problems which are not
related to the watchdog at all.



Re: athn0: device timeout

2015-11-30 Thread Gonzalo L. Rodriguez
I have the same problem with a new macbookpro12,1 my urtwn adapter work 
just fine in a regular ehci(4) machine, but on xhci(4)'s macbookpro I 
need to reconnect like 10 times, and even that way, doesn't work. :/

On 28/11, Stefan Sperling wrote:
; On Sat, Nov 28, 2015 at 07:35:00AM -0700, bluesun08 wrote:
; > xhci0 at pci0 dev 20 function 0 "Intel Bay Trail xHCI" rev 0x0c: msi
; > usb0 at xhci0: USB revision 3.0
; > uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
; > uhub2 at uhub0 port 2 "Genesys Logic USB2.0 Hub" rev 2.00/85.37 addr 3
; > athn1 at uhub2 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev
; > 2.00/1.08 addr 6
; > athn1: could not load firmware
; 
; I believe your problems are rooted in xhci(4) not athn(4).
; There are several known problems with xhci, some of which
; don't have a known fix yet.
; 
; To confirm this theory, could you try this athn adapter in a
; machine with USB ports driven by ehci(4) instead of xhci(4)?
; 

-- 
Sending from my toaster.



Re: athn0: device timeout

2015-11-29 Thread Adam Wolk
On Sat, 28 Nov 2015 22:30:03 -0800
Bryan Vyhmeister  wrote:

> On Sat, Nov 28, 2015 at 09:24:23AM -0700, bluesun08 wrote:
> > ok, now i tested my adapter on 
> > a) another machine
> > b) another usb port.
> > 
> > Result: The adapter don't work on a) and don't work on b).
> > 
> > Is there any other Wifi-USB-adapter which work reasonably reliable
> > on OpenBSD in HostAP mode?
> 
> I have what I believe is the exact same device you do (TP-Link
> TL-WN722N) and I just plugged it in to my MacBookAir7,2 where uhub0 is
> attached to usb0 which is attached to xhci0 and, after running
> fw_update to get the athn(4) firmware, was able to reattach and bring
> it up in hostap mode without any issues.
> 
> athn0 at uhub0 port 1 configuration 1 interface 0 "ATHEROS USB2.0
> WLAN" rev 2.00/1.08 addr 8
> athn0: AR9271 rev 1 (1T1R), ROM rev 13, address f8:1a:67:1f:cc:89
> 
> athn0: flags=8843 mtu 1500
> lladdr f8:1a:67:1f:cc:89
> priority: 4
> groups: wlan
> media: IEEE802.11 autoselect (autoselect hostap)
> status: active
> ieee80211: nwid "hostap test" chan 1 bssid f8:1a:67:1f:cc:89
> 
> 
> I think stsp@ is correct that something else is going on with xhci(4)
> on your machine since this USB device works pretty well. I also
> tested an older rum(4) device I have as well and that also works.
> 
> Bryan
> 

I recently bought the exact same TP-LINK USB wireless (TL-WN722N). It
brings the interface nicely up and the connection works but times out
quite regularly but I am able to reconnect it back with doas
sh /etc/netstart.

Though in my case it's just athn0: device timed out without any
firmware info.

Tested on OpenBSD -current amd64 snapshots from: 31 Oct & 25 November
on a Lenovo G50-70.

Now to be precise. I can use this dongle quite fine. It sometimes goes
up to 1 hour of usage without any timeouts. When it does timeout it's
usually in rapid succession (like 2-3 times in next 10 minutes). Each
time after a timeout I can restart the connection with netstart
*without* unplugging the device.

OpenBSD 5.8-current (GENERIC.MP) #1663: Wed Nov 25 13:59:58 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 8464887808 (8072MB)
avail mem = 8204222464 (7824MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6e40 (38 entries)
bios0: vendor LENOVO version "9ACN29WW" date 10/20/2014
bios0: LENOVO 20351
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC UEFI FPDT POAT ASF! HPET APIC MCFG WDAT SSDT BOOT 
LPIT ASPT DBGP SSDT SSDT SSDT SSDT
acpi0: wakeup devices P0P1(S4) UAR1(S3) EHC1(S3) XHC_(S3) HDEF(S4) TPD4(S4) 
TPD7(S0) TPD8(S0) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
PXSX(S4) RP04(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 1895.87 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 1895.62 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 1895.62 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 1895.62 MHz
cpu3: 

Re: athn0: device timeout

2015-11-28 Thread bluesun08
Hi again,

here are more error-messages:

Nov 28 20:34:23 openbsd /bsd: athn0 detached
Nov 28 20:34:25 openbsd /bsd: athn0 at uhub0
Nov 28 20:34:25 openbsd /bsd:  port 1 configuration 1 interface 0 "ATHEROS
USB2.0 WLAN" rev 2.00/1.08 addr 2
Nov 28 20:34:26 openbsd /bsd: athn0: AR9271 rev 1 (1T1R), ROM rev 13,
address c4:e9:84:dc:44:ba
Nov 28 20:34:26 openbsd /bsd: athn0 detached
Nov 28 20:34:27 openbsd /bsd: usbd_fill_iface_data: bad max packet size
Nov 28 20:34:27 openbsd /bsd: usbd_fill_iface_data: bad max packet size
Nov 28 20:34:27 openbsd /bsd: athn0 at uhub0
Nov 28 20:34:27 openbsd /bsd:  port 1 configuration 1 interface 0 "ATHEROS
USB2.0 WLAN" rev 2.00/1.08 addr 2
Nov 28 20:34:37 openbsd /bsd: athn0: firmware command 0x18 timed out
Nov 28 20:34:47 openbsd /bsd: athn0: firmware command 0x17 timed out
Nov 28 20:34:57 openbsd /bsd: athn0: firmware command 0x18 timed out
Nov 28 20:35:07 openbsd /bsd: athn0: firmware command 0x17 timed out




--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/athn0-device-timeout-tp283934p283949.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.



Re: athn0: device timeout

2015-11-28 Thread Stefan Sperling
On Sat, Nov 28, 2015 at 03:59:08AM -0700, bluesun08 wrote:
> Hi again,
> 
> here are more error-messages:
> 
> Nov 28 20:34:23 openbsd /bsd: athn0 detached
> Nov 28 20:34:25 openbsd /bsd: athn0 at uhub0
> Nov 28 20:34:25 openbsd /bsd:  port 1 configuration 1 interface 0 "ATHEROS
> USB2.0 WLAN" rev 2.00/1.08 addr 2
> Nov 28 20:34:26 openbsd /bsd: athn0: AR9271 rev 1 (1T1R), ROM rev 13,
> address c4:e9:84:dc:44:ba
> Nov 28 20:34:26 openbsd /bsd: athn0 detached
> Nov 28 20:34:27 openbsd /bsd: usbd_fill_iface_data: bad max packet size
> Nov 28 20:34:27 openbsd /bsd: usbd_fill_iface_data: bad max packet size
> Nov 28 20:34:27 openbsd /bsd: athn0 at uhub0
> Nov 28 20:34:27 openbsd /bsd:  port 1 configuration 1 interface 0 "ATHEROS
> USB2.0 WLAN" rev 2.00/1.08 addr 2
> Nov 28 20:34:37 openbsd /bsd: athn0: firmware command 0x18 timed out
> Nov 28 20:34:47 openbsd /bsd: athn0: firmware command 0x17 timed out
> Nov 28 20:34:57 openbsd /bsd: athn0: firmware command 0x18 timed out
> Nov 28 20:35:07 openbsd /bsd: athn0: firmware command 0x17 timed out
> 

This is probably related to
http://marc.info/?l=openbsd-bugs=144335205811632=2
and http://marc.info/?l=openbsd-tech=143645936727569=2

Can you confirm that your athn device works fine on a different
USB host controller (perhaps in a different machine)?

Why didn't you include a full dmesg in your report?



Re: athn0: device timeout

2015-11-28 Thread Stefan Sperling
On Sat, Nov 28, 2015 at 07:35:00AM -0700, bluesun08 wrote:
> xhci0 at pci0 dev 20 function 0 "Intel Bay Trail xHCI" rev 0x0c: msi
> usb0 at xhci0: USB revision 3.0
> uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
> uhub2 at uhub0 port 2 "Genesys Logic USB2.0 Hub" rev 2.00/85.37 addr 3
> athn1 at uhub2 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev
> 2.00/1.08 addr 6
> athn1: could not load firmware

I believe your problems are rooted in xhci(4) not athn(4).
There are several known problems with xhci, some of which
don't have a known fix yet.

To confirm this theory, could you try this athn adapter in a
machine with USB ports driven by ehci(4) instead of xhci(4)?



Re: athn0: device timeout

2015-11-28 Thread bluesun08
ok, i try it on another machine but now i get the error message:

athn0: could not load firmware

Despite:

ls /etc/firmware
-r--r--r--   1 root  bin 70624 Aug  9 01:05 athn-ar7010
-r--r--r--   1 root  bin 70624 Aug  9 01:05 athn-ar7010-11
-r--r--r--   1 root  bin 51280 Aug  9 01:05 athn-ar9271






--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/athn0-device-timeout-tp283934p283962.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.



Re: athn0: device timeout

2015-11-28 Thread bluesun08
So now i can test my athn device on 
a) a different host controller and
b) on a different machine.

The results: The athn device won't work on a) and won't work on b).





--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/athn0-device-timeout-tp283934p283969.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.



Re: athn0: device timeout

2015-11-28 Thread bluesun08
ok, now i tested my adapter on 
a) another machine
b) another usb port.

Result: The adapter don't work on a) and don't work on b).

Is there any other Wifi-USB-adapter which work reasonably reliable on
OpenBSD in HostAP mode?

regards

Alex



--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/athn0-device-timeout-tp283934p283972.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.



Re: athn0: device timeout

2015-11-28 Thread bluesun08
sorry, i forgot:

dmesg

OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3965698048 (3781MB)
avail mem = 3841617920 (3663MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebd40 (19 entries)
bios0: vendor American Megatrends Inc. version "P1.30" date 07/07/2014
bios0: ASRock Q1900-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG LPIT AAFT HPET SSDT SSDT SSDT UEFI
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) XHC1(S4) EHC1(S4) PXSX(S4)
PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) BRCM(S0) BRC3(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.46 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins
acpimadt0: bogus nmi for apid 0
acpimadt0: bogus nmi for apid 2
acpimadt0: bogus nmi for apid 4
acpimadt0: bogus nmi for apid 6
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus 4 (RP04)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: !C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: !C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: !C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51),
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PLPE
acpipwrres1 at acpi0: PLPE
acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1
acpipwrres3 at acpi0: CLK0, resource for CAM1
acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 90 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 2000 MHz: speeds: 1993, 1992, 1909, 1826, 1743,
1660, 1577, 1494, 1411, 1328 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0c
vga1 at pci0 dev 2 function 0 "Intel Bay Trail Video" rev 0x0c
intagp at vga1 not configured
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ahci0 at pci0 dev 19 function 0 "Intel Bay Trail AHCI" rev 0x0c: msi, AHCI
1.3
ahci0: port 1: 1.5Gb/s
scsibus1 at ahci0: 32 targets
cd0 at scsibus1 targ 1 lun 0:  ATAPI
5/cdrom removable
xhci0 at pci0 dev 20 function 0 "Intel Bay Trail xHCI" rev 0x0c: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel Bay Trail TXE" rev 0x0c at pci0 dev 26 function 0 not 

Re: athn0: device timeout

2015-11-28 Thread Bryan Vyhmeister
On Sat, Nov 28, 2015 at 09:24:23AM -0700, bluesun08 wrote:
> ok, now i tested my adapter on 
> a) another machine
> b) another usb port.
> 
> Result: The adapter don't work on a) and don't work on b).
> 
> Is there any other Wifi-USB-adapter which work reasonably reliable on
> OpenBSD in HostAP mode?

I have what I believe is the exact same device you do (TP-Link
TL-WN722N) and I just plugged it in to my MacBookAir7,2 where uhub0 is
attached to usb0 which is attached to xhci0 and, after running fw_update
to get the athn(4) firmware, was able to reattach and bring it up in
hostap mode without any issues.

athn0 at uhub0 port 1 configuration 1 interface 0 "ATHEROS USB2.0 WLAN"
rev 2.00/1.08 addr 8
athn0: AR9271 rev 1 (1T1R), ROM rev 13, address f8:1a:67:1f:cc:89

athn0: flags=8843 mtu 1500
lladdr f8:1a:67:1f:cc:89
priority: 4
groups: wlan
media: IEEE802.11 autoselect (autoselect hostap)
status: active
ieee80211: nwid "hostap test" chan 1 bssid f8:1a:67:1f:cc:89


I think stsp@ is correct that something else is going on with xhci(4) on
your machine since this USB device works pretty well. I also tested an
older rum(4) device I have as well and that also works.

Bryan