LAN-WLAN Brücke (bridge) unter Raspbian einrichten

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

    habe mich hier registriert, da ich alleine nicht mehr weiterkomme.

    Ich versuche meinen ethernet-only AV-Receiver (Yamaha RV-V675), mit Hilfe des Raspberry Pi 1 B+ und an dem angeschlossenen WiFi Adapter (EDIMAX EW-7612UAN V2), in das heimische WLAN-Netz zu integrieren.

    Es gibt im Internet zahlreich Anleitungen dazu, doch die meisten sind veraltet, verwechseln Wlan-Bridge mit einem Wlan Router oder Setzen auf Lösungen, welche zwar einen Internet-Zugang freischalten aber das Gerät eben nicht in das bestehende Netzwerk einbinden.

    Was ich ausschließen kann sind die Lösungen mit bridge-utils, da dazu (so wie ich es verstanden habe) eine spezielle Hardware verbaut werden muss, die das unterstützt. Ich kriege jedenfalls bei dem Befehl: "ifup br0" die Fehlermeldung: "can't add wlan0 to bridge br0: Operation not supported"

    Nach langer Suche bin ich dann auf die Seite von Framp's Linux Tipps und Tricks gestoßen, wo er die Brücke mit Hilfe eines ARP Proxies realisiert: https://www.linux-tips-and-tricks.de/de/raspberry/1…l-bruecke-bauen

    Die Anleitung hat auch wunderbar geklappt und ich kann meinen Receiver auch in der Fritzbox unter Netwerkverbindungen sehen, ich kann ihn auch anpingen und kann sogar die Weboberfläche im Browser aufrufen und Internetradio hören.

    Mein Problem ist, das die zugehörige Android-App von Yamaha den nicht finden kann. Die App funktioniert problemlos, wenn ich den Receiver, testweise mit einem Kabel verbinde.

    Framp hat mir empfohlen mit tcpdump zu beobachten, was an meinem wlan0 Interface ankommt, wenn ich die App auf dem Smartphone starte, das habe ich anschließend auch gemacht. Hier die Ausgabe:

    Code
    sudo tcpdump -i wlan0 host 192.168.178.52
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
    22:28:06.659735 IP android-7d142868885e1.fritz.box.42097 > 255.255.255.255.1900: UDP, length 129
    22:28:06.659773 IP android-7d142868885e1.fritz.box.42097 > 239.255.255.250.1900: UDP, length 129
    22:28:06.659800 IP android-7d142868885e1.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s)
    22:28:06.965565 IP android-7d142868885e1.fritz.box.42097 > 255.255.255.255.1900: UDP, length 129
    22:28:06.965605 IP android-7d142868885e1.fritz.box.42097 > 239.255.255.250.1900: UDP, length 129

    So wie er meint sucht die App beim Start nach dlna/upnp-Clients im Netzwerk. Was auch in meinen Augen Sinn ergibt, denn der Receiver fungiert auch als ein dlna/upnp-Clients.

    Desweiteren habe ich festgestellt, dass der umgekehrte Weg, (Receiver angeschlossen am TV und mit der Fernbedienung bedient) auch nicht funktioniert. Er findet meinen dlna/upnp-Server nicht. Betreibe meine Fritzbox als dlna/upnp-Server und kann von dort aus problemlos Musik und Videos an mein Smartphone und Fernseher streamen.

    Es sieht so aus als ob nur der Port 80, für die Internetverbindung und Onlineradio offen ist, alle anderen (insbesondere der für dlna wichtige 1900) geschlossen sind bzw. die Verbindung wird auf diesen Port nicht weitergeleitet.

    Um nun noch mehr Verwirrung zu stiften, habe ich die Ports von dem Receiver mit nmap abgescannt - hier die entsprechende Ausgabe:


    Ich bin verwirrt :conf:

    Ach ja vielleicht sollte ich erwähnen, dass mir der Receiver sagt (in seinem Einstellungsmenü), dass seine IP-Adresse die 192.168.178.35 ist - unter der ist er aber nicht in meinem Netzwerk zu erreichen, sondern eben nur unter der 192.168.178.37, die auch so in der Fritzbox angezeigt wird.

    Was ich noch gemacht habe:

    • Den Energiesparmodus der WLAN-Treiber zu deaktivieren. Laut der Anleitung aus der Debian-Wiki (https://wiki.debian.org/BridgeNetworkConnectionsProxyArp)
      kann der Energiesparmodus bei ARP-Proxies zu Problemen führen. Leider ohne Erfolg.
    • Fritzbox neu gestartet -> keine Änderungen
    • Downgegradet und versucht mit dem oben verlinkten Wiki-Artikel, ARP-Proxy unter Jessie einzurichten -> keine Änderungen.

    Bin nun mit meinem Latein am Ende und hoffe das jemand von euch mir helfen kann. Ich wäre Ihm/Ihr sehr dankbar dafür.

    Gruß

    Waldemar

    PS.: auf der Suche nach einer Lan-Wlan-Bridge bin ich auch über die Lösung mit Hilfe von etablets gestoßen: https://wiki.debian.org/BridgeNetworkConnections

    Leider war das zu hoch für mich, so dass ich damit nichts Anfangen konnte, aber vielleicht blickt da jemand von euch durch.

  • LAN-WLAN Brücke (bridge) unter Raspbian einrichten? Schau mal ob du hier fündig wirst!

  • Es sieht so aus als ob nur der Port 80, für die Internetverbindung und Onlineradio offen ist, alle anderen (insbesondere der für dlna wichtige 1900) geschlossen sind bzw. die Verbindung wird auf diesen Port nicht weitergeleitet.

    Um nun noch mehr Verwirrung zu stiften, habe ich die Ports von dem Receiver mit nmap abgescannt - hier die entsprechende Ausgabe:

    BTW: nmap zeigt (mit "open") ob auf den Ports gelauscht wird. Der tcp-scan den Du hier gepostet hast zeigt, dass auch auf dem TCP-Port 1900 (... und nicht nur auf dem TCP-Port 80) gelauscht wird. Wenn Du den UDP-Port 1900 meinst und diesen UDP-Port scannen willst, dann mit:

    Code
    sudo nmap -sU 192.168.178.37 -p1900

    EDIT:

    Wenn Du arp-scan installiert hast, dann poste mal die Ausgabe von:

    Code
    sudo arp-scan -I wlan0 -RN -l

    und auch die Ausgaben von:

    Code
    sysctl net.ipv4.ip_forward
    sudo iptables -nvx -L

    EDIT 2:

    BTW: Statt den Receiver, könntest Du einen 2. PI an der bridge anschließen/verbinden und testen/schauen ob auf dem 2. PI die upnp-multicast-Pakete ankommen.

    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

    3 Mal editiert, zuletzt von rpi444 (20. September 2018 um 23:05)

  • Hallo.

    Seitdem das mit den bridge-utils auf dem PI nicht mehr funktioniert ist es besser einen Router zu bauen statt einer Bridge.

    Dabei hat das LAN Interface ein anderes Subnet als das der FB. Auf dem WLAN eine statische IP und die Routingtables auf der FB anpassen.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Hallo Leute,

    danke für die herzliche Aufnahme hier im Forum.

    Vorbemerkung:

    Nachdem ich die Fritzbox neu gestartet habe, wurden die IP-Adressen neu vergeben. Der Receiver ist jetzt unter der IP 192.168.178.27 zu erreichen. Bitte nicht verwirren lassen.

    rpi444

    Danke für die Aufklärung bezüglich UDP und TCP-Port - für mich war bis jetzt immer ein offener Port ist ein offener Port ;)

    Nun zur Sache:

    Sieht schon mal gut - ahm ich meine schlecht aus ;)

    Die anderen Befehle bringen eigentlich nichts Aufregendes - zumindest für mich.



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


    Code
    sudo iptables -nvx -L
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
        pkts      bytes target     prot opt in     out     source               destination         
    
    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
        pkts      bytes target     prot opt in     out     source               destination         
    
    Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
        pkts      bytes target     prot opt in     out     source               destination         


    Der_Imperator

    Mir ist eigentlich egal ob der PI als Router oder als Bridge fungiert, solange ich meinen Receiver bequem per App bedienen kann (heißt ich muss nicht immer den Fernseher einschalten) und seine volle Funktionalität gewährleistet ist. Korrigiert mich bitte wenn ich falsch liege, aber für mein Verständnis spannt ein Router sein eigenes Subnetz auf und man hat keinen Zugriff von Außen auf die einzelne Geräte und das will ich eben vermeiden.


    @all

    Ich glaube wir können das Problem nun daran festmachen, dass der ARP Proxy die UDP Anfragen an dem Port 1900 nicht weiterleitet. Die Frage ist nun wie kann man den Port öffnen und kann man das überhaupt bei einem ARP Proxy?

    Gruß

    Waldemar

  • Code
    Host is up (0.048s latency).
    
    PORT     STATE  SERVICE
    1900/udp closed upnp
    MAC Address: 74:DA:38:59:BC:FE (Edimax Technology)
    
    Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds

    @all

    Ich glaube wir können das Problem nun daran festmachen, dass der ARP Proxy die UDP Anfragen an dem Port 1900 nicht weiterleitet. Die Frage ist nun wie kann man den Port öffnen und kann man das überhaupt bei einem ARP Proxy?

    Warum zeigt der arp-scan die IP-Adresse (und MAC-Adresse) 192.168.178.27 deines Receivers nicht an?

    Ich denke der Receiver wird den UDP-Port 1900 evtl. (automatisch) öffnen, sobald die upnp-multicast-Pakete ihn erreicht haben. Das scheint bis jetzt aber nicht der Fall zu sein.

    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

  • Keine Ahnung - aber er ist da - ich kann ihn anpingen

  • Keine Ahnung - aber er ist da - ich kann ihn anpingen

    Versuch mal ihn per arp-Protokoll zu erreichen:

    Code
    sudo apt-get install iputils-arping
    sudo arping -c 3 -I <interface-PI> -s <IP-Adresse-PI> <IP-Adresse-Receiver>

    (ohne spitze Klammern).

    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

  • Da geht nix

    Code
    pi@raspberrypi:~ $ sudo arping -c 3 -I wlan0 -s 192.168.178.26 192.168.178.27
    ARPING 192.168.178.27 from 192.168.178.26 wlan0
    Sent 3 probes (3 broadcast(s))
    Received 0 response(s)

    D. h. wenn schon das arp-broadcast nicht bis zum Receiver geht, dann wird m. E. das upnp-multicast auch nicht bei deinem Receiver ankommen.

    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

  • Zitat von rpi444

    D. h. wenn schon das arp-broadcast nicht bis zum Receiver geht, dann wird m. E. das upnp-multicast auch nicht bei deinem Receiver ankommen.

    Waldemar hat auf der WLAN Seite folgendes empfangen. Sind das nicht die upnp multicasts?

    Zitat von Waldemar
    22:28:06.659735 IP android-7d142868885e1.fritz.box.42097 > 255.255.255.255.1900: UDP, length 129 22:28:06.659773 IP android-7d142868885e1.fritz.box.42097 > 239.255.255.250.1900: UDP, length 129 22:28:06.659800 IP android-7d142868885e1.fritz.box > igmp.mcast.net: igmp v3 report, 1 group record(s) 22:28:06.965565 IP android-7d142868885e1.fritz.box.42097 > 255.255.255.255.1900: UDP, length 129 22:28:06.965605 IP android-7d142868885e1.fritz.box.42097 > 239.255.255.250.1900: UDP, length 129
    Zitat von Waldemar

    Korrigiert mich bitte wenn ich falsch liege, aber für mein Verständnis spannt ein Router sein eigenes Subnetz auf und man hat keinen Zugriff von Außen auf die einzelne Geräte und das will ich eben vermeiden.

    Sofern wie schon beschrieben statische IPs benutzt werden und statischen Routen dahin im Router definiert werden gibt das kein Problem. Broadcasts werden da nicht weitergeleitet. Das koennte vielleicht fuer upnp ein Problem sein :denker:

  • Waldemar hat auf der WLAN Seite folgendes empfangen. Sind das nicht die upnp multicasts?

    Das sind schon upnp-multicasts, die auf der WLAN-Seite des PI ankommen aber anscheinend erreichen diese nicht den Receiver.

    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

  • Ich hatte mal ein ähnliches Problem an einer SonicWall mit einem Sonos System.

    Die Sonos App kommuniziert per Multicast Nachrichten mit den Lautsprechern. Bei der SonicWall ist es nun so, dass das eingebaute WLAN in einer anderen Zone ist als das LAN (ähnlich wie beim TO).

    Man muss also auf der Firewall Multicast explizit erlauben (inklusive Angabe der erlaubten Multicast-Adressen) und dies für jede Zone separat freischalten.

    Vermutlich musst du das auch bei dir aktivieren. Wie das aber auf dem Pi geht.... keine Ahnung....

    Grüsse

    Peter

    Kleiner Nachtrag, da es mich wundergenommen hat:

    Evtl. hilft dir eine Route für Multicast

    Code
    route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

    Quelle: http://developerweb.net/viewtopic.php?id=6750

    Einmal editiert, zuletzt von someone (21. September 2018 um 19:27)

  • ... dass das eingebaute WLAN in einer anderen Zone ist als das LAN (ähnlich wie beim TO).

    Ist das beim arp-proxy auch der Fall?

    Er könnte auch mit:

    Code
    sudo tcpdump -vvveni eth0 multicast

    und parallel mit:

    Code
    sudo tcpdump -vvveni wlan0 multicast

    auf seinem PI schauen.

    Auch wenn am eth0-Interface die multicast-Pakete gesehen werden, heißt das m. E. nicht, dass diese auch den Receiver erreichen.

    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

  • So Leute,

    habe jetzt mal die Vorschläge abgearbeitet - bis jetzt noch ohne Erfolg.

    Code
    route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

    Quelle: http://developerweb.net/viewtopic.php?id=6750

    brachte leider keine Besserung.

    Hier noch die tcpdump Ausgaben nach dem ich das Kommando ausgeführt hatte.



    Beim wlan0 Interface kommt was an IP vom Handy ist 192.168.178.24

    Beim eth0 sieht man nur die Fritzbox mit der Mac-Adresse b8:27:eb:ff:62:9b


    Apropos Sonos - habe hier ein Thread gefunden wo ebenfalls versucht wird Broadcast Pakete an mehrere Interfaces zu verteilen:

    https://community.ubnt.com/t5/EdgeRouter/…1259616/page/11

    Die benutzen dort ein Tool namens: "udp-bcast-rellay"

    Leider konnte ich in den Paketquellen nichts derartiges finden. Was ich gefunden habe, ist ein fünf Jahre altes Git-Repo mit einem Tool namens: "udp-broadcast-relay" https://github.com/nomeata/udp-broadcast-relay. Der Syntax nach scheint es aber das Gleiche zu sein.

    Versuche es mal zu kompilieren, wobei ich da sehr skeptisch bin:

    Zitat
    • I run debian woody with Linux 2.4.20, and here it works.

    ;)

    Einmal editiert, zuletzt von Waldemar (21. September 2018 um 22:33) aus folgendem Grund: Link zu "udp-broadcast-relay" Git-Repo hinzugefügt.

  • Die gute Nachricht ist ich konnte es kompilieren. Die schlechte:

    Code
    pi@raspberrypi:~/build/udp-broadcast-relay $ sudo ./udp-broadcast-relay 1 1900 wlan0 eth0
    bind: Address already in use
    A program is already bound to the broadcast address for the given port

    Hm komisch - mit jedem anderen Port hat udp-broadcast-relay keine Probleme, nur mit dem Port 1900 gibt es die Meldung: "bind: Address already in use

    A program is already bound to the broadcast address for the given port". Die Meldung kriege ich auch nach einem Neustart.

    Also scheint er doch irgendwie belegt zu sein :conf:


    Hier noch meine Routingtabelle nachdem ich den Befehl:

    Code
    sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

    ausgeführt habe.

    2 Mal editiert, zuletzt von Waldemar (21. September 2018 um 22:38)

  • Da geht nix

    Code
    pi@raspberrypi:~ $ sudo arping -c 3 -I wlan0 -s 192.168.178.26 192.168.178.27
    ARPING 192.168.178.27 from 192.168.178.26 wlan0
    Sent 3 probes (3 broadcast(s))
    Received 0 response(s)

    Versuch mal mit konfiguriertem arp_filter in der "/etc/sysctl.conf"-Datei:

    Code
    net.ipv4.conf.all.arp_filter = 1
    net.ipv4.conf.default.arp_filter = 1
    net.ipv4.conf.eth0.arp_filter = 1
    net.ipv4.conf.wlan0.arp_filter = 1

    danach:

    Code
    sudo sysctl -p

    ausführen. Jetzt erneut den arping mit dem eth0-Interface ausführen:

    Code
    sudo arping -c 3 -I eth0 -s 192.168.178.26 192.168.178.27

    und

    Code
    sudo arping -c 3 -I wlan0 -s 192.168.178.26 192.168.178.27

    Die IP-Adressen evtl. anpassen, falls nicht mehr aktuell (hier .27 für Receiver und .26 für wlan0/eth0).

    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

  • So, neuer Tag, alte Probleme :)

    Bei wlan0 Interface tut sich immer noch nichts

    Code
    pi@raspberrypi:~ $ sudo arping -c 3 -I wlan0 -s 192.168.178.26 192.168.178.27
    ARPING 192.168.178.27 from 192.168.178.26 wlan0
    Sent 3 probes (3 broadcast(s))
    Received 0 response(s)

    Dafür aber bei eth0

    Code
    pi@raspberrypi:~ $ sudo arping -c 3 -I eth0 -s 169.254.114.18 192.168.178.27
    ARPING 192.168.178.27 from 169.254.114.18 eth0
    Unicast reply from 192.168.178.27 [00:A0:DE:A4:35:8B]  2.540ms
    Unicast reply from 192.168.178.27 [00:A0:DE:A4:35:8B]  1.927ms
    Unicast reply from 192.168.178.27 [00:A0:DE:A4:35:8B]  0.951ms
    Sent 3 probes (1 broadcast(s))
    Received 3 response(s)

    habe aber keine Ahnung ob das schon vorher so wahr, also ohne die Einträge in die "/etc/sysctl.conf"-Datei.

    Dabei fällt mir auf, das die IP-Adresse von eth0 irgendwo hinter ferner liefen ist.

    framp

    Die Zeile in deiner Anleitung:

    Code
     post-up /sbin/ip addr add $(ip addr show wlan0 | grep -Eo "^\s+inet [^ ]+ " | sed -E 's/^\s+//' | cut -f 2 -d ' ' | cut -f 1 -d/)/32 dev eth0

    sollte doch dafür sorgen, dass die IP-Adresse von eth0, die Gleiche ist wie die von wlan0 - oder verstehe ich das falsch?

    Bzw. so steht sie auch in der Debian-Wiki: https://wiki.debian.org/BridgeNetworkConnectionsProxyArp

    Zitat
    Code
    # clone the dhcp-allocated IP to eth0 so dhcp-helper will relay for the correct subnet  
    post-up /sbin/ip addr add $(/sbin/ip addr show wlan0 | perl -wne 'm|^\s+inet (.*)/| && print $1')/32 dev eth0

    Hier vielleicht zur Info, die aktuelle Netzwerkkonfiguration

    3 Mal editiert, zuletzt von Waldemar (22. September 2018 um 12:05)

Jetzt mitmachen!

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