Reboot/Shutdown schließt Port - danach kein aktives ssh mehr!

  • Nö, das LAN Kabel ist es nicht. Eher das Handshake der beiden Eth-Controller, wenn es das überhaupt ist.

    Beim Pi 4 kann man da mMn nichts mehr verstellen.



    Servus !

    RTFM = Read The Factory Manual, oder so

  • Ziehe probeweise einmal das Ethernetkabel nach dem reboot Befehl ab.

    Leider immer noch kein Rebooten - alles beim "Alten" ...

    Wenn Du ihn bspw. mit der IP erreichen kannst, aber nicht unter dem Hostnamen.

    ... und hier auch nicht: mit beiden geht's gleich gut - oder eben auch nicht.

  • Hetzt warte erstmals ab, ob er bei abgezogenem Kabel überhaupt rebootet, oder nicht.

    Nur, falls ich das richtig verstanden habe: ich gebe ihm den reboot-Befehl und ziehe dann das Kabel ab - also z. B. "sudo shutdown -r 10" und ziehe? So hab' ich's mal probiert, aber keine Veränderung festgestellt. Es leuchtet nur das rote LED (tat's aber vorher auch).

    Hast Du einmal in die Logfiles reingeschaut ?

    Ähm, welche wären das?

  • ich gebe ihm den reboot-Befehl und ziehe dann das Kabel ab - also z. B. "sudo shutdown -r 10"

    Was willst du denn jetzt? Neustarten oder herunterfahren??


    Neustarten (rebooten) sudo reboot

    herunterfahren sudo shutdown -h

  • shutdown -h now = System hold after shutdown

    shutdown -r now = System restart after shutdown

  • Muss mich korrigieren: habe "sudo shutdown -r 1" eingegeben - und das grüne LED hat tatsächlich gearbeitet.

    Hm, nach dem Wiederanschließen war der raspi weg (client_loop: send disconnect: Broken pipe). Da habe ich wohl was nicht wirklich kapiert ...

  • Nimm mal den Raspi komplett vom Netz also alle Stecker ziehen. Dann wieder alle Kabel rein aber Netzteil als letztes. Klingt als hättest Du irgendwo Kriechströme.

  • Nimm mal den Raspi komplett vom Netz also alle Stecker ziehen. Dann wieder alle Kabel rein aber Netzteil als letztes. Klingt als hättest Du irgendwo Kriechströme.

    Sorry, leider immer noch kein Reboot. Sollte ich ihn aus seinem Acryl-Häuschen holen, in dem er sitzt?

  • Wäre ein Versuch wert. Zu dem hätte ich auch mal per wlan probiert. Nur um eventuelle Fehlerquellen auszuschließen. Hast Du nach der Neuinstallation gleich ein update/upgrade gemacht ? Oder war dieser "Bug" vorher schon da ?

  • Als Router habe ich die Fritz!Box 7580 und auf dem Rechner Linux (Mint 20 Cinnamon). Der Raspberry hängt am LAN.

    Installiere auf deinem Linux-Rechner iputils-arping, arp-scan und tcpdump.

    Poste von deinem Linux-Rechner, die Ausgaben von:

    Code
    arp -av
    ip a

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

  • Okay, hier ist arp -av:

    fritz.box (192.168.178.1) auf e0:28:6d:6d:03:b5 [ether] auf wlp1s0

    ? (192.168.178.39) auf f0:b0:14:59:31:e0 [ether] auf wlp1s0

    raspberrypi.fritz.box (192.168.178.67) auf dc:a6:32:2d:47:51 [ether] auf wlp1s0

    Einträge: 3 Ignoriert: 0 Gefunden: 3


    ... und hier ip a:

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    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

    inet6 ::1/128 scope host

    valid_lft forever preferred_lft forever

    2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000

    link/ether 30:f9:ed:d9:bd:3b brd ff:ff:ff:ff:ff:ff

    3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

    link/ether b8:76:3f:f6:17:2b brd ff:ff:ff:ff:ff:ff

    inet 192.168.178.31/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp1s0

    valid_lft 845745sec preferred_lft 845745sec

    inet6 fe80::4179:f67c:51c4:b2d/64 scope link noprefixroute

    valid_lft forever preferred_lft forever

    4: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000

    link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff

    inet 172.16.235.1/24 brd 172.16.235.255 scope global vmnet1

    valid_lft forever preferred_lft forever

    inet6 fe80::250:56ff:fec0:1/64 scope link

    valid_lft forever preferred_lft forever

    5: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000

    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff

    inet 172.16.39.1/24 brd 172.16.39.255 scope global vmnet8

    valid_lft forever preferred_lft forever

    inet6 fe80::250:56ff:fec0:8/64 scope link

    valid_lft forever preferred_lft forever

  • Wäre ein Versuch wert. Zu dem hätte ich auch mal per wlan probiert. Nur um eventuelle Fehlerquellen auszuschließen. Hast Du nach der Neuinstallation gleich ein update/upgrade gemacht ? Oder war dieser "Bug" vorher schon da ?

    WLAN fiel mir vorhin auch schon mal ein. Aber basteln tu' ich erst morgen. Update - ja, hab ich gemacht. Ich probier's ohne mal mit der anderen SD aus - danke!

  • Poste von deinem Linux-Rechner die Ausgaben von:

    Code
    sudo arping -c 3 -I wlp1s0 192.168.178.67
    sudo arp-scan -I wlp1s0 -l
    ping -c 4 192.168.178.67


    EDIT:


    BTW: WLAN (auf dem PI) ist hier in diesem Fall, zum testen nicht geeignet.


    EDIT 2:


    ... Und die Ausgabe von:

    Code
    nc -zv 192.168.178.67 22

    ?

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