Incorrect TCP/IP Analyzer???

[Bigpoppapump]

I just ran the TCP/IP Analyzer and a few things seem to be incorrect.
The IP address under the title isnt mine. Do you think its a proxy server or something?

RWIN is incorrect, it says 49152 when it should read 256960.

MTU reads at 1500.... ok
MSS reads at 1460.... ok

What to do now??? Thx

[blebs]

Your IP address displayed could be a proxy or router, if your using one.
Which OS are you using? If it's W98, do you have the VTCP.386 update installed? With out the update, it will show only RWIN up to 65535. Everything else looks ok if your cable or non-PPPoE connected. I'm just wondering about your IP address shown. ;)

[Lobo]

Sir, Cablenut and I told you yesterday what to do, again download and install Vtcp386 Fix patch from patch page :)

[Bigpoppapump]

Hey Lobo I already have the Vtcp386 fix installed. I tried the test again and its still the same.... wrong IP address and Im not running a proxy server. RWIN still shows incorrect value.

[Lobo]

You sure you installed patch right, after unzipping you have to go where you unzipped it to click and click on merge or install :)

[Lobo]

And no, the analyzer is not wrong :eek:

[rmrucker]

Something about that connection is screwy -- what it is, Satellite or Wireless???

All TcpOptions are OFF -- SACK, Scaling, Timestamping. Also, PathMTU Discovery is OFF.

Something very different is going on...

[ 03-09-2001: Message edited by: rmrucker ]

[Lobo]

The more I think of it the above post applies as Cablenuts patch does not all those things off, has to be something with that IP address, call cable co, call President :)

[Lobo]

Man, Im'm confused as hell, yesterday the last thing you said was you had connection through cox@home and were running Cablenuts patch, now you say your RWIN should be 256960 which is our patch, the patchs are not the problem :confused:

[rmrucker]

And *neither* of the patches turn OFF all the things I listed. If this is Cable, then this is really weird.

Big- run the Tweak tester at DSLR and post what it shows -- JUST OUT OF INTEREST. And then run the Analyzer here. POST all your results for us to see.

This is the address: www.dslreports.com/tweaks (http://www.dslreports.com/tweaks)

[Bigpoppapump]

Ok fellas heres the test results....

Heres DSLR's Test

* Please wait up to 30 seconds.. collecting data
* Your RWIN reads as 254464 (scaling is on)
* Some tests failed.
* Turn Path MTU Discovery ON
* Recommendations end.
* Detail..
TCPopts hex string is 020405b4010303030101080a000000000000000001010402
Max Segment Size is 1460
* Your MTU is set ok
Window Scaling 3 bits (RFC1323)
TSOPT - time stamp option (RFC1323)
SACK Permitted (RFC2018)
Ping stability 77 67 68 66 114 130 65 92 64 67
* Quick packet-loss tested ok
Scaled DefaultRcvWindow (RWIN) is 254464
Your RWIN limits you @81ms to 25132kbps
Your RWIN limits you @200ms to 10178kbps
* Your RWIN is advertised as 254464 (scaling is on)
(Beyond 65k, advertised RWIN is scaled)
* Path MTU Discovery is OFF
Max packet from you 576 bytes
(Which is less than your advertised MSS)
* End

Heres Speedguides TCP/IP Analyzer

TCP options string = 020405b4

MTU = 1500
MTU is fully optimized for broadband.

MSS = 1460
Maximum useful data in each packet = 1460, which is equal to MSS.

Default Receive Window (RWIN) = 49152
RWIN Scaling (RFC1323) = 0 bits
Unscaled Receive Window = 49152
For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 1966.08 kbps (245.76 KBytes/s) @ 200ms
Your RcvWindow limits you to: 786.432 kbps (98.304 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = OFF
Note: Under Windows, if MTU Discovery is OFF, packets are limited to 576 bytes.

Time to live left = 51 hops
TTL value is ok.
Note: Since TTL is decreased by at least 1 with each hop, the value above is equal to your TTL minus the number of hops to forums.speedguide.net

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = OFF

IP type of service field (RFC1349)= 00000000
Precedence (priority) = 000 (routine)
Delay = 0 (normal delay)
Throughput = 0 (normal throughput)
Reliability = 0 (normal reliability)
Cost = 0 (normal cost)

Now someone tell me that something is screwed up. That is still not my IP.

This is after I ran the Vtcp386 fix patch.... again. The Vtcp.386 fix patch is the 236926up.exe file right??? I just double clicked on it, I didnt see merge or install.

Someone please help out. Much appreciated fellas.Thx

[Philip]

Originally posted by Bigpoppapump:
Hey Lobo I already have the Vtcp386 fix installed. I tried the test again and its still the same.... wrong IP address and Im not running a proxy server. RWIN still shows incorrect value.

What do you mean by "Wrong IP address" ? You are getting results for a totally different IP ? You might want to do a tracert to forums.speedguide.net and see which IP the result is for.

[Lobo]

As rmrucker said, these patchs do not turn off the things your test show are off, call cable company about IP address, that has got to be the problem, Phillips TCP tool is showing correct info, tell cable co that IP number or if you have zone alarm firewall use who is it fuction to find out who IP belongs to :) :)

