In <qnirqrrmrrbet.j1foyi0.pminews (AT) news (DOT) mozilla.com>, on 06/25/2006
at 04:59 PM, "Dave Saville" <dave (AT) deezee-nospam (DOT) orgsaid:

>>There could be any number of reasons for this. You need to use iptrace on
>>the S/2 side and compare the ipformat results after normalizing the
>>formatted output.

>I am not an expert reading ip traces but it would appear that it sends
>the GET request, Gets a response that sets some cookies, sends an Ack to
>that and then nowt.
Without seeing the actaul data, I can only speculate. If there are no
other GETs waiting for responses, then the browser must think it has asked
for everything. It is odd that the GET response contains no data to be
rendered. This might indicate a problem on the Solaris side. What
happened to the FIN packet? Did it get lost?
Regards,
Steven

Wed, 28 Jun 2006 11:40:45 -0700, steve53 (AT) earthlink (DOT) net wrote:

>In <qnirqrrmrrbet.j1foyi0.pminews (AT) news (DOT) mozilla.com>, on 06/25/2006
at 04:59 PM, "Dave Saville" <dave (AT) deezee-nospam (DOT) orgsaid:

There could be any number of reasons for this. You need to use iptrace on
the S/2 side and compare the ipformat results after normalizing the
formatted output.
>
>>I am not an expert reading ip traces but it would appear that it sends
>>the GET request, Gets a response that sets some cookies, sends an Ack to
>>that and then nowt.
>
>Without seeing the actaul data, I can only speculate. If there are no
>other GETs waiting for responses, then the browser must think it has asked
>for everything. It is odd that the GET response contains no data to be
>rendered. This might indicate a problem on the Solaris side. What
>happened to the FIN packet? Did it get lost?

I would not know a FIN packet if I trod on one :-) If I run the trace again can
I PM you to have a look?

In <qnirqrrmrrbet.j1lj6x0.pminews (AT) news (DOT) mozilla.com>, on 06/28/2006
at 08:40 PM, "Dave Saville" <dave (AT) deezee-nospam (DOT) orgsaid:

>I would not know a FIN packet if I trod on one :-) If I run the trace
>again can I PM you to have a look?

Sure. I'm a bit cursious at to what is failing.

FWIW, you probably saw FIN packets in the TCP headers and ignored them.
:-) The typical TCP transaction starts with a couple of SYN packets,
continues with 0 or more ACK packets and finishes up with a couple FIN
packets. The ACK and FIN can happen in the same packet, but logically
they are separate functions.

Regards,

Steven

In <44a2fa5b$6$fgrir53$mr2ice (AT) news (DOT) mozilla.org>, on 06/28/2006
at 02:42 PM, steve53 (AT) earthlink (DOT) net said:

>In <qnirqrrmrrbet.j1lj6x0.pminews (AT) news (DOT) mozilla.com>, on 06/28/2006
at 08:40 PM, "Dave Saville" <dave (AT) deezee-nospam (DOT) orgsaid:

>>I would not know a FIN packet if I trod on one :-) If I run the trace
>>again can I PM you to have a look?

>Sure. I'm a bit cursious at to what is failing.

After looking at the trace output, unless I am more blind than usual, I
can only conclude that your tcp/ip stack is sick.

Take a look at packet #22. The Ack# value is supposed to be the Sequence#
value of the last packet received plus the number of data bytes in the
received packet. The math from packet #21 is

775502050 + 658 - 20 = 775502688

The Ack# in packet 22 is 3795336088 which is not even close.

Ipformat reports issues with the sizes of several other packets, but these
seem to have been ignored by the stack.

If you have SACK enabled, try turning it off. Use inetcfg to find out if
this is the case.

Regards,

Steven

Fri, 30 Jun 2006 14:23:12 -0700, steve53 (AT) earthlink (DOT) net wrote:

>In <44a2fa5b$6$fgrir53$mr2ice (AT) news (DOT) mozilla.org>, on 06/28/2006
at 02:42 PM, steve53 (AT) earthlink (DOT) net said:
>
>>In <qnirqrrmrrbet.j1lj6x0.pminews (AT) news (DOT) mozilla.com>, on 06/28/2006
>at 08:40 PM, "Dave Saville" <dave (AT) deezee-nospam (DOT) orgsaid:
>
I would not know a FIN packet if I trod on one :-) If I run the trace
again can I PM you to have a look?
>
>>Sure. I'm a bit cursious at to what is failing.
>
>After looking at the trace output, unless I am more blind than usual, I
>can only conclude that your tcp/ip stack is sick.
>
>Take a look at packet #22. The Ack# value is supposed to be the Sequence#
>value of the last packet received plus the number of data bytes in the
>received packet. The math from packet #21 is
>
775502050 + 658 - 20 = 775502688
>
>The Ack# in packet 22 is 3795336088 which is not even close.
>
>Ipformat reports issues with the sizes of several other packets, but these
>seem to have been ignored by the stack.
>
>If you have SACK enabled, try turning it off. Use inetcfg to find out if
>this is the case.

Thanks for looking, however it begs the question "why does it only fail going
through NAT?" SACK, whatever the hell that is, is FF. System is ECS 1.15 with
all TCP fixes.

Fri, 30 Jun 2006 14:23:12 -0700, steve53 (AT) earthlink (DOT) net wrote:


