Re: [Ethereal-users] RE: TCP ACK packets with data in them...

[Guy Harris <guy@xxxxxxxxxx>]

On Fri, Feb 28, 2003 at 05:42:43PM -0800, Bob Eby wrote:
> So, now that I know what's happening what do I do with it?  I'm not
> exactly a network guru here, I don't know whether to go to Sun and
> Microsoft to make a stink about this,

I guess the first question is "is this a problem"?

You send 1600 bytes over the wire; that requies one 1460-byte TCP
segment and one 140-byte TCP segment.  As you're sending it in one call,
you presumably don't expect that the receiver will necessarily get
notified until the entire packet's worth of data arrives.

As such, there's no reason to expect any of the segments other than the
last one to have the PUSH bit set.

> or if I just attempt to ignore it

Is there even anything to ignore?

I.e., is it making any difference to your application?  If so, what
difference is it making?

Note that if you send N bytes over TCP, there is no guarantee that a
single receive operation on the other end of the connection will get
exactly N bytes - it might get more or fewer.  If you want to put packet
boundaries into a TCP stream, you will have to put them there yourself -
TCP exports a byte-stream abstraction, not a sequenced-packet
abstraction.

> and chock it up as one minor pothole on the information superhighway.

It's just a characteristic of TCP in general, and of the Windows 2000
implementation of TCP in particular - although other TCP implementations
might well do the same thing, i.e.  if you write more than a single TCP
segment's worth of data in a single "send data" operation, at least some
TCP implementations  might set the PUSH bit only on the last segment.

> As a start I was hoping someone would duplicate my results and help
> affirm that this isn't merely a problem in ethereal or WinPCap.

This is not the result of an Ethereal or WinPcap problem; there's no
need to try anything to affirm that.

WinPcap is just a passive tap, and doesn't magically cause PUSH bits to
disappear; Ethereal isn't even a tap, it's just an application that uses
a tap to capture packets, saves those packets, and then reads them in
and analyzes them.  You're seeing exactly what went out over the wire,
and it's perfectly legitimate according to the TCP specification.