[Lobo]

Big do this and take Phillip's test again and post results here:
Windows scaling-yes
Time stamping-No
Selective Acts-yes
Path MTU Discovery-yes
Please go to this http://www.dslreports.com/front/drtcp.htmlRL
Download DR. TCP to your desktop
Where it saids adapter settings, select your adapter
Where it says Time Stamping, select No
Reboot for changes to take affect

Do not change any numbers in this box unless you know what you are doing.
A blank box only means that the default setting is being used :)

[rmrucker]

Philip- this IS very interesting. I am sure I do NOT understand it. The DSLR Tweak Tester is finding that:
_________________________

SackOpts is ON
TimeStamps is ON
Windows Scaling is ON
PMTUD is OFF

The SYN packet Window field is 31808
The maximum size Data Field is 536
(That is the maximum (sized) packet from you is 576 bytes).
_______________________

Your Analyzer is finding:

SackOpts is OFF
TimeStamps is OFF
Windows Scaling is OFF
PMTUD is OFF

The ACK packet Window field is 49152
The maximum size Data Field is 1460
(That is the Maximum useful data in each packet = 1460).
______________________

There are a couple of interesting things:

1) DSLR took out the IP address line from their tester. However, Big, please go to www.dslreports.com/ip (http://www.dslreports.com/ip) and see if it gives you the SAME IP address that the Analyzer does.

2) The Options are determined by examining the Tcp Options string at the end of the Tcp Header. You will note that the Tweak Tester and the Analyzer are reporting distinctly different Tcp Options strings:

TCPopts hex string is 020405b4010303030101080a000000000000000001010402

TCP options string = 020405b4

This completely explains why the Analyzer is not reporting SackOpts, Scaling, and Timestamping correctly (I use that word loosely -- I do not know who is right).

3) This does NOT explain the RWIN differences -- but then these are derived from two different packets, so who knows...

4) Both testers show that PMTUD is OFF. This is NOT in the Tcp Options string, but is instead in the IP header. Big, why is your PMTUD OFF? Are you using a router?

5) The two testers are showing completely different information in regards to Maximum Data Field size. DSLR is looking at packets that you are UPloading while the Analyzer is looking at packets going TO you.
______________________

OK, that is HOW the differences are present. Now to figure out WHY??? :)

[Philip]

I didn't mean to offend you on packet analyzis / TCP handshake :)

Just thought I'd send you an email with more detailed/technical explanation on how exactly the Analyzer works, trying to figure out what could the issue be.

[rmrucker]

No offense taken!! EVER!
____________________________

I got your email. Thanks. Everything sounds logical. You should be getting the correct packet (SYN) -- and you are certainly getting the correct packet for *most* people.

