E3372 ussd, sim menu, etc

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?

1 Like

Wow! That's exactly what I was looking for. Thank you very much for mentioning it!

Will post an update about how the installation went

Ok, first update. Reflashed to stick, configured as here:

config interface 'wan'
         option ifname 'wwan0'
         option proto 'ncm'
         option device '/dev/cdc-wdm0'
         option mode 'auto'
         option apn 'the_text_name_of_your_mobile_network'
         option ipv6 'auto'
         option metric '100'

got the same misbehavior as in linked post

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:

config interface 'wan'
         option ifname 'wwan0'
         option proto 'ncm'
         #option device '/dev/cdc-wdm0'
         option device '/dev/ttyUSB0'
         option mode 'auto'
         option apn 'the_text_name_of_your_mobile_network'
         option ipv6 'auto'
         option metric '100'

and do the following to activate changes

/etc/init.d/network restart

#and possibly these if still not working
ip link set wwan0 down
ip link set wwan0 up
ifdown wan
ifup wan

I think in the linked post that's what the author did too, it just wasn't very explicit.

Anyhow, now on to the sms, ussd.

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:

#begin ussd menu
sms_tool -d /dev/ttyUSB1 ussd "*888#"
#choose option 4
sms_tool -d /dev/ttyUSB1 ussd "4"
#then choose option 2
sms_tool -d /dev/ttyUSB1 ussd "2"

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.

1 Like

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.


You NEED to leave the "PCUI" port or you will "brick" the modem

Please, send me raw output.

1 Like

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...

#sms_tool -d /dev/cdc-wdm0  ussd "*888#"
unparsable CUSD response: +CUSD: 2

failed tcsetattr(/dev/cdc-wdm0): Not a tty

# sms_tool -d /dev/ttyUSB0 ussd "*888#"
failed tcsetattr(/dev/ttyUSB0): Not a tty

# sms_tool -d /dev/ttyUSB1 ussd "*888#"
unparsable CUSD response: +CUSD: 2

See your modem manual. Ex. for quectel 2 means "USSD terminated by network" ( https://www.quectel.com/UploadImage/Downlad/Quectel_EC25&EC21_AT_Commands_Manual_V1.3.pdf page 187)

Sigh.. I seem to have changed mode to LTE-only using


Unfortunately, the E3372 does not have such a nice manual as the EC25/21. Do you know, by any chance, what is the default value of AT^SYSCFGEX?

I've tried this one


except that locks me into WCDMA, but the USSD codes work again :slight_smile:


030201 or 00.

don't know, i debugged using a linux machine (modem manager gui) and found out was using ttyUSB0 for sms, in my case with AT^SETPORT="FF;10,12,16" usb0 is silent and usb1 has periodic messages.

mine is reporting:



//Mode is automatic, Acquisition order is WCDMA>GSM, band is any band, roaming is supported, Circuit switch and packet switch domains are supported

i also have option service 'preferlte' in /etc/config/network if it can help.

on other note AT+CMGF=1 text mode, AT+CMGF=0 pdu mode for SSDU, it's a lot easier make this work first on a linux machine then move to openwrt :wink:

@aceylacey sorry posted wrong output above, mine is reporting:



I ended up reflashing, and here is the default setting for an e3372h-607 (E3372h-607_Update_21.




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.

Interesting... Did you purposefully limit the frequency bands via the 800C5 part, or was it that way from the beginning?

Here is a hint at the syntax of SYSCFGEX as reported by my modem:

^SYSCFGEX:("00","01","02","03","99"),((2000000400380,"GSM900/GSM1800/WCDMA BCVIII/WCDMA BCI"),(280000,"GSM850/GSM1900"),(3fffffff,"All bands")),(0-2),(0-4),((80080000c5,"LTE BC1/LTE BC3/LTE BC7/LTE BC8/LTE BC28/LTE BC40"),(7fffffffffffffff,"All bands"))

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: as for usb vs ncm i guess you need to test with your setup to see differences, AFAIK ncm should perform better.

It's possible avoid the banner that shows every time I enter in Send message?

Hi @TonyB_IT
Of course I added an option to disable this message.

Configuration >> SMS Settings >> Uncheck the option

1 Like

Thanks for this app!