GR3mGH0n Posted May 15, 2017 Posted May 15, 2017 Today I encounter a rather significant packet loss at the wired ethernet connectionmy at my NanoPi NEO. The device is up-to-date running with Armbian 5.25 and Pi-hole. The system is the most of time idle and shouldn't suffer from heavy load or many simultaneous connections. From NanoPi NEO to Windows: --- 192.168.0.204 ping statistics --- 263 packets transmitted, 221 received, 15% packet loss, time 262004ms rtt min/avg/max/mdev = 0.358/0.457/0.729/0.049 ms From Windows to NanoPI NEO: Ping-Statistik für 192.168.0.10: Pakete: Gesendet = 249, Empfangen = 222, Verloren = 27 (10% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms Other clients in my network respond regular without any loss. Is there a solution for this problem? Thank you very much in advance! GR3mGH0n
GR3mGH0n Posted May 15, 2017 Author Posted May 15, 2017 Yes. Actually it was my first attempt to try a different ethernet cable and power supply. After some trial-and-error testing, I discovered the problem between the NanoPi NEO and the FritzBox. If I connect the NanoPi NEO to a switch, everything is fine. Every other device directly connected to the FritzBox is fine. Is the NanoPi NEO connected to the FritzBox, I encounter packet loss.
GR3mGH0n Posted May 15, 2017 Author Posted May 15, 2017 The setup is reproducible: Is the NanoPi NEO connected directly to the FritzBox 7490, the NanoPi NEO encounter packet loss. No other device (tested 5 (RPi 3 with Raspbian, WD NAS, Playstation 4, HP Printer and Windows PC)) encounter packet loss while connected to the FritzBox. Is the NanoPi NEO connected to a switch, the device behave like expected.
GR3mGH0n Posted May 16, 2017 Author Posted May 16, 2017 Today I tried several different OS with this setup. I installed four additional images with Kernel 3.4.113 and 4.11.0. Including Armbian 5.25, 5.27 and generic NanoPi NEO images based on Ubuntu and Debian. Every attempt return the known error. The generic images provide less packet loss (about 5 %) but reveal a significant long latency: min/avg/max/mdev = 0.436/167.328/1391.205/264.400 ms min/avg/max/stddev = 0.437/288.446/1636.203/455.779 ms A run, connected to a switch, return this result: min/avg/max/mdev = 0.452/0.501/0.731/0.047 ms Any suggestions?
gnasch Posted May 16, 2017 Posted May 16, 2017 maybe verify autonegotiation, check if successful and at what speed? gnasch
hkubota Posted May 16, 2017 Posted May 16, 2017 Any suggestions?Switch the ports and cables of that FritzBox?
tkaiser Posted May 16, 2017 Posted May 16, 2017 22 hours ago, GR3mGH0n said: Is the NanoPi NEO connected to a switch, the device behave like expected. So you've already found a solution and can now check whether 'Green mode' or not is related when directly connected to the box: Heimnetz -> Heimnetzübersicht -> Netzwerkeinstellungen.
GR3mGH0n Posted May 16, 2017 Author Posted May 16, 2017 1 hour ago, gnasch said: maybe verify autonegotiation, check if successful and at what speed? gnasch Auto-negotiation looks good on both connections (FritzBox and switch). It is set in any case to: Speed: 100Mb/s Duplex: Full 33 minutes ago, hkubota said: Switch the ports and cables of that FritzBox? I have switches cables and ports plenty of times in different variantions, even those who shouldn't directly relate to the connection. 25 minutes ago, tkaiser said: So you've already found a solution and can now check whether 'Green mode' or not is related when directly connected to the box: Heimnetz -> Heimnetzübersicht -> Netzwerkeinstellungen. I know about this feature. I changed the setting several times with and without reboots afterwards of the FritzBox and the NanoPi NEO but the issue persists. From my perspective is the connection the the switch more a workaround than a proper solution.
tkaiser Posted May 16, 2017 Posted May 16, 2017 5 minutes ago, GR3mGH0n said: I changed the setting several times with and without reboots afterwards of the FritzBox and the NanoPi NEO but the issue persists. Then out of ideas since normally living on network layers 3 or above (though had this issue once few years ago with a printer connected to an IEEE 802.3az capable switch where something went wrong. Using an insanely long cable 'fixed' it according to customer's administrator)
GR3mGH0n Posted May 16, 2017 Author Posted May 16, 2017 I know that ethernet cables should be at least 1m long. For that reason I only use cables with at least 1,5m length, though it is hard to keep those cables tidy and neat. I just tried my best cable I have got: 30m Cat 6a ... issue persists.
Recommended Posts