However, in this instance it appears that the SYN packet is somehow being read incorrectly????? Or for SOME reason the Tcp Options string is being misread???

Since ONLY packets with the SYN bit set *normally* have the Tcp Options string, and since the Analyzer IS reporting an MSS value, we must assume that it IS reading from the SYN packet. Correct?

Also, the 'ACK' (non-SYN) packet Window field appears to be incorrect -- or at least atypical. If we "scale" the value listed we get:

49152 * 2^3 = 393216

This is not the RWIN that Big has listed. Big's RWIN is set at 256960. The 'ACK' packet Window field should contain:

256960 => 11 11101011 11000000

Shifted 3 bits = 01111101 01111000 => 32120

The ACK Window field should say 32120 (0x7D78). If this is scaled, it would give us:

32120 * 2^3 = 256960

Which is exactly where Big set his RWIN.

[I fully realize that I did "circular" math -- but this is what should happen and this is how the numbers SHOULD turn out.]
_____________________________

The point behind all of this is that there are two separate problems:

1) The Tcp1323Options are somehow being misread.
2) The 'ACK' packet Window field is not typical.
_____________________________

I guess the next most important question is -- Bigpoppapump, ARE YOU FOR REAL???

[ 03-10-2001: Message edited by: rmrucker ]

[Philip]

I still think the result is due to web proxy of some kind between him and the Analyzer. That's the only logical explanation to me, backed up by the fact he doesn't get a correct IP reading.

[rmrucker]

I agree the IP address anomaly is weird and may be something to investigate. That is why I sent him to www.dslreports.com/ip. (http://www.dslreports.com/ip.) My next step would be to use Steve Gibson's IP Agent and see if all three IP Address are the same. Then, I would run a tracert to see what that shows. You can't have too much data!

What I do NOT understand is why the DSLR Tweak Tester is reading a DIFFERENT Tcp Options string than you are. This SHOULD not be! Both SHOULD be reading the SYN packet Tcp Options string. The Tweak Test IS -- but yours is apparently not -- eh, as best I can tell.

I don't know how to reconcile this. Obviously the two Tcp Option Strings are NOT the same. Why?

Then there is the issue of the ACK packet Window field. Is it possible the Analyzer is grabbing the wrong packet for Big? How is it getting that 49152?

Is there anyway for you to retrieve the raw Analyzer data for big's test? Is it possible to SEE his packets as they arrive at SpeedGuide?

Is it possible that he is going through some strange router to get to Colorado that he doesn't go through to get to New Jersey? Could this strange router modify his packets this way?? I am at a loss...

[jpalminteri]

I have used both the dslreports and speedguide tweak tester and I have received the same results from both. The speedguide tester does show the IP of my router because it is also acting as a firewall. I have ran several tests with both testers and found them to be accurate in all cases. The TOS field might be a bit different depending on the interpretation of the field. It should be clear. :)

[mpd]

It's very simple, really. The TCP Analyzer is activated by pointing your browser to http://forums.speedguide.net:8117. The browser then opens a connection, perhaps through a proxy (if so configured).

The DSL Reports server is activated by a Java applet, which opens a connection directly to it, bypassing any proxies, even if the browser is configured to always go through a proxy.

The difference in the options string is caused by the fact that we are looking at two completely different hosts, with different IPs and different TCP options.

The reason we show an IP at the top of the screen is precisely to avoid this kind of controversy: If the IP does not match yours, all bets are off.

Mike.

[jpalminteri]

Typically in the Defense Dept we do NOT allow Java Applets to complete through a firewall even if initiated from behind same. HTTP(S) requests when initiated from behind a firewall are allowed to complete, but do take on the IP of the outside interface of the firewall. Packets coming in from the outside typically take on the IP of the inside interface of the firewall. These differences, when taken into account, can give useful info as long as one ignores the IP if it is has changed. My experience has been that there are devices such as firewalls and routers that may incorrectly pass/lose packets. Internally we fix these ASAP. The Internet is such that an individual entity needs to know a fix is necessary, and may not due to the lack of knowledge of other types of traffic. The most prevalent problem is incorrectly configured routers and/or firewalls causing more problems than they fix. I will try the speedguide tester from work and see if it completes with the firewall IP. It should. Java Applets start then die quickly since the firewall stops all such traffic. :)

