Unusual Packet Capture Between Linux and Windows

Hey All,


I am trying to solve a networking problem between my Windows Desktop and
a 32 bit Ubuntu 10.04 Server. I believe that somewhere in the network
stack traffic is being modified in a hard to detect manner.

The problem I noticed came from when I tried to do a packet capture on
both Linux (using tcpdump) and on Windows (using Wireshark). I
attempted to download a file from an Apache server running on the linux
box to the Windows box. Recording the traffic from linux seemed to show
that the transit worked, however from the Windows side Wireshark
reported a number of Dup Acks and many smaller packets with slightly
different data in them.


I have flushed all my iptables rules on the linux box so I am not sure
what could cause the discrepancy. I can include the pcap files if needed.

Any help is appreciated,
Bill

On Friday, October 7th, 2011 at 12:51:20h -0400, Billy Mays wrote:

> I am trying to solve a networking problem between my Windows Desktop and
> a 32 bit Ubuntu 10.04 Server.

It would help if you provided details on how the Windoze machine is
connected to the Ubuntu server, and if you are talking only about IPv4
traffic.

On 10/7/2011 1:08 PM, J G Miller wrote:
> On Friday, October 7th, 2011 at 12:51:20h -0400, Billy Mays wrote:
>
>> I am trying to solve a networking problem between my Windows Desktop and
>> a 32 bit Ubuntu 10.04 Server.
>
> It would help if you provided details on how the Windoze machine is
> connected to the Ubuntu server, and if you are talking only about IPv4
> traffic.

My Winders Machine is a 64bit Vista (I know, I know) which is directly
connected to the Linux box:


Internet <=====> (eth0) Linux (eth1) <=======> Windows.

My linux box also doubles as my Nat, but I had that disabled for my
test. I also tried replacing my Windows box with a 32 bit Ubuntu 10.04
Laptop, so I believe the problem is on the server side. I can provide
any other details if needed.

Bill

Billy Mays <(E-Mail Removed)> wrote:
> I am trying to solve a networking problem between my Windows Desktop
> and a 32 bit Ubuntu 10.04 Server. I believe that somewhere in the
> network stack traffic is being modified in a hard to detect manner.

> The problem I noticed came from when I tried to do a packet capture
> on both Linux (using tcpdump) and on Windows (using Wireshark). I
> attempted to download a file from an Apache server running on the
> linux box to the Windows box. Recording the traffic from linux
> seemed to show that the transit worked, however from the Windows
> side Wireshark reported a number of Dup Acks and many smaller
> packets with slightly different data in them.

> I have flushed all my iptables rules on the linux box so I am not
> sure what could cause the discrepancy. I can include the pcap files
> if needed.

Have you computed/compared the checksum/hash/whatnot of the file
you've downloaded and found it differs between the original on the
Linux system and the copy on the Windows system?

The many smaller packets - do they actually contain data, or might
they be ACK only segments and perhaps you are looking at the padding?

rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On 7.10.11 7:51 , Billy Mays wrote:
> Hey All,
>
>
> I am trying to solve a networking problem between my Windows Desktop and
> a 32 bit Ubuntu 10.04 Server. I believe that somewhere in the network
> stack traffic is being modified in a hard to detect manner.
>
> The problem I noticed came from when I tried to do a packet capture on
> both Linux (using tcpdump) and on Windows (using Wireshark). I attempted
> to download a file from an Apache server running on the linux box to the
> Windows box. Recording the traffic from linux seemed to show that the
> transit worked, however from the Windows side Wireshark reported a
> number of Dup Acks and many smaller packets with slightly different data
> in them.
>
>
> I have flushed all my iptables rules on the linux box so I am not sure
> what could cause the discrepancy. I can include the pcap files if needed.
>
> Any help is appreciated,
> Bill


Check that there are no duplicate IP or MAC addresses in the network,
they can cause those extra packets (if they are real). To be sure,
remove the cable to your connection to the Internet for the test
duration.

Check the captures from each end with Wireshark - it can read a
pcap file and decode it. To get at the TCP payload, click the
'Follow TCP stream' option for both and check results.

If there are still problems, please post the outputs of:

iptables -nLv
route -n
ifconfig -a

from the Linux machine.

The IP details from Windows ipconfig/all (if there is such in the
new box anymore) will be of help.

--

Tauno Voipio

Billy Mays wrote:
> Hey All,
>
>
> I am trying to solve a networking problem between my Windows Desktop and
> a 32 bit Ubuntu 10.04 Server. I believe that somewhere in the network
> stack traffic is being modified in a hard to detect manner.

If it's a gig nic

ethtool -k eth0

will tell you if it's using tcp segmentation offload.

If it is you can also turn it off with ethtool.

Billy Mays wrote:
> Hey All,
>
>
> I am trying to solve a networking problem between my Windows Desktop and
> a 32 bit Ubuntu 10.04 Server. I believe that somewhere in the network
> stack traffic is being modified in a hard to detect manner.


If it's a gig nic

ethtool -k eth0

will tell you if it's using tcp segmentation offload.

If it is you can also turn it off with ethtool.

On 10/10/2011 4:39 AM, Andy Furniss wrote:
> Billy Mays wrote:
>> Hey All,
>>
>>
>> I am trying to solve a networking problem between my Windows Desktop and
>> a 32 bit Ubuntu 10.04 Server. I believe that somewhere in the network
>> stack traffic is being modified in a hard to detect manner.
>
>
> If it's a gig nic
>
> ethtool -k eth0
>
> will tell you if it's using tcp segmentation offload.
>
> If it is you can also turn it off with ethtool.

