Sft1200 opal issue with usb tethering after updating to 4.3.11

Technical Support for Routers
23

I also experienced bug of reconnection on SFT1200 in 4.3.11. Now in 4.3.17 it seems to be fixed.

But as some mentioned, there is still something wrong with usb tethering on SFT1200/Opal especially when non USB-C power adapter is used (or POE USB-C splitter / usb powerbank / usb-a to usb-c cable).

I power some of my GL Opal routers with POE Splitter 5V / 3A (or 2A) or with common USB-A 5V/2A adapter with USB-A to USB-C cable (genuine Samsung). Had no issues with thetering on AR300M16/Shadow or GL-MT1300/Beryl (they have OpenWRT 22, Opal has OpenWRT 18).

I used devices like Huawei 4G/LTE USB stick e3372, or some supercheap LTE+WIFI USB stick (CPU: ASR 1803, Wi-Fi: ASR5803). With Opal routers thetering device is 80-90% of the time not visible / not detected if I use non genuine power adapter, despite there is plenty of power.

Example: Opal connected using 2A or 3A (10/15W) POE USB-C Splitter (inside are 2 power cables feeding usb-c connector, no special data logic for power negotiation).

Power consumption with Huawei e3372 is no more than 5-6 watts, but this thetering USB device keeps disconnecting. If I reduce power consumption - by disabling wifi or by disconnecting LAN cable, thetering will be enabled (or is more stable).

Similar with USB-A Adapter or Power bank (USB-A to USB-C cable). Sometimes, after reboot thetering is present, but it will disapear as soon as power consumption increases (despite being low).

I checked logs with USB LTE stick connected (thetering was disabled) and I found this:

root@GL-SFT1200:~# dmesg
[   73.346090] dwc2 17000000.usb: **Overcurrent change detected**
[   73.423113] found hnat device to add
[   73.426814] [hnat notice]add wifi dev index 5 ndev84881000
[   73.449232] lb-fmac 11000000.wifi-lb .tmp.phy0.sta0: Remove Interface
[   73.456085] found hnat device to del
[   73.468288] lb-fmac 11000000.wifi-lb .tmp.phy0.sta0: CLOSE
[   73.475908] lmac[0] vif_mgmt_unregister index=1 
[   73.583019] lb-fmac 11000000.wifi-lb .tmp.phy0.sta0 (unregistering): Remove Interface Over
[   73.594946] usb 1-1: **USB disconnect**, device number 4

Similar for fw 4.3.7, 4.3.11, 4.3.17.

I think when @marcone plugged USB meter in line, it increased resistance little bit and "overcurrent" detection was not triggered (or in less cases).

Has Opal too aggressive overcurrent protection / detection ?

Yesterday I tested AR300M16/Shadow powered by Powerbank with 2A port.
Connected 4 port USB hub AXAGON - then added 16GB USB storage stick, USB to Serial adapter connected to Victron charge controller and of course 4G+Wifi USB stick (ASR5803 chipset). Shadow idle power consumption was around 0,4 Amps.

I started speedtest (using 4G stick with sim card). During upload there was maximum power draw at 0,6 Amps (5,1 volts). Then I connected shadow to wifi router using WIFI thetering and also connected LAN cable. All was super stable even after restarts.

Opal's power consumption is just around +2W higher than AR300M16/Shadow so it should work without issue even on 2 Amp power bank / adapter.

I cant test my GL-MT1300/Beryl right now, but I think thetering with 4G USB worked also fine even when powered with USB Powerbank. Beryl has higher power consumption than Opal.

Opal works as expected only when I use genuine usb-c adapter or usb-c adapter with usb-c cable (tested with samsung). Any combination with USB-A to USB-C cables or USB-C poe splitter doesnt work well with thetering.

Not sure if this is software or hardware related.
Can be this strange overcurrent protection disabled / adjusted somehow ?

1 Like
24

I cannot exactly explain how does the hardware handle the current. I asked hardware engineers to have a check. SFT1200 Opal is just sensitive to power input.

Anyway pls use the stock power adapter if you can because it is well tested.

1 Like
25

SFT1200's USB output is sensitive to voltage. If voltage drops a lot it will just cut.

26

there's a known issue with dwc2 on kernel 4.14.90, it's actually fixed in 4.14.91 and upwards

Please may SiFlower rebase the SFT1200 kernel on 4.14.349

The latest supported 4.14 kernel fixes so many things for the SFT1200 and would improve it's lifespan.

27

Hi hecatae:

Do you know what the impact of this known dwc2 problem is?

From the link you provided, there are a lot of contents related to dwc2, we hope to narrow the scope of the problem.

1 Like
28

@dxf

Which dwc2 driver is the SFT1200 base using, the dwc2 driver on the Openwrt base was heavily patched with upstream patches when 19.07-rc1 was released.

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=9f451ec698ede068e911821473cbe94f50a2977c

Openwrt never backported this to the 18.06 base, but these changes are specific for allowing devices like the e3372 that @Daimonion is having problems with to work.

29

Hi hecatae:

We have already merged these patches.

1 Like
30

Thank you for confirming, looking further at:

@dxf any issue with updating the entire dwc2 driver?

31

It will cause some compilation failures.

32

@dxf I'm willing to test anything you want to throw at me, I have four SFT1200 to test with.

1 Like