[Bigpoppapump]

I went to DSLR and it reads my correct IP. Im not running a proxy or a router. Any more info you need, let me know. Thx

[Philip]

rmrucker, the Analyzer still looks for packets from the client, it still extracts the options string from the SYN packet, just the unscaled RWIN from the first non-SYN client packet.

The SCALE and everything else HAS to be extracted from the client SYN packet.

I'll send you an email with more details.

[rmrucker]

I know the SCALE is from the SYN packet -- it is directly out of the Tcp Options string of the Tcp Header. You know I know this. You also know that I know where your RWIN is coming from. (The first non-SYN packet is sometimes loosely referred to as the ACK packet -- it is the packet after SYN,ACK).
___________________

For Big's test, the Tcp Options string is truncated after the MSS option. All other options are lost.

DSLR is displaying a complete Tcp Options string -- with all four options. The TCP Analyzer is not. Something must be responsible for this difference.

[Philip]

"Im not running a proxy or a router"

We didn't mean that you are running a proxy server, rather your Internet Explorer might be going through a Web Proxy.

[rmrucker]

So, let me get this straight.

Big is going through a proxy and the proxy is the IP address that SpeedGuide is reporting. The connection that SpeedGuide is really testing then is the connection between this proxy and SpeedGuide.

And Big is routed through a proxy by his ISP against his knowledge? (I really have no idea -- these are not smart a$$ questions!)

So there is no solution for Big? The Analyzer will never read his setting correctly? Can he ask his ISP to dump the proxy? What about disabling the Proxy setting in the Control Panel | Network Properties?? Would that solve this problem? (I am grasping for straws now!)

Big, have you run a tracert to the displayed address?? Where is it and how far away from you is it?

[Philip]

As I mentioned before, the Proxy setting in IE > Tools > Internet Options > Connections > LAN settings. In there, disable proxy, uncheck "Automatic settings" and try again.

AFAIK, @Home (and possibly other ISPs) install software that authomatically enables proxy too.

[mpd]

This is what Philip and rmrucker meant (your settings should look like this: )


http://forums.speedguide.net/~mpd/proxy.png

[ 03-11-2001: Message edited by: mpd ]

[Bigpoppapump]

Ive tried to disable everything in the Lan settings window but it doesnt work. Ill uncheck them then test it still wont show my IP, then ill go back to the lan settings window and the box "use automatic configuration scipt" will be checked and will say "http://proxy8080". After I uncheck all boxes do I have to restart? And will they stay unchecked? Another question..... Even if Im going through a proxy how is it that DSLR shows my correct IP? This **** is freaky. Thx

[rmrucker]

Mike- EXACTLY. I would have to think THAT should work if a Proxy is responsible. I HOPE that it is -- then this is a GREAT example of how important UNchecking those boxes are!!

Big- I don't know if you have to reboot, but it would not surprise me. Open up the LAN Settings and remove the check boxes and reboot. Retest and repost.

Mike and Philip- if this works, you may want to consider adding a note to the first (pretest) page that notifies the user of this phenomenon. Something like: "If you are using a Proxy, the IP address at the top of the test will not be your IP address and the test results will be inaccurate. Turn off Proxy server prior to testing."

The goal here is to eliminate posts like this... I think you agree with that!

:) While I have you two here... are you guys thinking of checking upload packet size as well? That comes into play for two main reasons:

1) PMTU Discovery. If this is off, Upload packet size is cut to 576 -- as it shows on Bigpoppapump's DSLR report. Since this is not a "negotiated" variable during the handshake, this does not effect download packet size.

