Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • State Verified Answer
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 707 subscribers
  • Views 5640 views
  • Users 0 members are here
Related

Raspberry Pi Wired Ethernet Intermittent

centipede

I have been trying to solve this for a number of months with no success.  Nor can I find any posts where someone else has already found a solution.  If someone knows of an existing solution please point me to it.

 

My Raspberry Pi is setup such that the WIFI is a hot spot with port forwarding/NAT to the wired Ethernet port.  All is working great, except for this one weird problem. The problem is that the wired connection will stop working for a time, if a large amount of data is sent out at once.  For example. if a large web page (I am using lighty) is to be displayed, or a large file is to be transferred via ftp.  With the web page case, it will typically succeed 2/3 times.  With a file of a few megabytes, it fails every time.

 

Here are some specifics:

 

1)  The wired connection will usually recover on it's own after several minutes.

2)  This is weird, the wired connection will recover, right away, if I have the PI ping another machine on the LAN, and not appear to fail at all if ping is continuously running in another terminal., (it does fail but recovers right away, I can see brief pauses in ftp traffic)

3) The ARP table, and ifconfig both look the same when all is well and when the Ethernet is broken.

4) The WIFI port continues to work, communicating to lighty (port 80) even when Ethernet is broken.  The WIFI port does not have fail when sending out a large web page.

5)  IPtraf, observing eth0, shows that when broken, UDP packets are still being received, while TCP packets are not

6) I have seen this problem on both the PI-2 and PI-3, I am running Jessie

7) I can transfer large files into the PI (uploading), but not out of the PI (downloading), using FTP, over Ethernet.

8) When the PI is in a failed state, SSH is broken, and it appears that all other TCP traffic fails, even connections already established.

9) Wireshark and various /var/log files have not provided a clue, the PI just stops sending packets, with no clue I can find to explain it.

10) The problem exists whether Ethernet is set up as using dynamic addressing or static addressing.

11) ifdown eth0 then ifup eth0 will usually fix it, but they sometimes have to be done twice.

12) Not sure this is relevant, but I am using a hardware tree file to set the UART port back to the GPIO pins.

 

Perhaps I need more buffers, but free does not indicate this.  Perhaps I need to adjust the pacing of transmission, but I am not sure how to do this.  Also top does not indicate a CPU overload.

 

Please help if you can,

Robert

  • 0 in reply to centipede

    When you use "sftp" that means you're using ssh. This uses encryption of the data on the line.
    that could slow things down. But still, I get 10+ Mbytes per second on my pi three. It seems that my first test with "rsync" had the most slowdown, probably in the rsync protocol (rsync was written for "slow links" so it behaves a bit suboptimal on fast links).

     

    On my pi three that I've now tested I can transfer a 15Mbyte file in sub-two-seconds. I tried ftp, scp and rsync (both over ssh and rsh).

     

    So your situation with transfer stopping or being slow is something specific to your situation. Have you tried another ethernet cable?

     

    (I had a client once who declined my offer of putting cat5 in their building.... Later on they asked why things were slower at 100mbps than at 10. Turns out they had wired all the cables wrong, 10mbs communication mostly worked even with the wrongly wired cables, 100mbps had too many transmission errors so things would grind to a halt....)

  • 0 in reply to rew

    Roger,

     

    I am not concerned with the speed, I just wish the transfer did not stop after 32K.  I have tried different Ethernet cables. The cable between the pi and the switch is around 12 feet long and connects into a 10/100 switch from Netgear, which then connects to a 10/100/1000 switch shared with the desktop which is running the ftp client.  Something like this:

     

     

    PI---------Netgear 10/100---------------Netgear 10/100/1000-------------Desktop

                         |                                           |       |

                         ---other machines                  |      ------other machines

                                                                     |

                                                                    ----- global Internet via various switches & routers

     

    It's good to know you had success with your PI-2 and PI-3, that gives me hope.  Are you running the same version of the PI operating system?

    Is it possible we have PI's made by different manufacturers, that use a somewhat different design?

  • 0 in reply to centipede

    I have know problems with packets between two routers/switches not getting sent (it happens in my network and I end up resetting them!). Please try to connect the desktop temporarily to the router directly to eliminate one possible problem.

    Clem

  • 0 in reply to centipede

    It is possible for different manufacturers but they are the same design but maybe different components. Check board and you should see the UK on the Pi.

    Clem

  • 0 in reply to clem57

    Clem,

     

    I connected the PI to the 10/100/1000 switch in my diagram, so both machines are on the same switch similar to what you suggested, and now my FTP transfers from the PI work perfectly every time with no errors!   I have other machines connected to the 10/100 and they seem to have no issues, so I do not know why PI does, but I am very happy to have followed your advice.  More testing to do, but this seems to have fixed my problem!  YEAH!

     

    Thank you both,

    Robert

  • 0 in reply to centipede

    Makes perfect sense to me. The router is buffer limited on the trip back to the switch and either "forgets" or more probably drops packets. Glad though you narrowed the problem outside the Pi.

    Clem

  • 0 in reply to centipede

    My focus on speed is not because you would want "speed". But having proper speed means things are working correctly.

     

    My guess is that you have SOMETHING in your setup that is flaky. Either a bad networking cable (which after switching to the other router suddenly isn't broken, i.e. a flaky contact), or maybe the exact port in the switch. I've had switches develop "bad" ports.

     

    Clem, TCPIP was designed with "packet loss" in mind. An occasional dropped packet will NOT break a TCPIP connection. On the other hand, a continuous 10% packetloss will cause bigger transfers big problems: TCPIP thinks packets are dropped because too many packets are being sent. So it thinks that reducing the speed will improve things. A constantly overloaded link (e.g. because thousands of people are webbrowsing and the new connections that don't know to reduce speed are already overloading the link) or simply a flaky link (e.g. a percentage of packets have bad CRC and are dropped, independent of the amount of packets) will cause TCPIP big problems. But none of this would cause a connection to die after just 32kBytes of transferred data).