I'd say most (openwrt) devices would freeze or reboot, but not factory reset themselves.
Except perhaps for those with dual firmwares, who might decide to switch over to the other FW.
This is a completely bog standard subscription. The APN is not the default, but documented and available to all customers.
root@miraculix:/tmp# mmcli -m any --simple-connect=apn=internet.public
successfully connected the modem
root@miraculix:/tmp# mmcli -b 2
--------------------------------
General | path: /org/freedesktop/ModemManager1/Bearer/2
| type: default
--------------------------------
Status | connected: yes
| suspended: no
| interface: wwan0
| ip timeout: 20
--------------------------------
Properties | apn: internet.public
| roaming: allowed
--------------------------------
IPv4 configuration | method: static
| address: 77.18.148.220
| prefix: 29
| gateway: 77.18.148.221
| dns: 193.213.112.4, 130.67.15.198
| mtu: 1500
--------------------------------
Statistics | attempts: 1
root@miraculix:/tmp# ifconfig wwan0 77.18.148.220/29
root@miraculix:/tmp# ip route add default dev wwan0 table 42
root@miraculix:/tmp# ip rule add pref 2000 from 77.18.148.220 lookup 42
Connecting back from the outside:
bjorn@louie:~$ traceroute 77.18.148.220
traceroute to 77.18.148.220 (77.18.148.220), 30 hops max, 60 byte packets
1 213.138.100.3 (213.138.100.3) 3.898 ms 3.833 ms 3.839 ms
2 4008.be1.cr4.man.bytemark.co.uk (80.68.87.248) 1.190 ms 1.186 ms 1.391 ms
3 130.180.202.76 (130.180.202.76) 1.089 ms 1.057 ms 1.080 ms
4 be16.asr01.ld5.as20860.net (130.180.202.0) 6.329 ms 6.379 ms 6.245 ms
5 * * *
6 ti3004c400-ae0-0.ti.telenor.net (146.172.105.73) 37.781 ms 37.675 ms 37.538 ms
7 ti0001c360-ae96-0.ti.telenor.net (146.172.23.46) 48.763 ms 48.779 ms 48.810 ms
8 ti0275c360-ae1-0.ti.telenor.net (146.172.22.37) 49.657 ms 48.834 ms 48.771 ms
9 ti0300a401-ae1-0.ti.telenor.net (146.172.98.246) 37.964 ms 38.011 ms 37.923 ms
10 ti280839047j370-ae0-21.ti.telenor.net (193.214.190.90) 42.481 ms 42.464 ms 42.414 ms
11 * * *
12 77.16.1.147.tmi.telenormobil.no (77.16.1.147) 44.163 ms 44.057 ms 43.948 ms
13 77.18.148.220.tmi.telenormobil.no (77.18.148.220) 420.392 ms 420.342 ms 382.868 ms
bjorn@louie:~$ ssh bjorn@77.18.148.220
The authenticity of host '77.18.148.220 (77.18.148.220)' can't be established.
ECDSA key fingerprint is SHA256:i8cfDc9kCFjkeEJNBcAxIaQE9c/g3+a5pWLP4ngOn88.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '77.18.148.220' (ECDSA) to the list of known hosts.
bjorn@77.18.148.220's password:
Linux miraculix 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Aug 16 17:57:15 2021
bjorn@miraculix:~$ ifconfig wwan0
wwan0: flags=4291<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1500
inet 77.18.148.220 netmask 255.255.255.248 broadcast 77.18.148.223
ether 12:01:0b:49:d0:02 txqueuelen 1000 (Ethernet)
RX packets 52 bytes 6380 (6.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 121 bytes 18200 (17.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
bjorn@miraculix:~$
@frollic I can understand some sort of crash or reboot but to factory default and then come back up with the 4G interface down is just useless for a remote application, this is why I class Glinet products as crap.
I am now looking at how the device factory defaults to see if I can alter the scripts to at least force the 4G modem to be online from default.
or the opposite, always check the settings upon (re)boot, and reapply if they're gone.
or just always apply them 
@frollic The issue is that it reboots and factory defaults itself so need some way to at least the force the 4G up from factory, I'm not sure if its possible to change the defaults.
HI.
As @paqs mentioned early, this GLi sounds a peace of cr...
Its not acceptable a device crash and reset over heavy load, the less you should expect is a crash but after rebooting keeps customized state ( with all configs defined by user ).
Remember my old asus wl500gP, dd-wrt in my case, on heavy load ( to many connections and low memory, used to crash and reboot, but maintained all my configs.
And about modify defaults factory config, only using a custom firmware, not the standard one from Gli.
@nomadeh Yep these Glinet devices are absolute crap, all I can do for now is use putty on the remote windows machine to run a remote script over SSH via the LAN port to force the 4G modem and cloud back up, this should at least get it back online if it happens again. They really are a half baked mess, I don't know why they bothered to have this cloud system if the default is to disable it.
@paqs and @nomadeh, I fI understand well you are talking of bugs on other system than OpenWrt System ?
In case of GLInet problem, you may preffer try to contact their support...
Nor dd-wrt, nor glinet firmwares are supported here at OpenWrt forum !
1 Like
I bought them from outside USA... without any problem !
Avoid the Huawei E5576-320. I'm having problems with it. Works fine with Ubuntu, but runs into a modeswitch loop on OpenWRT 21.02. It's a shame because the thingie works both with USB and WLAN. Haven't tried RC4 yet, I have to admit.
See my ticket usb-modeswitch: support for Huawei E5576-320 CDC #15893.
If it works with Ubuntu then it is possible to make it work in OpenWrt. What is the device ID it is swtched to in Ubuntu? Which driver does it use? What is the unswitched device ID?
According to what Lars writes in that usb_modeswitch discussion, the correct switching message for this modem is the "HuaweiNew" message. This is supported directly by usbmode and should also be the default for the 12d1:1f01 unswitched device:
"12d1:1f01": {
"*": {
"t_vendor": 4817,
"t_product": [ 5339, 5340 ],
"mode": "HuaweiNew",
"msg": [ ]
}
},
(5339 decimal is 0x14db)
I initially started with the ticket I linked in my reply. Later, I also started a forum thread that also failed to gain me any help: USB modprobe problems in 21.02.0-rc3.
Please read the ticket. It should answer all your questions. For speed, here is a compact form of the answers that are detailed in the ticket.:
It has three IDs:
12d1:1c20 is the E5576-320 powered down (not really...). 12d1:14db is the CDC mode. 12d1:1f01 AFAIK is mass storage mode.
After a fresh boot, there are these USB drivers:
usb_common 2672 2 ehci_platform,usbcore
usb_storage 42016 0
usbcore 140096 9 huawei_cdc_ncm,cdc_ncm,usbnet,usb_storage,cdc_wdm,ledtrig_usbport,ehci_platform,ehci_fsl,ehci_hcd
usbnet 17424 2 huawei_cdc_ncm,cdc_ncm
The same after I attached the device and waited for it to settle. Then, I used the device switch to start it into network mode. After a short time, it starts to alternate between 12d1:14db and 12d1:1f01. The drivers are unchanged.
I captured the output from lsusb -v in both modes:
Mass Storage
Bus 001 Device 063: ID 12d1:1f01 HUAWEI_MOBILE HUAWEI_MOBILE
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1
idProduct 0x1f01
bcdDevice 1.02
iManufacturer 1 HUAWEI_MOBILE
iProduct 2 HUAWEI_MOBILE
iSerial 3 0123456789ABCDEF
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8
bInterfaceSubClass 6
bInterfaceProtocol 80
iInterface 4 Mass Storage
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
can't get device qualifier: No such device
can't get debug descriptor: No such device
cannot read device status, No such device (19)
As you can see, lsusb is too slow to finish before the next switch, which also gets a new device address.
CDC ECM
Bus 001 Device 070: ID 12d1:14db HUAWEI_MOBILE HUAWEI_MOBILE
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1
idProduct 0x14db
bcdDevice 1.02
iManufacturer 1 HUAWEI_MOBILE
iProduct 2 HUAWEI_MOBILE
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0058
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 2mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2
bFunctionSubClass 6
bFunctionProtocol 0
iFunction 8 CDC ECM
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2
bInterfaceSubClass 6
bInterfaceProtocol 0
iInterface 5 CDC Ethernet Control Model (ECM)
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Ethernet:
iMacAddress 7 628C97AEDA83
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 5
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 6 CDC Ethernet Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 2
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
HTH
Ok. I think it's important to be aware that identify switching is entirely firmware controlled. The switch from 1f01 (storage mode) is wanted and necessary. We request it by sending that magic USB storage command from usbmode, and the modem firmware complies. This works as expected.
Switching back to storage mode is unexpected and unwanted. We don't request that. And AFAIK there is no way to do so either, except disconnecting the device. I can see two possibilities:
- the device is actually disconnected. Maybe it crashed or lost power?
- the firmware decided to switch mode on its own for some unknown reason. Maybe it expects some specific action from the host within a certain time period?
I believe 1 is the most likely explanation. We have seen 2, but I believe that was a ZTE modem and it has been a while since I heard of it. Besides, that problem should affect Ubuntu as well. And this is also true for any host independent firmware crash. If it was the problem, then Ubuntu would have suffered as well.
So I am going to put all my money (both coins) on the power theory. Maybe your OpenWrt host just can't provide enough umphh for this modem? I assume Ubuntu is running on another host system? Most LTE modems are quite power hungry, and will pull a lot higher current peaks than the USB spec allows. Possible solutions are powered USB hubs or split cables.
Sigh. The only thing I found in my "collection" of USB hardware was a USB2 hub with a barrel connector for power. I actually found a USB A cable with the same size barrel on the other end, so I could connect the hub to an additional power source Alas, this did not even change the problem.
BUT! I have a USB power tester with a nice graphical display, all in a small package with a USB A plug, a USB A receptable und two USB C connectors. It even displays graphs for current and voltage. The E5576-320 draws 480 mA when it oscillates. The voltage is constant, as is the current. In storage mode, it draws a little less current, about 467 mA.
So your theory #1 is not supported by what I see. I believe it's time for me to buy a more modern hub, at least for USB 3.0, better for a higher standard. I'll have a look.
Until then, I have the suspicion that "somebody" should look at the tools that are used by the OpenWRT modprobe mechanism. I had already built a VM with an OpenWRT build environment when RC4 came out and had'nt yet found the time to find out how I can patch those tools to log what they are doing. That still needs some work.
Maybe they already can and I haven't found the right knob yet?
Again: There is nothing you can do to change the identity of a USB device, unless the firmware implements some trigger. This is done to switch modems from storage mode to modem mode(s), but that's a one-way thing. There is no way to switch back. Nothing any application does can change that.
The switch back to storage mode from modem mode must be firmware initiated.
I obviously cannot check your current measurements, but constant current in modem mode is unlikely. A modem will have very spiky power requirements. The current in storage mode is surprisingly high on the other hand. Makes you wonder how they can burn all that just to run the USB controller, with no USB data transmission and no radio. I wonder if that instrument can possibly show correct values? Maybe it's averaging the current over a long period?
Many moons ago, I used to have a tp703n which has gpio usb controlled. I also have a usb control mains power strip and the main router is connected to this. I have the tp703n connected via main router lan. The tp703n pings the internet and do a gpio reset if internet cannot be reached. Maybe you can do something similar and also scp the config back on at the same time.
I doubt it is averaging over more than two seconds. When I switch to the bar graph, it is build anew and the "worms" creep over the display without major wiggling.
The device has also a WLAN access point, and I think that is what is burning most of the power. The current is suspiciously close to 500mA, so it believe it is possible that the Netgear WNDR4300 or the hub is limiting the current. I plain forgot that I bought a spare Netgear R6220. Checking ... Nope, it's also only got a USB 2.0 port.
The Huawei device page specs the power requirements at < 3.5W, so we may indeed have a power problem.
I propose we put this on hold until I have a USB 3.1 hub (I found out it 3.0 hubs aren't much cheaper, so I'll got for the fastest you can get. As usual, hub's for 3.2 are slow to appear.)
And we switch to the thread I had started for this (USB modprobe problems in 21.02.0-rc3). I'll ping you when I have a new test.
Update:
I'm doing that just now, if anybody is interested.
As suggested by others you can use an Android Phone tethered via USB as a WAN with wireguard on the AP.
Alternatively, you could run Wireguard on the Android phone with USB tethering to the router as the WAN.
I use this as a backup WAN on a TPLink Archer C7 V5
I've found a tethered Android phone to provide a really stable LTE connection.
That way you don't have to deal with connectivity issues I've personally seen with modems/modem drivers on Linux.
My configs.
Network
config interface 'wan'
option device 'eth0.2'
option proto 'dhcp'
option metric '100'
config interface 'lte'
option device 'usb0'
option proto 'dhcp'
option metric '99'
Firewall
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
list network 'lte'
...
Required Packages
- kmod-usb-net-rndis
1 Like