0€

CarTFT.com: Professional CarPCs and Displays

«   Wechseln zu: MiniPC.de – Small, flexible, powerful

Change Language:

English
Shop for mobile PC- and GPS-solutions

LTE/4G/5G Modems unter Linux im QMI-Modus


Einführung

Wir haben in einem Projekt einige 5G M.2 Modemkarten genommen und getestet inwieweit sie sich unter Linux verwenden lassen. Als Hauptrouter verwenden wir einen unter Xenserver/XCP-NG virtualisierten pfSense der an eine Glasfaser-Verbindung angeschlossen ist. Was fehlte war eine Backup-Leitung in Form einer 4G-/5G-Verbindung. Leider ist die Kompabilität jenseits von langsamen PPP-Verbindungen unter pfSense (FreeBSD-basiert) grauenhaft bzw. kaum vorhanden. Daher muss für die 4G-/5G-/LTE-Verbindung auf einen Linux-Router ausgewichen werden. Dieser kann dann als „Zubringer“ für pfSense agieren bzw. gleichzeitig auch als eigenständiger Router für ein Subnetz oder andere Netzbereiche. Hier haben wir „OpenWRT“ als Router-Software ausgesucht denn dies benötigt kaum Ressourcen (nichteinmal 1GB RAM und 1GB HDD), bietet sehr gute Unterstüzung für Modemkarten und umfangreiche Einstell- und Erweiterungsmöglichkeiten.

Bzgl. der Hardware ist es in einer virtualisierten Umgebung natürlich ersteinmal schwierig M.2 Modems in die virtuelle Maschine zu bekommen. Hierzu verwenden wir eine PCIe USB3-Schnittstellenkarte und reichen diese per PCI Passthrough an die OpenWRT-VM weiter. An die USB-Karte schließen wir unsere USB3-M.2-Adapterbox an. Der Vorteil ist daß das Modem dann außerhalb des Servers/Systems liegt, hier auch die SIM-Karte eingelegt wird und die 4G/5G-Antennen angeschlossen werden. In unserem Fall haben wir auch eine 15m USB3 Aktiv-Verlängerung verwendet um die USB3-Modembox in die Nähe der 4G/5G-Dachantenne zu bekommen da es oft natürlich schwierig sein kann einen Server in örtlicher Nähe zu einer Antenne zu bringen. Mit 15m USB-Kabel (vermutlich sind auch größere Längen möglich, bzw. dann auch in optischer AOC-Kabelausführung) und 5-10m Antennenkabel hat man dann genügend Spielraum um die Modembox passend zu platzieren.


Verwendete Hardware

In unseren Tests haben wir folgende Modemkarten verwendet :
Eingebaut in der USB3-M.2-Adapterbox.

Alle diese Modems bieten unter Linux eine QMI-Schnittstelle. Unsere Anleitung kann prinzipiell natürlich auch in einer unvirtualiserten Bare-Metal Umgebung nachgestellt werden, also direkt auf einem OpenWRT-System bzw. auf beliebigen Linux-Systemen.

Standortbedingt ist an unserem Teststandort bislang leider nur 4G möglich, so daß 5G nicht getestet werden konnte. Die erreichten 4G-Geschwindigkeiten sind aber bereits schon sehr ordentlich. Als Antenne verwenden wir eine „Wittenberg LAT 60 Duo“. Der darauf ausgerichtete Antennenmast der Telekom ist 3,2km Luftlinie entfernt.


Installation OpenWRT (unter Xenserver/XCP-NG)

OpenWRT steht nicht als ISO zur Verfügung sondern nur als System-Image. Dh. für die Installation wird ein Zwischenschritt benötigt.
Wir legen zunächst eine neue virtuelle Maschine an mit diesen Einstellungen :

