Beiträge von rpi444

    Sind die Dateien größer bricht der Transfer ab.

    Wenn ich MSDOS-Fenster mit ftp xxx.xxx.xxx.xxx eine Verbindung öffne und größere Dateien übertrage,

    das bricht, unabhängig von der Größe der Dateien der Transfer bei genau 39518208 Bytes ab.

    ich denke, dass da evtl. ein Buffer (von 39518208 Bytes) im Spiel ist, weil es immer genau bei der Datenmenge, einen Abbruch im Transfer gibt.

    Teste mal mit einem anderen Protokoll (z. B. http) und anderem Dienst/Download-tool (z. B. einfacher python-Server und axel).

    EDIT:

    Ich habe mal zum PI4 (ftp-Server) mit pyftpdlib und 100MB-Datei getestet. Es gibt keine Probleme:

    ftp-Server auf dem PI4
    ftp-Client im WLAN des PI4

    Wenn ich sie eingesteckt lasse verändert sich nichts.

    Bildschirm ist dauerhaft mit Strom und PI verbunden.

    OK. Was Du noch als letzter Test probieren kannst, ist, eine neue SD-Karte die Du nicht formatierst und auf die Du das aktuelle Buster-lite-Image kopierst. Danach den PI4 booten und wenn er jetzt richtig bootet, dann rebooten (ohne vorheriges update) und nach dem erfolgreichen reboot:

    Code
    sudo apt update
    sudo apt-get upgrade --with-new-pkgs
    sudo dpkg --configure -a

    ausführen. Wenn das beendet ist, den PI4 rebooten.

    Beim booten stecke ich die Tastatur normalerweise ab. Im Tastatur USB Hub ist noch eine Maus und ein USB bluetooth headset connector.


    Nach unzähligen boot Versuchen waren leider nur 4 erfolgreich.

    Das ist aber merkwürdig, denn entweder er bootet oder er bootet nicht.

    Versuch mal mit permanent angesteckter Tastatur (inkl. Maus und USB-headset).

    Warum steckst Du die Tastatur beim booten ab? Bildschirm ist permanent am PI und hat auch immer Strom beim rebootendes PI bzw. immer vor dem booten des PI?

    ...t wlan0, ich starte das also dann mal mit wlan0 und frage meinen Freund ...

    OK, wenn Du deinen Freund nicht erreichen kannst oder auch wenn Du ihn erreichen kannst, hier ein Web-Tool:

    https://www.ipfingerprints.com/portscan.php

    mit dem Du selber auch einen TCP-Portscan auf den TCP-Port 25565 und die externe IPv4-Adresse deiner FritzBox, mit einem Web-Broser aus deinem WLAN machen kannst. Das Webtool ist selbsterklärend und es funktioniert, denn ich habe es soeben mit meinem PI getestet.

    Da steht sehr viel, unter anderem die IP-Adresse des Pi, die soll ich hier doch nicht öffentlich posten, oder?

    Naja, das ist ja keine öffentliche IP-Adresse und könnte gepostet werden, wird hier aber nicht benötigt.

    Ich will nur wissen ob der PI per Kabel oder per WLAN mit der FritzBox verbunden ist und wenn per Kabel, das Interface dann eth0 ist bzw. wenn per WLAN, das Interface dann wlan0 ist?

    Wenn nicht, dann könntest Du tcpdump auch zweimal starten:

    Code
    sudo tcpdump -c 50 -vvveni eth0 port 25565

    und

    Code
    sudo tcpdump -c 50 -vvveni wlan0 port 25565

    , dann wird das richtige Interface schon dabei sein. ;)

    Ich habe jemanden mit Linux gefunden (der Freund ist es nicht), und der hat das für mich gemacht. Beim oberen Kommando kam die fehlermeldung: failed no route to host

    das untere Kommando hat funktioniert

    Code
    Host is up (0.062s latency)
    
    PORT        STATE        SERVICE
    25565/tcp    filtered    minecraft

    So sah das aus.

    Bei mir hat sich bei tcpdump überhaupt nichts getan.

    Ist für diesen Portscan die externe/öffentliche IPv4-Adresse der FritzBox verwendet worden bzw. war tcpdump rechtzeitig aktiv?

    Wenn ja, dann stimmt die Portweiterleitung in der FritzBox nicht.

    Was Du noch testen kannst, ist statt "any" mit tcpdump, das tatsächliche Interface zu benutzen (eth0 oder wlan0).

    Denn any funktioniert nicht immer zuverlässig in Linux.

    Poste mal von deinem PI, die Ausgabe von:

    Code
    ip a

    ... oder so?

    Du kannst die externe/öffentliche IPv4-Adresse deiner FritzBox, auf deinem PI (Kommandozeile) feststellen, mit:

    Code
    host -4s myip.opendns.com 208.67.222.222

    Der Freund deines Sohnes soll dann von seinem Internetanschluss, einen Portscan auf diese IPv4-Adresse und den Port 25565 machen. Mit z. B.:

    Code
    nc -zv IP-Adresse 25565

    oder mit

    Code
    sudo nmap -sS IP-Adresse -p25565

    (wenn es Linux hat, ... oder gleichwertig mit einem anderen OS). IP-Adresse anpassen bzw. diese musst Du ihm mitteilen. Während des Portscans muss dann tcpdump auf deinem PI aktiv sein.

    da passiert gar nichts (außer der gleichen Meldung wie oben)

    wenn ich mit Ctrl C abbreche, erscheint

    0 packets captured

    Ich hab irgendwas gelesen von DNS-Dys oder so? Kann man damit was machen? Oder muss noch irgendeine Firewall umgangen werden?

    Hast Du lange genug gewartet (mit Ctrl C), ... bis der Freund deines Sohnes den Zugriff gemacht hat?

    Hat der Freund deines Sohnes per IPv4 oder per IPv6 zugegriffen? Firewall gibt es nur für IPv6, in der FritzBox.

    Deine Frage zu DNS-Dys irritiert jetzt. Meinst Du evtl. DynamicDNS? Hat der Freund deines Sohnes für den Zugriff, die externe/öffentliche IPv4-Adresse deiner FritzBox benutzt? Wenn ja, wie habt ihr diese externe IPv4-Adresse der FritzBox ermittelt? Das könnte man auch von PI aus machen.

    da steht bei mir:

    Code
    listening an any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

    Das ist erstmal OK so. Jetzt soll der Freund deines Sohnes von außen auf den Port 25565 zugreifen, damit Du sehen kannst (mit Hilfe vom gestarteten tcpdump) ob dieser Zugriff am PI auch ankommt. Wenn ja, dann ist die Portweiterleitung in der FritzBox OK und es liegt an der Konfiguration des Servers, wenn etwas nicht richtig funktioniert.

    ... dann möchte ich via Notebook draußen vor Ort und einem LAN-Kabel remote auf den RPI drauf.

    Was genau meinst Du mit "LAN-Kabel remote"?

    EDIT:

    BTW: Wenn es nur eine einfache Kabelverbindung ist, musst Du nicht viel beachten.

    Denn wenn der PI und das Notebook ohne Zugang zu einem DHCP-Server gestartet werden und noch die default Konfiguration haben, bekommt/hat das LAN-Interface im PI und im Notebook einen LL-IP-Adresse (IPv4 und/oder IPv6) und damit kann zwischen den beiden Geräten eine Kabelverbindung hergestellt werden.

    Die LL-IP-Adresse des PI kann von Notebook aus, mit einem arp-scan ermittelt werden.

    ich habe nun den Pi nochmals neu aufgesetzt ...

    1. Versuch: Verwendung des Buster-Lite-Images (32Bit) (DHCP)

    -- hier hatte ich das gleiche Ergebnis

    2. Versuch: wieder 64Bit und Verwendung statischer IP für den Pi

    -- funktioniert.

    Wie ich bereits geschrieben habe, wäre eine Neuaufsetzung dafür nicht erforderlich gewesen.

    Es kann auch nicht sein, dass es mit 64Bit funktioniert und mit 32Bit nicht. Aber OK, Du bist an einem Erkenntnisgewinn ja auch nicht interessiert.

    Test IPv4 ok
    Test IPv6 ok
    Test Dual Stack ok

    OK, dann kann man auf dem PI (in der Kommandozeile oder gleichwertig) testen, ob die Portweiterleitung in der FritzBox richtig konfiguriert ist bzw. richtig funktioniert. Z. B. mit:

    Code
    sudo tcpdump -c 100 -vvveni any port 25565

    Wenn keine Ausgabe, dann evtl. "any" durch "eth0" oder durch "wlan0" ersetzen und erneut von außen (Internet) testen, je nach dem ob der PI per Kabel oder per Wlan mit der FritzBox verbunden ist.