TCP handshake problem

[Uros_1]

We can not access the web page www.marand.si from any hpux 11.x server with the browser. This can be demonstrated from several different site s with different infrastructure and different HPUX servers. The only common thing is the version of HPUX 11.x.
As we see the problem, HPUX server does not follow standard threeway tcp handshake procedure!
1. hpux sends SYN
2. hpux receives syn-ack
3. hpux sends ack AND "GET / HTTP/1.0" in the same packet
4. hpux resends ack AND "GET / HTTP/1.0" in the same packet
5.hpux resends ack AND "GET / HTTP/1.0" in the same packet
6 server closes the session

We have no problem accessing the web site with HPUX 10.20 for example!!

I enclose ethereal dump file!

[harry d brown jr]

You do realize that the BROWSER, and I have no clue as to which one you are talking about, is NOT PART OF THE OPERATING SYSTEM!

And maybe if we knew WHICH web server you are talking about, it might help?

live free or die
harry

[Uros_1]

THX for your answer!
The details:
-the server we try to connect to is www.marand.si
-the web server they have is apache 1.3.20
-the OS they have is RH LInux (nmap fingerfrint)

The problem can be reproduced by nc (netcat) or wget, so it is not a browser issue nor it is a apache 1.3.20 issue since connection to other servers(apache 1.3.20) can be established. It could be their RH OS, but then why conection to their server works from any other server or client computer I have ?

BTW, I strongly believe that OS is responsible for session establishment and that makes me believe that problem is somehow related to HPUX TCP session establishment procedure (TCP stack), but I am willing to look at other opinions!

I would please ask you if you could take a look at the tcpdump file ant tell me your opinion!

[harry d brown jr]

For some reason I can not open the tcp "dump" file. How about attaching it as a text file?

live free or die
harry

[Ron Kinner]

Unable to read your tcpdump file.

However, 1.3.20 is obsolete. There was a bug corrected in 1.3.27 where the parsing of the HTTP/1.0 message was case sensitive. This may be your problem rather than the presence of the data within the ACK. This is actually a valid construct and the receiving unit is required to store this data until the connection is established then process it. Even if that doesn't fix your problem you need to upgrade before someone exploits the known vulnerabilities of 1.3.20.

I presume the HPUX is able to go to other sites like att.com, google.com, yahoo.com, or hp.com?

Ron

[Uros_1]

This is tcpdump:

13:47:07.416579 hp.netsec.si.53352 > marwww.marand.si.http: S 3732374182:3732374182(0) win 0 (DF)
13:47:07.434504 marwww.marand.si.http > hp.netsec.si.53352: S 3920179087:3920179087(0) ack 3732374183 win 512
13:47:07.436919 hp.netsec.si.53352 > marwww.marand.si.http: P 1:285(284) ack 1 win 32768 (DF)
13:47:08.972504 hp.netsec.si.53352 > marwww.marand.si.http: P 1:285(284) ack 1 win 32768 (DF)
13:47:12.042612 hp.netsec.si.53352 > marwww.marand.si.http: P 1:285(284) ack 1 win 32768 (DF)
13:47:18.162825 hp.netsec.si.53352 > marwww.marand.si.http: P 1:285(284) ack 1 win 32768 (DF)
13:47:27.381561 marwww.marand.si.http > hp.netsec.si.53352: R 3920179088:3920179088(0) win 512

tcpdump was taken on RH Linux. I also include file saved as modified libcap(tcpdump). The dump was taken with ethereal!

If you look at the packets. Shouldn't the third packet be just ACK and then another packet with data request?

[rick jones]

there is nothing immediately obvious in the trace. I was going to postulate that having he DF bit set was an issue, but if that were the case, then the initial SYN would remain unACKed by the remote TCP rather than the initial request.

still, i suppose that if there is a really small MTU between the two systems and the IVMP messages are not being generated it could cause a blackhole - so, just on a lark, you might try setting ip_ptmu_strategy to a value of 0. however, i'd be surprised if that was the problem.

one possibility is that the remote TCP does not like seeing data in the ACK of a SYN|ACK, but data in the ACK of a SYN|ACK is perfectly valid. so either the remote stack, or some intervening firewall is fubar

what does the working access look like from the 10.20 machine?

[Uros_1]

