LTE Modem speeds twice slower on OpenWRT than Windows

Hardware:

  • Rock Pi 4B v1.4 RK3399 4GB RAM

  • Wallys DR7915 AX1800 (MT7915 DBDC) AP card

  • Sierra Wireless EM7345 (Intel XMM7160) 4G LTE modem

  • microUSB m.2 WWAN enclosure

  • 15dbi 2x2 MIMO external antenna

  • dumb 12V DC from 270W Flex PSU

Running OpenWRT 23.05.0-rc3 with the following additional packages:

kmod-usb-serial kmod-usb-net kmod-usb-serial-wwan kmod-usb-serial-option kmod-usb-net-qmi-wwan kmod-usb-net-cdc-mbim kmod-mt76 kmod-mt76-connac kmod-mt76-core kmod-mt7915-firmware kmod-mt7915e luci luci-ssl umbim nano terminfo luci-proto-mbim wpad-openssl

EM7345 is running latest firmware, has AT (&GNSS) ports enabled, set to 4G LTE only via AT command. It is managed by luci-proto-mbim, because I couldn't get it to work with ModemManager.

Tested many times, both via ethernet & wireless - the results are the same. About 6Mbps/6Mbps when the modem is connected to Rock 4B running OpenWRT, about twice that when connected to a Windows 10 laptop.

The only thing I noticed is that modem consumes more power from Windows laptop than SBC - didn't see it draw more than 0.4A connected to SBC, whereas from Windows laptop saw it drawing over a bit over 0.5A a few times. Can't be a power issue since the PSU currently in use can provide over 10A on 12V lane that powers SBC. Looks to me lower power draw is a consequence not a cause...

Windows laptop & desktop connecting to the device both have DefaultTTL set to 65 in OS, since they were originally tethered to a smartphone. Not sure how that translates given the current configuration, and if it could be the cause of slower speeds. It would be nice to create a firewall rule ensure TTL of 65 on WWAN interface, but guides I found all seem rather old, not sure if they're applicable to 23.05.0-rc3...

I have very little experience with OpenWRT, and no prior experience with WWAN on Linux. Please kindly help me figure this out!

See this post to create ttl 65 rule on nftables

chain mangle_postrouting_ttl65 {
  type filter hook postrouting priority 300; policy accept;
  oifname "eth1" counter ip ttl set 65
}

chain mangle_prerouting_ttl65 {
  type filter hook prerouting priority 300; policy accept;
  iifname "eth1" counter ip ttl set 65
}

Is important in rule that the interface much how the modem is detected, on my case is "eth1" but it could be eth2 3 or usb 0 1 2 3

1 Like

Thank you.

That post was one of the first one to come up for me, however, since it's for 22.03, I didn't risk applying right away.

My LTE modem's interface name is wwan1 (device name wwan0). I tried both:

1.) put this in /etc/config/firewall
config include
    option path '/etc/firewall.user'
    option fw4_compatible '1'

2.) create the file '/etc/firewall.user'

3.) put this line in it:
nft add rule inet fw4 mangle_forward oifname wwan1 ip ttl set 65

4.) restart the firewall
/etc/init.d/firewall restart

and

chain mangle_postrouting_ttl65 {
  type filter hook postrouting priority 300; policy accept;
  oifname "wwan1" counter ip ttl set 65
}

chain mangle_prerouting_ttl65 {
  type filter hook prerouting priority 300; policy accept;
  iifname "wwan1" counter ip ttl set 65
}

in /etc/nftables.d/12-mangle-ttl-65.nft

Tested both solutions with a smartphone - and each of them immediately tripped tethering detection of my carrier. Windows machines with TTL set to 65 on themselves don't to that.

Thus, I assume carrier doesn't throttle the modem connected to SBC running OpenWRT compared to the same modem connected to Windows laptop, and the problem lies elsewhere...

If the physical interface is detected as wwan0 the rule is

chain mangle_postrouting_ttl65 {
  type filter hook postrouting priority 300; policy accept;
  oifname "wwan0" counter ip ttl set 65
}

chain mangle_prerouting_ttl65 {
  type filter hook prerouting priority 300; policy accept;
  iifname "wwan0" counter ip ttl set 65
}

check the device name in cat /etc/config/network

1 Like

@antoncycle

Thank you.

I've applied the rules in question. They do work as intended, and are useful for connecting additional devices on which setting custom ttl is less trivial - however sadly didn't help with low speed.

Evidently, the issue lies elsewhere. My problem remains unsolved. LTE modem is still stuck at 6mbps when connected to OpenWRT host.

you can try to install microcom and run the following at command:

AT+QCAINFO

1 Like

Thank you.

EM7345 replies ERROR, probably doesn't supports this command.

I checked with another SIM card, and discovered that at the moment carrier definitely throttles the one I typically use. With another SIM card, speeds with modem connected to OpenWRT host are much higher at the moment.

That doesn't explain how I got much higher speeds just by switching the modem to laptop, with the very same SIM card, a week ago. I checked those results a couple of times by switching the modem between SBC & laptop back and forth, the behavior was consistent and repeatable...

Frankly, I'm baffled at this point. But also relieved that modem can operate at expected speeds under OpenWRT with my hardware.

Guess I'll have to wait for a new billing cycle when carrier de-throttles the usual SIM card and see what happens then...

1 Like

As carrier de-throttled the SIM card, I'm getting expected speeds on my OpenWRT host. The issue seems to have magically resolved itself.

I still have no idea why did switching the modem between OpenWRT host and Windows laptop resulted in drastically different performance, but can't reproduce the issue anymore.

1 Like

This is all that is needed... As it changes the TTL on the output packets to the ISP, if the LTE modem is directly connected to OpenWRT, the TTL might need to be 64 instead of 65, as there is 1 less hop since OpenWRT has direct access to the connection.

This has no effect on your speeds, as it changes the TTL on all your inbound connections and does nothing for tethering.

chain mangle_prerouting_ttl65 {
  type filter hook prerouting priority 300; policy accept;
  iifname "wwan0" counter ip ttl set 65
}
1 Like

Thank you.

I removed the unnecessary rule. The setup is performing as expected.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.