Huawei E3372s + Linux (Rasbian), Problem mit eingehenden Verbindungen


7

Ich habe ein Linux-basiertes Betriebssystem (Rasbian), das auf Raspberry Pi 2+ läuft, und es verwendet den 4G / LTE-USB-Stick des Huawei E3372 für die Internetverbindung.

Alle meine ausgehenden Verbindungen funktionieren einwandfrei (der Huawei USB-Modus wurde mithilfe von usb_modeswitch-rules und Udev / rules.d geändert), aber ich kann keine eingehende Verbindung zum Raspi empfangen. Eingehend funktioniert einfach nicht .

Ich kann keine Pakete oder Verbindungen empfangen , die ich in Echtzeit und aus Protokollen mit Tools von Raspbian-Paketdistributionen verfolgt habe.

Ich habe bereits mit meinem 4G-ISP bestätigt, dass der erweiterte Dienst, der bidirektionalen Verkehr ermöglicht, für mein 3G / 4G-Abonnement aktiviert, zurückgesetzt und so viel von ihrem Wissen ist, dass er von Anfang an einwandfrei funktioniert, aber ich kann keine Pakete mit empfangen der Raspi.

Das Huawei E3372s verwendet (im Gegensatz zu den meisten älteren Sticks, die wie Wählen wählen wvdial) das CDC_ETH- Treibersystem, das ein ethernetähnliches Gerät für das System erstellt (in diesem Fall ETH1) und in diesem Fall einwandfrei funktionieren sollte.

Ich habe alle erforderlichen Aufgaben mit IPTables gelöscht, neu erstellt, getestet, geändert, erneut gelöscht und erneut ausgeführt, Route mehrmals überprüft, geändert und getestet sowie bestätigt, dass keine Blockiersysteme bekannt sind, die die Verbindung über den Huawei USB-Stick verhindern Trotzdem kann ich nicht einmal Ping auf mein System empfangen, obwohl voll funktionsfähige Dienste ausgeführt werden.

Ich habe auch einfachere und unkompliziertere Bereiche wie das Zulassen / Verweigern von Regeln durch Hosts überprüft und hatte kein Glück damit. Es ist auch kein APN-Name, da alle Einstellungen mit der internen Konfiguration des Huawei über die Weboberfläche korrekt eingestellt wurden.

Ich habe jedoch gelegentlich in zufälligen Foren festgestellt, dass die Huawei CDC_ETH-Lösung möglicherweise Fehler bei der Verarbeitung eingehender Verbindungen mit ihrem Treiber aufweist.

Wenn einer von Ihnen Erfahrung mit eingehenden Verbindungsproblemen zwischen Debian / Rasbian / Linux mit Huawei E3372s oder einem relativen 3G / 4G-USB-Produkt hat, das CDC_ETH verwendet und eine Lösung für dieses Problem gefunden hat


Haben Sie 2 Verbindungstypen - ppp0stellt eine Verbindung zu Ihrem ISP her und eth1/wlan1sollte Sie mit Ihrem Netzwerk verbinden. Siehe Unterschied zwischen ppp0 und wwan0
eyoung100

Wie oben beschrieben, erstellt Huawei keine DFÜ- oder ppp-beschriebenen Geräte. Bei der Überprüfung von Geräten, z. B. mit ifconfig, erkennt das System das Gerät als normales ethernetbasiertes Gerät ETH1 (zusätzlich zur regulären nicht eingesteckten ethernetkabelbasierten Verbindung ETH0). Daher werden alle Verbindungen wie bei jeder LAN-basierten (Ethernet-ähnlichen) Verbindung behandelt, die im Normalfall problemlos einen bidirektionalen Zugriff ermöglichen würde. Zumindest soweit mein Wissen reicht.
Janne Honkonen

Zusätzlich zum vorherigen Kommentar gibt es, wie angegeben, keine zusätzlichen Geräte. Nur 3: Lo (für lokale), Eth0 (für nicht verwendetes Kabel-Ethernet) und Eth1 (Huawei gibt vor, ein Ethernet-Gerät zu sein)
Janne Honkonen

Sie müssen den PPPoE-Client für Ihre Distribution installieren. Das PPPoE steuert die Verbindung zu Ihrem ISP. Lesen Sie den Link in meinem 1. Kommentar.
eyoung100

