RPi3B+ mit Buster WiFi-AP Netzzugang via LTE-USB-Stick

  • Hallo community,

    ich bastel nun schon seit 3 Tagen an meinem RPi3B+ herum, komme aber nicht weiter.

    Ich möchte eine Internetverbindung, welche von einem Huawei E3372 USB-LTE-Stick hergestellt wird, über das interne WLAN des RPi teilen, sprich einen AP aufmachen.

    Das Raspbian läuft, ist aktuell. Der Stick hat eine SIM, ohne Pin-Abfrage, und stellt bei Netzempfang automatisch eine Verbindung her, das funktioniert bisher.

    Sobald ich aber eine der diversen Anleitungen aus dem Netz befolge, ist der Pi nicht mehr erreichbar. Weder per Wlan, noch über Ethernet. Irgendwo mache ich vermutlich etwas falsch.

    Gibt es eine Anleitung, an derer ich mich Orientieren kann ?

    Bisher habe ich die folgenden 2 Anleitungen getestet:

    Diese und auch diese

    Beide male kein Zugriff nach dem reboot mehr möglich.

    Das Wlan hat die wlan0, die Netzwerkverbindung die eth0, der Stick die eth1.

    Wer kann helfen ??

    Gruß

  • RPi3B+ mit Buster WiFi-AP Netzzugang via LTE-USB-Stick? Schau mal ob du hier fündig wirst!

  • Das Wlan hat die wlan0, die Netzwerkverbindung die eth0, der Stick die eth1

    Ich würde jetzt folgendermaßen vorgehen.

    1. Eine einwandfrei funktionierende Netzververbindung über den Patchkabelanschluß auf eth0 herrichten, die manuell via iproute2 und ohne solchen Mist wie networkmanager oder dem alten ifupdown hergestellt wird und dabei sicherstellen, dass dieser Port nach jedem Reboot immer eth0 benannt ist.... insbesondere auch dann, wenn der UMTS-Stick eingesteckt ist.

    2. Ebenfalls mit iproute2-Kommandos (+ iw, wpa-supplicant,dhclient) manuell eine einwandfrei funktionierende Netzwerkverbindung über wlan0 herstellen, um sicherzustellen, dass die Hardware grundsätzlich fehlerfrei funktioniert und man danach verstanden hat, wie die Network-Connectivity funktioniert

    3. Im Zusammenwirken mit dem funktionieren Patchkabelanschluss auf eth0 nun auf wlan0 einen Accesspoint mit hostapd einrichten

    4. Wenn 1, 2 und 3 erfolgreich waren, kann man nun auf Punkt 3 aufbauend versuchen, den Forward des Hostapd-Traffics auf den UMTS-Stick als Default-Gateway einzurichten, also nicht mehr zum vorherigen Default-Gateway des DSL-Routers.

    Eigentlich ist das alles nicht soooo kompliziert.... nur einfach irgendwelche Tutorials abzuschreiben, und nicht zu verstehen, was man da abschreibt und lapidar festzustellen "geht nicht" ist m.M.n. auf jeden Fall eine Garantie für dauerhafte Probleme und möglicherweise auch für bestehende ungelöste und damit signifikante Sicherheitsprobleme.

    jm2c

    Einmal editiert, zuletzt von WinterUnit16246 (24. Juli 2019 um 14:49)

  • Ich würde jetzt folgendermaßen vorgehen.

    1. Eine einwandfrei funktionierende Netzververbindung über den Patchkabelanschluß auf eth0 herrichten, die manuell via iproute2 und ohne solchen Mist wie networkmanager oder dem alten ifupdown hergestellt wird und dabei sicherstellen, dass dieser Port nach jedem Reboot immer eth0 benannt ist.... insbesondere auch dann, wenn der UMTS-Stick eingesteckt ist.

    Hallo ThomasL,

    die eth0 bleibt, egal ob der LTE-Stick gesteckt ist, oder nicht, immer der Netzwerkbuchse zugeordnet. Sobald der Stick hinzu kommt, wird diesem die eth1 zugewiesen. Abfrage erfolgte mit ifconfig -a

    Die Verbindung in mein Netzwerk via wlan0 ist ebenso funktionstüchtig.

    Wenn es heute Abend nicht zu Warm ist in meinem Arbeitszimmer, setze ich mich mal wieder ran.

    Danke für deine Hilfe !

  • roadghost

    Hier noch n tip

    Aber leider wird der iptables teil nicht mehr richtig funktionieren seit

    buster ist nftables standard siehe hier

    https://www.kuketz-blog.de/?s=nftables

    https://www.kuketz-blog.de/howto-wechsel-…es-zu-nftables/

    Wahrscheinlich ist das auch das problem

    und das auch noch

    https://wiki.debian.org/SystemdNetworkd

    https://www.linuxquestions.org/questions/debi…ion-4175624292/

    https://wiki.archlinux.org/index.php/Systemd-networkd

    *********************
    WLAN AP mit umts und hostapd und isc-dhcp-server

    (kannst auch was anderes nehmen)

    *********************

    voher natürlich /network/interfacesdatei sichern

    cp /etc/network/interfaces.wlan /etc/network/interfaces

    *********************
    Zuerst umts Verbindung starten wegen ppp0 (siehe iptables MASQUERADE )
    wvdial umts-pin
    wvdial umts
    ****************
    Falls Wlan nicht mit Tastenkomb einzuschalten ist

    rfkill unblock wlan
    ****************
    ifup wlan0
    echo 1 > /proc/sys/net/ipv4/ip_forward
    iptables -t nat -A POSTROUTING -s 10.10.0.0/16 -o ppp0 -j MASQUERADE
    netstat -an
    route
    iptables -t nat -A POSTROUTING -s 192.168.2.0/16 -o ppp0 -j MASQUERADE
    iptables -t nat -A POSTROUTING -s 192.168.2.0/12 -o ppp0 -j MASQUERADE
    service hostapd stop
    service isc-dhcp-server stop

    --------------------------------

    Das bei dir wahrscheinlich nicht

    /etc/init.d/networking restart

    --------------------------------------

    service isc-dhcp-server start
    service hostapd start

    Für 192.168.2.0 natürlich deine 192.168.xxx.xxx

    oder was du sonst hast

    *********************************
    Ende

    service hostapd stop
    service isc-dhcp-server stop

    ************************

    Nich die schönste Lösung QuickAndDirty aber funktioniert

    Deine Wlanclients müssen natürlich die gateway route gesetzt haben

    route add default gw 192.168.xxx.xxx (DeineRPI-IP)

    und nameserver

    echo nameserver xxx.xxx.xxx.xxx >> /etc/resolv.conf

    KeineDauerlösung sondern für adhoc, oder test gedacht, aber man kann erstmal sehen oballes funktioniert

    :)

  • die eth0 bleibt, egal ob der LTE-Stick gesteckt ist, oder nicht, immer der Netzwerkbuchse zugeordnet. Sobald der Stick hinzu kommt, wird diesem die eth1 zugewiesen. Abfrage erfolgte mit ifconfig -a

    Hast Du das anhand der MAC verglichen...?... bzw. wie kannst Du bestätigen, dass das so bleibt? Ich weiss im Moment nicht, wann der Kernel solchen Sticks das Merkmal "Ethernet"-Port zuweist, und ob das Kernelseitig wirklich zwingend nach dem internen physischen Device passiert, so dass er immer eth1 bekommt. Ich würde das zur Sicherheit selber festlegen.

    ifconfig ist etwas, was Du Dir wie "sudo" meiner Meinung nach abgewöhnen solltest. Um den Status der Netzwerk-Interfaces zu bestimmen oder auch zu verändern, sind die ip-Kommandos aus dem Paket iproute2 die richtige Wahl, z.B.

    Code
    ip a
    ip l
    ip r

    Damit solltest Du Dich unbedingt vertraut machen. Siehe:

    https://www.thomas-krenn.com/de/wiki/Linux_ip_Kommando

    Zitat, gleich der erste Satz aus dem Link:

    "Das Kommando ip aus der iproute2 Toolsammlung dient unter Linux zur Konfiguration von Netzwerkadressen. Es ersetzt das ifconfig Kommando aus den obsoleten net-tools"

    Das ist nichts wirklich neues, das gilt seit Jahren, es wird meistens nur hartnäckig ignoriert, weil sich zu viele an den alten Koma-Patienten festkrallen und veraltete Tutorials krampfhaft mit irgendwelchen Cheats am Leben halten.

    Aber leider wird der iptables teil nicht mehr richtig funktionieren seit

    buster ist nftables standard siehe hier

    Natürlich funktioniert das unverändert. Glaubst Du wirklich, weltweit hätten auf einmal alle auf Buster umgestellten Server-Systeme keinen Paketfilter mehr? Umgestellt wurden dieTabellen und die Paketfilter-Module im Kernel, aber das iptables-Frontend im userspace funktioniert nachwievor.... das wird jetzt lediglich durch einen iptables-translator geschickt. Man kann sich natürlich auch das neue netfilter-Frontend "nft" installieren (was sicher eine Empfehlung ist), oder aber genausogut bis auf weiteres das alte "iptables" nutzen... am Ende kommt bei beiden im Kernel das richtige raus. Langfristig ist's imho aber eine gute Empfehlung, die neue Syntax im neuen Frontend zu nutzen.

    Btw, wieso sollte systemd-networkd was damit zu tun haben, wenn gar nicht klar ist, dass das überhaupt eingerichtet ist? Und selbst wenns das für eth0 wäre, hat das trotzdem keinen Einfluss auf die wlan- Funktionen. Ganz nebenbei bemerkt, käme ich auch gar nicht auf die Idee, WLAN mit systemd-networkd einrichtenzu wollen , weil networkd diese Schnittstellen gar nicht direkt verwaltet.... das wäre also nur ne unnütze Gehhilfe, die man gar nicht braucht, wenn mans direkt selber verwaltet.

    Außerdem, Du postest hier irgendwelche Fragmente einer völlig unbekannten Installation ohne überhaupt irgendeinen Zusammenhang zu erklären. Was soll man denn mit solchen wahllosen abgesetzten Kommandos erreichen, ohne das auch nur irgendwas dafür vorbereitet wurde oder das man die Zusammenhänge kennt?

    Abesehen davon, ist nicht nur 'iptables' -ein derzeit nur noch im Kompatibilitäts-Mode arbeitendes Tool- ein eher nicht so guter Rat, das gleiche gilt imho auch für /etc/init.d/networking, /etc/network/interfaces. Und statt dem isc-dhcp-server würde ich für so eine mini-lösung eher dnsmasq verwenden, was weniger als 1/10 des Ballast der Alternative mitbringt. Dabei gehts mir nicht um die Reduzierung des Speicherplatzbedarfs, sondern um Reduzierung der installierten Code-Basis.

    jm2c

    8 Mal editiert, zuletzt von WinterUnit16246 (24. Juli 2019 um 18:26) aus folgendem Grund: sorry, wegen edits.... akku am Laptop is leer... da muss alles schnell gehen....

  • danke für den Link zum Linux ip Kommando

    Gerne. :)

    Die praktische Anwendung für so ein hostapd-Projekt habe ich vor einigen Tagen hier beschrieben.

Jetzt mitmachen!

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