VM template : Other install media
Install from ISO : Hier verwenden wir ein beliebiges Linux-System mit Rescue-Modus. Z.b. Debian oder Ubuntu.
Boot Mode : BIOS Boot
vCPUs : 1 (ggf. auch 2, aber es ist keine Mehrleistung zu erwarten)
Memory : 1GB (ggf. auch nur 512 MB)
Virtual disk : 1GB (ggf. auch nur 512MB)
Network : z.b. 1x LAN und 1x internes Interface als quasi WAN-port für pfSense
Das System booten wir dann in den Rescue-Modus einer Linux-BootCD.



Nun laden wir das neueste OpenWRT-Image herunter, packen es aus und kopieren es auf die virtuelle Festplatte :

wget https://downloads.openwrt.org/releases/23.05.5/targets/x86/64/openwrt-23.05.5-x86-64-generic-ext4-combined-efi.img.gz
gunzip openwrt-*.img.gz
dd if=openwrt-23.05.5-x86-64-generic-ext4-combined.img bs=1M of=/dev/xvda (dauert ca. 1 Sekunde)
Das System jetzt in einen Partitionshelfer wie z.b. gparted oder pmagic booten um den verfügbaren HDD-Platz auch nutzen zu können. (Achtung, Bootreihenfolge anpassen so daß DVD vor HDD gebootet wird). Bei gparted erscheint die Meldung „The backup GPT table is corrupt, but the primary appears OK, so that will be used“. Dies kann mit „Ok“ bestätigt werden. Die Meldung „Not all of the space available to /dev/xvda appears to be used, you can fix the GPT to use all of the space (an extra xxxx blocks) or continue with the current setting?“ mit „Fix“ bestätigen.
Dann die letzte Partition /dev/xvda2 auf den maximal verfügbaren Speicherplatz vergrößern und Speichern/Bestätigen.


System herunterfahren.
Jetzt weisen wir den PCI USB3 Controller der virtuellen Maschine exklusiv zu.
Auf der xenserver/xcp-ng Console (z.b. per SSH) finden wir zunächst die PCI Gerätenummer des Controllers heraus.
Das funktioniert i.d.R. am schnellsten mit diesem Befehl :

# lspci |grep USB
00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 05)
03:00.0 USB controller: Fresco Logic FL1100 USB 3.0 Host Controller (rev 10)
42:00.0 USB controller: Fresco Logic FL1100 USB 3.0 Host Controller (rev 10)

In unserem Fall ist die USB-Controllerkarte die 42:00.0
Diese nehmen wir bei Xenserver/XCP-NG nun zunächst aus dem System heraus.

# /opt/xensource/libexec/xen-cmdline --set-dom0 "xen-pciback.hide=(0000:42:00.0) "
Dann ist Neustart des Systems nötig.
Dann weisen wir die PCI-Karte exklusiv der OpenWRT-VM zu.

# xe vm-param-set other-config:pci=0/0000:42:00.0 uuid=[UUID-der-OpenWRT-VM]

Jetzt schließen wir den USB3 M.2 Modemadapter an die USB-PCI-Controllerkarte an und booten OpenWRT.

In OpenWRT werden per SSH zunächst ein paar Pakete installiert die für den Modembetrieb nötig sind :

# opkg update
# opkg install kmod-usb-net-qmi-wwan uqmi luci-proto-qmi kmod-usb-serial-option picocom

Das Modem sollte nun im System sichtbar sein :

# ls -l /dev/cdc* (->/dev/cdc-wdm0)

