Huawei E-173u -2 mit Alditalk unter ArchLinux

  • Habe basierend auf folgender Anleitung versucht ein Huawei E173u-2 Surfstick unter ArchLinux auf dem RaspberryPi zum laufen zu bringen und hatte diverse Probleme, Zugriff aufs Internet zu bekommen. Habs dann mit einigen Modifikationen aber letztendlich geschafft:

    LieberScholli
    12. November 2013 um 00:40

    Da die Lösung nicht gerade naheliegend ist, soll der folgende Beitrag dazu helfen anderen die aufwändige Fehlersuche zu ersparen.

    Zur installation diverser Software ist zunächst einmal Zugang zum Internet über die Ethernet Schnittstelle vonnöten.

    Weil ArchLinux mit der Paketverwaltung pacman arbeitet, ist die Anleitung im obengenannten Link etwas abzuwandeln.

    Folgende Pakete sind zu installieren (habe Archlinux ohne graphische Benutzeroberfläche laufen - die Installation erfolgte also von der Konsole):

    als root (es werden jeweils automatisch die abhängigen Pakete mitinstalliert):
    pacman -S libusb
    pacman -S libpcap
    pacman -S libusb-compat
    pacman -S ppp
    pacman -S gcc

    Wie folgt das Modem Initialisierungsscript herunterladen, entpacken und installieren:
    cd /usr/local/bin (in diesem Verzeichnis liegen normalerweise lokale Programme und Scripts)
    wget http://raspberry-at-home.com/files/sakis3g.tar.gz (Sakis 3g aus dem Internet ziehen)
    tar -xvzf sakis3g.tar.gz (dekomprimieren und entpacken )
    rm sakis3g.tar.gz (das nicht mehr benötigte Archiv löschen)
    chmod 744 sakis3g (Zugriffsrechte festlegen)
    nano /etc/sakis3g.conf (die Konfigurationsdatei für sakis3g erzeugen - vi als editor geht natürlich auch)

    Folgendes im editor eintragen:
    SIM_PIN="XXXX" <- hier steht in Wirklicheit die gültige PIN
    APN="internet.eplus.de" (wurde die Tagesflat von Alditalk gebucht, sollte hier tagesflat.eplus.de stehen, sonst saugt eplus relativ schnell den Restbetrag der Prepaid Karte leer)
    APN_USER="eplus"
    APN_PASS="gprs"
    PPPD_OPTIONS="10.0.0.1:10.0.0.2 modem crtscts -detach defaultroute dump noipdefault usepeerdns usehostname ktune logfd 2 noauth lock maxfail 3 ipcp-accept-local ipcp-accept-remote noaccomp nobsdcomp noccp nopcomp novj novjccomp debug"
    (geändert 24.05.2014 laranja - Es hatte sich ein Doppelpunkt im Block oben zwischen modem und crtscts eingeschlichen - sorry ! )

    Nun sakis3g neu kompilieren:

    sakis3g recompile (dauert ein wenig)

    mit dem Internet verbinden:
    sakis3g connect

    Internetverbindung trennen
    sakis3g disconnect

    Weitere Optionen mit sakis3g --help

    Hintergrund - oder auf welche Schwierigkeiten ich bei der Ausarbeitung stiess.

    Nacdem ich die im obengenannten Forumsbeitrag aufgezählten Pakete installiert hatte, musste ich zusätzlich noch gcc (gnu c++ compiler) installieren, weil Archlinux in der Standardversion keinen c++ Compiler mitbringt. Zunächst verband sich nach der Installation der Stick relativ schnell mit eplus und die blaue LED am Stick leuchtete permanent. Allerdings konnte ich keine Rechner im Internet ansprechen - weder ping noch tcp protokolle funktionierten. Nach der Installation von Traceroute stellte ich allerdings verwundert fest, dass offensichtlich Zugriff auf DNS bestand, weil traceroute die IP des Zielhosts anzeigte. Der Aufruf von "route" zeigte 10.64.64.64 als defaultroute. Dieser host ließ sich aber nicht anpingen. Ein von traceroute als erster hop angegebener Host sendete aber ping pakete zurück. Nach langer Fehlersuche verdichtete sich das Problem auf ppp, welches nach erfolgreicher Verbindung mit dem Provider, die IP Verbindung mit dem Zielhost aushandelt. Es wurde zwar die Rechneradresse des PI vom Zielhost übertragen, aber die Aushandlung des Remote Peer blieb offen (Meldung "Could not determine remote IP address: defaulting to 10.64.64.64") Normalerweise sollte das keine Rolle spielen, aber ich konnte das ganze erst zum laufen bekommen, als ich eine beliebige Wunschadresse als Zielhost vorgab (nur eben nicht 0.0.0.0 wie beider Anfrage gesendet):

    Kein Erfolg hiermit:
    ############ Auszug aus dem Logfile, das ich mit "sakis3g reconnect --debug 2>/tmp/log_sakis" erzeugte #############
    CHAP authentication succeeded
    sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
    rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    rcvd [IPCP ConfReq id=0x0]
    sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
    rcvd [IPCP ConfRej id=0x3 <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    sent [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14>]
    rcvd [IPCP ConfReq id=0x1]
    sent [IPCP ConfAck id=0x1]
    rcvd [IPCP ConfNak id=0x4 <addr 10.128.134.237> <ms-dns1 212.23.115.148> <ms-dns2 212.23.115.132>]
    sent [IPCP ConfReq id=0x5 <addr 10.128.134.237> <ms-dns1 212.23.115.148> <ms-dns2 212.23.115.132>]
    rcvd [IPCP ConfAck id=0x5 <addr 10.128.134.237> <ms-dns1 212.23.115.148> <ms-dns2 212.23.115.132>]
    Could not determine remote IP address: defaulting to 10.64.64.64
    not replacing existing default route via 192.168.0.1
    Cannot determine ethernet address for proxy ARP
    local IP address 10.128.134.237
    remote IP address 10.64.64.64

    Der Schlüssel zum Erfolg war die Vorgabe irgendeiner IP (ziemlich egal welche) als Wunschzieladresse -siehe den rot markierten Bereich:
    ############ Auszug aus dem Logfile, das ich mit "sakis3g reconnect --debug 2>/tmp/log_sakis" erzeugte #############

    CHAP authentication succeeded
    sent [IPCP ConfReq id=0x1 <addr 10.0.0.1> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
    rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    sent [IPCP ConfReq id=0x2 <addr 10.0.0.1> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    sent [IPCP ConfReq id=0x3 <addr 10.0.0.1> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    rcvd [IPCP ConfReq id=0xe]
    sent [IPCP ConfNak id=0xe <addr 10.0.0.2>]
    rcvd [IPCP ConfRej id=0x3 <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
    sent [IPCP ConfReq id=0x4 <addr 10.0.0.1> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14>]
    rcvd [IPCP ConfReq id=0xf]
    sent [IPCP ConfAck id=0xf]
    rcvd [IPCP ConfNak id=0x4 <addr 10.129.199.182> <ms-dns1 212.23.115.150> <ms-dns2 212.23.115.84>]
    sent [IPCP ConfReq id=0x5 <addr 10.129.199.182> <ms-dns1 212.23.115.150> <ms-dns2 212.23.115.84>]
    rcvd [IPCP ConfAck id=0x5 <addr 10.129.199.182> <ms-dns1 212.23.115.150> <ms-dns2 212.23.115.84>]
    Cannot determine ethernet address for proxy ARP
    local IP address 10.129.199.182
    remote IP address 10.0.0.2

    Vielleicht hat ja einer der mehr Ahnung hat als ich eine Erklärung, warum sich das so verhält ?

    Einmal editiert, zuletzt von laranja (24. Mai 2014 um 14:26)

  • Hallo Laranja,

    Deine Beschreibung kann sicherlich einigen helfen!:thumbs1:

    Der grosse Netzwerkspezialist bin ich zwar auch nicht, aber ich vermute mal, daß 10.0.0.2 eine Gateway-IP der für Dich (virtuell) eingerichteten Schnittstelle "draussen" bei Deinem Provider ist und "10.129.x.x" die vom Provider Deinem E173 zugeteilte IP - zwischen diesen beiden IP's läuft die Internetverbindung. Diese Remote-IP mußt Du vorgeben, da sie zu Deinem Netzwerk passen muß (denke ich mal).

    Ich arbeite mit LTE (hier DSL-Wüste) mit einem "Huawei E3276" (baugleich mit Vodafone K5150). Sehr wahrscheinlich würde das ebenso Deiner Beschreibung entsprechend funktionieren.

    Ich wollt's genau wissen und habe mir die Einwahl mehr oder weniger mühevoll zusammengestrickt - leider sind insbesondere die Huawei-Spezial-AT-Kommandos sehr schlecht dokumentiert und kaum was zu finden. :huh:

    Grob skizziert klappt's mit folgendem Ablauf:

    - USB LTE Stick: erzeugt /dev/ttyUSB0, /dev/ttyUSB1
    - Kernelmodule "option" und "usb-wwan" -> erzeugen ein "wwan0" interface
    - Einwahl mit "chat" Skript: 2 Kommandos genügen: PIN-Nummer und Einwahl

    Die Verbindung steht, jetzt wird gebraucht:
    - dhcpcd oder dhclient: über "wwan0" eine IP vom Provider holen, von Zeit zu Zeit leasetime verlängern
    - iptables: IP masquerading einrichten, damit alle im lokalen Netzwerk rauskommen
    - dnsmasq: als vorgeschalteter DNS und als DHCP Server für's lokale Netz

    Abschliessend starte ich noch ein Terminalprogramm (wie beispielsweise minicom), das die Status- und Feldstärkemeldungen des Modems über ttyUSBx abholt, andernfalls würde das Modem nach einigen Minuten auflegen (vermutlich läuft dann dort der Speicher voll).

    Das läuft hier zwar nicht auf dem RPi, würde dort aber sicher genauso funktionieren. Und Archlinux-spezifisch ist das alles sicher auch nicht.

    Gruß, mmi

  • Hallo MMI.

    zunächst mal danke für die Antwort. Mit den AT Kommandos musste ich mich gar nicht herumschlagen, das hat sakis3g von alleine ohne weiteres zutun bereits vollautomatisch erledigt. Die Einwahl und die g3 Verbindung funktionierte auf Anhieb tadellos. Mein Problem trat bei PPP auf, als mein Raspi die IP des Zielrouters erfahren sollte.

    Bei der Angabe der (Wunsch-) Zieladresse ist es eigentlich ziemlich egal was für eine IP vorgeschlagen wird. Habe das auch mal mit meiner Class C Webserveradresse im Internet versucht. PPP der Gegenseite nimmt das brav als Zieladresse an. Damit kann ich dann sogar meinen Webserver (und alle anderen) ansprechen. Offensichtich spielt es überhaupt keine Rolle was da angegeben wird. Der eplus Host reagiert auf alles, allerdings nur mit Anmeldung. Und die funktioniert bei eplus offensichtlich nur wenn eine Adresse vorgeschlagen wird, die nicht 0.0.0.0 ist. Vermutlich sendet der lokale PPP Prozess eine (falsche) 0.0.0.0 um von der Gegenseite die korrekte Adresse zurückzuerhalten. Eplus nimmt 0.0.0.0 aber vermutlich klaglos als IP an. PPPlokal meckert dann - keine Adresse erhalten, und nimmt default 10.64.64.64, worauf hin dann wiederum die Kommunikation wegen der fehlenden Anmeldung scheitert - jedenfalls könnte ich mir das so oder ähnlich vorstellen.

  • Hallo laranja,

    Hauptsache es funktioniert!

    Ich bin eher ein Verfechter des "KISS"-Prinzips, wie es auch Motto bei Archlinux ist. So schön der schnelle Erfolg - in diesem Fall mit "sakis3g" - auch ist, aber sobald sich eine Kleinigkeit ändert, ist man auf ein Update des Entwicklers angewiesen (der dann hoffentlich noch am Ball bleibt). Ich verstehe natürlich, daß nicht jeder Lust, Zeit und eine gewisse Erfahrung hat, sich stundenlang mit den untersten Ebenen zu beschäftigen.

    Bei den neueren Huawei Modems müsste es interessante Kommandos geben - z.B. sofortiger Start im Modemmodus, kein modeswitch mehr erforderlich). Oder ausschließlich im LTE800-Modus arbeiten - das würde ich noch benötigen, da ich mit externer Richtantenne für 800 MHz arbeite, da funktionieren die anderen Bänder nicht. Es dokumentiert offiziell keiner was - das ist ja auch verständlich - der "normale" Anwender verwendet "plug-and-play" seines Telefonproviders unter Windows. :(

    Gruß, mmi

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!