eth1 is the one that seems to be having the problem, while eth0 is an
interface I know to work (just to clarify the output below). I ran
ethtool on both of my interfaces and included only the differences
between them. I must admit I am not familiar with specifics of what
they do:

Offload parameters for eth1:

tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
generic-segmentation-offload: on


Offload parameters for eth0:

tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
generic-segmentation-offload: off



Which of these are safe to change? Would any of these possibly be the
source of my error?

Thanks for any input,
Bill

On 10/7/2011 3:39 PM, Tauno Voipio wrote:
> On 7.10.11 7:51 , Billy Mays wrote:
>> Hey All,
>>
>>
>> I am trying to solve a networking problem between my Windows Desktop and
>> a 32 bit Ubuntu 10.04 Server. I believe that somewhere in the network
>> stack traffic is being modified in a hard to detect manner.
>>
>> The problem I noticed came from when I tried to do a packet capture on
>> both Linux (using tcpdump) and on Windows (using Wireshark). I attempted
>> to download a file from an Apache server running on the linux box to the
>> Windows box. Recording the traffic from linux seemed to show that the
>> transit worked, however from the Windows side Wireshark reported a
>> number of Dup Acks and many smaller packets with slightly different data
>> in them.
>>
>>
>> I have flushed all my iptables rules on the linux box so I am not sure
>> what could cause the discrepancy. I can include the pcap files if needed.
>>
>> Any help is appreciated,
>> Bill
>
>
> Check that there are no duplicate IP or MAC addresses in the network,
> they can cause those extra packets (if they are real). To be sure,
> remove the cable to your connection to the Internet for the test
> duration.
>
> Check the captures from each end with Wireshark - it can read a
> pcap file and decode it. To get at the TCP payload, click the
> 'Follow TCP stream' option for both and check results.
>
> If there are still problems, please post the outputs of:
>
> iptables -nLv
> route -n
> ifconfig -a
>
> from the Linux machine.
>
> The IP details from Windows ipconfig/all (if there is such in the
> new box anymore) will be of help.
>

No dupe MAC address, also the pcap files are limited to just the http port.

Here are the networking outputs:

root@af:/# iptables-save
# Generated by iptables-save v1.4.4 on Tue Oct 11 12:30:32 2011
*filter
:INPUT ACCEPT [12:1426]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6:879]
COMMIT
# Completed on Tue Oct 11 12:30:32 2011
# Generated by iptables-save v1.4.4 on Tue Oct 11 12:30:32 2011
*mangle
:PREROUTING ACCEPT [12:1426]
:INPUT ACCEPT [12:1426]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6:879]
:POSTROUTING ACCEPT [6:879]
COMMIT
# Completed on Tue Oct 11 12:30:32 2011
# Generated by iptables-save v1.4.4 on Tue Oct 11 12:30:32 2011
*nat
:PREROUTING ACCEPT [2:142]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Tue Oct 11 12:30:32 2011



* on my machine the -nLv arguments complained about an error, so I hope
the iptables-save output is sufficient.




root@af:/# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
128.61.70.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 128.61.70.1 0.0.0.0 UG 100 0 0 eth0



root@af:/# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:14:d1:17:56:f4
inet addr:128.61.70.70 Bcast:128.61.70.255 Mask:255.255.255.0
inet6 addr: fec0::8:214:d1ff:fe17:56f4/64 Scope:Site
inet6 addr: 2002:803d:4634:8:214:d1ff:fe17:56f4/64 Scope:Global
inet6 addr: 2002:803d:4619:c:214:d1ff:fe17:56f4/64 Scope:Global
inet6 addr: fec0::c:214:d1ff:fe17:56f4/64 Scope:Site
inet6 addr: fe80::214:d1ff:fe17:56f4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:180483631 errors:0 dropped:477 overruns:0 frame:0
TX packets:130226712 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4244833066 (4.2 GB) TX bytes:536028103 (536.0 MB)
Interrupt:19 Base address:0xc000

eth1 Link encap:Ethernet HWaddr 6c:f0:49:5c:df:ce
inet addr:192.168.5.1 Bcast:192.168.255.255 Mask:255.255.0.0
inet6 addr: fe80::6ef0:49ff:fe5c:dfce/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:65985246 errors:42 dropped:0 overruns:0 frame:22
TX packets:76048156 errors:0 dropped:0 overruns:0 carrier:234
collisions:0 txqueuelen:1000
RX bytes:2566577847 (2.5 GB) TX bytes:2776372800 (2.7 GB)
Interrupt:26

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12712273 errors:0 dropped:0 overruns:0 frame:0
TX packets:12712273 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2194810978 (2.1 GB) TX bytes:2194810978 (2.1 GB)





Thanks,
Bill

Billy Mays wrote:

> eth1 is the one that seems to be having the problem, while eth0 is an
> interface I know to work (just to clarify the output below). I ran
> ethtool on both of my interfaces and included only the differences
> between them. I must admit I am not familiar with specifics of what they
> do:
>
> Offload parameters for eth1:
>
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: on
> generic-segmentation-offload: on
>
>
> Offload parameters for eth0:
>
> tx-checksumming: off
> scatter-gather: off
> tcp-segmentation-offload: off
> generic-segmentation-offload: off
>
>
>
> Which of these are safe to change? Would any of these possibly be the
> source of my error?

I would try

ethtool -K eth1 tso off

tcp-segmentation-offload means that you nic is doing some of the work to
do with tcp that the kernel netcode usually does. This could be why you
see different dumps as tcpdump will be seeing the packets before the nic
has segmented them.

It should be safe to turn off the others (tx sg gso) if you need to test
further.