I am using a huawei e3372h with OpenWrt 19.07.6. I am in hilink mode and it is working. I am able to use the WebUI to do things like send/receive sms, activate ussd menu, use the sim card menu. However, the double nat is eating away at me.
If the modem were in 'stick' mode, how would the above operations take place? Say you need to check how much money or quota you still have left, or purchase more data, or anything else that is done via the ussd menu. Custom AT commands? Custom scripts that run custom AT commands?
On the PC, with a stick modem, there is the so-called Dashboard, which makes a graphical interface that is similar to the hilink one. It functions via the serial port. Is there any such thing on a headless OpenWrt box?
daemon.notice netifd: wan (6693): Timeout running AT-command
daemon.notice netifd: wan (6693): Failed to set operating mode
daemon.notice netifd: wan (7490): Stopping network wan
daemon.notice netifd: wan (7490): sending ->
daemon.notice netifd: Interface 'wan' is now down
daemon.notice netifd: Interface 'wan' is setting up now
daemon.notice netifd: wan (7499): Configuring modem
daemon.notice netifd: wan (7499): WARNING: Variable 'modes' does not exist or is not an array/object
daemon.notice netifd: wan (7499): Setting mode
daemon.notice netifd: wan (7499): sending ->
Solution was to change the device to /dev/ttyUSB0 like this:
Installation of sms-tool and luci-app-sms-tool went smoothly. Got the sms-tool from here and the luci-app-sms-tool from here.
The sms-tool (binary is named sms_tool) can be called from the command line to send and receive sms (as the name implies) and also can do USSD codes. To achieve my purpose of navigating USSD menus, the command line usage went something like this:
You just run these commands one after another, and it appears that the remote end maintains some sort of a state about where you are in the menu.
The same thing can be done from Luci, but... the responses to the USSD sometimes showed up, sometimes not. The reply gets received, but somehow it just does not get displayed. As a result you lose track of where you are in the menu. Not sure why this happens, console version works flawlessly in this regard.
Another bug that I had observed had to do with SMS messages. Some received messages could not be decoded. They just appear blank. You can, nevertheless, see the contents by using the -r (show raw binary) switch. Then you can grab the hex string and decode the message manually by using one of many online decoders to confirm that the message is actually there.
Anyhow, that's my initial feedback. All in all, I am quite happy with the result.
Big Thanks to @IceG and everyone who made OpenWrt possible. The significance of this project for digital freedom is larger than one realizes.
AFAIK ttyUSB0 is 4g modem, this does not perform well as ncm for data connection bandwidth/latency wise. also ttyUSB1 in my case show some debug messages, like sim registration etc., that mess up sms messages.
i use AT^SETPORT="FF;10,12,16" since i care only for 4g and sms, and i use ttyUSB0 for sms because it has no debug messages going on.
^SETPORT:3: 3G DIAG
^SETPORT:10: 4G MODEM
^SETPORT:1: 3G MODEM
^SETPORT:12: 4G PCUI
^SETPORT:13: 4G DIAG
^SETPORT:5: 3G GPS
^SETPORT:14: 4G GPS
^SETPORT:A: BLUE TOOTH
You NEED to leave the "PCUI" port or you will "brick" the modem
I set my modem likewise to yours AT^SETPORT="FF;10,12,16", previous setting was ^SETPORT:A1,A2;12,1,16,A1,A2. The /dev/ interfaces did not change - cdc-wdm0, ttyUSB0 and ttyUSB1. Is there a correlation between the selected ports and the devices? For example, does 10 become ttyUSB0 and 12 becomes ttyUSB1?
I tried setting each of the above as the device in the configuration file. Only ttyUSB0 resulted in the modem picking up an IP.
Then, I tried sending some AT command over each with socat. Of the three, cdc-wmd0 did not respond to input at all, ttyUSB0 responded, and ttyUSB1 responded. The latter, however, gives errors if the uplink is already established.
# socat - /dev/ttyUSB1,crnl
On ttyUSB0 there are periodic messages about signal strength and protocol used. These did not change between the previous port selection and the new one, despite the previous one using 3G modem instead of 4G.
Ha! It seems I forgot to do AT^RESET after changing the ports. No wonder there was no change between before and after above. Having properly reset it, I can now report that using /dev/cdc-wdm0 picks up an IP address as expected. Receiving sms works on either /dev/cdc-wdm0 or /dev/ttyUSB1, but not /dev/ttyUSB0. But running ussd codes no longer works on any of the interfaces...
I ended up reflashing, and here is the default setting for an e3372h-607 (E3372h-607_Update_21.200.07.00.00):
This appears to be the "auto" mode. The connection stays in LTE normally, if USSD code is run, it is downgraded to WCDMA temporarily and then reverts back to LTE on its own after some time. This is true in both the default (3G modem), and the minimized (4G modem) port settings. I have not measured the speeds of LTE connections going through /dev/cdc-wdm0 vs /dev/ttyUSB*, however.
guess i have 800C5 instead of 7FFFFFFFFFFFFFFF due to option service 'preferlte' in /etc/config/network, i get rock solid performance on a capped 30/15mbps contract with ncm and no issues with sms/ussd on usb0 with minimized port settings, this on a e3372s-153 Revision: 21.297.05.00.00. as for usb vs ncm i guess you need to test with your setup to see differences, AFAIK ncm should perform better.