2) Linksys (and Ugate) routers with PPPoE. The upload and download packet size will be asymmetric due to a bizarre phenomenon that these routers demonstrate. Briefly, the if the Linksys router on PPPoE recieves a SYN or SYN,ACK packet with an MSS field greater than 1492, the MSS field is overwritten as 1362. This can cause unilateral limitation of the Uploading packet size. The importance of this will depend upon the Unix version of the server performing the test.

[rmrucker]

I also found this advice from Scoot in another thread:

Try this: Start>Run and type: regsvr32 -u ahiehelp.dll
It disables the proxy for good, if you have the @Home software installed.

If the check boxes don't work, this might be worth a try...

[Bigpoppapump]

Ok fellas, I was going through a web proxy to speedguides analyzer. Heres the test results now from both sites.....* Please wait up to 30 seconds.. collecting data
* Your RWIN reads as 254464 (scaling is on)
* All tests passed perfectly.
* We recommend you leave everything as it is!
Detail..
TCPopts hex string is 020405b4010303030101080a000000000000000001010402
Max Segment Size is 1460
Your MTU is set ok
Window Scaling 3 bits (RFC1323)
TSOPT - time stamp option (RFC1323)
SACK Permitted (RFC2018)
Ping stability 64 73 64 136 64 64 65 67 64 65
Quick packet-loss tested ok
Scaled DefaultRcvWindow (RWIN) is 254464
Your RWIN limits you @72.6ms to 28040kbps
Your RWIN limits you @200ms to 10178kbps
Your RWIN is advertised as 254464 (scaling is on)
(Beyond 65k, advertised RWIN is scaled)
Your Path MTU Discovery is ON
Max packet from you 1500 bytes
* End


Note: If the above is not your IP address, you need to disable any Web proxy you might be going through.

TCP options string = 020405b4010303030101080a000000000000000001010402

MTU = 1500
MTU is fully optimized for broadband.

MSS = 1460
Maximum useful data in each packet = 1448, which is less than MSS because of Timestamps, or other TCP/IP options used.

Default Receive Window (RWIN) = 490560
RWIN Scaling (RFC1323) = 3 bits
Unscaled Receive Window = 61320
RWIN is a multiple of MSS
Other values for RWIN that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)

bandwidth * delay product:
Your RcvWindow limits you to: 19622.4 kbps (2452.8 KBytes/s) @ 200ms
Your RcvWindow limits you to: 7848.96 kbps (981.12 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 74 hops
TTL value is ok.
Note: Since TTL is decreased by at least 1 with each hop, the value above is equal to your TTL minus the number of hops to forums.speedguide.net

Timestamps (RFC1323) = ON
Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349)= 00000000
Precedence (priority) = 000 (routine)
Delay = 0 (normal delay)
Throughput = 0 (normal throughput)
Reliability = 0 (normal reliability)
Cost = 0 (normal cost)

Love the idea for the note under the IP address,hehehe.

[rmrucker]

I guess that note is just for you, Big!

But it looks like you have changed your RWIN to 490560. And believe it or not, BOTH Tweak Testers seem to agree on that -- it's just that the DSLR one doesn't know how to report the value correctly!

[Bigpoppapump]

Yeah I changed my RWIN a little bit.... But at least im getting accurate results now. Damn that proxy. Thx fellas.

[jpalminteri]

Proxies are a pain in the ____. They sometimes are necessary when coupled with a firewall and not optional. I believe AOL uses one that is not optional. If a proxy server is being used, but is in some way optional as in your http connection will work after unchecking all the aforementioned boxes by all means do so. Sometimes there are more optimum routes through proxy servers, sometimes they are used for monitoring. We have our firewall do double duty as backup DNS. This is not good and is in the process of being changed, such that a firewall performs only that function. In general, one never needs or wants a proxy unless there is some ancillary function to be performed. In general, on the internet one would not expect to encounter them often in general use. ISP's probably use them in some cases for monitoring their traffic and seeing what sites their users are vsiting. This is one of AOL's reasons. :)