Verbindung ins LAN nicht möglich

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

    ich verwende den RBp+ (Raspian) mit anderen Rechnern (Linux und Macs) und einem Router auf dem ein DHCP-Server läuft, in meinem Netzwerk. Das am RBp+ angeschlossene Netzwerkkabel funktioniert, ich habe es ausprobiert. Mein Router zeigt mir auch nur altbekannte Clients, aber keine an den RaspberryPi vergebene ip. Eine Verbindung kommt also nicht zustande:

    ifconfig zeigt keine ip für eth0 an. Die Schnittstelle ist physikalisch aber aktiv (grün blinkt und gelb daueran).
    Ein ping 192.168.1.1 zu meinem Router, wie auch ein ping zu meinem Laptop gibt als Ausgabe:

    Code
    connect: Network is unreachable

    ping localhost hingegen funktioniert und cat/proc/net/dev zeigt mir auch, das ein Treiber für eth0 geladen ist.

    In der resolv.conf stand direkt nach dem Start von Raspbian nameserver 8.8.8.8 drin, das habe ich mit der ip meines Routers überschrieben und das netzwerk neu gestartet mit:

    sudo /etc/init.d/networking restart

    Dabei habe ich u.a. folgende Meldungen erhalten:

    [warn] Running /etc/init.d/networking restart is deprecated because it may not re-enable some interfaces ... (warning). (*)

    Listening on LPF/eth0/MAC-Adresse
    Sending on LPF/eth0/MAC-Adresse
    Sending on Socket/fallback

    Auch nach einem kompletten Neustart bleibt der Effekt gleich: Keine Verbindung zum Netzwerk. Der Versuch über sudo dhclient eth0 die Zuweisung einer ip manuell zu erzwingen funktioniert nicht. Das der DHCP Client läuft habe ich mit dhclient -4 -vd eth0 überprüft.

    In meiner Datei interfaces steht (was doch eigentlich richtig sein müsste, oder?):


    Trotz der Nutzung meiner alten Linux-Literatur, meinem schönen neuen Buch "Hannahs 25 neue Server" und dem Forum hier komme ich langsam nicht weiter - also habe ich mir noch das Hilfsscript runtergeladen und auf meinen RBp+ laufenlassen (s.u.).

    Spoiler anzeigen

    Meine Vermutung ist nun: Es liegt an der Warnung (siehe oben das rote Sternchen in Klammern) oder an der Meldung RNIO11E "Es ist kein Standardgateway definiert"

    Wo wird das Standardgateway definiert? In der Datei /etc/network/interfaces oder in der Datei /etc/networks? Oder liegt der Fehler ganz woanders? Ein Tipp wäre toll.:danke_ATDE:

    Grüße
    Clint


  • Meine Vermutung ist nun: Es liegt an der Warnung (siehe oben das rote Sternchen in Klammern) ...

    Versuch mal mit:

    Code
    sudo service networking restart


    und siehe danach die Ausgabe von:

    Code
    sudo cat /var/log/syslog | grep -i dhc | tail -n 25

    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

  • Code
    sudo cat /var/log/syslog | grep -i dhc | tail -n 25

    Nur mal eine Anmerkung dazu. :D

    schneller wäre:

    Code
    grep -i dhc /var/log/syslog | tail -n 25

    Ist auch Ressourcen sparender und macht keine weitere Subshell auf ;)

    neben den dhclient könnte man auch mal folgendes versuchen:

    Code
    sudo ip addr add 192.168.1.250/24 dev eth0
    sudo ip route add default via 192.168.1.1 dev eth0 
    ip a s dev eth0
    ip r s 
    ping -c 3 -w 1 192.168.1.1

    Wenn das klappt dann schafft der PI die config nicht.

    Und jetzt noch eben aufräumen:

    Code
    sudo ip addr del 192.168.1.250/24 dev eth0
    sudo ip route del default
  • Hallo ruedigerp,

    okay also einmal [font="Courier"]sudo /sbin/dhclient[/font] ausgeführt. Anschließend habe ich mit [font="Courier"]sudo /etc/init.d/networking restart[/font] den Netzwerkkram neu gestartet und folgende Meldung erhalten:

    [warn] Running /etc/init.d/networking restart is deprecated becauseit may not re-enable some interfaces ... (warning).
    [ok] Reconfiguring network interfaces...done.

    Das hat was gebracht. Die [warn] - Meldung ist zwar immer noch da, aber die Meldung
    [font="Courier"][....] Reconfiguring network interfaces...Internet Systems Consortium DHCP Client 4.2.2[/font]

    ist nun durch die [ ok ] - Meldung ersetzt und der Meldungsblock mit [font="Courier"]Sending on Socket/fallback[/font] erscheint garnicht mehr.

    Wenn [font="Courier"]sudo /sbin/dhclient[/font] notwendig ist, müsste der Befehl dann nicht bei jedem Start automatisert ausgeführt werden?

    Allerdings ergibt [font="Courier"]ifconfig[/font] immer noch keine ip für eth0. Ping nach draußen geht weiterhin nicht ([font="Courier"]connect: Network is unreachable[/font])

    Könnte es noch nötig sein den Standardgateway irgendwo einzutragen

    Güße
    Clint


  • Könnte es noch nötig sein den Standardgateway irgendwo einzutragen

    Nein, braucht man nicht, denn der dhclient sendet dhcpdiscover/-request per broadcast an 255.255.255.255 port 67.

    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

  • Wenn du erst dhclient aufrufst und danach dann noch mal das Netzwerk neustartetest ist das nicht gut.
    Richtig wäre network restart dann dhclient, wenn Du es schon manuell aufrufst.

    Noch richtiger wäre: Es kommt alles nach dem starten des PI von alleine hoch und funktioniert ;)

    Wenn Dein Router alles richtig macht, dann musst du nichts mehr setzten. Der router gibt ihm IP, Netzmaske, Router usw. alles wenn er anfragt.

    Kannst Du Deine Interface Config in /etc/network/interfaces mal anpassen und dem eth0 noch ein Hotplug mitgeben?

    Dann kannst Du mal das Netzwerkkabel ziehen und wieder reinstecken, dann sollte der PI das mitbekommen und alles was er für die Config braucht selbst antriggern, wenn er das erkennt.

  • Hallo zusammen,

    also, ich habs probiert. Der Befehl [font="Courier"]sudo service networking restart[/font] hat zu keiner Änderung geführt. Die Suche im Logfile (siehe Spoiler) hat mich auf etwas aufmerksam gemacht: Da steht u.a. [font="Courier"]No DHCPOFFERS received[/font]. Ein Hinweis auf externe Probleme? Alle anderen Rechner haben ja ihre dyn ip vom DHCP Server auf dem Router.

    Jetzt der Satz halbkryptischer Befehlssequenzen: Ausgeführt. Jetzt ist der eth0 die ip 192.168.1.250 zugewiesen, sagt [font="Courier"]if config[/font]. Und der Pingbefehl gibt jetzt nicht mehr network unreachable sondern:

    [font="Courier"]PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
    ... 192.168.1.1 ping statistics ...
    1 packets transmitted, 0 received, 100% packet loss, time 0m[/font]s

    Mein Server meldet trotzdem keine weitere vergebene Ip auch die *.250 ist nicht vergeben.

    So jetzt uss ich noch den Aufräumblock ausführen...

    Gruß
    Clint

    Spoiler anzeigen


    pi@raspberrypi ~ $ sudo cat /var/log/syslog | grep -i dhc | tail -n 25
    Jun 20 14:48:09 raspberrypi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
    Jun 20 14:48:21 raspberrypi dhclient: No DHCPOFFERS received.
    Jun 20 14:48:21 raspberrypi dhclient: No working leases in persistent database - sleeping.
    Jun 20 14:52:30 raspberrypi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
    Jun 20 14:52:35 raspberrypi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
    Jun 20 14:52:42 raspberrypi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
    Jun 20 14:52:50 raspberrypi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
    Jun 20 14:53:01 raspberrypi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 20
    Jun 20 14:53:21 raspberrypi dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
    Jun 20 14:53:31 raspberrypi dhclient: No DHCPOFFERS received.
    Jun 20 14:53:31 raspberrypi dhclient: No working leases in persistent database - sleeping.
    Jun 20 14:56:44 raspberrypi dhclient: Internet Systems Consortium DHCP Client 4.2.2
    Jun 20 14:56:44 raspberrypi dhclient: Copyright 2004-2011 Internet Systems Consortium.
    Jun 20 14:56:44 raspberrypi dhclient: All rights reserved.
    Jun 20 14:56:44 raspberrypi dhclient: For info, please visit https://www.isc.org/software/dhcp/
    Jun 20 14:56:44 raspberrypi dhclient:
    Jun 20 14:56:44 raspberrypi dhclient: Listening on LPF/eth0/b8:27:eb:a8:a0:68
    Jun 20 14:56:44 raspberrypi dhclient: Sending on LPF/eth0/b8:27:eb:a8:a0:68
    Jun 20 14:56:44 raspberrypi dhclient: Sending on Socket/fallback
    Jun 20 15:30:26 raspberrypi dhclient: No broadcast interfaces found - exiting.
    Jun 20 15:34:07 raspberrypi dhclient: Internet Systems Consortium DHCP Client 4.2.2
    Jun 20 15:34:07 raspberrypi dhclient: Copyright 2004-2011 Internet Systems Consortium.
    Jun 20 15:34:07 raspberrypi dhclient: All rights reserved.
    Jun 20 15:34:07 raspberrypi dhclient: For info, please visit https://www.isc.org/software/dhcp/
    Jun 20 15:34:07 raspberrypi dhclient: Usage: dhclient [-4|-6] [-SNTP1dvrx] [-nw] [-p <port>] [-D LL|LLT]#012 [-s server-addr] [-cf config-file] [-lf lease-file]#012 [-pf pid-file] [--no-pid] [-e VAR=val]#012 [-sf script-file] [interface]
    pi@raspberrypi ~ $

  • Code
    Jun 20 15:34:07 raspberrypi dhclient: Internet Systems Consortium DHCP Client 4.2.2
    Jun 20 15:34:07 raspberrypi dhclient: Copyright 2004-2011 Internet Systems Consortium.
    Jun 20 15:34:07 raspberrypi dhclient: All rights reserved.
    Jun 20 15:34:07 raspberrypi dhclient: For info, please visit https://www.isc.org/software/dhcp/

    Ist das die aktuelle Ausgabe von? Wie sind auf deinem PI, die Ausgaben von:

    Code
    date


    und

    Code
    sudo dhclient -4 -vd eth0


    ?

    EDIT:

    Evtl. auch die Kabelverbindung zwischen PI und Router, prüfen.

    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

    Einmal editiert, zuletzt von rpi444 (4. Dezember 2014 um 22:53)

  • Hallo zusammen,

    so jetzt nach dem Aufräumen erhalte ich nach einem neustart der Netzwerkdienste (in der richtigen Reihenfolge) mehrfach

    [font="Courier"]DHCPDICOVER on eth0 to 255.255.255.255 port 67 interval x
    NO DHCPOFFERS received
    No working leases in persistent database - sleeping
    done.[/font]

    Die Zeile mit dem roten x taucht gleich mehrfach auf und das x steht für verschiedene Intevallziffern Aber auch hier wieder NO DHCPOFFERS RECEIVED. Für mich sieht das so aus als würde der RBp+ nach einer ip anfragen und dann irgendwann aufgeben weil mein Router im keine OFFER sendet. :-/ Warum auch immer?

    Könnte das der Punkt sein?

    Ähm ja, ich habe meine Systemzeit noch nicht eingestellt, das wollte ich über einen Zeitserver aus dem I-Net machen...

    Und [font="Courier"]sudo dhclient -4 -vd eth0[/font]
    liefert:

    Code
    Internet Systems Consortium DHCP Client 4.2.2
    Copyright 2004-2011 Internet Systems Consortium.
    All rights reserved.
    For info... [i](Anm.: blabla...)[/i]

    Grüße
    Clint


  • Und [font="Courier"]sudo dhclient -4 -vd eth0[/font]
    liefert:

    Code
    Internet Systems Consortium DHCP Client 4.2.2
    Copyright 2004-2011 Internet Systems Consortium.
    All rights reserved.
    For info... [i](Anm.: blabla...)[/i]

    Ich denke nicht, dass das (s. o.) die Ausgabe von "sudo dhclient -4 -vd eth0" ist.

    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,

    also sudo dhclient -4 -vd eth0 liefert tatsächlich:

    pi@raspberrypi ~ $ sudo dhclient -4 -vd eth0
    Internet Systems Consortium DHCP Client 4.2.2
    Copyright 2004-2011 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/
    Usage: dhclient [-4|-6] [-SNTP1dvrx] [-nw] [-p <port>] [-D LL|LLT]
    [-s server-addr] [-cf config-file] [-lf lease-file]
    [-pf pid-file] [--no-pid] [-e VAR=val]
    [-sf script-file] [interface]
    pi@raspberrypi ~ $

    Was sollte den dort normalerweise erscheinen? Inzwischen glaube ich auch, dass irgendetwas zwischen DHCP Client und DHCP Server nicht passt.

    Ich habe ebend aus lauter Verzweiflung mal das WLAN-Zäpfchen in RBp+ reingesteckt und schnell den WiFI-Zugang zu meinem Router eingestellt - ich bin drin. Jetzt lasse ich gleich nochmal das Netzwerkscript hier aus dem Forum laufen und poste eine vollständige Ausgabe. Ziel ist immer noch eth0 in Betrieb zu kriegen...

    P.S.: Das Netzwerkkabel habe ich (nochmal) geprüft. Mein Laptop zum Schreiben ins Forum hängt jetzt dran. Das Kabel funktioniert also...

    Grüße
    Clint


  • also sudo dhclient -4 -vd eth0 liefert tatsächlich:

    Code
    pi@raspberrypi ~ $ sudo dhclient -4 -vd eth0
    Internet Systems Consortium DHCP Client 4.2.2
    Copyright 2004-2011 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/
    Usage: dhclient [-4|-6] [-SNTP1dvrx] [-nw] [-p <port>] [-D LL|LLT]
                    [-s server-addr] [-cf config-file] [-lf lease-file]
                    [-pf pid-file] [--no-pid] [-e VAR=val]
                    [-sf script-file] [interface]

    Dann versuch mal mit:

    Code
    sudo service networking stop
    sudo dhclient -4 -d -v eth0

    Siehe auch die manpage für dhclient, auf deinem PI.

    Code
    man dhclient

    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

    Einmal editiert, zuletzt von rpi444 (5. Dezember 2014 um 08:56)

  • Hallo Leute,

    aktuell sieht es so aus: eth0 funktioniert nicht, garnicht (bis auf die LEDs...)! wlan0 funktioniert. Hotplug bei wlan0 auch. Für wlan organisiert er dhclient auch eine ip. Und ich kann über mein LAN auf den RBp+ zugreifen, z.b. via ssh von einer Konsole auf meinem Laptop. Internet geht auch.

    Also ist mein dhclient grundsätzlich in der Lage sich eine ip zu holen, die Netzwerkkonfiguration soweit okay.

    Nochmal das LAN-Kabel gegen ein anderes geprüftes Kabel ausgetauscht: Keine Veränderung eth0 ist tot. :(

    @ rpi444
    bin deinen Hinweisen nachgegangen. In der man page steht ja der grundlegende Ablauf beschrieben wie der client sich seine Informationen holt - also habe ich mir auch mal die dhclient.conf durchgelesen - und einfach mal mit der auf meinem Laptop verglichen.

    In der dhclient.conf vom Laptop steht: [font="Courier"]send host-name "<hostname>";[/font]
    In der dhclient.conf vom RBp+ steht: [font="Courier"]send host-name = gethostname(); [/font]

    Evtl. hat das einen Einfluss wobei es ja mit wlan0 funktioniert. Nach allem was ich jetzt sonst noch probiert habe, einschließlich eines upgrades aller Pakete auf meinen RBp+
    Und der installation eines weiteren Raspbian (falls im ersten irgendetwas nicht okay ist) auf einer zweiten Mikro-SD-Karte (gleicher Effekt: wlan0 funktioniert, eth0 nicht) muss ich zu dem Schluß kommen, das die Steckbüchse eth0 zwar die LEDs blinken lassen kann, mehr aber auch nicht. Hardwaredefekt des Steckkontaktes.
    Dafür spricht auch nochmal das Verhalten von dhclient bei nicht eingesteckten LAN-Kabel. Es ist identisch mit eingestecktem LAN-Kabel.

    Also mein Fazit: eth0 läßt sich nicht aktivieren. Ich muss, zähneknirschend, wlan0 nutzen. Vielleicht findet sich ja die Lösung bei der weiteren Arbeit zu meinem Projekt von selbst. =(

    Allen hier vorerst vielen Dank für eure Tipps und Hilfen (habe einiges gelernt) :danke_ATDE:

    Grüße
    Clint


  • ... eth0 ist tot. :(

    Wie war die Ausgabe von:

    Code
    sudo dhclient -4 -d -v eth0


    nach dem:

    Code
    sudo service networking stop


    und ohne WLAN-Stick in deinem PI?

    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

  • Man eben eine ganz bescheidene Frage:

    Code
    dpkg -l | grep network-manager

    liefert das etwas network-manager zurück? Wenn ja schmeiss den scheiß runter und benutze Dein Netzwerk.

    Kannst Du mal nach dem restart vom Netzwerk folgende Ausgabe von ip hier rein schreiben, damit wir mal sehen wie es nach dem starten aussieht.

    Code
    ip a
    ip r s
    iptables -n -v -L

    Dein Router: 192.168.1.1
    Dein PI eth0 z.B.: 192.168.1.250
    Pi WLAN: 192.168.1.12
    Anderer Rechner im Netz: 192.168.1.10
    Wenn vorhanden noch ein anderer Rechner: 192.168.1.11

    Du verbindest Dich ja per WLAN von der 192.168.1.10 auf den PI über WLAN 192.168.1.12. Wenn Du einen weiteren Rechner hast z.B. 192.168.1.11, dann setze mal eine Route zu diesem Rechner explizit über eth0

    Code
    sudo ip route add 192.168.1.11 via 192.168.1.250 dev eth0

    Jetzt setzt Du mal ein tcpdump auf eth0 an:

    Code
    tcpdump -vvvv -en -i any proto ICMP | tee netzdump.log &

    Das "&" am Ende schiebt tcpdump in den Hintergrund. Wenn Du tcpdump nachher beenden willst einfach den Befehl fg eintippen und dann tcpdump mit strg+c abbrechen. Das Tee pumpt das ganz auch noch ins logfite netzdump.log, so das man sich das später auch noch angucken kann.

    Wenn Du jetzt einen Ping auf andere Rechner im Netz machst solltest Du den sehen. Jetzt der Reihe nach:

    Code
    ping -c 3 -w 1 192.168.1.1 
    ping -c 3 -w 1 192.168.1.10
    ping -c 3 -w 1 192.168.1.11

    Jetzt wie schon beschrieben fg eingeben und strg+c drücken, damit der tcpdump wieder abgebrochen wird.

    Bei jedem ping solltest Du den Request und darauf dann eine Antwort (Reply) sehen:

    Code
    11:26:54.965164 Out c2:7c:78:a6:85:08 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
        172.18.5.1 > 172.18.5.17: ICMP echo request, id 15477, seq 1, length 64
    11:26:54.996416  In e2:6b:e0:fe:4f:f2 ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 64, id 24709, offset 0, flags [none], proto ICMP (1), length 84)
        172.18.5.17 > 172.18.5.1: ICMP echo reply, id 15477, seq 1, length 64

    Wenn das Ziel nicht erreichbar ist:

    Code
    11:31:26.972543  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 128: (tos 0xc0, ttl 64, id 27636, offset 0, flags [none], proto ICMP (1), length 112)
        172.18.5.1 > 172.18.5.1: ICMP host 172.18.5.100 unreachable, length 92
    	(tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
        172.18.5.1 > 172.18.5.100: ICMP echo request, id 15682, seq 25, length 64
    11:31:26.972558  In 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 128: (tos 0xc0, ttl 64, id 27637, offset 0, flags [none], proto ICMP (1), length 112)
        172.18.5.1 > 172.18.5.1: ICMP host 172.18.5.100 unreachable, length 92
    	(tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
        172.18.5.1 > 172.18.5.100: ICMP echo request, id 15682, seq 26, length 64

    Man sieht also keinen Request.

  • Hallo ruedigerp,

    Ich habe die AUfgabe gleich zweimal ausgeführt um mal Vergleiche zwischen "es geht nicht mit eth0" und "es funktioniert mit wlan0" ziehen zu können.

    eth0 (ohne wlanstick):

    Spoiler anzeigen


    pi@raspberrypi ~ $ sudo service networking stop
    [....] Deconfiguring network interfaces...Internet Systems Consortium DHCP Client 4.2.2
    Copyright 2004-2011 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/

    Listening on LPF/eth0/b8:27:eb:a8:a0:68
    Sending on LPF/eth0/b8:27:eb:a8:a0:68
    Sending on Socket/fallback
    done.
    pi@raspberrypi ~ $ sudo dhclient -4 -d -v eth0
    Internet Systems Consortium DHCP Client 4.2.2
    Copyright 2004-2011 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/

    Listening on LPF/eth0/b8:27:eb:a8:a0:68
    Sending on LPF/eth0/b8:27:eb:a8:a0:68
    Sending on Socket/fallback
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
    No DHCPOFFERS received.
    No working leases in persistent database - sleeping.

    mit wlan0 (ohne Netzwerkkabel an eth0)

    Spoiler anzeigen


    pi@raspberrypi ~ $ sudo service networking stop
    [....] Deconfiguring network interfaces...Internet Systems Consortium DHCP Client 4.2.2
    Copyright 2004-2011 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/

    Listening on LPF/wlan0/00:13:ef:50:0f:99
    Sending on LPF/wlan0/00:13:ef:50:0f:99
    Sending on Socket/fallback
    DHCPRELEASE on wlan0 to 192.168.1.1 port 67
    done.
    pi@raspberrypi ~ $ sudo dhclient -4 -d -v wlan0
    Internet Systems Consortium DHCP Client 4.2.2
    Copyright 2004-2011 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/

    Listening on LPF/wlan0/00:13:ef:50:0f:99
    Sending on LPF/wlan0/00:13:ef:50:0f:99
    Sending on Socket/fallback
    DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
    DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
    DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
    DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 20
    DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
    No DHCPOFFERS received.
    No working leases in persistent database - sleeping.

    Ein Unterschied ist sichtbar beim Stoppen der Netzwerkdienste: Beim Stoppen mit wlan0 wird die von DHCP-Server (auf meinem Router 192.168.1.102) erhaltene Release angezeigt.

    Die weiteren komplizierteren Fragestellen muss ich jetzt noch abarbeiten, das braucht eine kleine Weile. :denker:
    Immerhin konnte ich nebenbei schon Sitzungen mit SSH, SFTP und VNC einrichten... es geht also halbwegs voran.

    Grüße
    Clint


  • Ein Unterschied ist sichtbar ...

    Poste mal auch die Ausgabe von:

    Code
    sudo ethtool eth0


    Evtl. musst Du ethtool noch installieren:

    Code
    which ethtool
    Code
    sudo apt-get install ethtool

    EDIT:

    Das wlan-Interface hat lt. der Ausgabe von "sudo dhclient -4 -d -v wlan0", auch keine IP-Adresse vom DHCP-Server des Routers, zugewiesen bekommen (... siehe 2. Spoiler in deinem Beitrag oben). Schau mal im syslog/dmesg nach, auf welche Art und Weise das wlan-Interface die IP-Adresse bekommt (wenn es wie lt. deiner Ausage mit dem wlan0 funktioniert):

    Code
    sudo cat /var/log/syslog | grep -iE 'dhc|wlan'
    Code
    dmesg -T | grep -iE 'dhc|wlan'

    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

    Einmal editiert, zuletzt von rpi444 (6. Dezember 2014 um 13:38)

  • Hallo zusammen,

    hier also nochmal meine Hausaufgaben ;)

    Nochmal zu meiner Netzkonfiguration:
    Router (mit DHCP): 192.168.1.1
    Laptop (wlan0): 192.168.1.103
    RBp+ (wlan0): 192.168.1.102
    Mac (eth0): 192.168.1.104

    Ne, der Paketmanager dpkg findet nichts zum Thema network-manager, ist also kein Paket zum entfernen vorhanden und somit auch kein "manager" der mir in die Konfiguration funkt.

    Welche Schnittstellen finde ich mit[font="Courier"] ip a [/font]direkt nach dem Start (spoiler). Die erste Ausgabe ist wieder ohne Netzkabel an eth0 aber mit wlan0, die zweite Ausgabe Netzwerkkabel drin in eth0 und wlan0 deaktiviert:

    Spoiler anzeigen


    pi@raspberrypi ~ $ ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether b8:27:eb:a8:a0:68 brd ff:ff:ff:ff:ff:ff
    4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:13:ef:50:0f:99 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.102/24 brd 192.168.1.255 scope global wlan0
    valid_lft forever preferred_lft forever
    pi@raspberrypi ~ $ ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether b8:27:eb:a8:a0:68 brd ff:ff:ff:ff:ff:ff
    4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 00:13:ef:50:0f:99 brd ff:ff:ff:ff:ff:ff

    Interessant: Bei der zweiten Ausgabe (mit Netzwerkkabel in eth0) ist die Meldung N[font="Courier"]O-CARRIER [/font]nicht mehr da!
    Was ist dem raspberry außer den ips bekannt, wenn wlan0 an ist:

    Code
    pi@raspberrypi ~ $ ip r s
    default via 192.168.1.1 dev wlan0 
    192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.102



    Ohne wlan0 kommt mit[font="Courier"] ip r s[/font] nichts.

    Nun zu den[font="Courier"] iptables[/font] (als root aufgerufen):

    Finde ich erstmal unverdächtig. Habe auf meinem Laptop auch mal die iptables aufgerufen, und das sieht genauso aus. Es gibt bei der Ausgabe auch keinen Unterschied ob das Netzwerkabel in eth0 steckt oder nicht.

    Was sagt nun das [font="Courier"]ethtool[/font] aus:

    Spoiler anzeigen


    pi@raspberrypi ~ $ sudo ethtool eth0
    Settings for eth0:
    Supported ports: [ TP MII ]
    Supported link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes: 10baseT/Half 10baseT/Full
    100baseT/Half 100baseT/Full
    Advertised pause frame use: Symmetric Receive-only
    Advertised auto-negotiation: Yes
    Speed: 10Mb/s
    Duplex: Half
    Port: MII
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: pumbag
    Wake-on: d
    Current message level: 0x00000007 (7)
    drv probe link
    Link detected: no


    Mich wundert, das bei Speed 10Mb/s steht?! Allerdings steht das so auch bei meinem laptop, wenn ich da ethtool laufen lasse. Wesentlicher Unterschied ist beim Laptop steht wake-on: g und beim RBp+ steht wake-on: d?

    Habe mal gegoogelt (Quelle: http://www.thomas-krenn.com/de/wiki/Wake_on_LAN_unter_Linux). Wake-on: d bedeutet => Disable (wake on nothing).
    p Wake on phy activity
    u Wake on unicast messages
    m Wake on multicast messages
    b Wake on broadcast messages
    a Wake on ARP
    g Wake on MagicPacket(tm)
    s Enable SecureOn(tm) password for MagicPacket(tm)
    d Disable (wake on nothing). This option clears all previous options.

    Also habe ich bei mir auch gleichmal auf g geändert. Bringt aber leider keine Veränderung, obwohl der Modus g ja als unterstützt aufgeführt wird.

    Den tcpdump muss ich noch nachholen, wobei ich immer noch glaube, es mit einer technischen, weniger einer konfigurationssache zu tun zu haben.
    So, jetzt brauhe ich erst mal eine Pause ... und eine Pizza ... :)

    Grüße
    Clint

  • Hallo,

    das sieht doch alles gut aus. Beim ersten ohne Kabel ist das NO-Carrier genau richtig. Beim 2. ist das NO-Carrier weg und dafür genau das was man erwartet. NO-Carrier zeigt dir an das keine physikalisch Verbindung besteht, sprich kein Kabel dran oder Defekt. Also alles ok.

    Das "ip r s" sieht gut aus wenn WLAN an ist.

    iptables passt. Es sind keine einzigen Rules gesetzt und die DEFAULT Policy ist bei allen auf ACCEPT. Da blockiert auch nichts. Wollte damit nur ausschliessen das auf dem PI schon irgend etwas läuft was eine Firewall mitbringt oder konfiguriert. Nicht das wir hier Config und Hardware die ganze Zeit checken und es eigentlich nur der Paketfilter ist, der nichts auf eth0 rein oder raus lässt.

    Das von ethtool sieht auch ok aus. 10 MB/s sind richtig, der PI kann nur 10. Oder kann der + mehr?

    hm. Ich lese noch mal was wir ins jetzt schon alles gemacht hatten und dann mal weiter gucken.

Jetzt mitmachen!

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