I chose this modem over the E3372-320 as it is listed to support two extra bands (B38 and B40), one of which is used by my ISP. It was listed as an operator branded “Huawei” by the seller, but after receiving it I can confirm it displays nothing associating it with Huawei. Although it looks identical with other Huawei E3372’s, on the casing (and in the WebUI) the only branding on it references Brovi which appears to be a (different?) Chinese manufacturer/supplier.
There’s also a specifications document which looks identical (minus the Huawei branding) to the 320 counterpart, and while Huawei officially references multiple E3372 variations using the same document format neither the 325 nor the 320 are listed. Also, although the firmware numbers look completely different from Huawei-branded counterparts the WebUIs on the 320 and the 325 appear identical.
It is still unclear to me whether it is an unbranded derivative coming from one of Huawei’s OEM suppliers (sanctions avoidance?) or a knock-off clone riding on Huawei’s model numbers (and firmware functionality?).
The modem uses a vendor/device id of 3356:2001 which is not supported by the usbmode package included in OpenWRT 22.03 (and also not a Huawei vendor id).
root@openwrt:~# lsusb Bus 001 Device 056: ID 3566:2001 Mobile Mobile
The device seems to have some compatibility quirks concerning Linux support as described here by Pavel Piatruk (that I can confirm) at least with firmware 3.0.2.61 (H057SP5C983) / WEBUI 3.0.2.61 (W13SP3C7201) also running on my device. An elusive 3.0.2.62 update which I’m not receiving is claimed to resolve these issues.
The linked article above offers a solution for regular Linuxes which unfortunately won’t work on OpenWRT as it’s not using either usb-modeswitch nor udev. For OpenWRT I eventually managed to get the modem working by using information available in the 4pda.to forum. The provided script does get the modem to switch in the correct mode and create a usable rndis network interface but it also resets the device every 10 seconds by not detecting (at least for my device) that it is already in the correct mode. To avert this, I botched in some interface status checking to stop the switching once an IP address is assigned to the interface.
To use it with OpenWRT, start with installing the necessary software packages:
opkg update && opkg install usb-modeswitch kmod-usb-net-rndis kmod-usb-net-cdc-ether
Then create the file /etc/hotplug.d/usb/10-brovi and paste the content below. Adjust the IP address with the range you have on your device (if different) – if this range conflicts with addresses you’re already using elsewhere, there’s a method here to make the modem switch to a different IP range.
EXPECTED_IP="192.168.8."
if ! ls /tmp/brovi.lock ; then
if [ "${PRODUCT}" = "3566/2001/ffff" ] ; then
logger -t Brovi Script started.
if [ "${ACTION}" = "add" ] ; then
#logger -t Brovi +++ Detected PRODUCT: ${PRODUCT} +++
logger -t Brovi +++ Detected INTERFACE: ${INTERFACE} +++
if [ "${INTERFACE}" = "224/1/3" ] ; then
logger -t Brovi Interfaces changed - modeswitching...
touch /tmp/brovi.lock
logger -t Brovi Step 1...
usbmode -s -c /etc/brovi.json
sleep 10
if ! /sbin/ip a show | /bin/grep -q ${EXPECTED_IP} ; then
logger -t Brovi Step 2...
usbmode -s -c /etc/brovi.json
else
logger -t Brovi Skipping step 2 as interface is already connected...
fi
rm /tmp/brovi.lock
fi
fi
fi
logger -t Brovi Script completed.
fi
exit 0
Continue with the file /etc/brovi.json and its content:
{
"messages" : [ ],
"devices" : {
"3566:2001": {
"*": {
"t_class": 224,
"mode": "Huawei",
"msg": [ ]
}
}
}
}
After (re)plugging the modem and some shuffling by modeswitch the required interface should show up intermittently (also check that the green led stays lit on the modem):
root@openwrt:~# logread [...] kern.info kernel: [1651662.416007] usb 1-1.1: new high-speed USB device number 8 using ehci-pci kern.info kernel: [1651662.575390] rndis_host 1-1.1:1.0 usb0: register 'rndis_host' at usb-0000:00:13.0-1.1, RNDIS device, 6a:9b:ff:12:33:86
You’ll notice the mention of a usb0 interface above – you can use this under OpenWRT Network Interfaces setup screen to create a new interface using the usb0 device and set it up with DHCP. You’ll need to do this quick as the script will keep switching the modem every 10 seconds if it can’t find a working network interface and eventually the device will default to a non-resettable CD-ROM state.
If all works, the interface will get an IP address assigned in the 192.168.8.0/24 range (with 192.168.8.1 being the modem’s WebUI).
If you weren’t fast enough setting up the interface after plugging in the modem, try removing and plugging it again to restart the whole process. Also pay attention when using USB extension cables – some will work, some won’t.
To rule out multiple issues when things don’t work, first ensure the modem is functional with Windows in a location you know it has signal and plugged directly into the USB port of the router. Also, different routers have different power capabilities on USB ports – the E3372-325 modem is rated for up to 3.5W (so about 700mA). Finally, keep an eye on the debug log with logread -f to see what is happening under the hood.
user.notice Brovi: Script started. user.notice Brovi: +++ Detected INTERFACE: +++ user.notice Brovi: Script completed. user.notice Brovi: Script started. [...] user.notice Brovi: Script completed. user.notice Brovi: Script started. user.notice Brovi: +++ Detected INTERFACE: 224/1/3 +++ user.notice Brovi: Interfaces changed - modeswitching... user.notice Brovi: Step 1... [...] user.notice Brovi: Step 2... user.notice Brovi: Script completed. kern.info kernel: [1752694.145428] rndis_host 1-1.1:1.0 usb0: unregister 'rndis_host' usb-0000:00:13.0-1.1, RNDIS device daemon.notice netifd: Network device 'usb0' link is down daemon.notice netifd: Interface 'wwan' has link connectivity loss [...] kern.info kernel: [1752694.951456] usb 1-1.1: new high-speed USB device number 60 using ehci-pci ser.notice Brovi: Script started. ser.notice Brovi: Script completed. kernel: [1752695.109760] rndis_host 1-1.1:1.0 usb0: register 'rndis_host' at usb-0000:00:13.0-1.1, RNDIS device, 6a:9b:ff:12:33:86 daemon.notice netifd: Interface 'lte' is enabled daemon.notice netifd: Network device 'usb0' link is up daemon.notice netifd: Interface 'lte' has link connectivity daemon.notice netifd: Interface 'lte' is setting up now daemon.notice netifd: lte (5086): udhcpc: started, v1.35.0 daemon.notice netifd: lte (5086): udhcpc: broadcasting discover daemon.notice netifd: lte (5086): udhcpc: broadcasting discover daemon.notice netifd: lte (5086): udhcpc: broadcasting select for 192.168.8.122, server 192.168.8.1 daemon.notice netifd: lte (5086): udhcpc: lease of 192.168.8.122 obtained from 192.168.8.1, lease time 86400 daemon.notice netifd: Interface 'lte' is now up [...] user.notice Brovi: Skipping step 2 as interface is already connected... user.notice Brovi: Script completed. user.notice Brovi: Script started. user.notice Brovi: Script completed. user.notice Brovi: Script started.
I haven’t yet tested if this workaround will do its job on a router reboot but I kind of expect it not to, due to power on timing and things. Will update this post with more info when I’ll get to rebooting…
Update #1
As expected, due to timing differences the script is unable to activate the modem on router boot. By the time OpenWrt finishes starting up the modem goes into permanent CD-ROM only mode and will require a power cycle to become usable. On some routers that have the ability to power cycle the USB port(s) through software that would be the next thing to test.
Thanks for your post! I’m wondering whether turning the router’s USB port off (https://openwrt.org/docs/guide-user/hardware/usb.overview ) after a reboot will help with this annoyance.
I will receive an openwrt router with this capability this weekend and I’ll do some digging and report back!
Hi thanks for the guide! Regarding the setup of the interface, is there any guide to delay it longer? Everything works as expected, one interface is detected, I try to set it up but then it says at udhcpc broadcasting discover forever…
If your device is running the 3.0.2.61 version firmware, its startup is sketchy at best.
From what others write, it initiates in a RNDIS+CDROM mode, but this RNDIS (network) interface is non functional – you can actually see it in the log in my post above as lacking a MAC address. After the mode change triggered by the script the device finally presents the correct RNDIS interface which is usable as a network connection. Check your logs if the network RNDIS your kernel sees has or lacks the MAC.
You can try adjusting the sleep 10 timing a bit (by decreasing it or increasing it) to try to better match your device’s behaviour. If you’re using an USB extension cable, try without it.
If your router has multiple USB ports, test with a different one – the modem is rather power hungry during startup.