Squonk: Thanks for your great work and deep insight into this issue!

I'd like to step in and report of my experiences with this bug.

I'm heavily experimenting with USB webcams, weather data via ser2usb and 1-wire.
When running AA12.09 on MR3020 + DIR-505, I always had errors in the webcam pictures: Heavily distorted, i.e. one or more horizontal strips of the picture were shifted sideways and what has been shifted out of the picture one one side, appeared on the other side of the picture.

After switching the DIR-505 from AA to trunk (r40502): Surprise, surprise, the errors are gone! Yeah! Finally!
OK, at least with most of the cams I don't have errors any more but two Pro9000 from Logitech. Since they are old versions of this model and are known to make problems, I don't mind putting them in the trash can. The remaining ones are working well enough for me and show only occasionally single errors.

So as for the webcams: BIG improvement! Thanks for that!

Now for the drawback: owfs is making problems now on my DIR-505's (r40502+r40659) which both run as wifi client. I described the problem and the solution in https://forum.openwrt.org/viewtopic.php … 83#p232083

Could the described problem with owfs be related to AR9331's bug?
I have a workaround in place (separate USB hub for the DS9490 and reset of this hub via rc.local), but I would like to get rid of it, expecially the extra USB hub...

There is actual a big issue with native USB 2.0 devices, like LTE-Sticks from Huawei, see this ticket:

https://dev.openwrt.org/ticket/16505

After several try & error to test different combinations, i noted, that after a cold boot, mostly the E3276 stick (which include an own usb 2.0 hub!) is not detected correctly.

Pluggin the stick manually in & out mostly detect the stick, so i asume there is a initial-problem in the module-init
order and i bet, some registers are not correctly inititialized after reboot. Further more, there is a difference
between power on/off and a softreboot.

The ath9-driver is COMPLETLY disabled - so it can´t interfer with the USB-Port (For my project i have no need
for wireless at all...)

I get mostly this errors 3 times in a row on coldboot:

usb 1-1: device descriptor read/64, error -145
usb 1-1: device not accepting address 2, error -145
usb 1-1: new high-speed USB device number 3 using ehci-platform
usb 1-1: device not accepting address 3, error -145
hub 1-0:1.0: unable to enumerate USB device on port 1

With an extra USB-cable between 30-60cm in length the stick is more often detected.
The stick itself is working perfectly. I have 3 other Sticks from same type, and all switches
shows the same issues.

Older Huawei UMTS-Sticks, like the E3131, E303, etc. are always detected. This devices are
pure 2.0 Sticks, too !

It looks like a problem, that the E3276 needs very long time to initialize after power-plugging,
normaly 5-7 seconds to respond first time.

"old_scheme_first" and such tunings are useless, i tested all possible combinations - no luck.

In this Situation ONLY the "passive-Hub-Fix" is working very well. But here i have no
usb 1.1 issues, neighter power-problems and i don´t have ath9k enabled, which interfer...

Only one method is working "half" reliable:

- completly UNPLUG the stick from the device
- unplug the wrt710n for MINIMUM 5 seonds from power
- let the unit completly bootup
- manual plugin the stick, but WITH an usb-extra cable
- wait a few seconds and the stick is mostly detected first time.

I think some registers are not cleaned between reboot or a very short power on/off,
and initialisation not work, when the stick is plugged in at boot time.

Only "late inserting" makes ist detectable.

With other devices, lile FTDI, PL2303, USB-Sticks, Sensors or Harddrives i never have such
problems, no matter in which order the devices are plugged in and out (or booted up withit)

Have anyone an idea how to fix this problem ?

Using Huawei LTE Sticks with the WR710nV1 is a very common configuration...

We are also running into this issue. I can reproduct this by:
- Connecting my TP-Link MR3020 to a wireless network
- Getting some serial communication going (with or without usb hub)
- Pulling the power out of the router that produces the wireless network.

When I power cycle the port it get's back up, under a different port (/dev/ttyACM1 > /dev/ttyACM2), but this only works temporarily. Only if I also turn wifi off (wifi down) it keeps working.

I understand from the iw documentation that wpa_supplicant automatically tries to reconnect when a connection is broken, is there simple way to disable this? Did anyone try to only use iw?
More info: http://wireless.kernel.org/en/users/Doc … connection

(Last edited by peteruithoven on 22 May 2014, 12:29)

Hi,

Does anyone know whether the ar1311 device exhibits the same problem with USB?  I need to find a reliable module that can be used with a USB to serial adapters, regardless of operating mode(AP, client, etc.).  Is there another Atheros chip I should be looking at?  I'm also looking at the RT5350, but the power consumption of that device has me a bit concerned.  Thanks!

Exactly the issue I encounter. I finally added an embedded USB 2.0 hub, problem solved and I gained an external USB port in the process.

Using a high speed hub does help. I did some tests with 2 different high speed hubs and without a hub.

Test protocol
A router running in wisp mode (forwarding a wireless network)
Starting my OpenWRT router having it connect to the wisp router.
Connecting a fullspeed (Arduino like) device through usb and checking a log (tail -f) of the serial communication. I tried this with 2 usb hubs and without usb hub.
After a while I would pull the power plug out of the wisp router.
If the serial communication continued I tried restarting the router and checked whether the OpenWRT router reconnected automatically.
If the serial communication continued I tried this again.
After the test I restarted the OpenWRT router and serial device.

Without usb hub
Stopped serial communication consistently (3 times) after a short delay when I removed the power from the wisp router.

