Laura mentions that her Wireshark did pick up these LSO packets in the
trace, so I guess I was just unlucky.
As Graham suggested, I will give a try the "Edit | Preferences | Expand
Protocols and find IP | Check "Support packet-capture from IP TSO-enabled
hardware".
I'll let you know if that options resolves the incomplete capture trace.

It really bugs me, these fancy round-about attempts at improving performance
when they just end up complicating things.
I would suggest to the IEEEE that switches and nics simply support 32K
packets, and PMTU discovery would automatically ajust for individual neworks
as required. Problem solved :)

> 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@gmail.com
>
>
>
> On 7 January 2011 22:17, Martin Visser <martinvisser99@gmail.com> 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@gmail.com
>>
>>
>>
>> On 7 January 2011 20:25, Michael Lynch <michaellynch511@gmail.com> 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@gmail.com>
>>> To: "Community support list for Wireshark"
>>> <wireshark-users@wireshark.org>
>>> 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@gmail.com
>>>>
>>>>
>>>>
>>>> On 7 January 2011 14:27, Michael Lynch <michaellynch511@gmail.com>
>>>> 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@gmail.com>
>>>>> To: "Community support list for Wireshark"
>>>>> <wireshark-users@wireshark.org>
>>>>> 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@gmail.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7 January 2011 11:25, Michael Lynch <michaellynch511@gmail.com>
>>>>>> 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@wireshark.org>
>>>>>>> Archives: http://www.wireshark.org/lists/wireshark-users>>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users>>>>>>> mailto:wireshark-users-request@wireshark.org?subject=unsubscribe
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ___________________________________________________________________________
>>>>>> Sent via: Wireshark-users mailing list
>>>>>> <wireshark-users@wireshark.org>
>>>>>> Archives: http://www.wireshark.org/lists/wireshark-users>>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users>>>>>>
>>>>>> mailto:wireshark-users-request@wireshark.org?subject=unsubscribe
>>>>>
>>>>>
>>>>> ___________________________________________________________________________
>>>>> Sent via: Wireshark-users mailing list <wireshark-users@wireshark.org>
>>>>> Archives: http://www.wireshark.org/lists/wireshark-users>>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users>>>>> mailto:wireshark-users-request@wireshark.org?subject=unsubscribe
>>>>>
>>>>
>>>> ___________________________________________________________________________
>>>> Sent via: Wireshark-users mailing list <wireshark-users@wireshark.org>
>>>> Archives: http://www.wireshark.org/lists/wireshark-users>>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users>>>>
>>>> mailto:wireshark-users-request@wireshark.org?subject=unsubscribe
>>>
>>> ___________________________________________________________________________
>>> Sent via: Wireshark-users mailing list <wireshark-users@wireshark.org>
>>> Archives: http://www.wireshark.org/lists/wireshark-users>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users>>> mailto:wireshark-users-request@wireshark.org?subject=unsubscribe
>>>
>>
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@wireshark.org>
> Archives: http://www.wireshark.org/lists/wireshark-users> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users>
> mailto:wireshark-users-request@wireshark.org?subject=unsubscribe