TCP error on Bubba2

Got problems with your B2 or B3? Share and get helped!
Post Reply
Posts: 28
Joined: 30 Jan 2007, 21:22

TCP error on Bubba2

Post by lkbrow1 » 30 Sep 2008, 09:57

With a capture via tshark I found the checksum in the TCP packet never changing from A53F even though the timestamp changes. Wire Shark identifies the checksum in error. The ACK on the connection had a good
checksum, it was only the data packets and the retransmission of that data that showed up the errors.

Frame 7 (72 bytes on wire, 72 bytes captured)
Ethernet II, Src: ExcitoEl_00:00:8f (00:22:02:00:00:8f), Dst: AsustekC_46:8f:97 (00:1d:60:46:8f:97)
Destination: AsustekC_46:8f:97 (00:1d:60:46:8f:97)
Source: ExcitoEl_00:00:8f (00:22:02:00:00:8f)
Type: IP (0x0800)
Internet Protocol, Src: XX.XX.XX.XX (XX.XX.XX.XX), Dst: XX.XX.XX.XX (XX.XX.XX.XX)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 58
Identification: 0xc4f3 (50419)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0xd0b7 [correct]
Source: xx.xx.xx.xx (xx.xx.xx.xx)
Destination: xx.xx.xx.xx (xx.xx.xx.xx)
Transmission Control Protocol, Src Port: 46673 (46673), Dst Port: pop3 (110), Seq: 1, Ack: 49, Len: 6
Source port: 46673 (46673)
Destination port: pop3 (110)
Sequence number: 1 (relative sequence number)
[Next sequence number: 7 (relative sequence number)]
Acknowledgement number: 49 (relative ack number)
Header length: 32 bytes
Flags: 0x18 (PSH, ACK)
Window size: 5840 (scaled)
Checksum: 0xa53f [incorrect, should be 0xa1e2 (maybe caused by "TCP checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
Options: (12 bytes)
Timestamps: TSval 697835, TSecr 1804250887
[SEQ/ACK analysis]
[TCP Analysis Flags]
[This frame is a (suspected) retransmission]
[The RTO for this segment was: 0.295913000 seconds]
[RTO based on delta from frame: 6]
Post Office Protocol
Request command: CAPA

Posts: 28
Joined: 30 Jan 2007, 21:22

Re: TCP error on Bubb2

Post by lkbrow1 » 16 Oct 2008, 17:52

It turns out this was caused by the silicon bug. Executing the line:
ethtool --offload eth0 tx off rx off
as root fixed the problem.

Post Reply