With high speed usb hub Belkin f5u407
Kept working after I removed the power from the wisp router (3 times).
But it sometimes stops when I power the wisp router again and it tries to reconnect. 1 of out 3 times it stopped the first time, 2 times it stops after a second reconnect attempt.

With other high speed usb hub 225738
Kept working after I removed the power from the wisp router (3 times).
And it usually kept working through router restarts and reconnects.
2 out of 3 times it handled 3 restarts and kept working (I didn't test further)
1 out of 3 times it stopped serial communication on the second restart.

So using a high speed hub improves the situation a great deal, but it isn't unbreakable.

We've build Doodle3D using OpenWRT and having better full speed support is very important to us, since most 3D printers have something like a Arduino inside.
Let us know if we can provide more information or perform tests.

Hi everyone with USB stability issues...

I suppose you dont use AA12.09?
You must use trunk, BB >= r39212

Has anyone of you tried this new fix in trunk BB >= r40841 (2014-05-24)?
https://dev.openwrt.org/changeset/40841

Please report your tests in this thread

(Last edited by _wr703n_ on 3 Jun 2014, 13:54)

With r40867, I still see the "un-associated STA wifi kills FS USB" issue, no change at all.

Dana

FYI, a friend has tried a USB to serial adapter on a D-Link DIR-505 running OpenWRT, and it exhibits the same USB problem.  The DIR-505 contains an AR1311.  Thus it appears that the AR1311 has the same USB problem as the AR9331.

galen

Do you know for sure that he is using BB >= r40841?

Yes.  As of r40841 part of the problem appears solved, but not the "i-am-not-yet-unassociated-and-am-scanning-to-find-my-network" problem, described by others, above.  It appears the ar1311 is an ar9331, at least u-boot thinks so. 

U-Boot 1.1.4 (Feb  9 2012 - 20:12:45)

AP121 (ar9331) U-boot

DRAM:  64 MB
Top of RAM usable for U-Boot at: 84000000
Reserving 161k for U-Boot at: 83fd4000
Reserving 192k for malloc() at: 83fa4000
Reserving 44 Bytes for Board Info at: 83fa3fd4
Reserving 36 Bytes for Global Data at: 83fa3fb0
Reserving 128k for boot params() at: 83f83fb0
Stack Pointer at: 83f83f98
Now running in RAM - U-Boot at: 83fd4000
============================================ 
Date:Feb  9 2012  Time:20:12:45
Cameo Version: v1.00 Build:03
Module Name: D-Link DIR-505A1
[...]

In addition, /proc/cpuinfo reports:

system type             : Atheros AR9330 rev 1
machine                 : D-Link DIR-505 rev. A1

This version of U-Boot is "stupid" and doesn't "think" (doesn't recognize SoC version/revision).
AR1311 is fully compatible with AR9331 and looks like some kind of special revision.

In any case, it has the same bug.

As far as arcane bugs go, this one is pretty special :-)

danak6jq, what USB hub chipset did you use to fix the issue?

Microchip/SMSC USB2412 works like a charm.

I see this issue is marked as solved, but I'm still experiencing it with trunk (BB r41391) on a TL-WR703N (AR9331) with WiFi enabled: https://forum.openwrt.org/viewtopic.php?id=51315

In my case it involves a Logitech webcam repeatedly disconnecting, and appears to be related to the autofocus as I can cause a disconnect by waving my hands in front of it (I haven't 100% confirmed this is the cause though).

I was able to solve the problem by using an unpowered hub, but I'd love to know if there's a software fix.

It is not the same issue: the bug that is discussed here affects Full-Speed devices, which is not your case with a camera enumerated as High-Speed.

Ah okay. Any chance they're related though? I still don't know why using the hub helped.

The only thing coming out of my head is decoupling, but it looks like you already tried that. I suggest to put a scope if you have access to one. Having this phenomenon only when the autofocus is triggered is more than a simple coincidence IMHO: the autofocus motor is probably drawing too much current and/or is not sufficiently decoupled, causing the USB power to dip on these small routers.

Hi,

I want to use my WR703N as airplay device. I have compiled trunk (BB r41400) which
is suppose to have the famous usb patch applied.

No problems compiling firmware and running Shairport (https://github.com/sm3rt/OpenWRT-ShairPort) but i hear constantly sizzling/popping with and without playing music.

I have an Asus Xonar U3 DAC connected to WR703N. I realize that only with put one finger
in the bottom of the DAC, sizzling/popping disappear.

So i think i am affected by a usb ground loop. Can this be solved in software way?. I think
that this must be solved in hardware way. I am correct?.

Can someone with WR703N as airplay device and without sizzling/popping issues, comment which usb dac and which openwrt firmware or trunk revision are using?

Please, I will appreciate very much guru comments!!!

Thanks a lot.

(Last edited by netamego on 17 Jul 2014, 09:13)

Ok. My issue was finally ground loop problem and was solved after put an usb extension between wr703n and usb dac. Thanks.

(Last edited by netamego on 18 Jul 2014, 23:55)

Hi. I have tplink tl-mr3040(v2.1, aa 12.09) <---> dlink hub(dub h7) <---> usb audio card (xonar U3), so i hear the "sizzling/popping" with and without playing music too. Could you please tell me what usb extension did you used to solve ground loop.

So, finally i have flashed it with BB 14.07-rc2 and I think the problem has gone.

Does  BB 14.07-rc2 include Lucl web interface or just CL interface?