Ethernet Transfer Freezes (Hard)

kushalkoolwal · 05-06-2008, 10:57 AM

My Specs:
Kernel - 2.6.18-4-486 (etch default)
Debian 4.0
VIA CX700 with 2 Intel Corporation 8255xER/82551IT Fast Ethernet Controller

Observations:
I have been observing frequent freezes/lockups while uploading to my Debian system using ssh/sftp/scp/ftp. There is not particular point at which it freezes. I am able to upload small files (<100 MB) generally with no problems but if I try to transfer a large file (say 700MB) the system locks up i.e. hard freeze. I have to reset the system. None of the techniques mention here works.

Also this happens if I try to download any file from the Internet - For example if I try to download the ISOs from mirrors.kernel.org it will freeze.

I have tried this on Fedora 5/8 and Ubuntu but the same behavior.

Some questions:
1. I am not sure where to begin with. Are there any log in /var/log directory which would help?

2. Can I enable some DEBUG flag which will help me to see what's going on?

3. Will /proc directory help?

4. Looks like this is a hardware issues. Should I try any other mailing list?

Any help will be greatly appreciated.

stlouis · 05-06-2008, 02:45 PM

First off, are you possibly running on a DSL or similar service? If so, you may want to check the MTU rate on your server. I have run into a similar problem in the past.

ifconfig <adapter> (eg. ifconfig eth0) or ifconfig -a for ALL adapter info.

Typical respose should look similar to:
eth0 Link encap:Ethernet HWaddr 00:15:17:44:77

C
inet addr:172.28.173.16 Bcast:172.28.173.255 Mask:255.255.255.0
inet6 addr: fe80::215:17ff:fe44:77dc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1496912 errors:0 dropped:0 overruns:0 frame:0
TX packets:2592318 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:180989700 (172.6 MiB) TX bytes:3476832862 (3.2 GiB)
Base address:0x2000 Memory:88180000-881a0000

Check the MTU setting, which should be defaulted to 1500. This may need to be decreased.

I would try 1400, which is most likely lower than you need to go, but can be fined tuned after.

To reduce your MTU rate on the Server, you would issue the following command:

ifconfig <adapter> mtu <MTU size> (eg. ifconfig eth0 mtu 1400)

If this does NOT work, you can always set it back to the default 1500.

The ping command can be used to craft packets of certain sizes, which would be helpful in troubleshooting.

for example:

ping -s 1492 www.google.ca

The above command would craft a packet with a size of 1492 (DSL Standard).

From the response you will receive, the key factor you are looking for is "packet need to be fragmented". If you see this message, you packet is TOO BIG, reduce the MTU rate until you can successfully ping the remote HOST, without the above error.

You can actually run a quick ping test before you change the MTU rate. To test the default MAX:

ping -s 1500 <hostname/ip>

Oh, you will want to ping your Linux Server, as I'm guessing that's where the problem will be...

Hope this helps,

Jeff

stlouis · 05-06-2008, 02:49 PM

One last thing, can you use TCPDUMP or WIRESHARK to capture you DATA STREAM... You can set a FILTER to capture ALL or traffic based on PORT, PROTOCOL or IP...

I would do the TESTING with FTP...

This will give you a good look at what's exactly happening...

What type of Router do you have? Can you monitor or Debug Traffic?

Jeff

Vyatta -> Your Cisco Alternative
Zimbra -> Your MS Exchange Alternative

OpenSource Alternative, ALWAYS!

kushalkoolwal · 05-07-2008, 01:52 PM

Quote:

Originally Posted by stlouis

First off, are you possibly running on a DSL or similar service? If so, you may want to check the MTU rate on your server. I have run into a similar problem in the past.

ifconfig <adapter> (eg. ifconfig eth0) or ifconfig -a for ALL adapter info.

Typical respose should look similar to:
eth0 Link encap:Ethernet HWaddr 00:15:17:44:77

C
inet addr:172.28.173.16 Bcast:172.28.173.255 Mask:255.255.255.0
inet6 addr: fe80::215:17ff:fe44:77dc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1496912 errors:0 dropped:0 overruns:0 frame:0
TX packets:2592318 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:180989700 (172.6 MiB) TX bytes:3476832862 (3.2 GiB)
Base address:0x2000 Memory:88180000-881a0000

Check the MTU setting, which should be defaulted to 1500. This may need to be decreased.

I would try 1400, which is most likely lower than you need to go, but can be fined tuned after.

To reduce your MTU rate on the Server, you would issue the following command:

ifconfig <adapter> mtu <MTU size> (eg. ifconfig eth0 mtu 1400)

If this does NOT work, you can always set it back to the default 1500.

The ping command can be used to craft packets of certain sizes, which would be helpful in troubleshooting.

for example:

ping -s 1492 www.google.ca

The above command would craft a packet with a size of 1492 (DSL Standard).

From the response you will receive, the key factor you are looking for is "packet need to be fragmented". If you see this message, you packet is TOO BIG, reduce the MTU rate until you can successfully ping the remote HOST, without the above error.

You can actually run a quick ping test before you change the MTU rate. To test the default MAX:

ping -s 1500 <hostname/ip>

Oh, you will want to ping your Linux Server, as I'm guessing that's where the problem will be...

Hope this helps,

Jeff

Jeff, thank you very much for your detailed response. I tried what you mentioned but I wasn't able to detect anything.

Here are some outputs:

Code:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:04:BF:90:36:82  
          inet addr:192.168.0.1 Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::204:bfff:fe90:3682/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2049 errors:0 dropped:0 overruns:0 frame:0
          TX packets:181 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:265362 (259.1 KiB)  TX bytes:95235 (93.0 KiB)

Code:

#ping -s 1500 <troubled-computer>
1508 bytes from 192.168.0.1: icmp_seq=125 ttl=64 time=0.679 ms
1508 bytes from 192.168.0.1: icmp_seq=126 ttl=64 time=1.33 ms
1508 bytes from 192.168.0.1: icmp_seq=127 ttl=64 time=0.668 ms
1508 bytes from 192.168.0.1: icmp_seq=128 ttl=64 time=0.693 ms
1508 bytes from 192.168.0.1: icmp_seq=129 ttl=64 time=1.34 ms
1508 bytes from 192.168.0.1: icmp_seq=130 ttl=64 time=1.33 ms
1508 bytes from 192.168.0.1: icmp_seq=131 ttl=64 time=0.683 ms
1508 bytes from 192.168.0.1: icmp_seq=132 ttl=64 time=1.35 ms
1508 bytes from 192.168.0.1: icmp_seq=133 ttl=64 time=0.665 ms
1508 bytes from 192.168.0.1: icmp_seq=134 ttl=64 time=0.687 ms
1508 bytes from 192.168.0.1: icmp_seq=135 ttl=64 time=1.34 ms
1508 bytes from 192.168.0.1: icmp_seq=136 ttl=64 time=0.653 ms
1508 bytes from 192.168.0.1: icmp_seq=137 ttl=64 time=0.692 ms

--- 192.168.0.1 ping statistics ---
137 packets transmitted, 137 received, 0% packet loss, time 136001ms
rtt min/avg/max/mdev = 0.620/0.785/1.362/0.252 ms

Any further ideas? Just for kicks, I tested another Ethernet card (which uses another driver) and it worked just fine. It seems that the e100 driver is trying to do something which makes it to freeze. On windows it works fine too with E100.inf driver.

stlouis · 05-08-2008, 09:51 AM

Have you by chance updated your E100 linux driver to the latest version from Intels Website?

Jeff