No 3g connection on boot anymore

Hello

I maintain a router, a Buffalo WZR-HP-G300NH on behalf of relatives who can only attach the 3g modem onto it an power it on. Everything was fine with previous versions of OpenWrt and LEDE, but now it won't come up at boot. There is no way I can teach them to log into the thing and push buttons or type commands.

The modem is a Huawei E353s-2, shows up in lsusb as 12d1:1506.

There are a few ways to solve this, but I wish that anyone who can, would tell me what he knows.

Either I can install the last version of OpenWrt that did not have the problem. And then either remain in it or see what is done there differently. This is a regression anyway, but seemingly nobody has figured out what happened and why it happened. But it's a few major versions back in any case.

Or I can try some trick like service network reload in rc.local, but initially that did not work. If done manually, the modem connects and everything works. Detaching and then plugging in the modem doesn't do the trick.

Or I can link some modules from /etc/modules.d/to /etc/modules-boot.d/, as someone has done elsewhere (it was @stendahl here). But there is no list of the necessary modules. I already added a few, to no avail.

Manually adding option 'auto' '1' to the relevant section in /etc/config/network did not change anything.

I am using the common 3g stuff. Nothing fancy like NCM or the others.

Addition 1:

Installed LEDE 17.01.7 on a spare router. Once all the necessary packages were there and the APN name was correct, everything seems perfect. Except that my spare router is unable to power the modem and there are frequent disconnects because of that. Now trying to notice what are the glaring differences in order to make OpenWrt 19.07.3 do the same minus the disconnects.

Also noticed that if it connects, receives addresses but no traffic flows and disconnects because of missing echo packets, then that is caused by a wrong APN. Connecting but not receiving any addresses is caused by a missing wwan package.

Addition 2:

There is no explanation in the contents of /etc/modules-boot.d/ to this issue. A possible solution through it is not excluded, but there's practically no difference there between 17.01.7 and 19.07.3.

Addition 3:

Setting option force_link '1' does not solve it. The Interfaces tab still shows Error: Network device is not present.

Addition 4:

Adding option delay '45' to the relevant section in /etc/config/network did not help.

Addition 5:

Adding a file to /etc/modules-boot.d/ called 50-my-modemstuff that contains, in order, usbserial, usb_wwan and option did not change anything.

During boot, there's an instant when usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0 happens. This goes for ttyUSB1 and ttyUSB2 also. Ten seconds after that comes daemon.notice netifd: Interface 'modem3g' is setting up now. Two or three seconds after that comes daemon.notice netifd: Interface 'modem3g' is now down.

Something is required during those three seconds that is not there when it should be. And that something is not modeset, which seemingly happens eight seconds before the ttyUSB*devices are found. And that something is not the setting up of the USB serial devices either.

For some reason, the option to wait for the modem is not effective here. Three seconds is undoubtedly less than 45 seconds. So somehow I think the problem is in the network service that fails to respect something somewhere.

Addition 6:

In comparison, in the TL-WDR4300 running LEDE 17.01.7, the setting up of the interface happens only a second after the serial devices are present in ttyUSB*. Six seconds after that comes daemon.notice netifd: modem3g (1226): Trying to set PIN. It succeeds after a second or so.

It seems that long delays are not even really necessary. According to timestamps, the TP-Link running LEDE 17.01.7 sets up the serial devices seven seconds earlier in the boot process than the Buffalo running recent OpenWrt. Then the network service starts setting the interface up immediately. Setting PIN happens, I think, using an AT command via the serial device. So for some reason, the network service in the buffalo fails to communicate to the modem at all at that point. Yeah, checked it immediately. The gcom scripts, referring to /etc/gcom/setpin.gcom are identical between these setups.

Is it Stick or Hilink?

Hi, my 3g trouble happened only booting after a power shut down and it doesn't after the ash command reboot sent by ssh.
Is it your case?
If yes, it's the same trouble.
I just created a symlink in /etc/modules-boot.d/ pointing to the correct module in etc/modules.d/ that in my case was the 'option' module.
I just added a simple script monitoring, after boot, the correct creation of the device /dev/ttyUSB0 and the successful connection, otherwise reboot.
The real problem is why there is that difference between dry reboot and software reboot.
I hope it would help you

I now have the LEDE 17.01.7 in the Buffalo and everything works perfectly every time. All I needed to do after a bare install was to add a few packages and set up a basic configuration in luci.

I'd need to install 19.07.3 to the extra router to try that out and I'm not sure when I have the time to do that. At first I added only the option module to /etc/modules-boot.d/ in the 19.07.3 but then later added the other two when nothing changed.

I just wish someone would get at the bottom of this, because restarting the network service or rebooting the whole router are forms of percussive maintenance.

Because it works eventually, even with 19.07.3, then it must simply be some timing issue somewhere. There are enough waits, timeouts and delays littered everywhere, in the network service and gcom and chat scripts that likely one of these gets skipped somehow for some reason based on some condition that was newly introduced in 18.06 or so.

Hello all!

Just found out this thread, after spending several hours trying to troubleshoot this exact issue.
I'm using an GLinet AR-150 with a Huawei E3372h (stick mode) in plain 3G mode.

Everything was running perfectly with 18.x series, upgraded this week to 19.07.4 and I'm getting a device not found on the associated interface.

I'm currently working around the issue by restarting the network service on rc.local:
sleep 30
/etc/init.d/network restart

After a further analysis I've noticed the following startup scripts on /etc/rc.d:
S20network
S20usbmode

I'm not sure if these scripts are run in alphabetical order, if they are... this may be the root cause, the usbmode switch is being run AFTER the network init...

Hi !

Same issue here with AR-150 and Huawei E160E, OpenWRT 19.07.4.

I had the same idea and renamed S20network so it's run after S20usbmode, but it did not fix the issue.

Looks like usbmode takes very long, about 30 secs to start. Don't know if it's different with older versions.

I ended up putting network restart in rc.local as well. That killed OpenVPN so I finally added openvpn stop / network restart / openvpn start.

I'm considering filing a bug report for this...