>Take a look at packet #22. The Ack# value is supposed to be the Sequence#
>value of the last packet received plus the number of data bytes in the
>received packet. The math from packet #21 is
>
775502050 + 658 - 20 = 775502688
>
>The Ack# in packet 22 is 3795336088 which is not even close.

I have been ploughing up and down several traces and I cannot find *any* seq #
yack # that follows your rule. Most seem to be out by a constant 40.

AIUI the sequence # is how far down the entire data stream the first data byte
of that packet is and if received correctly the ack returned would be that
number + the data length. I can see where you are coming from but if the stack
were that buggered then nothing would ever work surely.

I now recall where the MTU of 1492 came from. I used to be on a cable modem
using PPPoE and that used an MTU of 1492. When I switched to my current ADSL
provider I never changed it. Now my ADSL uses PPPoA and nowhere in the
modem/router setup does it mention MTU. I called their, excellent, helpdesk
yesterday and they said it should be 1500.

I just changed all NICs to 1500, including the MTU dished out by the Sparc.
Switched the cables from the external net to the internal and rebooted the
laptop. netstat -n shows MTUs of 1500.

I reran the ping tests I had run previously and they failed exactly the same as
before. BUT the browser now loads the page - Go figure.

In <qnirqrrmrrbet.j1wcyc0.pminews (AT) news (DOT) mozilla.com>, on 07/04/2006
at 04:59 PM, "Dave Saville" <dave (AT) deezee-nospam (DOT) orgsaid:

Glad to see you tracked down the trigger to the problem.

>>Take a look at packet #22. The Ack# value is supposed to be the Sequence#
>>value of the last packet received plus the number of data bytes in the
>>received packet. The math from packet #21 is
>>
>775502050 + 658 - 20 = 775502688
>>
>>The Ack# in packet 22 is 3795336088 which is not even close.

>I have been ploughing up and down several traces and I cannot find *any*
>seq # yack # that follows your rule. Most seem to be out by a constant
>40.

Looks like I dropped a 20.

Ipformat reports several byte counts and you have to use the appropriate
ones to get the numbers to work. When things work correctly, the Seq#s
and the Ack#s increment by the data size. The basic formulas are

DataBytes = IP packet total length - IP header size - TCP header size

NextSeq = DataBytes + CurrentSeq

In the packet in question both the IP header and TCP header are 20 bytes.

>AIUI the sequence # is how far down the entire data stream the first data
>byte of that packet is and if received correctly the ack returned would
>be that number + the data length.

You are close. From the RFC

Sequence Number: 32 bits
The sequence number of the first data octet in this segment (except
when SYN is present). If SYN is present the sequence number is the
initial sequence number (ISN) and the first data octet is ISN+1.
Acknowledgment Number: 32 bits
If the ACK control bit is set this field contains the value of the
next sequence number the sender of the segment is expecting to
receive. a connection is established this is always sent.

>I can see where you are coming from but
>if the stack were that buggered then nothing would ever work surely.

In your case, the ACK was wrong only for the packet in in question and I
did not put in a lot of time to figure out why the particular # showed up.
I just knew it was wrong.

Regards,

Steven

Sir:

steve53 (AT) earthlink (DOT) net wrote:
<snip>

I think he has found a work-around in that he increased his MTU to 1500
bytes from 1496 or some such. The packets are now passing to the
browser. There is two possibilities why this work-around does work.
is the source has the Df flag set and is sending 1500 byte packets
(too large for the old MTU). two, he has configured his firewall to
drop fragments, thus the complete packet did not arrive. Either is a
misconfiguration error, of which he can only fix one.

In <c1.2b5.31djyv$2WQ@>, on 07/11/2006
at 08:07 PM, "William L. Hartzell" <wlhartzell (AT) comcast (DOT) netsaid:

>I think he has found a work-around in that he increased his MTU to 1500
>bytes from 1496 or some such.

This is a typical fix for fragmentation related problems.

>The packets are now passing to the
>browser.

Agreed.

>There is two possibilities why this work-around does work.

It's not so much a workaround, as a requirement for certain transports.

>
>is the source has the Df flag set and is sending 1500 byte packets (too
>large for the old MTU).

Possible, but I doubt it because unless I missed it, the DF flag is not
set in the smaller packets that were received.

two, he has configured his firewall to drop
>fragments, thus the complete packet did not arrive. Either is a
>misconfiguration error, of which he can only fix one.

I believe I mentioned this earlier. Some would argue that this is not a
misconfigration, but necessary to fight DS attacks. I don't spend enough
time on firewall configuration to have an opinion.

Steven

Tue, 11 Jul 2006 20:07:52 -0500, William L. Hartzell wrote:

>Sir:
>
>steve53 (AT) earthlink (DOT) net wrote:
><snip>
>
>I think he has found a work-around in that he increased his MTU to 1500
>bytes from 1496 or some such. The packets are now passing to the
>browser. There is two possibilities why this work-around does work.
is the source has the Df flag set and is sending 1500 byte packets
>(too large for the old MTU). two, he has configured his firewall to
>drop fragments, thus the complete packet did not arrive. Either is a
>misconfiguration error, of which he can only fix one.

Correct, upping the MTU to 1500 fixed it. The firewall is not configured to
drop fragments.