Using old USB mobile sticks as backup - but high CPU usage - or just not working

i have 3 mobilnet stick - planned to use as backup

hAP AC lite (952Ui-5ac2nD) 650MHz CPU:
Huawei 3131a (Down: 7mbps Up: 1.4mbps) sub 20% cpu usage while speedtest.net
ZTE MF195 (Down: 7mbps Up: 1.4mbps) sub 20% cpu usage while speedtest.net
ZTE MF667 - no port found

RB 951Ui-2HnD 600MHz CPU:
Huawei 3131a (Down: 7mbps Up: 1.4mbps) sub 50-60% cpu usage while speedtest.net
ZTE MF195 (Down: 7mbps Up: 1.4mbps) sub 20% cpu usage while speedtest.net
ZTE MF667 - no port found

I have a 751U-2HnD at home. As i remember (but will edit the post either way) it IS working with MF667 stick!

Why newer device not work with that stick? Same routerOS… Do that stick need additional power feeding?
Why is the 50-60% CPU usage? 6.41 routerOS and firmware too.

Those are the sticks that present themselves as a serial port with HAYES modem where you have to
configure a PPP line over the serial port, isn’t it?
Those always require quite some CPU. But other than that, they work reliably.
Newer sticks present a LTE interface which incurs less CPU overhead. Some sticks can be switched
to this mode by installing different firmware on them. But that is usually a tricky procedure.
(involving getting access keys from some misty site, etc)
And it not all positive as this firmware has a NAT router inside the stick that you cannot disable, so
one more layer of NAT.

yes, all the mentioned sticks working with AT command set and PPP-client interface.
The question is: is it possible, that some sticks requires more CPU than others? :astonished:


You mean, some sticks (and cards) have IP stack inside, and the offer the LTE interface for using that.
It is faster (since no need of emulation of PPP device/AT modem) and nowdays also the have passthru, so
you can use your Mikrotik device as a “LTE-bridge”, so if you have another router behind this, that can act as a DHCP client for the net.

About the ZTE MF667 stick: i’m pretty sure it’s worked with the original SIM, but today i’ve unlocked it.
Now the red LED goes blue - as on notebook/windows, but port is not added at RouterOS :frowning:

The LTE interface uses some block transfer mode where it can transfer an entire IP packet over the USB without having
to frame it character-by-character with async PPP framing. That of course saves a lot of CPU overhead.
But unfortunately that stick firmware is operating as a NAT router with DHCP server, you have to put a DHCP client on the LTE
interface and it gets a 192.168.8.x address from the stick (always 192.168.8.100 for the client and 192.168.8.1 for the stick).
The passthrough mode is only inside the MikroTik, i.e. you can bridge that 192.168.8.x network to some ethernet port.
But of course what you really want is that the DHCP server on the stick returns the actual external IP address of the 3G/4G link
and that the MikroTik can send packets as if it is on a normal network, no NAT in the stick. But due to firmware limitation
in the stick this cannot be done. I have sometimes read forum posts about a 3rd mode where this would be possible, but never seen
any reference by the manufacturer or sellers of those sticks. So for now I consider it an urban legend or misunderstanding.

I don’t have much experience with the PPP mode, I have a couple of those old sticks and I have tried it once and it worked,
but in daily operation I only have those LTE sticks (E3372)

I agree, that LTE interface can be better than PPP-async, and understand why async uses more CPU.
What i cannot understand at the moment, how is possible, that stick-A consumes less CPU than stick-B, on the same
routerboard, same speed. (both sticks has 7.2mbps speed)

I only met with 3G sticks and 4G module what receives real (or provider NAT’ed) IPaddress, non of them did NAT itself.
https://wiki.mikrotik.com/wiki/Manual:Interface/LTE#Passthrough
This is a new feature, what passes ALL frames received by LTE interface to specific ethernet port (if multiple MACs on net, passes to first or specified).
It’s like station pseudo-bridge worked in 802.11