Das Simcom-Modem sieht so aus (# dmesg):

[ 4561.625960] usb 2-1.2.2.2: new high-speed USB device number 12 using xhci_hcd
[ 4561.846720] option 2-1.2.2.2:1.0: GSM modem (1-port) converter detected
[ 4561.862118] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB0
[ 4561.876032] option 2-1.2.2.2:1.1: GSM modem (1-port) converter detected
[ 4561.892369] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB1
[ 4561.909181] option 2-1.2.2.2:1.2: GSM modem (1-port) converter detected
[ 4561.922440] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB2
[ 4561.938091] option 2-1.2.2.2:1.3: GSM modem (1-port) converter detected
[ 4561.958481] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB3
[ 4561.980857] option 2-1.2.2.2:1.4: GSM modem (1-port) converter detected
[ 4562.005352] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB4
[ 4562.022201] qmi_wwan 2-1.2.2.2:1.5: cdc-wdm0: USB WDM device
[ 4562.038126] qmi_wwan 2-1.2.2.2:1.5 wwan0: register 'qmi_wwan' at usb-0000:00:06.0-1.2.2.2, WWAN/QMI device, 82:d6:60:94:70:6e

Quectel :

[   11.810573] qmi_wwan 2-1.2.2.2:1.4: cdc-wdm0: USB WDM device
[ 11.823345] qmi_wwan 2-1.2.2.2:1.4 wwan0: register 'qmi_wwan' at usb-0000:00:06.0-1.2.2.2, WWAN/QMI device, c2:ff:5d:91:66:c3
[ 11.849161] usbcore: registered new interface driver qmi_wwan
[ 11.867334] usbcore: registered new interface driver cdc_mbim
[ 11.880668] usbcore: registered new interface driver option
[ 11.893929] usbserial: USB Serial support registered for GSM modem (1-port)
[ 11.913040] option 2-1.2.2.2:1.0: GSM modem (1-port) converter detected
[ 11.931437] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB0
[ 11.960033] option 2-1.2.2.2:1.1: GSM modem (1-port) converter detected
[ 11.989900] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB1
[ 12.007687] option 2-1.2.2.2:1.2: GSM modem (1-port) converter detected
[ 12.023923] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB2
[ 12.040403] option 2-1.2.2.2:1.3: GSM modem (1-port) converter detected
[ 12.058821] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB3

MeiG :

[ 2554.558037] usb 2-1.2.2.2: new high-speed USB device number 12 using xhci_hcd
[ 2555.586917] usb 2-1.2.2.2: USB disconnect, device number 12
[ 2726.117623] usb 2-1.2.2.2: new high-speed USB device number 13 using xhci_hcd
[ 2727.314051] usb 2-1.2.2.2: USB disconnect, device number 13
[ 2932.597482] usb 2-1.2.2.2: new high-speed USB device number 14 using xhci_hcd
[ 2932.821444] option 2-1.2.2.2:1.0: GSM modem (1-port) converter detected
[ 2932.840390] usb 2-1.2.2.2: GSM modem (1-port) converter now attached to ttyUSB0
[ 2932.863235] qmi_wwan 2-1.2.2.2:1.5: cdc-wdm0: USB WDM device
[ 2932.879384] qmi_wwan 2-1.2.2.2:1.5 wwan0: register 'qmi_wwan' at usb-0000:00:06.0-1.2.2.2, WWAN/QMI device, 06:dd:e6:da:53:0a

In der OpenWRT-Weboberfläche fügen wir nun die Modemverbindung hinzu (in unserem Beispiel mit Telekom-Daten) :
Network > Add new interface > Name : 5GMODEM, Protocol : QMI Cellular, APN: internet.telekom, Auth : PAP (telekom/tm), PDP : Ipv4

Beachten Sie daß Sie die PIN-Abfrage der SIM-Karte vor Inbetriebnahme ausschalten sollten.
Dazu bauen Sie die SIM-Karte temporär in ein beliebiges Handy ein und schalten PIN aus.

OpenWRT sollte die Verbindung nun bereits automatisch herstellen können. Das hatte bei uns mit dem Simcom und MeiG Modem
auf Anhieb funktioniert. Nur bei Quectel war noch etwas Nacharbeit nötig :

# picocom /dev/ttyUSB2 (vorher picocom installieren mit opkg install picocom)
AT+QCFG="usbnet" (Ausgabe sollte 0 sein für QMI, ansonsten setzen mit : AT+QCFG="usbnet",0)
AT+CGDCONT? (Ausgabe sollte „at+cgdcont=1,“IP“,“internet.telekom““ ergeben, sonst setzen mit :
„+CGDCONT: 1,"IP","internet.telekom","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0,,,,,,,,,"",,,,0“)
Dann sieht die Ausgabe so aus :

+CGDCONT: 1,"IP","internet.telekom","0.0.0.0",0,0,0,0,,,,,,,,,"",,,,0
Reset : AT+cfun=1,1
Dann OpenWRT „5GMODEM“-Interface „Restart“-Button
Und nach kurzer Zeit erscheint dann ein Virtual dynamic interface (DHCP client) mit IP-Adresse oder die IP-Adresse direkt im Modem-Interface.



Damit die Modem-Verbindung auch geroutet werden kann (NAT) weisen wir dem Interfaces „5G Modem“ die Firewall-Zone „wan“ zu und den Interfaces „lan“ und ggf. „wan“ (als Verbindung zu anderen Routern) der Zone „lan“. Ggf. sind noch DHCP-Server zu aktivieren auf dem „lan“-Interface (je nach örtlichen Gegebenheiten) und am besten auch auf „wan“ damit OpenWRT und pfSense direkt automatisch die Adressen aushandeln.

Unter Network > Firewall sind die Firewall-Einstellungen die für unsere Zwecke recht einfach gehalten sind. Bei 4G/5G-Verbindungen gibt es i.d.R. keine eingehenden Verbindungen bzw. Port-Forwarding.


Wenn Sie nun die IP-Adresse von OpenWRT als Gateway verwenden in Ihrem LAN dann greifen Sie bereits über das Modem auf das Internet zu.
Wir konnten dabei mit 4G in unserem Setup folgende Geschwindigkeiten erreichen :


Simcom : Ping 18ms, 271,79 Mbit Download, 61,21 Mbit Upload
Quectel : Ping 19ms, 277,72 Mbit Download, 60,91 Mbit Upload
MeiG : Ping 21ms, 178,23 Mbit Download, 68,89 Mbit Upload


pfSense Einstellungen

In pfSense legt man zunächst ein weiteres WAN-Interface an. Wenn in OpenWRT auf dem Interface ein DHCP-Server eingerichtet ist dann muss auf pfSense-Seite lediglich DHCP-Client eingestellt werden.
Unter System > Routing > Gateway Groups legen wir dann eine Gruppe an. Damit das Modem übernimmt beim Ausfall der Hauptleitung stellen wir als Trigger Lebel „Packet Loss“ ein, das Hauptgateway mit „Tier 1“ und das Modem-WAN mit „Tier 2“.


Unter System > Routing > Gatways stellen wir das „Default gateway Ipv4“ nun auf diese Gateway-Gruppe ein.
Achtung : Zur Gateway-Überwachung sollte man auf dem neuen WAN-Port als Monitor IP wie z.b. „1.1.1.1“ verwenden.
Google-IPs sind eher nicht zu empfehlen da diese ggf. den (Ping-)Zugang einschränken.


Mit diesen Einstellungen wird beim Ausfall der Hauptleitung auf das Modem-Gateway umgeschalten.
Dies nützt freilich nur etwas für ausgehende Verbindungen. Denn Port-Forwarding und statische IP ist bei 4G/5G-Verbindungen traditionell schwierig oder aufpreispflichtig.

Eine nette Nebenfunktion dieses Setups ist nun auch daß in pfSense per statischen DHCP-Mapping nun fallbezogen auch direkt der Modem-Zugang als Gateway an bestimmte Clients ausgegeben werden kann.

Sicherlich ist das Setup in der hier gezeigten Form (OpenWRT vor pfSense) natürlich ein Doppel-NAT-Szenario. Dies lässt sich im Einsatz mit Modemkarten allerdings nicht so leicht vermeiden. Hier müsste man dann M.2-zu-Ethernet Adapter verwenden die aber im Moment noch als experimentell angesehen werden müssen. Auch ist es so daß man bei entsprechend performanter Router-Hardware auch keinen wirklichen Unterschied feststellen kann im Vergleich zu einer Single-NAT Umsetzung.

Bei Fragen/Anmerkungen/Kommentaren stehen wir gerne zur Verfügung.

Oliver Aigner (07.11.2024)