Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #673 > unrolled thread

Unusual Packet Capture Between Linux and Windows

Back to article view | Back to comp.os.linux.networking

Contents

  Unusual Packet Capture Between Linux and Windows Billy Mays <noway@nohow.com> - 2011-10-07 12:51 -0400
    Re: Unusual Packet Capture Between Linux and Windows J G Miller <miller@yoyo.ORG> - 2011-10-07 17:08 +0000
      Re: Unusual Packet Capture Between Linux and Windows Billy Mays <noway@nohow.com> - 2011-10-07 13:23 -0400
    Re: Unusual Packet Capture Between Linux and Windows Rick Jones <rick.jones2@hp.com> - 2011-10-07 19:04 +0000
    Re: Unusual Packet Capture Between Linux and Windows Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-10-07 22:39 +0300
      Re: Unusual Packet Capture Between Linux and Windows Billy Mays <noway@nohow.com> - 2011-10-11 12:31 -0400
    Re: Unusual Packet Capture Between Linux and Windows Andy Furniss <spam@andyfurniss.entadsl.com> - 2011-10-08 14:00 +0100
    Re: Unusual Packet Capture Between Linux and Windows Andy Furniss <spam@andyfurniss.entadsl.com> - 2011-10-10 09:39 +0100
      Re: Unusual Packet Capture Between Linux and Windows Billy Mays <noway@nohow.com> - 2011-10-11 11:40 -0400
        Re: Unusual Packet Capture Between Linux and Windows Andy Furniss <spam@andyfurniss.entadsl.com> - 2011-10-11 20:08 +0100
          Re: Unusual Packet Capture Between Linux and Windows Billy Mays <noway@nohow.com> - 2011-10-11 20:13 -0400
            Re: Unusual Packet Capture Between Linux and Windows Andy Furniss <spam@andyfurniss.entadsl.com> - 2011-10-13 10:52 +0100
              Re: Unusual Packet Capture Between Linux and Windows Billy Mays <noway@nohow.com> - 2011-10-19 10:29 -0400

#673 — 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

[toc] | [next] | [standalone]

#674

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.

[toc] | [prev] | [next] | [standalone]

#675

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

[toc] | [prev] | [next] | [standalone]

#676

Billy Mays <noway@nohow.com> 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...

[toc] | [prev] | [next] | [standalone]

#677

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

[toc] | [prev] | [next] | [standalone]

#690

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

[toc] | [prev] | [next] | [standalone]

#685

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.

[toc] | [prev] | [next] | [standalone]

#686

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.

[toc] | [prev] | [next] | [standalone]

#689

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

[toc] | [prev] | [next] | [standalone]

#691

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.

[toc] | [prev] | [next] | [standalone]

#692

On 10/11/2011 3:08 PM, Andy Furniss wrote:
> 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.
>
>


Trying to disable anything but gso seems to be disabled:

root@af:/# ethtool -K eth1 tso off
Cannot set device tcp segmentation offload settings: Operation not supported
root@af:/# ethtool -K eth1 gso off
root@af:/# ethtool -K eth1 rx off
Cannot set device rx csum settings: Operation not supported
root@af:/# ethtool -K eth1 tx off
Cannot set device tx csum settings: Operation not supported





How can these settings be turned on, but not able to be turned off? 
Would it be easier to just spend $20 and get a new nic?

Bill

[toc] | [prev] | [next] | [standalone]

#696

Billy Mays wrote:

> Trying to disable anything but gso seems to be disabled:
>
> root@af:/# ethtool -K eth1 tso off
> Cannot set device tcp segmentation offload settings: Operation not
> supported
> root@af:/# ethtool -K eth1 gso off
> root@af:/# ethtool -K eth1 rx off
> Cannot set device rx csum settings: Operation not supported
> root@af:/# ethtool -K eth1 tx off
> Cannot set device tx csum settings: Operation not supported

Hmm, maybe search for you nic/driver and see if a bug has been 
reported/fixed.

> How can these settings be turned on, but not able to be turned off?
> Would it be easier to just spend $20 and get a new nic?

It may be quicker/less hassle - but I have no idea if it will actually 
fix your main problem. With tso off at least the tcpdumps should match.

[toc] | [prev] | [next] | [standalone]

#716

On 10/13/2011 5:52 AM, Andy Furniss wrote:
> Billy Mays wrote:
>
>> Trying to disable anything but gso seems to be disabled:
>>
>> root@af:/# ethtool -K eth1 tso off
>> Cannot set device tcp segmentation offload settings: Operation not
>> supported
>> root@af:/# ethtool -K eth1 gso off
>> root@af:/# ethtool -K eth1 rx off
>> Cannot set device rx csum settings: Operation not supported
>> root@af:/# ethtool -K eth1 tx off
>> Cannot set device tx csum settings: Operation not supported
>
> Hmm, maybe search for you nic/driver and see if a bug has been
> reported/fixed.
>
>> How can these settings be turned on, but not able to be turned off?
>> Would it be easier to just spend $20 and get a new nic?
>
> It may be quicker/less hassle - but I have no idea if it will actually
> fix your main problem. With tso off at least the tcpdumps should match.
>

For the sake of posterity, I believe I fixed the problem by updating my 
kernel from 2.6.32-21-generic-pae to 2.6.38-11-generic-pae.  Hope this 
helps someone in the future.

Bill

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web