THX for your answer,
I was not aware that sending a DATA request in response to syn-ack is a valid response (At least I could not find a RFC or any other doc)!
Then I also noticed that when I try to establish a connection from any other machine I get standard TCP handshake:
syn, syn-ack,ack and then there is a new packet with data request!

I also found out that if I use :
echo "GET / HTTP/1.0 \n\n" | nc www.marand.si 80 it fails with same packet order as with the browser but if I use:
telnet www.marand.si 80 and wait for conection establishment and the write GET / HTTP/1.0 then I get proper response(web page content)! So it seems that the problem occours when application requests the data before the TCP session is established! or something like that!

[Samantha Fetter]

Although it's been a while since this was posted, after upgrading a proxy server to 11.0 we started experiencing the same thing with 3 websites.

What I found on those sites, is that in their SYN-ACK packet, they had a window size set to ZERO! So only the "G" (first character of the GET request) would be allowed through, as it should, for testing to see if the window size has increased. I don't have exact server info on me at the moment, but I see:

us: SYN (normal win size)
site: SYN-ACK win 0
us: ACK + (1) byte of data (normal win size)
site: SYN-ACK win 0

so on and so forth. Whereas when going from 10.20, I see:

us: SYN (normal win size)
site: SYN-ACK win 0
us: ACK
site: ACK win of "normal" size
us: (18 bytes of data)
You get the picture.

I thought I'd post this in case others are experiencing it as well, in hopes to help alleviate the craziness I've been through in trying to troubleshoot this!

I also did the telnet to our proxy on the listening port, and did the "GET http://site.com HTTP/1.0" and hit return a few times and it showed up as the second example above, similar to the results found by the person reporting this issue.

Regards

[Uros_1]

Hi,


I have also reported the problem to HP. They answered suggesting changing mtu discovery parameter (ndd), which did not help in my case!

After a week or two, we noticed that everything is OK. (access to web site was successful). I checked their firewall OS version and it was different, so my conclusion was that they upgraded their firewall and the problem was gone!

I have also tcpdumped for a while and I have found some other sites with which our server was communicating with above mentioned tcp handshake. So I believe that this is not HPUX 11.0 problem but ......

Best regards

Uros

[rick jones]

Given the season...

It is also valid to have what are refered to as "Christmas Tree" segments with SYN, ACK, FIN and data in them :)

If you come across a site where they appear to not accept segments with data in the SYN|ACK you might send a polite note to the webmaster of that site mentioning the problem to them. Best to get root cause fixed rather than treating symptoms

[Uros_1]

THX for your answer!

I am aware of Xmas packets but I was not aware that they could be part of a "real" session not just part of network scan!

I would also appreciate a pointer where could I find information that DATA could be sent in the last TCP 3way packet. I have read several books about TCP and I was not able to find it.

Could you help ?

THX again

Uros

[Samantha Fetter]

I definitely agree as far as treating root cause, rather than the symptoms.

I, too, have been searching for anything that definitively says whether you can or cannot send data with that final piece of the handshake (ACK).

The only thing I've found is commentary saying that tcp/ip shouldn't accept data in a packet *without* the ACK flag set, but nothing about it having to accept data in a packet with it set, be it in the handshake or not.

Cheers!

[rick jones]

I was under the impression that it was valid to have data in a segment without the ACK bit set - that the ACK bit only said whether or not the ackno field of the header was valid.

As far as data in SYN's, from rfc793, section 3.4:

Several examples of connection initiation follow. Although these examples do not show connection synchronization using data-carrying segments, this is perfectly legitimate, so long as the receiving TCP doesn't deliver the data to the user until it is clear the data is valid (i.e., the data must be buffered at the receiver until the connection reaches the ESTABLISHED state).

[Samantha Fetter]

Thank you, Rick! I hadn't yet scoured the entire rfc (sheepish grin) but was doing quick-overs.

Excellent information.
Cheers

[rick jones]

no need for the sheepish grin, i suspect i've never read the whole thing either...

[Uros_1]

I completly agree with Samantha and you Rick, regarding curing the root problem, but since I could not find any information that HPUX sent valid packets and it worked from other OSes, I could not just blame the other party, allthough I suspected it from the begining.

Thank you for the rfc pointer and I must say that lately most of the solutions for may problems comes from rfc....

Thanks again Rick for a valuable hint and
mery Xmas :-)!

Uros