["Michael Lynch" <michaellynch511@xxxxxxxxx>]

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