Neuling im PI Bereich hat Fragen zu komischen Packetverlust

    Guten Abend,

    Ich bin seit kurzem Besitzer meines ersten Raspberry Pi 5. (Gb Variante mit ner 512 GB SSD.
    Diesen nutze ich mit Adguard Home in meinem Netzwerk. Der Raspberry Pi ist per LAN und Wireless Lan verbunden.

    Kurz nach der Einrichtung hatte ich seltsame Probleme. Das aufrufen von Webseiten dauerten sehr lange oder Sie waren mit einmal nicht mehr erreichbar.
    Seltsame Fehlermeldung in allen Möglichen Browsern bis hin zu Fehlfunktionen von Alexa. Hängen von Video Streams auf TV usw.

    Entfernte ich den PI als DNS lief alles wieder...

    Also aus unwissenheit, alles neu aufgesetzt da ich das Problem irgendwie nicht festmachen konnte oder dachte ich hab bei den Anleitungen irgenwie mist gebaut.
    Leider tratt das Problem danach wieder auf....


    Also man geschaut was in meinem Netzwerk so ab geht und siehe da, Anfragen verschwanden im Nirvana...
    Also Dauerping auf den PI und siehe an, sporadisch bis zu 40% Verlust und das bei Lan und Wireless Lan....


    Aktuell nutze ich ein Firtzbox 7590 AX + Netgear MS308E + 2 x FRITZ!Repeater 6000 + Repeater 1200 AX in meinem Haus.
    Da hängt alles dran was WLAN und LAN hat ... ca.: 30 Geräte inkl. NAS usw.
    Sowie ich den Raspberry Pi mit Adguard Home als DNS einbinde, fangen jedoch Probleme bei allen Geräten an.

    Also versucht das Problem ein zu grenzen und naja, nach etwas experimentieren Problem gefunden aber erklären kann ich es mir nicht.
    Daher suche ich hier mal nach Hilfe.

    Was habe ich bis jetzt rausgefunden:
    - IP V6 deaktivieren brachte keine Lösung
    - Manuelle IP Vergabe bracht auch nix

    Den PI nur per Wireless Lan einbinden - Problem gelöst, keine DNS Probleme oder packet verluste aber grottige Geschwindigkeit.

    Sowie ich den PI nur per Lan oder Lan und WLan verbinde fangen die Probleme wieder an. (Hierbei ist es egal ob der PI am LAN der Firtzbox oder am Netgear MS308E hängt.)

    Also weiter gesucht und folgendes konnte ich dabei feststellen. Drossle ichmanuell bei der Fritzbox oder dem Netgear MS308E den Port wo der PI dran hängt auf 100 Mbit funktioniert alles ohne Fehler.
    Egal ob nur LAN oder LAN und WLan. Es gibt dann kein Ping verluste mehr, keine DNS Probleme... Geschwiindigkeit ist supper.
    Sowie er aber an einen 1 Gbit Port hängt ist es vorbei und die probleme beginnen von vorn.

    Leider konnte ich nix so richtig passendes hierzu finden. Da meine Englisch kenntnisse zu wünschen überig lassen, dachte ich dass ich hier mal um Hilfe frage.
    Ist euch so etwas schon untergekommen? Mache ich einen Fehler?

    Vielleicht habt Ihr ja ein Paar Tips für mich.

  • Neuling im PI Bereich hat Fragen zu komischen Packetverlust? Schau mal ob du hier fündig wirst!

    Hat Adguard einen DHCP-Server?
    Sieh mal nach ob es 2 DHCP-Server im Netzwerk gibt,
    einer ist zumindestens die FritzBox. Es darf nur 1 DHCP-Server laufen.

    Ich habe hier PiHole am laufen, daher kenne ich Adguard nicht so genau.
    Aber so etwas ähnliches ist in unserer Fa. passiert,
    nach dem jemand seinen WLAN-Accesspoint ins Firmennetz eingesteckt hat.
    Ist schon etwas her.

    Und Herzlich Willkommen im Forum.

    MfG

    Jürgen

    Pfff! :conf: Ich kenne Adguard auch nicht und verwende ebenfalls Pi-hole. Auf den ersten Blick scheint Adguard genau das zu machen, was es soll, nämlich gewisse Anfragen ins Nirvana schicken. Pi-hole hat diverse Server-Listen, die man einfügen kann und die dann alles blocken, was auf der Liste steht. Da kann man aber auch bestimmte Domains auf eine White-List setzen, die dann trotzdem per DNS aufgelöst werden.

    BTW: LAN und WLAN am RPi haben unterschiedliche IP-Adressen. Welche der beiden IPs hast Du anfangs und dann später in der Fritte eingetragen?

    Hi hyle,

    Also der Pi hat
    im Lan die feste IP 192.168.178.20
    im WLan die 192.168.178.21

    In der Fritzbox ist beim lokalen DNS die 192.168.178.20 eingetragen.

    Der DHCP der Firritzbox geht von 192.168.178.25 bis 192.168.178.200
    Die Grundgeräte (Desktop PCs, NAs Lamptops) haben alle fest eingestellt IPs.

    Wenn ich per Lan und Wirelss Lan verbunden bin und machte ein Ping auf die Lan IP des PI erhalte ich folgendes:

    Ping-Statistik für 192.168.178.20:
    Pakete: Gesendet = 4, Empfangen = 2, Verloren = 2
    (50% Verlust),
    Ca. Zeitangaben in Millisek.:
    Minimum = 1ms, Maximum = 2ms, Mittelwert = 1ms

    mach es es auf die Wireless Lan IP:

    Ping-Statistik für 192.168.178.21:
    Pakete: Gesendet = 4, Empfangen = 3, Verloren = 1
    (25% Verlust),
    Ca. Zeitangaben in Millisek.:
    Minimum = 4ms, Maximum = 203ms, Mittelwert = 54ms

    stelle ich um auf 100 Mbit erhalte ich beim Ping auf Lan folgendes:

    Ping-Statistik für 192.168.178.20:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
    Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

    bei Wireless lan seht es dann so aus:

    Ping-Statistik für 192.168.178.21:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
    Ca. Zeitangaben in Millisek.:
    Minimum = 5ms, Maximum = 23ms, Mittelwert = 9ms

    Probleme die bei 1Gbit auftretten sind:
    - Seitenanfragen sehr Langsam
    - Darstellungsfehler im Browser auch z.B bei Amazon, Bilder werden nicht mehr angezeigt also nix was eigentlich durch die Blockliste blockiert werden sollte.
    - Webseiten werden teilweise sehr langsam oder nicht richtig geladen ... und ich sprehe hier nicht von Werbung, Es fehlen Teile von Texten. Videos auf Youtube oder Crunchyroll haben Aussetzer, Hängen oder Puffern sehr langsam

    Führe ich auf dem Pi den Befehl ip -s link show eth0 erhalte ich folgndes Ergebnis:
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 88:a2:9e:9a:1f:fe brd ff:ff:ff:ff:ff:ff
    RX: bytes packets errors dropped missed mcast
    555010 6615 38 1714 0 552
    TX: bytes packets errors dropped carrier collsns
    1353385 2141 0 1 0 0

    Selbst wenn ich google.de oder heise an pinge habe ich Verluste:

    Ping wird ausgeführt für google.de [192.178.183.94] mit 32 Bytes Daten:
    Zeitüberschreitung der Anforderung.
    Antwort von 192.178.183.94: Bytes=32 Zeit=14ms TTL=109
    Antwort von 192.178.183.94: Bytes=32 Zeit=13ms TTL=109
    Antwort von 192.178.183.94: Bytes=32 Zeit=14ms TTL=109

    Ping-Statistik für 192.178.183.94:
    Pakete: Gesendet = 4, Empfangen = 3, Verloren = 1
    (25% Verlust),
    Ca. Zeitangaben in Millisek.:
    Minimum = 13ms, Maximum = 14ms, Mittelwert = 13ms

    ing wird ausgeführt für heise.de [193.99.144.80] mit 32 Bytes Daten:
    Zeitüberschreitung der Anforderung.
    Zeitüberschreitung der Anforderung.
    Antwort von 193.99.144.80: Bytes=32 Zeit=15ms TTL=248
    Antwort von 193.99.144.80: Bytes=32 Zeit=14ms TTL=248

    Ping-Statistik für 193.99.144.80:
    Pakete: Gesendet = 4, Empfangen = 2, Verloren = 2
    (50% Verlust),
    Ca. Zeitangaben in Millisek.:
    Minimum = 14ms, Maximum = 15ms, Mittelwert = 14ms

    Und ichhabe keine Ahnung in welchen Zusammen das mit dem PI und Adguard Home steht. Ich weiß nur, dass wenn ich den Pi aus dem Netzwerk entferne oder den Lan Port auf 100 Mbit umstelle alles ohne Fehler funktioniert.

    Quote from Momonga

    Also der Pi hat
    im Lan die feste IP 192.168.178.20
    im WLan die 192.168.178.21

    Wenn dein PI per Lan mit der FB verbunden ist, brauchst Du das Wlan des PI nicht. D. h. Wlan im PI deaktivieren.

    Poste von deinem PI die Ausgaben von:

    Code
    sudo sysctl net.ipv4.tcp_window_scaling net.ipv4.tcp_moderate_rcvbuf net.core.default_qdisc net.ipv4.tcp_congestion_control

    Welche Firmware-Version hast Du z. Zt. auf deiner FB bzw. ist die Hardwarebeschleunigung in der FB aktiviert oder deaktiviert?
    Wenn dein PI nur per Lan mit der FB verbunden ist, teste mal auf deinem PI die Bandbreite mit iperf3 (evtl. installieren):

    Code
    iperf3 -c speedtest.studiofunk.de -p 5200 -4 -R

    Teste die Bandbreite mit iperf3, mit und ohne:

    Code
    sudo ethtool --set-eee eth0 tx-lpi off

    Fritz.box hat die Firmware: 8.25
    Hardwarebeschleunigung ist aktiv
    Das einzige was per USB angeschlossen ist, ist das Netzteil.
    Alle anderen Verbindungen machen ich per SSH oder Raspery PI Connect.


    Ergebnis Befehl 1:
    net.ipv4.tcp_window_scaling = 1
    net.ipv4.tcp_moderate_rcvbuf = 1
    net.core.default_qdisc = fq_codel
    net.ipv4.tcp_congestion_control = cubic

    Ergebnis Befehl 2:
    Connecting to host speedtest.studiofunk.de, port 5200
    Reverse mode, remote host speedtest.studiofunk.de is sending
    [ 5] local 192.168.178.20 port 48134 connected to 185.209.244.2 port 5200
    [ ID] Interval Transfer Bitrate
    [ 5] 0.00-1.00 sec 7.25 MBytes 60.8 Mbits/sec
    [ 5] 1.00-2.00 sec 7.88 MBytes 66.1 Mbits/sec
    [ 5] 2.00-3.00 sec 7.88 MBytes 66.1 Mbits/sec
    [ 5] 3.00-4.00 sec 8.00 MBytes 67.1 Mbits/sec
    [ 5] 4.00-5.00 sec 7.88 MBytes 66.1 Mbits/sec
    [ 5] 5.00-6.00 sec 7.88 MBytes 66.1 Mbits/sec
    [ 5] 6.00-7.00 sec 8.00 MBytes 67.1 Mbits/sec
    [ 5] 7.00-8.00 sec 7.75 MBytes 65.0 Mbits/sec
    [ 5] 8.00-9.00 sec 6.12 MBytes 51.4 Mbits/sec
    [ 5] 9.00-10.00 sec 7.62 MBytes 64.0 Mbits/sec
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bitrate Retr
    [ 5] 0.00-10.02 sec 79.0 MBytes 66.1 Mbits/sec 429 sender
    [ 5] 0.00-10.00 sec 76.2 MBytes 64.0 Mbits/sec receiver

    iperf Done.

    Ergebnis nach (sudo ethtool --set-eee eth0 tx-lpi off)
    Connecting to host speedtest.studiofunk.de, port 5200
    Reverse mode, remote host speedtest.studiofunk.de is sending
    [ 5] local 192.168.178.20 port 57518 connected to 185.209.244.2 port 5200
    [ ID] Interval Transfer Bitrate
    [ 5] 0.00-1.00 sec 6.88 MBytes 57.7 Mbits/sec
    [ 5] 1.00-2.00 sec 8.12 MBytes 68.1 Mbits/sec
    [ 5] 2.00-3.00 sec 8.12 MBytes 68.2 Mbits/sec
    [ 5] 3.00-4.00 sec 8.12 MBytes 68.1 Mbits/sec
    [ 5] 4.00-5.00 sec 8.00 MBytes 67.2 Mbits/sec
    [ 5] 5.00-6.00 sec 8.12 MBytes 68.1 Mbits/sec
    [ 5] 6.00-7.00 sec 8.00 MBytes 67.1 Mbits/sec
    [ 5] 7.00-8.00 sec 8.00 MBytes 67.1 Mbits/sec
    [ 5] 8.00-9.00 sec 7.88 MBytes 66.1 Mbits/sec
    [ 5] 9.00-10.00 sec 8.00 MBytes 67.1 Mbits/sec
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval Transfer Bitrate Retr
    [ 5] 0.00-10.03 sec 80.6 MBytes 67.5 Mbits/sec 49 sender
    [ 5] 0.00-10.00 sec 79.2 MBytes 66.5 Mbits/sec receiver

    iperf Done.

    Momonga

    Bitte benutze den Tag für Code-Block. Ds macht alles lesbarer und Platzsparender.

    Dein Beitrag #9 könnte dann so aussehen. Außerdem bleibt bei code die Struktur ( Einrückungen) erhalten.

    Fritz.box hat die Firmware: 8.25
    Hardwarebeschleunigung ist aktiv
    Das einzige was per USB angeschlossen ist, ist das Netzteil.
    Alle anderen Verbindungen machen ich per SSH oder Raspery PI Connect.

    Ergebnis Befehl 1:

    Code
    net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.default_qdisc = fq_codel
net.ipv4.tcp_congestion_control = cubic

    Ergebnis Befehl 2:

    :danke_ATDE:

    Quote from Momonga
    Code
    net.core.default_qdisc = fq_codel
net.ipv4.tcp_congestion_control = cubic
    Code
    [ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 79.0 MBytes 66.1 Mbits/sec 429 sender
[ 5] 0.00-10.00 sec 76.2 MBytes 64.0 Mbits/sec receiver

    Ergebnis nach (sudo ethtool --set-eee eth0 tx-lpi off)

    Code
    [ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.03 sec 80.6 MBytes 67.5 Mbits/sec 49 sender
[ 5] 0.00-10.00 sec 79.2 MBytes 66.5 Mbits/sec receiver

    Die retransmissions ohne "tx-lpi off" sind hoch (429 vs. 49).

    Teste mal mit:

    Code
    sudo ethtool --set-eee eth0 tx-lpi off
sudo sysctl net.core.default_qdisc=fq
sudo sysctl net.ipv4.tcp_congestion_control=bbr

    den download.

    Welche Bandbreite hat laut Tarif deines ISPs, dein Internetanschluss?

    EDIT:

    Hast Du den Lan-Port der FritzBox, über den Du die Messung gemacht hast, für 1Gbit oder für 100Mbit konfiguriert gehabt?

    Erste Hinweise auf ein Kabelproblem kann man mit z. B.:

    Code
    sudo ethtool -S eth0

    bekommen. Man achte dort auf:

    Code
    :~# ethtool -S eth0 | grep -iE 'rx_errors|rx_crc'
     rx_errors: 0
     rx_crc: 0

    Ob die Puffer der NIC überlaufen sind, mit z. B.:

    Code
    :~# ethtool -S eth0 | grep -i rbuf_ovflow_cnt
     rbuf_ovflow_cnt: 0

    EDIT:

    Teste mal auch, ob von deinem PI evtl. viele broadcast & Co. in kurzer Zeit, ins Subnetz deiner FritzBox gesendet werden:

    Code
    sudo tcpdump -c 100 -vvvnei eth0 -Q out 'broadcast or multicast or igmp'
    Code
    sudo tcpdump -c 100 -vvvnei wlan0 -Q out 'broadcast or multicast or igmp'

    Wi-Fi_Signal_Strength  txpower
    iptables chains order scheme iptables-diagram
    nftables-diagram

    Meine PIs

    PI4B/8GB (border device) FreeBSD 15.1R-p1 (arm64): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI4B/4GB FreeBSD 14.4R-p7 (arm64): SSH-Serv., WireGuard-Serv., ngircd-Serv., Mumble-Serv., ddclient

    PI4B/8GB Bookworm-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited once, last by rpi444 (July 4, 2026 at 4:06 PM).

    Quote from rpi444

    bekommen. Man achte dort auf:

    Die von dir gegreppten Einträge gibt es bei mir (Pi5 Trixie) nicht.

    Edited once, last by Franjo G (July 4, 2026 at 4:18 PM).

    Quote from Franjo G
    Quote from rpi444

    bekommen. Man achte dort auf:

    Die von dir gegreppten Einträge gibt es bei mir (Pi5 Trixie) nicht.

    OK, auf dem PI habe ich noch bookworm, aber auf einem Laptop habe ich trixie. Relevant sind dort:

    Code
    rx_frame_check_sequence_errors:
rx_alignment_errors:
rx_overruns:
rx_resource_errors:
q0_rx_dropped:

    BTW:

    Code
    rx_lpi_transitions: 27152833
rx_lpi_time: 323824410274
tx_lpi_transitions: 131749
tx_lpi_time: 352351104268

    sollte man evtl. abschalten:

    Code
    sudo ethtool --set-eee eth0 eee off
    Quote from rpi444

    sudo ethtool --set-eee eth0 eee off

    Das wirkt aber nur bis zu einem Reboot.

    Ein Eintrag in der config.txt disabled den Energy Efficient modus komplett.
    dtparam=eee=off

    Vorher

    Code
    ~ $ ethtool --show-eee eth0
EEE settings for eth0:
        EEE status: enabled - active
        Tx LPI: 250000 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full

    Nach dem Eintrag in die config.txt und reboot

    Code
    ~ $ ethtool --show-eee eth0
EEE settings for eth0:
        EEE status: not supported
    Quote from Franjo G
    Quote from rpi444

    sudo ethtool --set-eee eth0 eee off

    Das wirkt aber nur bis zu einem Reboot.

    Ein Eintrag in der config.txt disabled den Energy Efficient modus komplett.
    dtparam=eee=off

    Ja, wenn man es erstmal nur temporär zum testen deaktivieren will.

    Ich habe dann auf meinem PI, persistent nur das "tx-lpi" (mit einer timer-unit) deaktiviert:

    Code
    ethtool --set-eee eth0 tx-lpi off
    Code
    :~ $ ethtool --show-eee eth0
EEE settings for eth0:
	EEE status: enabled - inactive
	Tx LPI: disabled
	Supported EEE link modes:  100baseT/Full
	                           1000baseT/Full
	Advertised EEE link modes:  100baseT/Full
	                            1000baseT/Full
	Link partner advertised EEE link modes:  Not reported

    Mir hat das auf jeden Fall geholfen. Ich hatte nach Umstellung von Wlan auf Ethernet immer das Problem, dass nach längerer Nichtbenutzung ein erster Verbindungsversuch per SSH abbrach und erst ein zweiter erfolgreich war. Ich konnte mir das nie erklären warum. Das eee kannte ich nicht.
    Jetzt funktioniert es perfekt.

    :thumbup:

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login