1
Lösung für diejenigen mit demselben Problem, gelöst von der professionellen Task Force des ISP. Habe es nicht selbst getestet. PPPoE scheint in diesem Fall nicht zu funktionieren. Das Problem mit dem Huawei E3372s und seiner Hardware besteht darin, dass die virtuelle Hardware aufgrund des virtuellen HiLink / Ethernet-Modus keine regulären PPP-Verbindungen verhindert. Die einzige Lösung besteht darin, die Firmware von Huawei zu aktualisieren, um PPP-Verbindungen zuzulassen, die normalerweise nicht unterstützt werden. Ich hatte keine Zeit, dies selbst zu testen, da das Projekt einen begrenzten Zeitrahmen hat. Lösungen finden Sie hier: lteforum.at/mobilfunk/…
Janne Honkonen

Antworten:


5

Sie benötigen kein Firmware-Update, aber Sie benötigen einen Modusschalter, den Sie gefunden haben, und einen Dialer, den Sie nicht gefunden haben. Die folgenden Konfigurationsdateien aus NVDC Stuff Networking, Virtualization und Data Center Stuff funktionieren möglicherweise sofort . Wenn nicht, verwenden Sie jedes als Vorlage und optimieren Sie es, bis es funktioniert:

/etc/usb_modeswitch.conf

DefaultVendor=0x12d1
DefaultProduct=0x14fe

TargetVendor=  0x12d1
TargetProduct= 0x1506

MessageContent="55534243123456780000000000000011062000000100000000000000000000"

/etc/wvdial.conf

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0
Init3 = AT+CGDCONT=1,"IP","internet.t-mobile.cz"
Stupid Mode = 1
ISDN = 0
Modem Type = Analog Modem
New PPPD = yes
Phone = *99***#
Modem = /dev/gsmmodem
Username = { }
Password = { }
Baud = 9600

Verwendungszweck

  1. Erstellen Sie einen Link von /dev/gsmmodembis /dev/ttyUSB2, das ist das Modem.
  2. Wählen Sie die Außenwelt. Beachten Sie, dass Sie dies jedes Mal tun müssen:

    wvdial >/dev/null 2>&1 &
    
  3. Fügen Sie dem lokalen Startskriptbereich Ihres Systems Folgendes hinzu:

    MODEM_STORAGE="12d1:14fe"
    MODEM_MODEM="12d1:1506"
    
    # 0 = storage, 1= modem
    MODEM_MODE=0
    
    check_modem_mode () {
     echo -n "Checking modem presence... "
    
     lsusb | grep --quiet "$MODEM_STORAGE"
    
     if [ $? -eq 0 ]; then
      MODEM_MODE=0
      echo "OK: modem in mass storage mode"
     else
      lsusb | grep --quiet "$MODEM_MODEM"
      if [ $? -eq 0 ]; then
       MODEM_MODE=1
       echo "OK: modem in modem mode"
      else
       echo "ERROR: modem not found"
       exit 1
      fi
     fi
    }
    
    set_modem_mode () {
     while [ $MODEM_MODE -eq 0 ]
     do
      echo -n "Setting modem mode... "
      usb_modeswitch -s 15 -I -H -c /etc/usb_modeswitch.conf     >/dev/null 2>&1
      lsusb | grep --quiet "$MODEM_MODEM"
      if [ $? -eq 0 ]; then
       MODEM_MODE=1
       echo "OK"
      else
       echo "FAILED"
      fi
     done
    }
    

Erläuterung

Wie ich in einem früheren Beitrag erklärt habe , besteht ein GSM-Modem immer aus zwei oder mehr Teilen, im Fall dieses Modells aus drei Teilen.

  • Ein Speicherbereich, der einem USB-Stick ähnelt.
  • Ein Wireless-Ethernet-Adapter zum Anschließen mehrerer Geräte.
  • Ein PPP-Dialer, damit Ihr Mobilfunkanbieter weiß, dass Sie ein zahlender Kunde sind, und Ihnen bei Bedarf Überschreitungen in Rechnung stellen kann. Da Sie nachweisen können, dass Sie ein zahlender Kunde sind, weil PPPoE eine Authentifizierung erfordert, können Sie die ausgehandelte IP-Adresse verwenden, um auf das Internet zuzugreifen.

