Sierra Wireless EM7345 on Debian Linux

 Hardware, Kernel and drivers, Linux, Network  Comments Off on Sierra Wireless EM7345 on Debian Linux
May 132018
 

Hardware: Lenovo ThinkPad W550s with Sierra Wireless EM7345

Software: Debian 10 (buster/testing)

Operator: Sonera (Finland)

After Debian installation the modem is recognized, but somehow a working connection just can’t be created:

# mmcli -L

Found 1 modems:
 /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless Inc.] Sierra Wireless EM7345 4G LTE

# mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id '<snip>')
-------------------------
Hardware | manufacturer: 'Sierra Wireless Inc.'
| model: 'Sierra Wireless EM7345 4G LTE'
| revision: 'V1.1,11'
| H/W revision: 'unknown'
| supported: 'gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '<snip>'
-------------------------
System | device: '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4'
| drivers: 'cdc_acm, cdc_ncm'
| plugin: 'Generic'
| primary port: 'ttyACM0'
| ports: 'enx000011121314 (net), ttyACM0 (at), ttyACM2 (at)'
-------------------------
Numbers | own : 'unknown'
-------------------------
Status | lock: 'none'
| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)'
| state: 'registered'
| power state: 'on'
| access tech: 'lte'
| signal quality: '35' (recent)
-------------------------
Modes | supported: 'allowed: 2g, 3g, 4g; preferred: none'
| current: 'allowed: 2g, 3g, 4g; preferred: none'
-------------------------
Bands | supported: 'unknown'
| current: 'unknown'
-------------------------
IP | supported: 'ipv4, ipv6, ipv4v6'
-------------------------
3GPP | imei: '<snip>'
| enabled locks: 'none'
| operator id: '24491'
| operator name: 'FI SONERA'
| subscription: 'unknown'
| registration: 'home'
| EPS UE mode: 'csps-2'
-------------------------
SIM | path: '/org/freedesktop/ModemManager1/SIM/0'

-------------------------
Bearers | paths: '/org/freedesktop/ModemManager1/Bearer/0'

# nmcli connection add type gsm ifname "" con-name 4G apn internet connection.autoconnect no
Connection '4G' (ef2b6f2d-e072-44cf-a9f8-831b79b179f2) successfully added.

# nmcli connection up 4G
Error: Connection activation failed: Unknown error

daemon.log revealed that modem got stuck on “Connect: ppp0 <–> /dev/ttyACM0” and a bit later on “Couldn’t initialize PDP context with our APN: ‘Serial command timed out'”

Problem seems to be that NCM -mode isn’t actually supported by EM7345 – even though advertised by the firmware (and H/W revision says unknown). Small confirmation for this theory is that Lenovo provides drivers for older Windows versions where MBIM isn’t natively supported.

Let’s override defaults for cdc_ncm and prefer MBIM -mode.

# cat /sys/module/cdc_ncm/parameters/prefer_mbim
N
# echo "options cdc_ncm prefer_mbim=Y" > /etc/modprobe.d/cdc_ncm.conf
# modprobe -r cdc_mbim cdc_ncm
# modprobe cdc_mbim
# cat /sys/module/cdc_ncm/parameters/prefer_mbim
Y
# systemctl restart ModemManager
# mmcli -L

Found 1 modems:
 /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless Inc.] MBIM [1199:A001]

# mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id '<snip>')
-------------------------
Hardware | manufacturer: 'Sierra Wireless Inc.'
| model: 'MBIM [1199:A001]'
| revision: 'FIH7160_V1.2_WW_01.1616.01'
| H/W revision: 'XMM7160_V1.2_MBIM_GNSS_NAND_RE'
| supported: 'gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '<snip>'
-------------------------
System | device: '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-4'
| drivers: 'cdc_acm, cdc_mbim'
| plugin: 'Sierra'
| primary port: 'cdc-wdm0'
| ports: 'wwp0s20u4 (net), cdc-wdm0 (mbim), ttyACM0 (at), ttyACM2 (at)'
-------------------------
Numbers | own : 'unknown'
-------------------------
Status | lock: 'none'
| unlock retries: 'sim-pin2 (3)'
| state: 'registered'
| power state: 'on'
| access tech: 'lte'
| signal quality: '35' (recent)
-------------------------
Modes | supported: 'allowed: 2g, 3g, 4g; preferred: none'
| current: 'allowed: 2g, 3g, 4g; preferred: none'
-------------------------
Bands | supported: 'unknown'
| current: 'unknown'
-------------------------
IP | supported: 'ipv4, ipv6, ipv4v6'
-------------------------
3GPP | imei: '<snip>'
| enabled locks: 'fixed-dialing'
| operator id: '24491'
| operator name: 'FI SONERA'
| subscription: 'unknown'
| registration: 'home'
| EPS UE mode: 'csps-2'
-------------------------
SIM | path: '/org/freedesktop/ModemManager1/SIM/0'

-------------------------
Bearers | paths: 'none'

# nmcli connection up 4G
Error: Timeout expired (90 seconds)

…but still not quite there.
This time daemon.log says that the modem was stuck in 3GPP Registration state loop, idle -> registering -> home -> idle.

Reason for this behavior is Sonera, which (still) doesn’t support IPv6, and somehow fails the handshake if IP type ipv4v6 is offered first. Debug was done by running simple-connect manually:

# systemctl restart ModemManager
# mmcli -m 0 --simple-connect="apn=internet,ip-type=ipv4"
successfully connected the modem
# mmcli -m 0 --simple-disconnect
successfully disconnected all bearers in the modem
# systemctl restart ModemManager
# mmcli -m 0 --simple-connect="apn=internet,ip-type=ipv4v6"
error: couldn't connect the modem: 'Timeout was reached'
# systemctl restart ModemManager
# mmcli -m 0 --simple-connect="apn=internet,ip-type=ipv4"
successfully connected the modem
# mmcli -m 0 --simple-disconnect
successfully disconnected all bearers in the modem

So, how to translate this to network-manager actually handling the connection? Luckily just ignoring IPv6 altogether changes ip-type -setting, so (with nmcli) this is quite easily fixable:

# nmcli connection modify 4G ipv6.method ignore
# nmcli connection up 4G
Connection successfully activated (D-Bus active path: /<snip>)

…and finally, a working connection.

Getting more speed out of OpenWRT-enabled TL-WR1043NDv2

 Hardware, Kernel and drivers, Linux, Network  Comments Off on Getting more speed out of OpenWRT-enabled TL-WR1043NDv2
Mar 202018
 

Basic setup and debug

1Gbps/100Mbps -cable connection, router, couple of cat6 cables, laptop & speedtest.net (note: speedtest.net might not give reliable results on high-speed links).

 

Default speeds (without a router).
Cable modem is setup as a dumb bridge, it’ll just be a media converter between ethernet and the DOCSIS 3.1 -world. First tests were run with laptop hooked up to it with cat6 -cable, public IP-address resided on the laptop and “Hey, this works”. Plugged it into existing infrastructure (WDR4300) and carried on with my normal life.

Then came the next weekend and I had a bit too much time in hand to benchmark – and I found out that the wireless router runs out CPU if I download something big and the speed was capped at about 240Mbps…

What if I’ll change a router?
WDR4300 has an AR9344 CPU running at 560MHz – my reserve WR1043NDv2 has QCA9558 CPU running at 720MHz – a whopping 160MHz (~28.5%) more! I took a look at OpenWRT OpenSSL benchmarks and they confirmed my theory, CPU should be about a quarter faster, but would it translate into real world performance?

This is a bit like comparing apples and oranges, because the CPUs are different, firewall rules are close but not identical, and the latter one doesn’t handle wireless at the same time, but the speed difference is still noticeable.

What if I’ll simplify firewall rules?
Replaced all the default LEDE -firewall rules with just one NAT-rule, just allowed everything, and … about +10% more bandwidth.
How do I get more speed out of a CPU? Overclock!
Had a crazy idea, is it possible to overclock a router? And found out it actually is possible, just backup mtd0 (u-boot) -partition, replace default MHz -values with hex-editor to something else and burn the image back to router. Or use pre-made images or some chinese guys closed-source bootloader.

