[Martin Visser <martinvisser99@xxxxxxxxx>]

Michael,

Just done a bit more googling and reading. Certainly this Microsoft
customer service engineer thinks that a lot of problems are caused by
Large Segment Offload  -
http://blogs.msdn.com/b/psssql/archive/2010/02/21/tcp-offloading-again.aspx

There may be some value in turning this off, assuming it is on (at
least for a test) and seeing whether Wireshark starts behaving and
your application as well.

Regards, Martin

MartinVisser99@xxxxxxxxx



On 7 January 2011 22:17, Martin Visser <martinvisser99@xxxxxxxxx> wrote:
> Michael,
>
> "Large packets" are perfectly legal. It is possible that you are
> sending "jumbo" packets which are supported on gigabit ethernet.
> Normally you would need to configure that on your servers explicitly
> though and you need to make sure your clients are also similarly
> configured to support these. (The reason I didn't mention it earlier
> is that it I expect you would have mentioned jumbo packets if you were
> using thhese) It would be good for you to confirm that your server is
> using Large Segment Offload. This will in the NIC driver
> configuration.
> BTW Laura Chappell blogged about LSO at
> http://laurachappell.blogspot.com/2010/09/analyzing-huge-packets-tsolro.html
> and in fact I got a bit confused by it about a year or so ago.
>
> Yep, that wiki entry is a bit brief, and could be enhanced. The issue
> I guess is for to understand whether you found a bug or whether you
> aren't using Wireshark correctly of not. (Having a driver using LSO
> shouldn't be causing you to drop packets, I am not sure what is going
> on there). I have just found though a post and response from April
> 2010 that might shed some light. Have a look at
> http://www.wireshark.org/lists/wireshark-users/201004/msg00067.html
> and possibly try out Graham's suggestion at the bottom of
> http://www.wireshark.org/lists/wireshark-users/201004/msg00068.html
>
> One other reason you are getting that could be you are using a teaming
> adapter. If you are only using Wireshark to monitor a single physical
> NIC you might not be seeing all the traffic.
>
> Regards, Martin
>
> MartinVisser99@xxxxxxxxx
>
>
>
> On 7 January 2011 20:25, Michael Lynch <michaellynch511@xxxxxxxxx> wrote:
>> Thanks Martin
>>
>> I realise that sniffing traffic on the wire is more practical, but I am in a
>> test environment in this case.
>>
>> Wouldn't the machine on the mirrored port simply experience the same
>> problem?
>> (Oh wait, I see what you mean.. I am monitoring on the server... and the
>> large packets are out-going, and so therefore if I was sniffing on the wire
>> they would be of normal size.)
>>
>> However, I understand this is an open source project, and I really want to
>> help (I beleive many other users have experienced this problem with perhaps
>> no resolution as to what is really going on).
>> But I'm not about to delve in the ins and outs or even the code of WinPCap.
>>
>> For a novice user it would be helpful if either a) Large packets at least
>> had a mention, or b) The issue was at least mentioned in
>> http://wiki.wireshark.org/TCP_ACKed_lost_segment
>>
>> Thanks for explaining Martin.
>> I will post some net caps perhaps on monday back in the office.
>> I opened the NetMon capture file in Wireshark and the large packets are
>> listed and the "acked lost segments" are no longer there.
>> However I still saw some "acked lost segment", god knows where they are
>> comming from. (I think we have a few problems with this applications use of
>> SOAP, which is what led me here in the first place!!)
>>
>> Cheers!
>> Michael.
>>
>> ----- Original Message ----- From: "Martin Visser"
>> <martinvisser99@xxxxxxxxx>
>> To: "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
>> Sent: Friday, January 07, 2011 3:14 PM
>> Subject: Re: [Wireshark-users] Packets not captured, tcp acking lost
>> segments. Large packets
>>
>>
>>> Michael,
>>>
>>> Normally your server will be connected to a switch. If this is a
>>> manageable switch, you should be able to configure it to port-mirror,
>>> which means a copy of the traffic on one port is sent to another port.
>>> This will enable easy monitoring of your traffic, and you will see
>>> what is actually going on the wire. When I meant "avoid", it is more
>>> about making sure you see what is on the wire rather than the tricks
>>> that the driver might be doing. (I try to avoid installing Wireshark
>>> or Net Mon on production servers - not that it doesn't work, but I
>>> don't want my measuring application potentially affecting the normal
>>> performance of the server).
>>>
>>> I'm not sure if there is possibly an issue with WinPcap library not
>>> working properly on your box of not. You might want to post a small
>>> capture file showing what you saw with Wireshark and what you captured
>>> with Net Mon. (Also note that Wireshark can read Net Mon files - does
>>> this show the difference as well?)
>>>
>>> Regards, Martin
>>>
>>> MartinVisser99@xxxxxxxxx
>>>
>>>
>>>
>>> On 7 January 2011 14:27, Michael Lynch <michaellynch511@xxxxxxxxx> wrote:
>>>>
>>>> Thanks Martin
>>>>
>>>> I read up on LSO. It explains how these >4K packets are appearing
>>>>
>>>> Yes I am running Wireshark on the application server. I had a hard time
>>>> installing it on my switch!! No CD-rom drive!! :)
>>>> (I am not sure what you mean by 'Server Switch')
>>>>
>>>> But why is MS Net Mon seeing these large packets?
>>>>
>>>> Wireshark is providing misleading information and I don't think i'm the
>>>> only
>>>> one that is suffering major confusion.
>>>> I think my self lucky as I have witnessed the packets in NetMon.
>>>> Most users on the net seem to have presumed that packets are being lost!
>>>>
>>>>> Wireshark will see the large segments go out.
>>>>
>>>> But its not...?
>>>>
>>>>> You might want to capture on your server switch rather than the server
>>>>> to avoid seeing this.
>>>>
>>>> I don't want to avoid packets, I want to see the packets!
>>>>
>>>>
>>>>
>>>> Cheers
>>>> Michael.
>>>>
>>>>
>>>>
>>>> ----- Original Message ----- From: "Martin Visser"
>>>> <martinvisser99@xxxxxxxxx>
>>>> To: "Community support list for Wireshark"
>>>> <wireshark-users@xxxxxxxxxxxxx>
>>>> Sent: Friday, January 07, 2011 1:46 PM
>>>> Subject: Re: [Wireshark-users] Packets not captured, tcp acking lost
>>>> segments. Large packets
>>>>
>>>>
>>>>> It sounds like you are capturing traffic on the server rather than the
>>>>> wire. If your server NIC and driver does Large Segment Offload, the
>>>>> segmentation is done by the NIC, which allows the transfer from your
>>>>> kernel to the NIC do be done in larger chunks, meaning a more
>>>>> efficient transfer. Wireshark will see the large segments go out.
>>>>>
>>>>> You might want to capture on your server switch rather than the server
>>>>> to avoid seeing this.
>>>>>
>>>>> Regards, Martin
>>>>>
>>>>> MartinVisser99@xxxxxxxxx
>>>>>
>>>>>
>>>>>
>>>>> On 7 January 2011 11:25, Michael Lynch <michaellynch511@xxxxxxxxx>
>>>>> wrote:
>>>>>>
>>>>>> Hi All
>>>>>>
>>>>>> I think I've found something everyone may be interested in...
>>>>>>
>>>>>> In wireshark I am monitoring traffic of a SOAP application.
>>>>>>
>>>>>> Upon transfer of a BLOB, wire shark is showing many "Tcp ACKed lost
>>>>>> segment"
>>>>>> packets.
>>>>>> On top of this there is no evidence of any of the SOAP data, other than
>>>>>> the
>>>>>> initial header.
>>>>>>
>>>>>> Now I've search for this lost segment business, and no forums really
>>>>>> seem
>>>>>> to
>>>>>> have much of a solution other than perhaps disabling sequence analysis.
>>>>>>
>>>>>> However I think I have found the problem, but I have no understanding
>>>>>> of
>>>>>> the
>>>>>> whats and whys.
>>>>>>
>>>>>> In Microsoft Net Mon, the data packets ARE THERE!!!
>>>>>>
>>>>>> i.e
>>>>>> Sent packet: Captured Frame Length = 4434, Media Type = Ethernet...
>>>>>> Continuaion to packet #76.
>>>>>> Received packet: Ack
>>>>>>
>>>>>> The received packet is the only packet that shows up in Wireshark! (I
>>>>>> have
>>>>>> cross referenced the Packet ID)
>>>>>> Wireshark is NOT COLLECTING LARGE PACKETS!!
>>>>>>
>>>>>> I have no idea how packets THAT LARGE got onto the wire IN THE FIRST
>>>>>> PLACE!!
>>>>>>
>>>>>> What is going on??!! :)
>>>>>>
>>>>>> Cheers
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> ___________________________________________________________________________
>>>>>> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>>>>>> Archives: http://www.wireshark.org/lists/wireshark-users
>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>>>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>>>
>>>>>
>>>>>
>>>>> ___________________________________________________________________________
>>>>> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>>>>> Archives: http://www.wireshark.org/lists/wireshark-users
>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>>>
>>>>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>
>>>>
>>>> ___________________________________________________________________________
>>>> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>>>> Archives: http://www.wireshark.org/lists/wireshark-users
>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>>
>>>
>>> ___________________________________________________________________________
>>> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>>> Archives:    http://www.wireshark.org/lists/wireshark-users
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>
>>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>> ___________________________________________________________________________
>> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-users
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>