TCP segment length 0

[k***@gmail.com]

Hi,

Is sending a packet with tcp.len =0 valid ? Is there a bug on BSD
system which prevent this. Thanks for reading.

Regards

[Rick Jones]

Post by k***@gmail.com
Is sending a packet with tcp.len =0 valid ?

IIRC, no, it is not valid. How would a receiving TCP be able to
ACKnowledge something that occupies zero bytes in the sequence number
space?

Post by k***@gmail.com
Is there a bug on BSD system which prevent this.

Given the above, I'd say no :)

A zero-length message sent via _UDP_ is valid though. But there are
no guarantees you will be told that it likely didn't make it to the
other end.

rick jones

[k***@gmail.com]

Isit not for the TCP keepalive length=0? But for TCP keep alive seq
number is -1. But in my case It's not keep-alive packet the sequence
number being not -1. But when this packet of tcp.len = 0 is sent
somehow i'm getting TCP reset after few packet exchanges So thats why I
suspect any BSD bugs ..?.

[Rick Jones]

Isit not for the TCP keepalive length=0? But for TCP keep alive seq
number is -1.

I do not believe that a TCP keepalive segment has a sequence number of
-1. The sequence number is, IIRC, selected to be to the "left" of the
window so the receiving TCP will "accept" it (ie not abort) and
generate an immediate ACK based on the "arrival of out of order data"
rule.

But in my case It's not keep-alive packet the sequence number being
not -1. But when this packet of tcp.len = 0 is sent somehow i'm
getting TCP reset after few packet exchanges So thats why I suspect
any BSD bugs ..?.

I read your initial post as asking if it was OK to try to send a
zero-length segment via TCP - ie that you were trying to make a send()
call with a length of zero and have that cause a zero-length TCP
segment to be transmitted.

Do you believe that the stack is actually sending zero-length TCP
segments that are not simply "bare" ACKs? Do you have a packet trace
to share?

Do you have an application that is explicitly trying to call send()
with a zero-length buffer?

rick jones

[k***@gmail.com]

Yes the application is sending packet with tcp len 0. Question was is
it valid ?

Below is the packet as seen in ethereal. (Is there better way to share
the trace from ethereal.)

"Transmission Contrl Protocol, Src Port: 8100 (8100), Dst Port: 8489
(8489), seq: 30653, ack:0, Len:0"

Thanks for the help.

Post by Rick Jones

Isit not for the TCP keepalive length=0? But for TCP keep alive seq
number is -1.

I do not believe that a TCP keepalive segment has a sequence number of
-1. The sequence number is, IIRC, selected to be to the "left" of the
window so the receiving TCP will "accept" it (ie not abort) and
generate an immediate ACK based on the "arrival of out of order data"
rule.

But in my case It's not keep-alive packet the sequence number being
not -1. But when this packet of tcp.len = 0 is sent somehow i'm
getting TCP reset after few packet exchanges So thats why I suspect
any BSD bugs ..?.

I read your initial post as asking if it was OK to try to send a
zero-length segment via TCP - ie that you were trying to make a send()
call with a length of zero and have that cause a zero-length TCP
segment to be transmitted.
Do you believe that the stack is actually sending zero-length TCP
segments that are not simply "bare" ACKs? Do you have a packet trace
to share?
Do you have an application that is explicitly trying to call send()
with a zero-length buffer?
rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
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...

[k***@gmail.com]

Based on my search on internet looks like sending zero-length data is
valid. But not sure BSD had any bug on this? ANy opinion pl.?

[Albert Manfredi]

Post by k***@gmail.com
Isit not for the TCP keepalive length=0? But for TCP keep alive seq
number is -1. But in my case It's not keep-alive packet the sequence
number being not -1. But when this packet of tcp.len = 0 is sent
somehow i'm getting TCP reset after few packet exchanges So thats why I
suspect any BSD bugs ..?.

Keep-alive segments, if used at all, may contain one byte of garbage
data or may contain no data at all, and a sequence number of -1. What
I'm saying is that just because keep-alives contain "no data" does not
mean that either the TCP header length or the IP total length field
would be set to 0.

A TCP/IP packet with "no data" should still have a IP Total Length of at
least 40 (bytes), and a TCP header length of 5 (32-bit words), no? I
don't see where a 0 is specified anywhere for a length field of any
sort.

Bert

[Albert Manfredi]

Post by Albert Manfredi
A TCP/IP packet with "no data" should still have a IP Total Length of
at least 40 (bytes), and a TCP header length of 5 (32-bit words), no?
I don't see where a 0 is specified anywhere for a length field of any
sort.

Sorry, that would be 80 bytes minimum IP Total Length. Half for the IP
header, the other half for the TCP header.

Bert

[k***@gmail.com]

Yes, your are right I'm talking about the TCP with data length 0,
headers are still valid

[Albert Manfredi]

Post by k***@gmail.com
Hi,
Is sending a packet with tcp.len =0 valid ? Is there a bug on BSD
system which prevent this. Thanks for reading.

TCP length? You mean header length? The only length field in the TCP
header is "header length," which is the number of 32-bit words in the
TCP header. It's required because the TCP header is variable length,
depending if you use the options.

I don't see how header length can legitimately be 0 for TCP. The length
of the entire packet would be in the IP header, not the TCP header, and
since that value includes headers and data, I don't see how it could
legimately be 0 either.

Bert

[k***@gmail.com]

No, I was referring to segment length.