[Anleitung] WLAN-LAN Brücke (bridge), oder wie bringe ich mein ethernet-only Gerät ins Wlan

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo Leute,

    mit dieser Anleitung will ich euch einen Weg aufzeigen, wie ihr eure ethernet-only Geräte in das heimische Wlan integrieren könnt. In meinem Fall war es ein AV-Receiver der kein Wlan unterstützt, ich aber auch keinen Kabel verlegen wollte bzw. konnte.

    Vorbemerkung

    Diese Anleitung erhebt keinen Anspruch auf Vollständigkeit oder Korrektheit. Bin selbst ein Laie, der nur seinen AV-Receiver in das heimische Wlan integrieren wollte. Meine Tortur könnt ihr hier nachlesen: LAN-WLAN Brücke (bridge) unter Raspbian einrichten

    Es gibt bestimmt auch elegantere Wege um das zu erledigen. Siehe dazu das Debian Paket "bridge-utiles". Leider konnte ich die "bridge-utiles" nicht einsetzten, da sie meine Hardware nicht unterstützen. Über sachliche Korrekturen, Vorschläge und Tipps, würde ich mich freuen.

    Im Grunde beruht diese Anleitung auf zwei Kernbestandteile - zwei Proxy-Servern.

    • Der eine Proxy-Server heißt parprouted er ist für unicast TCP Verbindungen zuständig. Also alles was mit Internet zu tun hat.
    • Der andere Proxy-Server heißt mcproxy er ist für multicast UDP Verbindungen zuständig, er wird nur benötigt wenn ihr Zuhause einen UPnP/dlna Medienserver betreibt und auf den über den Ethernet-Anschluss zugreifen wollt.

    Verwendete Hard/ und Software

    Ich verwende einen "Raspberry Pi 1 B+"

    Einen Wifi Adapter "EDIMAX EW-7612UAN V2" mit den vorinstallierten Treibern "8192cu".

    Und den schon angesprochenen AV-Receiver (Yamaha RX-V675), denn es in das WLAN-Netzwerk zu integrieren gilt.

    Als Software setze ich auf Raspbian (Jessie)-lite.

    Anmerkung: ich hatte ursprünglich einen ARP-Proxy nach Framp's-Anleitung (sie ich unten verlinkt) unter Raspbian (Stretch) realisiert. Er hat auch problemlos funktioniert, aber da ich das Gefühl hatte, dass Jessie etwas runder auf dem alten Pi läuft, habe ich auf Jessie downgegradet.

    Heißt: wer Stretch einsetzt, der sollte zur Einrichtung eines unicast ARP-Proxies, Framp's-Anleitung verwenden und zur Einrichtung eines Multicast-Proxies mit dieser Anleitung weitermachen - würde mich über das Feedback freuen, ob "mcproxy" auch unter Stretch läuft - vielleicht ist er sogar in den Paketquellen?

    Vorbereitung

    Der von mir verwendete Wlan Adapter, genauer gesagt die zu dem Adapter gehörende Treiber 8192cu, bieten eine Stromsparfunktion an. Leider bewirkt die Funktion, dass es oft zu Verbindungsabbrüchen kommt. Weswegen ich sie als erstes abgeschaltet habe. Dazu mit:

    Code
    sudo nano /etc/modprobe.d/8192cu.conf

    die "8192cu.conf"-Datei öffnen/anlegen und dort Folgendes eintragen:

    Code
    # disable power management and USB suspend
    options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

    und mit Strg-o abspeichern und Strg-x nano beenden.

    Unicast Brücke (bridge) mit Hilfe eines ARP-Proxies realisieren.

    Als erstes wollen wir mit Hilfe des Pakets "parprouted" einen ARP-Proxy realisieren. Der ARP-Proxy leitet TCP Pakete vom Interface "wlan0" auf das Interface "eth0" bzw. vice versa weiter, womit eine vollständige Internetanbindung am "eth0" Port realisiert wird. Die dazu notwendigen Anleitungen für verschiedene Raspbian Versionen habe ich unten verlinkt. Da sie alle einwandfrei funktioniert haben, habe ich mich nicht weiter damit beschäftigt. Der Vollständigkeit halber werde ich hier die einzelne Befehle aus der Anleitung zur Jessie erneut abtippen.

    Da Jassies neuer DHCP Client Daemon (DHCPCD) anscheinend nicht mit der üblicher Art der Netzwerkkonfiguration kompatibel ist, sollte zunächst der "dhcpcd" deaktiviert werden. Dazu einfach folgenden Befehl ausführen:

    Code
    sudo systemctl disable dhcpcd


    Als erstes werden die nötige Pakete installiert, dazu folgenden Befehl ausführen:

    Code
    sudo apt-get install parprouted dhcp-helper

    Um dem Kernel erlauben die IP-Pakete weiterzuleiten, muss "ip-forwarding" aktiviert werden. Dazu mit:

    Code
    sudo nano /etc/sysctl.conf

    die Datei "sysctl.conf" öffnen und dort folgende Zeile suchen #net.ipv4.ip_forward=1 die Raute "#" entfernen und mit Strg-o und Strg-x abspeichern. So, dass die Zeile nun wie folgt aussieht:

    Code
       .
       .
    net.ipv4.ip_forward=1
       .
       .
       .

    Dann editiert man die Datei /etc/default/dhcp-helper, so dass (so wie ich es verstehe) die ganzen DHCP Anfragen über wlan0 erfolgen (in der Anleitung heißt es relay einschalten).

    Man ersetzt die Zeile DHCPHELPER_OPTS="-b eth0" mit DHCPHELPER_OPTS="-b wlan0" so dass sie wie folgt aussieht:

    Code
    # relay dhcp requests as broadcast to wlan0
    DHCPHELPER_OPTS="-b wlan0"

    Wer den Avahi-Daemon installiert hat, der kann auch hier die mDNS Anfragen weiterleiten, in dem er die Datei /etc/avahi/avahi-daemon.conf bearbeitet und dort nach der Zeile enable-reflector sucht und den Wert "yes" hinzufügt, so dass sie wie folgt aussieht:

    Code
       .
       .
    [reflector]
    enable-reflector=yes
       .
       .
       .

    Zum Schluss noch das Netzwerk konfigurieren. Dazu die Datei /etc/network/interfaces öffnen und wenn man dort vorher keine besonderen Einstellungen gemacht hat, alles löschen und durch Folgendes ersetzen:

    Darin sorgt die Zeile: post-up /usr/sbin/parprouted eth0 wlan0 dafür, dass der "parprouted" rechtzeitig gestartet wird und sämtliche TCP-Pakete zwischen den beiden Interfaces "wlan0" und "eth0" weiterleitet.

    Damit ist die Brücke für einfache TCP-Verbindungen fertig. Am besten jetzt den Pi rebooten, damit alles seine Ordnung hat.

    Man kann jetzt TV-Boxen, Sat-Receiver, Drucker etc. an den Ethernet-Anschluss anschließen und sollte vollen Internet-Zugang haben. Also surfen, YouTube, Facebook etc. Das angeschlossene Gerät sollte auch in dem Wlan-Router (im meinem Fall die Fritzbox) mit einer eigener IP-Adresse sichtbar sein.

    Wer also Zuhause keinen Medienserver betreibt kann hier aufhören und sich eine Menge Arbeit ersparen.


    Multicast Brücke (bridge) mit Hilfe eines Multicast-Proxies realisieren

    Die muticast Brücke wird benötigt um multicast UDP Pakete vom Interface "wlan0" auf das Interface "eth0" bzw. vice versa weiterzuleiten. Die Pakete werden typischerweise zwischen einem Media-Server und einem Media-Client ausgetauscht. Im meinem Fall "missbrauche" ich die Fritzbox als Medienserver und der AV-Receiver dient als Media-Client für Musikstreams.

    Es gibt hier mehrere Programme, die die Weiterleitung beherrschen, das wohl beliebteste scheint "SMCRoute" zu sein (weiterführende Links dazu habe ich unten angegeben). Bei mir hat aber nur "mcproxy" den gewünschten Erfolg gebracht.

    Voraussetzung für Multicasting prüfen

    Bevor es nun ans Eingemachte geht wollen wir zuerst prüfen ob der Kernel mit der nötigen Voraussetzung kompiliert wurde.

    Dazu suchen wir in der Datei /proc/config.gz nach Zeilen CONFIG_IP_MULTICAST=y bzw. CONFIG_IP_MROUTE=y. Da die Datei /proc/config.gz als Modul realisiert wurde, muss das Modul zuerst mit sudo modprobe configs geladen werden. Hier meine Ausgabe:

    Code
    pi@raspberrypi:~ $ sudo modprobe configs
    pi@raspberrypi:~ $ zegrep -i 'mroute|multicast' /proc/config.gz
    CONFIG_IP_MULTICAST=y
    CONFIG_IP_MROUTE=y
    CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
    CONFIG_IPV6_MROUTE=y
    CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y

    Der Kernel wurde also mit allen nötigen Voraussetzungen für Multicasting kompiliert.

    Dann schauen wir noch ob die beiden Netzwerkschnittstellen Multicasting unterstützen. Dazu folgenden Befehl ausführen:

    Auch hier sieht man an den Zeilen "RUNNING MULTICAST" dass das jeweilige Interface Multicasting unterstützt.

    D.h. wir können mit dem aufsetzen eines Multicast-Proxy fortfahren.


    Mcproxy kompilieren und installieren

    Leider habe ich "mcproxy" nicht in den Paketquellen gefunden, somit musste ich es selber kompilieren.

    Um es zu kompilieren braucht man folgende Pakete (Achtung es installiert das halbe KDE - der Download ist über 100 MB zumindest auf meiner "lite"-Version):

    Code
    sudo apt-get install build-essential git qt5-qmake qt5-default

    Anschließend klont man das Git-Repo mit:

    Code
    git clone https://github.com/mcproxy/mcproxy.git build/mcproxy

    Nun wechselt man in das Verzeichnis build/mcproxy/mcproxy (2 x mcproxy) mit:

    Code
    cd build/mcproxy/mcproxy

    und kompiliert das Programm mit folgenden zwei Befehlen:

    Code
    qmake
    make

    Wenn der Compiler fertig ist, installiert man "mcproxy" mit dem Befehl:

    Code
    sudo make install

    Der Befehl kopiert nur die ausführbare "mcproxy"-Datei in das Verzeichnis /usr/local/bin/


    Mcproxy konfigurieren

    Nach der Installation checkt man als erstes ob das Programm alle benötigten Kernel Features findet, die es so braucht. Dies macht man mit dem Befehl sudo mcproxy -c. Bei mir sieht es wie folgt aus:

    Na wenn da überall Ok steht dann ist alles gut - denke ich mal ;)

    Um das Programm starten zu können braucht man noch eine Konfigurationsdatei.

    Auf der GitHub-Seite des Projektes ist eine Beispielsdatei vorhanden: https://github.com/mcproxy/mcprox…xy/mcproxy.conf

    Ich habe sie mit:

    Code
    wget https://raw.githubusercontent.com/mcproxy/mcproxy/master/mcproxy/mcproxy.conf

    heruntergeladen und dort den Eintrag: pinstance myProxy: eth0 ==> eth1 eth2; durch: pinstance myProxy: wlan0 ==> eth0; ersetzt, so dass sie bei mir wie folgt aussieht:

    Anschließend habe ich sie mit:

    Code
    sudo mv mcproxy.conf /etc

    in das /etc Verzeichnis verschoben.

    Nun kann man "mcproxy" mit dem Befehl:

    Code
    sudo mcproxy -f /etc/mcproxy.conf

    Bzw. wenn man es im Hintergrund starten will (der bevorzugte Weg):

    Code
    sudo nohup mcproxy -f /etc/mcproxy.conf &

    starten. Dabei gibt der Parameter "-f" den Pfad zur Konfigurationsdatei an.

    Wenn "mcproxy" gestartet ist, kann man die ganzen Weiterleitungen mit dem Befehl ip -s mroute verfolgen. Das sollte ungefähr wie folgt aussehen:

    Code
    pi@raspberrypi:/ $ ip -s mroute
    (192.168.178.27, 239.255.250.250) Iif: eth0       Oifs: wlan0 
      1 packets, 135 bytes
    (192.168.178.65, 239.255.255.250) Iif: wlan0      Oifs: eth0 
      4 packets, 796 bytes

    Anmerkung: die gezeigten Weiterleitungen ist nur eine Momentaufnahme - es können auch noch mehr Weiterleitungsrouten auftauchen oder weniger - also nicht wundern, wenn die Ausgabe leer ist.


    Problembehebung

    Sollte es zu Problemen kommen, kann man "mcproxy" mit den Parameter "-dsvv" starten, dadurch wird der Debug-Modus aktiviert und man kann an der Ausgabe vielleicht erkennen wo das Problem ist. Der Befehl sieht dann wie folgt aus:

    Code
    sudo mcproxy -dsvv -f /etc/mcproxy.conf


    Desweiteren kann man schauen ob "mcproxy", die nötigen Kernelparameter richtig gesetzt hat:

    Code
    pi@raspberrypi:/ $ sudo sysctl -a | grep 'mc_' | grep -v ipv6 | egrep 'eth0|wlan0'
    sysctl: reading key "net.ipv6.conf.all.stable_secret"
    sysctl: reading key "net.ipv6.conf.default.stable_secret"
    sysctl: reading key "net.ipv6.conf.eth0.stable_secret"
    sysctl: reading key "net.ipv6.conf.lo.stable_secret"
    sysctl: reading key "net.ipv6.conf.wlan0.stable_secret"
    net.ipv4.conf.eth0.mc_forwarding = 1
    net.ipv4.conf.wlan0.mc_forwarding = 1

    Wichtig dabei ist net.ipv4.conf.eth0.mc_forwarding = 1 und net.ipv4.conf.wlan0.mc_forwarding = 1


    Außerdem kann man versuchen "mcproxy" mit dem Parameter "-r" zu starten:

    Code
    sudo nohup mcproxy -r -f /etc/mcproxy.conf &

    Der Parameter "-r" bedeutet laut Hilfe:

    Code
        -r
            Reset the reverse path filter flag, to accept data from
            foreign subnets.


    Der Autor? empfiehlt auch (https://groups.google.com/forum/#!topic/…oxy/YhfT0_vUH50) folgende Parameter in die Datei /etc/sysctl.conf einzutragen:

    Code
    net.ipv4.conf.all.rp_filter = 0
    net.ipv4.conf.eth0.rp_filter = 0
    net.ipv4.conf.wlan0.rp_filter = 0


    McProxy als Service für systemd einrichten

    Damit "mcproxy" bei Systemstart automatisch und ordnungsgemäß gestartet wird, wollen wir ihn in "systemd" integrierten.

    Dazu die Datei "mcproxy.service" mit wget von diesem GitHub-Repo: https://github.com/Tilka/aur-mcpr…mcproxy.service herunterladen.

    Code
    wget https://github.com/Tilka/aur-mcproxy-git/raw/master/mcproxy.service

    Den Pfad zu der ausführbaren Datei "mcproxy" anpassen /usr/bin/mcproxy -> /usr/local/bin/mcproxy, sodass die Datei wie folgt aussieht:

    Code
    [Unit]
    Description=mcproxy multicast proxy for IGMP/MLD (RFC 4605)
    Documentation=http://mcproxy.realmv6.org/wiki/Documentation
    After=network.target
    
    [Service]
    ExecStart=/usr/local/bin/mcproxy -f /etc/mcproxy.conf
    
    [Install]
    WantedBy=multi-user.target

    Anschließend die Datei mit:

    Code
    sudo mv mcproxy.service /etc/systemd/system

    nach /etc/systemd/system verschieben.

    Nun muss der Dienst noch aktiviert werden, dazu folgenden Befehl ausführen:

    Code
    sudo systemctl enable mcproxy.service

    Zum Schluss kann man es mit:

    Code
    sudo systemctl start mcproxy.service

    starten. Ich habe hier einen Reboot durchgeführt, um zu sehen ob der Dienst auch wirklich ordnungsgemäß und automatisch gestartet wird.

    Noch ein paar hilfreiche Befehle

    Um den aktuellen Status von "mcproxy" zu sehen einfach folgenden Befehl ausführen:

    Code
    sudo systemctl status mcproxy

    Um die Log-Messages zu sehen ("-u" steht für Unit):

    Code
    sudo journalctl -u mcproxy


    Weiterführende Links

    ARP-Poxy

    Framp's Anleitung (für Stretch): https://www.linux-tips-and-tricks.de/de/raspberry/1…l-bruecke-bauen

    Anleitung (für Jessie): https://github.com/a2retrosystems…nd-Raspberry-Pi

    Debian-Wiki Anleitung (für Wheezy): https://wiki.debian.org/BridgeNetworkConnectionsProxyArp


    Multicast

    McProxy

    Projectseite: https://mcproxy.realmv6.org/trac/

    Dokumentation: https://mcproxy.realmv6.org/trac/wiki/Documentation

    Projektseite auf GitHub: https://github.com/mcproxy/mcproxy

    SMCRoute

    Ist ein sehr beliebtes Programm zur Multicastrouting.

    Hier gibt der Autor von SMCRoute weitere Informationen bezüglich Multicast: http://troglobit.com/howto/multicast/

    Benutzungsanleitungen zu SMCRoute:

    https://github.com/CedricCabessa/…st_multicast.md

    https://thedevops.party/dlna-communica…ugh-the-router/

    http://bda.ath.cx/blog/2009/01/2…fic-with-linux/

    (Achtung Japanisch, hat aber sehr schönen Befehle): http://rufas.manyoldmoon.com/blog/1605

    IGMPproxy

    Ein weiterer Multicast-Proxy, der voll und ganz auf IMG-Protokoll setzt. Hat wahrscheinlich den Vorteil, dass man sich nicht erst die ganzen Qt-Pakete installieren muss.

    Projektseite: https://sourceforge.net/projects/igmpproxy/

    Projektseite auf GitHub: https://github.com/pali/igmpproxy


    Danksagungen

    Ich möchte mich bei allen bedanken, die mir bei der Lösung des Problems geholfen haben.

    Insbesondere möchte ich mich bei framp bedanken, der mit seiner Anleitung zur ARP-Proxy mir den Weg geebnet hat und auch sonst mit Rat und Tat zur Stelle war. Desweiteren möchte ich mich ebenfalls bei rpi444 und someone aka Peter bedanken, die ihre Zeit geopfert haben um mir bei meinem Problem zu helfen. Danke euch Jungs. :danke_ATDE:

    Tipp zum Schluss

    Wer seinen Pi nur als Wlan-Lan-Brücke einsetzen will, der sollte sich OpenWRT für Raspberry Pi anschauen:

    https://openwrt.org/toh/raspberry_pi_foundation/raspberry_pi

    Damit kann man die Brücke mit nur ein paar Mausklicks einrichten. Hier ist z.B. so eine Anleitung (ab Schritt 7 wird's interessant):

    https://www.nerd-quickies.net/2017/04/03/set…h-openwrt-luci/

    Allerdings ist OpenWRT mehr für Router ausgelegt und damit nicht so umfangreich konfigurierbar und erweiterbar wie Raspbian.

    Abschließende Worte

    Ich habe versucht diese Anleitung so umfangreich und detailliert wie möglich zu gestalten. Sollten jedoch Unklarheiten oder weitere Fragen auftreten, dann zögert nicht mich anzuschreiben. Bitte bedenkt aber, ich bin selbst ein Laie und freue mich, dass ich es irgendwie geschafft habe.

    Für weitere Tipps, Korrekturen und Anregungen bin ich offen und würde mich darüber freuen.


    Gruß

    Waldemar


    EDIT:

    Habe weiter unten noch zwei weitere Programme vorgestellt:

    Multicast-Relay: [Anleitung] WLAN-LAN Brücke (bridge), oder wie bringe ich mein ethernet-only Gerät ins Wlan

    wlan_kabel: [Anleitung] WLAN-LAN Brücke (bridge), oder wie bringe ich mein ethernet-only Gerät ins Wlan

    3 Mal editiert, zuletzt von Waldemar (28. Oktober 2018 um 22:15) aus folgendem Grund: Code zum Download der "mcproxy.conf" Datei angepasst Tippfehler behoben Links zu weiteren vorgestellten Programmen hinzugefügt

  • [Anleitung] WLAN-LAN Brücke (bridge), oder wie bringe ich mein ethernet-only Gerät ins Wlan? Schau mal ob du hier fündig wirst!

  • Perfekt :thumbup:Gefällt mir besser als mein Howto :lol:.

    Kommt auch nicht oft vor dass jemand schon nach 15 Beitraegen im Forum ein detailertes, gut strukturiertes, auf das Wesentliche reduziertes und recht leicht les- und umsetzbares HowTo schreibt. :bravo2:

    Ich werde auf meiner deutschen Seite meines Howtos auf diese Seite einen Link auf Dein Tutorial setzen.

  • Hallo Leute,

    heute möchte ich euch zwei weitere Programme vorstellen um eine multicastfähige wlan-lan Brücke zu erstellen.

    Vorbemerkung

    Leider lief das im ersten Post vorgestellte Programm "Mcproxy", nicht ganz rund bei mir. Es kann Tage/Wochen problemlos laufen, aber früher oder später hängt es sich mit der Meldung:

    Code
    ERROR: failed to get multicast route stats! Error: Cannot assign requested address errno: 99

    auf. Wobei die Error-Meldung in Sekundentakt auftaucht und selbst ein Restart von Mcproxy keine Besserung bringt - nur ein Reboot hilft.

    Habe auch keine Ahnung woran es wirklich liegt, aber ich vermute mal, dass der kleine Pi mit dem ganzen Multicast-Routing einfach überfordert ist. Denn auch sämtliche Smart-TVs im Haushalt lassen Ihre Multicast-Pakete über den McProxy laufen - das sieht dann so aus:

    Code
    pi@raspberrypi:~ $ ip -s mroute
    (192.168.178.1, 239.255.255.250) Iif: wlan0      Oifs: eth0 
      2 packets, 302 bytes
    (192.168.178.65, 239.255.255.250) Iif: wlan0      Oifs: eth0 
      4 packets, 796 bytes
    (192.168.178.27, 239.255.250.250) Iif: eth0       Oifs: wlan0 
      1 packets, 135 bytes
    (192.168.178.25, 239.255.255.250) Iif: wlan0      Oifs: eth0 
      516 packets, 60613 bytes

    und da sind noch nicht alle drin ;) Vielleicht bringt das alles den Pi aus dem Takt.

    Da ich mit der Situation nicht zufrieden war, habe ich mich weiter auf die Suche begeben und zwei weiter Programme gefunden, die interessant sein könnten - nämlich "Multicast-Relay" und "wlan_kabel".

    In diesem Post gehe ich nur auf "Multicast-Relay" ein, da es für mich das interessantere ist und bereits seit 4 Tagen problemlos läuft. Das Programm "wlan_kabel" stelle ich dann im nachfolgenden Post kurz vor.

    "Multicast-Relay" ist eigentlich ein direkter Ersatz für "Mcproxy" (ist aber kein Proxy - bitte nicht falsch verstehen), somit besteht die Brücke wieder aus zwei Teilen:

    • einer unicast-Brücke, die wird weiterhin mit dem Paket parprouted realisiert
    • und einer multicast-Brücke, die wird diesmal mit dem Programm Multicast-Relay realisiert.

    Unicast Brücke

    Wie schon in der Vorbemerkung erwähnt wird auch diesmal die unicast-Brücke mit Hilfe des Pakets "parprouted" realisiert und bis auf den Eintrag in die Datei /etc/network/interfaces ändert sich hier nichts. Der Vollständigkeitshalber kopiere ich die einzelne Schritte aus dem ersten Post, hier rein.

    Da Jassies neuer DHCP Client Daemon (DHCPCD) anscheinend nicht mit der üblicher Art der Netzwerkkonfiguration kompatibel ist, sollte zunächst der "dhcpcd" deaktiviert werden. Dazu einfach folgenden Befehl ausführen:

    Code
    sudo systemctl disable dhcpcd

    Als erstes werden die nötige Pakete installiert, dazu folgenden Befehl ausführen:

    Code
    sudo apt-get install parprouted dhcp-helper

    Um dem Kernel erlauben die IP-Pakete weiterzuleiten, muss "ip-forwarding" aktiviert werden. Dazu mit:

    Code
    sudo nano /etc/sysctl.conf

    die Datei "sysctl.conf" öffnen und dort folgende Zeile suchen #net.ipv4.ip_forward=1 die Raute "#" entfernen und mit Strg-O und Strg-X abspeichern. So, dass die Zeile nun wie folgt aussieht:

    Code: /etc/sysctl.conf
       .
       .
       .
    net.ipv4.ip_forward=1
       .
       .
       .

    Dann editiert man die Datei "/etc/default/dhcp-helper", so dass (so wie ich es verstehe) die ganzen DHCP Anfragen über wlan0 erfolgen (in der Anleitung heißt es relay einschalten).

    Man ersetzt die Zeile DHCPHELPER_OPTS="-b eth0" mit DHCPHELPER_OPTS="-b wlan0"

    Code: /etc/default/dhcp-helper
    # relay dhcp requests as broadcast to wlan0
    DHCPHELPER_OPTS="-b wlan0"


    Wer den Avahi-Daemon installiert hat, der kann auch hier die mDNS Anfragen weiterleiten, in dem er die Datei "/etc/avahi/avahi-daemon.conf" bearbeitet und dort nach der Zeile enable-reflector sucht und den Wert yes hinzufügt, so dass sie wie folgt aussieht: .

    Code: /etc/avahi/avahi-daemon.conf
       .
       .
    [reflector]
    enable-reflector=yes
       .
       .
       .


    Zum Schluss noch das Netzwerk konfigurieren. Hier gibt es einen Unterschied zu dem ersten Post.

    Da "Multicast-Relay" mit der gleichen IP-Adresse für das Interface "wlan0" und "eth0" nicht klar kommt, jedoch eine eigenständige IP-Adresse für das jeweilige Interface voraussetzt, habe ich dem Interface "eth0" eine statische IP-Adresse außerhalb meines Netzwerks vergeben.

    Bei mir Zuhause belegt die FritzBox den Adressraum 192.168.178.1/24 was alle Adressen zwischen 192.168.178.1 ... 192.168.178.255 einschließt. Um dem nicht in die Quere zu kommen, habe ich dem "eth0" Interface die Adresse 192.168.1.2/24 zugeteilt, was einem Adressraum von 192.168.1.1 ... 192.168.1.255 entspricht.

    Dazu die Datei "/etc/network/interfaces" öffnen und wenn man dort vorher keine besonderen Einstellungen gemacht hat, alles löschen und durch Folgendes ersetzen:


    Wie man sieht, wird auch hier der "parprouted" mit dem Befehl post-up /usr/sbin/parprouted eth0 wlan0 gestartet und erstellt eine unicast-Verbindung zwischen "eth0" und "wlan0".

    Multicast Brücke

    Um Multicast-Pakete weiterzuleiten wird diesmal das Programm "Multicast-Relay" verwendet.

    Das Programm kann man hier finden: https://github.com/alsmith/multicast-relay

    Zum jetzigen Zeitpunkt ist der Commit: 2cf5bafedfc6523c2c94c64e33a43fad96d3d0c9, der letzte.

    Es handelt sich hier um ein Python-Script welches, wie es aussieht, in erste Linie für Sonos-Lautsprecher entwickelt wurde, leitet aber auch die für meinen Einsatzzweck wichtige Multicastpakete "239.255.255.250:1900" weiter.

    Das Script setzt auf das Python-Paket "netifaces" auf. Womit man das Paket zuerst installieren sollte. Das kann man ganz bequem aus den Paketquellen installieren. Dazu folgenden Befehl aufrufen:

    Code
    sudo apt-get install python-netifaces

    Als nächstes klont man das GitHub-Repo (vorausgesetzt git ist installiert) mit dem Befehl:

    Code
    git clone https://github.com/alsmith/multicast-relay.git build/multicast-relay

    Anschließend kopiert man einfach das Script nach /usr/local/bin/, mit folgendem Befehl:

    Code
    sudo cp build/multicast-relay/multicast-relay.py /usr/local/bin/multicast-relay.py

    Anmerkung: bei mir war das Script schon als eine ausführbare Datei markiert, sollte es nicht der Fall sein, dann kann man es mit dem Befehl: sudo chmod +x build/multicast-relay/multicast-relay.py zuerst als eine ausführbare Datei markieren.

    Nun kann man es auch schon testen, dazu einfach folgenden Befehl eingeben:

    Code
    sudo multicast-relay.py --interfaces wlan0 eth0 --noMDNS --noSonosDiscovery --allowNonEther --foreground --verbose

    Parametererklärung:

    --interfaces Die Interfaces zwischen denen die Pakete weitergeleitet werden.

    --noMDNS Leite keine mDNS Anfragen weiter - das macht bei uns der Avahi-Daemon, wenn man dort in der Konfigurationsdatei "enable-reflector=yes" eingetragen hat.

    --noSonosDiscovery Leite keine Broadcast Pakete vom Port 6969 weiter - ist nur für Sonos interessant - außerdem sollte sich theoretisch der "parprouted" um broadcast/unicast Pakete kümmern.

    --allowNonEther Ist z.Z. ein experimentelles Feature welches es ermöglicht, dass wir unser "wlan0" Interface nutzen können.

    --foreground Führe das Programm im Vordergrund aus, um die Statusmeldungen zu sehen.

    --verbose Zeige noch mehr status-Informationen.

    Weitere mögliche Parameter kann man mit dem Befehl multicast-relay.py --help erfahren.

    Funktioniert alles wie gewünscht kann man das Programm mit "Strg-c" wieder beenden.

    Multicast-Relay als Service für systemd einrichten

    Damit "Multicast-Relay" beim Systemstart automatisch startet, wollen wir es analog zum Mcproxy, als Service in systemd integrieren.

    Dazu erstellen wir mit "nano" folgende Datei:

    Code
    sudo nano /etc/systemd/system/multicast-relay.service

    und tragen dort Folgendes ein:

    Code: /etc/systemd/system/multicast-relay.service
    [Unit]
    Description=Relay broadcast and multicast packets between interfaces
    Documentation=https://github.com/alsmith/multicast-relay
    After=network.target
    
    [Service]
    ExecStart=/usr/local/bin/multicast-relay.py --interfaces wlan0 eth0 --noMDNS --noSonosDiscovery --allowNonEther --foreground
    
    [Install]
    WantedBy=multi-user.target

    Anschließend aktivieren wir den Service mit:

    Code
    sudo systemctl enable multicast-relay.service

    Der Service kann nun mit dem Befehl:

    Code
    sudo systemctl start multicast-relay.service

    gestartet werden.

    Bei mir hat der Start schon gereicht und ich konnte den Receiver sofort einsetzen.

    Allerdings denke ich, dass ein Reboot an der Stelle auch nicht schadet - es sei den man ist auf seine Uptime besonders stolz ;)

    Wie ich in der Vorbemerkung geschrieben habe, läuft mein Receiver mit diesem Setup seit ungefähr 4 Tagen problemlos. Sollte ich irgendwelche Probleme bemerken, werde ich das hier nochmal nachreichen.

    Wie immer, bin ich für konstruktive Vorschläge und Korrekturen offen :)


    Gruß

    Waldemar

    2 Mal editiert, zuletzt von Waldemar (28. Oktober 2018 um 22:50)

  • Hallo Leute,

    hier möchte ich euch ein kleines aber feines Programm namens "wlan_kabel" vorstellen. Das Programm wurde von Wolfgang Illmeyer entwickelt und ist dazu da um, wie der Name schon sagt, ein "Wlan-Kabel" zu simulieren - heißt ethernet-only Geräte mit Hilfe eines Computers (mit einem Ethernet-Anschluss und einer WLAN-Schnittstelle) in das Wlan-Netzwerk zu integrieren. Eigentlich das, wonach ich die ganze Zeit gesucht habe ;)

    Das Programm kann man hier finden: https://github.com/escitalopram/wlan_kabel

    Wie Wolfgang auf seiner GitHub Seite schreibt, ist der Nachteil von "wlan_kabel", dass an dem Ethernet-Port nur ein Gerät angeschlossen werden kann. Heißt: während ich mit der Lösung aus dem Post 1 (Kombi aus parprouted und mcproxy) einen Switch an den Ethernet-Port anschließen könnte und so theoretisch noch 20 weitere Geräte an dem Ethernet-Port betreiben könnte, ist es mit dem Programm "wlan_kabel" nicht möglich.

    Das wäre mir aber alles egal, wenn da nicht noch ein für mich viel gravierender Fehler wäre.

    Dadurch, dass hier einfach alle Pakete die durch das "wlan0" Interface laufen, stur auf das "eth0" Interface kopiert werden bzw. vice versa. Führt schon der kleinster Download bzw. Upload auf den Pi (damit meine ich den Pi selbst, nicht den angeschlossenen Receiver) dazu dass die CPU-Last auf 100% steigt und "wlan_kabel" beendet wird.

    Schade eigentlich - hoffe Wolfgang kann das irgendwannmal beheben.

    Wer also seinen Pi als eine reine Wlan-Lan Brücke einsetzen will, der kann das Programm verwenden - allen Anderen würde ich davon eher abraten.

    Nichtsdestotrotz möchte ich euch zeigen, wie ihr das Programm testen könnt.

    Netzwerkkonfiguration

    Wie Wolfgang auf seiner GitHub Seite schreibt, braucht "wlan_kabel" keine besondere Konfiguration, es muss nur eine Wlan-Verbindung vorhanden sein.

    Bei mir sah die /etc/network/interfaces Datei wie folgt aus:

    WLAN_KABEL kompilieren und testen

    Um "wlan_kabel" zu kompilieren braucht man keine besondere Pakete, es reicht eigentlich nur "build-essential" und "git" zu installieren - dazu einfach folgenden Befehl ausführen:

    Code
    sudo apt-get install build-essential git

    Dann kann man auch schon das git-Repo von GitHub, klonen mit:

    Code
    git clone https://github.com/escitalopram/wlan_kabel.git build/wlan_kabel

    Anschließend wechselt man in das Verzeichnis mit:

    Code
    cd build/wlan_kabel/

    und kompiliert das Paket mit dem Befehl:

    Code
    make

    Ist der Kompiliervorgang abgeschlossen, kann man auch schon das Programm testen. Dazu folgender Befehl:

    Code
    ./wlan_kabel wlan0 eth0 00:22:15:49:e5:55

    Dabei sollte 00:22:15:49:e5:55 die Mac-Adresse des am Ethernet-Port angeschlossenen Gerätes sein - also im meinem Fall des Receivers.


    Wie am Anfang erwähnt wäre das Tool perfekt für mich, wenn da die Hohe CPU-Auslastung nicht wäre.

    Somit bleibe ich vorerst bei der Kombi aus "parprouted" und "Multicast-Relay", welches bis jetzt tadellos ihren Dienst verrichtet.


    Gruß

    Waldemar


    PS.: hier noch der Link wie ich auf das Programm gekommen bin: https://raspberrypi.stackexchange.com/questions/5105…dge-to-ethernet

  • Ich habe nun meinen RaspberryPi über die Methode 1 (parprouted und mcproxy) eingerichtet, allerdings mit nur mäßigem Erfolg. In seltenen Fällen klappt die Verbindung zu meiner Yamaha Pianocraft MCR-N560D und zwar auch nur dann, wenn ich über OpenVPN oder die App MyFRITZ! eine VPN-Verbindung zwischen Smartphone und Netzwerk herstelle. Es ist echt wie verhext. Mit Methode 2 (parprouted und Multicast) war ich gänzlich erfolglos. Wie muss ich denn für den Fall, dass ich über

    Code
    auto eth0
    allow-hotplug eth0
    iface eth0 inet static
      address 192.168.1.2/24

    dem eth0 Device eine statische Adresse zuweise meine Anlage einrichten (IP-Adresse, Subnetz, Std. Gateway, DNS-Server (P und S)? Ich habe auf meinem RaspberryPi übrigens auch noch ein Pi hole eingerichtet. Dies sollte aber keinen (negativen) Einluss haben. Ich habe testweise die Anlage auch direkt über Kabel an der Fritzbox (statt an den Pi) angehängt und alles hat wie gewohnt 1a funktioniert.

    Kann mir wer helfen? Es wäre so schön, wenn ich meine Anlage wieder in vollem Funktionsumfang nutzen könnte.

    Danke euch und viele Grüße,
    Michael

  • Ein kleiner Nachtrag von mir: Wenn ich mich mit meinem Smartphone neu am WLAN anmelde, klappt die Verbindung zur Anlage über die App nicht. Erst wenn ich auf dem Pi

    Code
    sudo tcpdump -vvveni wlan0 multicast

    eingebe, klappt die Verbindung für die laufende Session (d.h. solange das Smatphone im WLAN ist) reibungslos. Was passiert beim Aufruf von tcpdump, was diesen Effekt haben könnte?

  • ..., klappt die Verbindung für die laufende Session (d.h. solange das Smatphone im WLAN ist) reibungslos. Was passiert beim Aufruf von tcpdump, was diesen Effekt haben könnte?

    Beim Aufruf von tcpdump passiert Folgendes:

    Code
    device wlan0 entered promiscuous mode

    Ob das diesen Effekt hat, weiß ich nicht.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo rpi444,

    vielen Dank für deine Antwort. Zum promiscuous mode muss ich heute Abend noch einmal recherchieren. Kurz zusammengefasst: Wenn ich mich mit meinem Smartphone am WLAN anmelde und einmalig "sudo tcpdump -vvveni wlan0 multicast" ausführe, klappt die Verbindung zur Stereoanlage für die Zeit, in der ich im WLAN bin problemlos. Verbinde ich mich (bzw. das Smartphone) neu mit dem WLAN, habe ich keine Chance mehr. Was ich überdies noch beobachtet habe: Habe ich bei deaktiviertem WLAN die mobilen Daten aktiviert und mache einen VPN-Tunnel zum RasPi auf, klappt hin und wieder ebenfalls die Verbindung mit der Anlage. Sehr dubios. Hast du eine Idee, wie ich den "promiscuous mode" für wlan0 dauerhaft aktivieren könnte? Hat das irgendwelche Nachteile?

    Viele Grüße,
    Michael

  • Wenn ich mich mit meinem Smartphone am WLAN anmelde und einmalig "sudo tcpdump -vvveni wlan0 multicast" ausführe, klappt die Verbindung zur Stereoanlage für die Zeit, in der ich im WLAN bin problemlos. Verbinde ich mich (bzw. das Smartphone) neu mit dem WLAN, habe ich keine Chance mehr. Was ich überdies noch beobachtet habe: Habe ich bei deaktiviertem WLAN die mobilen Daten aktiviert und mache einen VPN-Tunnel zum RasPi auf, klappt hin und wieder ebenfalls die Verbindung mit der Anlage. Sehr dubios. Hast du eine Idee, wie ich den "promiscuous mode" für wlan0 dauerhaft aktivieren könnte? Hat das irgendwelche Nachteile?

    Den "promiscuous mode" kannst Du dauerhaft mit ifconfig (oder gleichwertig) für das Interface aktivieren:

    Zitat

    [-]promisc

    Ein-/Ausschalten des promiscuous Modus der Schnittstelle. Ist er eingeschaltet, so werden alle Pakete

    vom Netzwerk empfangen unabhängig davon ob sie an die Schnittstelle adressiert sind.

    Ob es Nachteile hat kann ich nicht sagen. Evtl. ist der Ressourcenverbrauch bzw. der Traffic am Interface etwas höher.

    Was ich aber nicht richtig verstehe: Du schreibst:

    Zitat


    Wenn ich mich mit meinem Smartphone am WLAN anmelde und einmalig "sudo tcpdump -vvveni wlan0 multicast" ausführe, ...

    Führst Du "sudo tcpdump -vvveni wlan0 multicast" im Smartphone aus oder in deinem PI?

    BTW: Bzgl. Smartphone/Tablet mit Android (oder gleichwertig), gibt es im WLAN meiner FritzBox (... und den FritzBoxen meiner Freunde) massiven "packet loss" bei den anderen Geräten im WLAN der FritzBox. Deshalb benutze ich Smartphone bzw. Tablet (mit diesen OS's) nur im Gast-WLAN meiner FritzBox.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hallo rpi444,

    zu deiner Frage:

    Zitat

    Führst Du "sudo tcpdump -vvveni wlan0 multicast" im Smartphone aus oder in deinem PI?

    Ich führe den Befehl auf dem Pi direkt aus. In der Konsole auf dem Pi läuft dann der gesamte Traffic durch. Ich kann dann über STRG+C tcpdump wieder beenden. Dann kann ich von meinem Android-Phone aus noch immer problemlos auf die Anlage zugreifen. Erst wenn ich WLAN aus meinem Phone ausschalte und gleich wieder einschalte, klappt es nicht mehr. Ich müsste dann wieder "sudo tcpdump -vvveni wlan0 multicast" ausführen.

    Wie bzw. in welcher config-Datei kann ich den "promiscuous mode" denn dauerhaft ab nach dem Boot des Pi aktivieren für das Device wlan0? Ich würde das einfach gerne mal testen.


    Viele Grüße,
    Michael

  • Erst wenn ich WLAN aus meinem Phone ausschalte und gleich wieder einschalte, klappt es nicht mehr.

    Was klappt nicht mehr? Der Zugriff von deinem Android auf die Anlage? Wenn ja, was hat der Android bzw. die Anlage, mit deinem PI zu tun?

    Versuch mal in der Datei "/etc/rc.local".

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Was klappt nicht mehr? Der Zugriff von deinem Android auf die Anlage? Wenn ja, was hat der Android bzw. die Anlage, mit deinem PI zu tun?

    Versuch mal in der Datei "/etc/rc.local".

    Lass es mich so formulieren: Nur bei laufendem "sudo tcpdump -vvveni wlan0 multicast" in der Konsole auf dem Pi klappt der Zugriff über mein Android Phone auf die Anlage. Beende ich den tcpdump-Prozess auf dem Pi, kann ich mich auch nicht mehr mit der Anlage verbinden. Das riecht schon sehr nach dem "promiscuous mode" Problem.

  • Hallo rpi444,

    erstmal danke für den Tipp mit dem "promiscuous mode". Im Netz steht an vielen Stellen, dass eine dauerhafte Aktivierung für eine Schnittstelle nicht wirklich ideal ist. Ich habe nun probeweise in

    Code
    /etc/rc.local

    folgende Zeilen hinzugefügt:

    Code
    ifconfig wlan0 up
    ifconfig wlan0 promisc

    Nach einem Reboot des Pi ist der Parameter PROMISC für Device wlan0 nun dauerhaft gesetzt.

    Code
    pi@flightpi:~$ ifconfig wlan0
    wlan0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500
            inet 192.168.160.230  netmask 255.255.255.0  broadcast 192.168.160.255
            inet6 fd00::ba27:ebff:fea2:65c2  prefixlen 64  scopeid 0x0<global>
            inet6 fe80::ba27:ebff:fea2:65c2  prefixlen 64  scopeid 0x20<link>
            ether b8:27:eb:a2:65:c2  txqueuelen 1000  (Ethernet)
            RX packets 2297  bytes 193293 (188.7 KiB)
            RX errors 0  dropped 1298  overruns 0  frame 0
            TX packets 1429  bytes 381490 (372.5 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    Nun kann ich zu jeder Gelegenheit vom Android Phone auf meine Yamaha-Anlage mittels der Yamaha-App (NP Controller) zugreifen. Das wollte ich haben. Werde heute Abend noch ein wenig recherchieren zu diesen Themen. Aber von mir aus soll's das nun gewesen sein.

    Danke euch und viele Grüße,
    Michael

  • Aber von mir aus soll's das nun gewesen sein.

    Naja, mich würde schon interessieren, warum das nur mit aktiviertem "promiscuous mode" für das wlan0-Interface funktioniert und das schon deshalb, weil:

    Code
    RX errors 0  dropped 1298  ...

    für dieses Interface angezeigt werden.

    Aber ohne deine Hilfe ist das leider nicht möglich (... siehe meine Beiträge oben).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Zum Thema dropped habe ich hier gelesen:

    Zitat

    RX = received, also empfangen


    TX = transceived, also gesendet


    errors sind Übertragungsfehler (z.B. fehlerhafte Prüfsumme)... Shit happens. Solange das nicht überhand nimmt ist das i.O. Das können auch Kollisionen am Switch sein, wenn das Netz ausgelastet ist.


    dropped sind Pakete, die der Treiber ignoriert hat. Das passiert auch bei kompletter Auslastung des Netzes, wenn der Treiber, oder die Karte nicht mehr nachkommt, die Pakete zu bearbeiten. Auch hier gilt: In einem gewissen Rahmen ist das i.O.


    overrun ist wie dropped, nur dass hier die Karte schon die Pakete verworfen hat, weil Ihr interner Buffer vollgelaufen ist. Gleiche Anmerkung wie vorher...

    In meinem Fall werden also ziemlich viele empfangene (RX) Pakete ignoriert. Hm, was ich noch sagen kann ist, dass auf dem Pi auch Pi24 (Flightradar24) läuft. Vielleicht hängt es damit zusammen? Ansonsten läuft auf diesem Pi nichts.

  • Aber ohne deine Hilfe ist das leider nicht möglich (... siehe meine Beiträge oben).

    Versteh mich bitte nicht falsch, rpi444: Ich bin zunächst sehr froh darüber, dass nach Tagen des Rumbastelns endlich meine Anlage zuverlässig angesteuert werden kann. Wenn wir jetzt noch ein bisschen in die Tiefe bohren, bin ich allerdings jederzeit zu allem bereit. ;)


    Aber Achtung: Das Wort "Anfänger" unter meinem Namen ist wörtlich zu nehmen. ;)

  • Interessant ist noch der Hinweis, dass die Anlage zwar angepingt werden kann, z.B. auch vom Laptop, der ganz normal im WLAN hängt. Allerdings erscheint die Anlage nicht unter den verbundenen Geräten im Netzwerk in der FritzBox (Heimnetz > Netzwerk > Netzwerkverbindungen). Auch das ist für mich eigentlich ein Rätsel.

  • Allerdings erscheint die Anlage nicht unter den verbundenen Geräten im Netzwerk in der FritzBox (Heimnetz > Netzwerk > Netzwerkverbindungen).

    Hat die Anlage eine IP-Adresse aus dem DHCP-Pool der FritzBox, zugewiesen bekommen?

    Wird die Anlage gesehen, wenn Du einen arp-scan (oder gleichwertig) im Netzwerk (WLAN) der FritzBox machst?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Hat die Anlage eine IP-Adresse aus dem DHCP-Pool der FritzBox, zugewiesen bekommen?

    Nein, ich habe der Anlage auch mit 192.168.160.210 eine feste IP-Adresse zugewiesen.

    Wird die Anlage gesehen, wenn Du einen arp-scan (oder gleichwertig) im Netzwerk (WLAN) der FritzBox machst?

    Ergebnis:

    Code
    pi@flightpi:~ $ sudo arp-scan --interface=eth0 192.168.160.0/24
    Interface: eth0, datalink type: EN10MB (Ethernet)
    Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
    192.168.160.20  34:e6:d7:38:51:53       (Unknown)
    192.168.160.210 00:a0:de:a8:29:0f       YAMAHA CORPORATION
    
    5 packets received by filter, 0 packets dropped by kernel
    Ending arp-scan 1.9: 256 hosts scanned in 3.274 seconds (78.19 hosts/sec). 2 responded

    Die 192.168.160.210 ist die Anlage. Die 192.168.160.20 ist mein Laptop, von dem ich hier schreibe. Hintergrund: Ich habe am Pi einen Switch über LAN angeschlossen. Daher die beiden IP-Adressen. Aber ja, der arp-scan liefert die Anlage zurück. Außerdem interessant: Der Laptop 192.168.160.20 erscheint auch nicht in der FritzBox. Die 192.168.160.20 kommt übrigens über DHCP. Der Range, den die FritzBox übergibt, geht von 192.168.160.20...200. :conf:

    Einmal editiert, zuletzt von michael.wiesner (25. November 2019 um 22:46)

Jetzt mitmachen!

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