Die Aufzählungszeichen 1 und 2 werden über die etc/modeswitch.confKonfigurationsdatei gesteuert . 12d1ist sozusagen die Vendor MAC Address. Mit dem lokalen Skript wird der Rest der MAC-Adresse erstellt. 12:D1:14:FEendet als Speichergerät und 12:D1:15:06als Modem. Wenn Sie das lokale Skript nicht verwenden, geben Sie ausb_modeswitch -s 15 -I -H -c /etc/usb_modeswitch.conf

Hinweis: Standardmäßig, dh ohne Modusschalter, sieht Linux nur das Speichergerät, weshalb das OP den PPP-Dialer oder das drahtlose Gerät nicht sehen oder verwenden kann .


Sobald das Modem mit dem Modeswitch, wvdial oder einem seiner vielen Ersatzmodule eingeschaltet ist, wird der Zugriff auf die Außenwelt gesteuert . Wenn sich das Modem im Modemmodus befindet, sehen Sie endlich eine Ausgabe ähnlich der folgenden:

wwan0     Link encap:Ethernet  HWaddr 58:2c:80:13:93:13
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.83.249.176  P-t-P:10.64.64.64  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:4265 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6699 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:506706 (494.8 KiB)  TX bytes:600991 (586.9 KiB)

bei der Ausstellung ifconfig


1

Ich denke, das ist ein NAT-Problem. Auch wenn der ISP die Verbindungen nicht NAT-fähig macht, verwendet das Huawei NAT für die eth1Schnittstelle.

Das Huawei hat grundsätzlich zwei Modi:

  • Hi-Link , das NAT verwendet und eine Ethernet-Schnittstelle bietet.
  • Nicht-Hi-Link , bei dem PPP oder NDIS verwendet wird, um eine Verbindung zum Mobilfunkanbieter herzustellen.

Es gibt viele Tutorials zum Wechseln zwischen den beiden Modi durch Flashen einer anderen Firmware. Da Sie Ihr Modem während dieses Vorgangs möglicherweise blockieren, verzichte ich darauf, einen bestimmten Link zu veröffentlichen.


1

In meinem Fall habe ich festgestellt, dass dies das ist, was ich für die usb_modeswitch-Konfiguration benötige

cat /etc/usb_modeswitch.d/huawei_e3372.conf 
# modeswitch config file for the huawei e3372

DefaultVendor=0x12d1
DefaultProduct=0x1f01

TargetVendor=  0x12d1
TargetProduct= 0x14dc

MessageContent="55534243123456780000000000000011062000000100000000000000000000"

Mit diesem Befehl können Sie das Modem ausführen und zum Laufen bringen.

sudo usb_modeswitch -s 15 -I -H -c /etc/usb_modeswitch.d/huawei_e3372.conf

Dies ist nicht das e3372s-Gerät, sondern nur ein gerades e3372.
Nelaaro

0
sudo usb_modeswitch -v 12d1 -p 1f01 -V 12d1 -P 14DC -J 

-J, --huawei-new-mode apply a special procedure

Dies funktioniert bei mir, um zum Modemgerät zu wechseln

lsub
Bus 001 Device 028: ID 12d1:14dc Huawei Technologies Co., Ltd. E33372 LTE/UMTS/GSM HiLink Modem/Networkcard

Vom Massenspeichergerät

Bus 001 Device 027: ID 12d1:1f01 Huawei Technologies Co., Ltd. E353/E3131 (Mass storage mode)

Dies ist das System, an dem ich arbeite

uname -a                                                                                                                                                                          
Linux aaron-pc 4.9.63-1-MANJARO #1 SMP PREEMPT Sat Nov 18 14:12:41 UTC 2017 x86_64 GNU/Linu

0

Selbst wenn der LTE ISP oder das Huawei NATing betreiben, gibt es eine Problemumgehung mit ssh -R: Wenn Sie einen Server im Internet besitzen, können Sie Ihre Ports über ssh weiterleiten, z. B. für Tomcat:

ssh -R 4080:localhost:8080 my.cloud.server

und auf die pi wie zugreifen

http://my.cloud.server:4080

OpenVPN sollte auch funktionieren.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.