My setup is the following: Host_A is a firewall (SuSE 10.2) connected to the internet and to the LAN switch. Host_B (SuSE 11.1) is part of the LAN and connected to the switch.
Data transfer (using scp) from Host_B to Host_A works at the expected speed (about 11.2 MB/s). However, transfers from Host_A to Host_B are VERY slow at about 56 KB/s. There are no error messages.
However, looking at the packets with Wireshark shows many errors for transfers from Host_A to Host_B. This is an example:
I haven’t seen any issues in the VM I setup (really fast transfers
though of course no real “hardware” in the VM to be broken) but I guess
hardware is a possibility. Can you setup another system on the network
to test to/from as well? Maybe another 11.1 system? Have you tried
getting the LAN trace w/Wireshark from the other box (whichever is the
“other” box) to see if the results vary at all? That’s definitely too
slow no matter how much overhead SSH applies.
Good luck.
vodoo wrote:
> Hi
>
> My setup is the following: Host_A is a firewall (SuSE 10.2) connected
> to the internet and to the LAN switch. Host_B (SuSE 11.1) is part of the
> LAN and connected to the switch.
>
> Data transfer (using scp) from Host_B to Host_A works at the expected
> speed (about 11.2 MB/s). However, transfers from Host_A to Host_B are
> VERY slow at about 56 KB/s. There are no error messages.
>
> However, looking at the packets with Wireshark shows many errors for
> transfers from Host_A to Host_B. This is an example:
>
> No. Time Source Destination
> Protocol Info
> 29 0.209087 192.168.100.100 192.168.100.80 TCP
> 6334
>> 27426 [ECN] Seq=1 Win=24558 [TCP CHECKSUM INCORRECT] Len=1408
>
> Frame 29 (1482 bytes on wire, 1482 bytes captured)
> Arrival Time: Dec 31, 2008 10:23:57.914786000
> [Time delta from previous captured frame: 0.000561000
> seconds]
> [Time delta from previous displayed frame: 0.000561000 seconds]
> [Time since reference or first frame: 0.209087000 seconds]
> Frame Number: 29
> Frame Length: 1482 bytes
> Capture Length: 1482 bytes
> [Frame is marked: True]
> [Protocols in frame: eth:ip:tcp:data]
> [Coloring Rule Name: Checksum Errors]
>
> [Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
> || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1]
> Ethernet II, Src: AsustekC_a9:0e:03 (00:1f:c6:a9:0e:03),
> Dst: IntelCor_96:20:d2 (00:1c:c0:96:20:d2)
> Destination: IntelCor_96:20:d2 (00:1c:c0:96:20:d2)
> Address: IntelCor_96:20:d2 (00:1c:c0:96:20:d2)
> … …0 … … … … = IG bit: Individual
> address (unicast)
> … …0. … … … … = LG bit: Globally unique
> address (factory default)
> Source: AsustekC_a9:0e:03 (00:1f:c6:a9:0e:03)
> Address: AsustekC_a9:0e:03 (00:1f:c6:a9:0e:03)
> … …0 … … … … = IG bit: Individual
> address (unicast)
> … …0. … … … … = LG bit: Globally unique
> address (factory default)
> Type: IP (0x0800)
> Internet Protocol, Src: 192.168.100.100 (192.168.100.100),
> Dst: 192.168.100.80 (192.168.100.80)
> Version: 4
> Header length: 20 bytes
> Differentiated Services Field: 0x08 (DSCP 0x02: Unknown DSCP; ECN:
> 0x00)
> 0000 10… = Differentiated Services Codepoint: Unknown (0x02)
> … …0. = ECN-Capable Transport (ECT): 0
> … …0 = ECN-CE: 0
> Total Length: 1468
> Identification: 0xbd7b (48507)
> Flags: 0x04 (Don’t Fragment)
> 0… = Reserved bit: Not set
> .1… = Don’t fragment: Set
> …0. = More fragments: Not set
> Fragment offset: 0
> Time to live: 64
> Protocol: TCP (0x06)
> Header checksum: 0x2db3 [correct]
> [Good: True]
> [Bad : False]
> Source: 192.168.100.100 (192.168.100.100)
> Destination: 192.168.100.80 (192.168.100.80)
> Transmission Control Protocol, Src Port: 6334 (6334), Dst Port: 27426
> (27426),
> Seq: 1, Len: 1408
> Source port: 6334 (6334)
> Destination port: 27426 (27426)
> Sequence number: 1 (relative sequence number)
> [Next sequence number: 1409 (relative sequence number)]
> Acknowledgment number: Broken TCP. The acknowledge field is
> nonzero while the ACK flag is not set
> Header length: 40 bytes
> Flags: 0x40 (ECN)
> 0… … = Congestion Window Reduced (CWR): Not set
> .1… … = ECN-Echo: Set
> …0. … = Urgent: Not set
> …0 … = Acknowledgment: Not set
> … 0… = Push: Not set
> … .0… = Reset: Not set
> … …0. = Syn: Not set
> … …0 = Fin: Not set
> Window size: 24558
> Checksum: 0xaa68 [incorrect, should be 0x8cd9 (maybe caused
> by “TCP checksum offload”?)]
> [Good Checksum: False]
> [Bad Checksum: True]
> Options: (20 bytes)
> TCP MD5 signature (option length = 130 bytes says option
> goes past end of options)
> Data (1408 bytes)
>
> Is this a probable hardware problem or something wrong with my setup or
> a software (driver) problem?
>
> Any insight how to debug this would be appreciated.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org