720MHz to 1GHz (+38%) and +32% more bandwidth with default firewall, nice!

Now let’s try it with a bare minimum firewall…
Same as before, just one NAT-rule.

+11% – and the speed is almost doubled from the start (WDR4300 and ~240Mbps).

What is this “NAT Boost / Hardware NAT” -feature in stock TP-Link firmware?
Back to default CPU speeds, stock firmware has some kind of shortcut for packets going through a NAT. Let’s see if we have..yes, OpenWRT is bringing SFE (Shortcut Forwarding Engine) -support to their later release.

Luckily there were some images ready for testing.

Shortcut forwarding engine, with just a NAT-rule.
Let’s combine that with a minimal firewall setup, just a single NAT-rule.
Shortcut forwarding engine, overclocked.
And what happens if we push the CPU from 720MHz to 1GHz. (With default LEDE-firewall.)
Full speed!
Let’s drop the firewall (use just a single NAT-rule), what’s the maximum attainable speed?

…not bad, just about 3.5 times faster than the original, and just a bit short of “full wirespeed”. But I think I’ll stick with a firewalled version and take that ~80Mbps hit.

Jun 222015
 

If you get hit with “RTNETLINK answers: Cannot allocate memory” when trying to add IPv6 default gateway back after losing all IPv6 -connectivity, raise net.ipv6.route.max_size.

The defaults (on my machines) were quite small compared to IPv4:

CentOS 7.0:
# sysctl net.ipv4.route.max_size
net.ipv4.route.max_size = 2147483647
# sysctl net.ipv6.route.max_size
net.ipv6.route.max_size = 4096

CentOS 7.1:
# sysctl net.ipv4.route.max_size
net.ipv4.route.max_size = 2147483647
# sysctl net.ipv6.route.max_size
net.ipv6.route.max_size = 16384

Debian 7.8/8.1:
# sysctl net.ipv4.route.max_size
net.ipv4.route.max_size = 2147483647
# sysctl net.ipv6.route.max_size
net.ipv6.route.max_size = 4096

Jun 022015
 

Finnish ISP DNA revealed their IPv6 -support for cable networks, but just listed “these devices are compatible” without more technical details.

How to get running (I used OpenWRT and EPC3825 was just a bridge):
* use DHCPv6-client
* request an /56 -prefix
* router will get an /128 -address and I found my /56 -network at the routes (with ip -6 route)
* drop a slice from it (/64) with radvd to your lan side
* remember to configure an IPv6 -firewall
* enjoy

Oct 142014
 

Usually one of the first things we want to do with a new server is to restrict access to SSH -service.

So far it seems that everyone advices “disable firewallD, install iptables service and use it like you’ve always used” but how about trying to get along with this new tech?

Restricting access to SSH isn’t as hard as it might seem at the first glance. First we check what services are allowed in public (usually the default) and internal -zones:

# firewall-cmd --zone=internal --list-services
dhcpv6-client ipp-client mdns samba-client ssh
# firewall-cmd --zone=public --list-services
dhcpv6-client ssh

Then we add our admin-IP to internal -zone:

# firewall-cmd --permanent --zone=internal --add-source=<admin-ip>

Remove access to SSH-service from public:

# firewall-cmd --permanent --zone=public --remove-service=ssh

And reload the changes into use:

# firewall-cmd --reload

–permanent makes changes which stay over reboot/reload, but they aren’t active immediately – without –permanent the changes are active immediately but are lost on reload/reboot

Service definitions can be found (in RHEL/CentOS 7) at /etc/firewalld/services/ – if you create a new one -> use –reload to make it active.

Jan 182012
 

One way to get IPv6 /64 bridged to your LAN:


brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ebtables -t broute -A BROUTING -p ! ipv6 -j DROP
ifconfig br0 up

 

Opened up: create software bridge from your WAN -interface to LAN -interface, but allow only IPv6 to fly over it. In my setup IPv4 is natted.