Post Reply 
Proxomitron reduces RWIN to 32768
Oct. 25, 2005, 02:53 PM
Post: #46
 
ProxRocks Wrote:not to be the skeptic, but sounds like a bunch of hocus-pocus to me...
I say "butterfly" three times, ask you to repeat, then I show you an ink blot of a BAT and ask you what you see - then you tell me you see a BUTTERFLY, not a BAT...
I tell you to increase your RWIN, tell you it increases your throughput by 300% - then whoala, you PERCEIVE a 300% increase, whether it is "there" or not...

I couldn't have said it better. I am using the default settings and consistently getting better than 98% of my ISP's advertised rate.

Get hpHOSTS!
Add Thank You Quote this message in a reply
Oct. 25, 2005, 04:45 PM
Post: #47
 
z12 Wrote:
JJoe Wrote:So then it appears that only XP/Home/SP2 users with Proxomitron directly connected to the net are experiencing this (good idea Mike).

Not Exactly.

I'm seeing the wrong RWIN reported at speedguide as long as I'm connecting directly via proxo.

proxo-->speedguide = wrong RWIN reported
So then you don't have XP/Home?
XP/Home/SP2 and proxo-->speedguide = wrong RWIN reported
is what I meant.

z12 Wrote:As a side note, I am seeing alot of 4xx Response codes in proxo's log window when I'm chaining thru AnalogX proxy especially at (CastleCops.com).


My thought right now is proxo doesn't support "TCP 1323 Options". This would limit RWIN to 65535 (2^16).


To test this, I set my RWIN to 38272 and disabled the "TCP 1323 Options" in speedguides TcpOptimizer program.

After rebooting, I tested again and speedguide did not report the RWIN that I had entered (it reported 39xxx, I don't remember exactly).

So now I wonder about the validity of the speedguides results.

At this point, I think I'm going to download a packet sniffer and look for myself.


Mike

Hmmm. The number reported may be rounded up to an even multiple of MSS. Scaling does seem to work.
But I have been wondering about the test.

Can you find a speed difference?
Not that I doubt Tony Tough's words but my helper did not.

This is like the only time I've ever wanted XP on my computer. lol

--
JJoe
Add Thank You Quote this message in a reply
Oct. 25, 2005, 05:09 PM
Post: #48
 
Tony Tough Wrote:Because of all these problems I finally switched to BFilter.

Hi! It's quite strange, but after upgrading Sidki's filters SpeedGuide test shows the correct RWIN, but just after reloading that page and permit "tame redirect" on page "Connection parameters retrieved".
Quote this message in a reply
Oct. 26, 2005, 01:23 AM
Post: #49
 
Hi all

Hey JJoe, welcome to UPF Smile!

JJoe Wrote:So then you don't have XP/Home?

No, XP Pro SP2, forgot to mention that in the previous post.

I downloaded Ethereal and have been playing with that.

It is indicating the same as speedguide as far as RWIN & scale factor:

proxo-->web RWIN=32768 (8000h) sf=0

proxo-->AnalogX proxy -->web RWIN=256960 (FAF0h) sf=4

However, I noticed after two packets of data were received from speedguide of 57 & 614 bytes, the next time proxo sent the window size it was 32097 (32768 - 57 - 614 = 32097).

Perhaps proxo has an internal receive window that is 32768 bytes in length.


I'm going to sniff some more packets Smile!

Mike
Add Thank You Quote this message in a reply
Oct. 26, 2005, 02:16 AM
Post: #50
 
Oddysey Wrote:Kye-U;

I'd have to question JJoe's answer. How is it that last piece of the pie in the communications chain, Proxo, can write a packet that basically limits the RWIN value

z12 Wrote:Using Jetico Firewall, XP built in firewall disabled.

I ran the speedguide TcpOptimizer app and set my RWIN to 256960 then rebooted.

Checked my RWIN at http://www.speedguide.net:8117/ thru proxo and it reported:

Default Receive Window (RWIN) = 32768

Z,

I know 0 about Jetico and just googled it finding it does stateful packet inspection in & out.

If you can write a rule for proxo if you don't have one already to look like this:

Block Proxomitron = TCP/UDP both directions; local endpoint = any; remote endpoint = any address any port; rule valid always; action = deny

log it if you want

It seems like if proxo is the culprit then Jetico should intercept any attempts by proxo to send out any RWIN data...

just an idea

------------

any body else using a software firewall with stateful packet inspection may want to try this just for grins

I have such a rule maybe those who are not experiencing a problem do too - maybe not

I also use a router so maybe I'll try scaling up and disabling my soft firewall to see if I get the problem. I'm not on XP though.
Add Thank You Quote this message in a reply
Oct. 26, 2005, 10:21 AM
Post: #51
 
Peakaboo,

The problem isn't that proxo is sending RWIN, thats part of the TCP protocol, the problem is that its not the value I have specified.


For Win98 users, I ran across this link:

---
http://support.microsoft.com/support/kb/...9/7/05.ASP

RFC 1323 Options Can Not Be Enabled in Windows 95 and Windows 98
---

It's always something

Mike
Add Thank You Quote this message in a reply
Oct. 26, 2005, 07:54 PM
Post: #52
 
Mike;
z12 Wrote:Peakaboo,

The problem isn't that proxo is sending RWIN, thats part of the TCP protocol, the problem is that its not the value I have specified.


For Win98 users, I ran across this link:

---
http://support.microsoft.com/support/kb/...9/7/05.ASP

RFC 1323 Options Can Not Be Enabled in Windows 95 and Windows 98
---

It's always something

Mike
Thanks for that link. I didn't know about it directly, but that's most likely because I already had the hotfix installed, a long time ago. Angel

For those members who don't have it, and don't want to play Microsoft's game ("You can't possibly know what you're doing, we'll have to do it for you - and oh, by the way, we'll need to access your credit card too."), the file is part and parcel of the way-cool Win98/SE Service Pack, found at http://exuberant.ms11.net/. The current version of that pack is 2.0.2, and I've been using the product since JC was a mess cook on the Merrimac. Shock


Oddysey

I'm no longer in the rat race - the rats won't have me!
Add Thank You Quote this message in a reply
Oct. 26, 2005, 11:46 PM
Post: #53
 
Oddysey,

Yeah, I'm sure I also had that hotfix back when I was running 98.

From MS's link, I got the distinct impression you could now get charged for that fix.

BTW, nice link you found there, now why couldn't MS do that? Oh wait, never mind.

Mike
Add Thank You Quote this message in a reply
Oct. 27, 2005, 03:09 AM
Post: #54
 
Mike;
z12 Wrote:Oddysey,

Yeah, I'm sure I also had that hotfix back when I was running 98.

From MS's link, I got the distinct impression you could now get charged for that fix.

BTW, nice link you found there, now why couldn't MS do that? Oh wait, never mind.

Mike
Possibly because there isn't anything for them to buy up, so they could turn around and claim that they invented it first?! Dead

Actually, nearly all of this stuff is from them in the first place, one way or another. The Service Pack, particularly the Hot Fixes portion, is almost entirely a 'repackaging' effort, or so I've been led to believe in reading the documentation over the years. Surely there are some original things in there, but I stopped trying to keep up with the Change Log a long time ago. Shock

Who knows, perhaps there are things in there that are partially (or mainly) responsible for the reason that I've not suffered any kind of break-in during the last 4(!) years.


Oddysey

I'm no longer in the rat race - the rats won't have me!
Add Thank You Quote this message in a reply
Oct. 27, 2005, 02:31 PM
Post: #55
 
Hi all

After having some issues with chaining proxo to AnalogX's proxy, I decided to try BFilter.

I downloaded, the latest version and cofigured it to listen on port 8081. Since I didn't want BFilter to do the filtering, I am running it in Passive mode (clicked on the tray icon and unchecked Active). Then I set proxo to use a proxy (localhost:8081).

This setup seems to be working well so far. Speedguide reports the correct RWIN & Scaling and things seem to be zipping right along. I'm not seeing anything unusual in proxo's log window (no 4xx errors) as I did with the AnalogX Proxy.

BFilter doesn't do SSL, so I'm not sure if that will be an issue or not, but so far so good.

Mike
Add Thank You Quote this message in a reply
Oct. 30, 2005, 01:41 AM (This post was last modified: Oct. 31, 2005 05:48 PM by Peakaboo.)
Post: #56
 
z12 Wrote:Hi all
I downloaded, the latest version and cofigured it to listen on port 8081. Since I didn't want BFilter to do the filtering, I am running it in Passive mode (clicked on the tray icon and unchecked Active). Then I set proxo to use a proxy (localhost:8081).

This setup seems to be working well so far. Speedguide reports the correct RWIN & Scaling and things seem to be zipping right along.
Mike

Interesting result. Put a local proxy in passive mode between proxo and browser and change proxy port...

What happens if you:

1) just change the port and don't use bfilter or
2) if you use bfilter and proxo chain and listen on port 8080 instead of 8081?

just curious Wink

______________

peakaboo Wrote:I also use a router so maybe I'll try scaling up and disabling my soft firewall to see if I get the problem. I'm not on XP though.

scaled up with RWIN = 128480 disabled software firewall and tested tcp/ip analyzer and it read the 128480 correctly...

so win95 does not have this problem.

ftp speed increased to 96.6% of advertised with scale up only 1 instance of packet loss so far - some discernable page load speed increase - will dance with this setting for awhile and probably drop back to 64240. I know I tested this scale up 2 speed 128480 4 months ago and found the 64240 to be better...


FYI, the speed guide TCP/IP analyzer when you run the test and you run win9x will tell you:

Note: Under Windows 9x, if you have RWIN set to any other value, and the Analyzer reports xxxxx you might need to install the MS Vtcp386 fix.

Also Faq #7 http://www.speedguide.net/faq_in_q.php?c...=98&qid=27 will point you to the Vtcp.386 fix.

I know they have this patch at http://www.speedguide.net/downloads.php (towards bottom of page)

and breaks it out between win95 vs win98

For Win95 if you do not have the RFC 1323 registry key you will have to add it... go here for more info if you are comfy editing your registry http://www.hakanozerdem.biz/registry/sou...il-745.htm

bunch of other patches and updates at SG dwnload along with TCP Optimizer latest version 2.0.2
Add Thank You Quote this message in a reply
Oct. 31, 2005, 12:45 AM
Post: #57
 
Hi all,
i did the same setup as z12 suggested, and confirm the Browser hat the correct RWIN Value with this setup. Ur questions Peakaboo i tried already and it does not change anything. By the way i have DSL/PPOE and XP SP2. Now, concerning the setup with Bfilter in conjunktion with Proxo, 3 major drawbacks:
1. no SSL anymore,
2. Upload-test, or even Upload at all not possible anymore (check ie. with:
http://www.speakeasy.net/speedtest/ or
http://www.wieistmeineip.de/speedtest/ ),
3. No logins anymore.
I didnt check with AnalogX but think i would anyway not use that combination... So, the big question still exists, how to confince Proxo to hand over the right RWIN/TCPWindowSize configured in the registry.
And, ProxRocks, sorry, but this issue is sure not 'hokuspokus'. A too small RWIN for fast Bandwith reduces browsing and download speed significantly.

WildTbag
Add Thank You Quote this message in a reply
Oct. 31, 2005, 02:41 AM
Post: #58
 
WildTbag;
Quote:And, ProxRocks, sorry, but this issue is sure not 'hokuspokus'. A too small RWIN for fast Bandwith reduces browsing and download speed significantly.
And yet, I can't shake this feeling that Scott just couldn't have overlooked such an important factor, if it were truly within the parameters that Proxo must consider and act upon. Wanna know what I think? I think that Scott did it right, and that we'll find out sometime in the future that everyone else (Bfilter, anything else) has been overlooking something that Scott took into account. Either that, or else the OS is the real culprit, and everyone else has been taking it into account, and making up for the error. (But that's just a guess, you understand. Angel )


Oddysey

I'm no longer in the rat race - the rats won't have me!
Add Thank You Quote this message in a reply
Oct. 31, 2005, 01:30 PM
Post: #59
 
WildTbag Wrote:And, ProxRocks, sorry, but this issue is sure not 'hokuspokus'. A too small RWIN for fast Bandwith reduces browsing and download speed significantly.

WildTbag
You say "butterfly", I say "bat"...
Add Thank You Quote this message in a reply
Nov. 04, 2005, 12:36 PM
Post: #60
 
Kye-U Wrote:
Quote:Bet you both have SP2.
I have read that SP1 was OK.
Win98 is OK.
So Microsoft did it. ;-)

--
JJoe

Perhaps when a proxy server is used in SP2, the RWIN is limited?

Not impossible. In sp2 Microsoft limited tcpip.sys to handling only 10 incomplete connections at a time. This is the infamous "EventID 4226: TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts." The idea behind this was to slow down the speed at which worms spread. However, it has broken a few programs, including P2P programs.

Now I've just checked on opening a moderately simple web page, and Proxomitron was opening 4 connections. Won't take much to hit the limit. On some occasions I've seen it open far more - usually when I was using a proxy handler after Proxomitron - so it might, with some setups, fall foul of this limit, and in a few cases, badly so. Anything more than 10 will have to wait in a queue, slowing things down drastically, particularly if it's trying to open up 20+ connections, which I have seen. Fortunately there is an unofficial fix - patch tcp.ip.sys so that it can handle 50 incomplete connections at once, which was the original setting before sp2:

http://www.lvllord.de/?lang=en&url=tools

This works - I've run it on my machine. I tested my connection at http://www.dslreports.com/tweaks and got 65535, whether Proximitron was used, bypassed or not used at all. Gives no problems at all. Actually it looks as if you may be able to tweak it to over 50 incomplete connections, but 50 seems fine enough to me.

For good measure MS also decided, with sp2, to block access to raw sockets, on the grounds that 'only attack programs use them.' This screwed a lot of security programs (e.g. nmap) and got a lot of administrators annoyed. MS' official response to complaints? "Stop using the program that causes the problem." A workaround was initially found - then MS patched the workaround. Now nmap has been patched to get round the whole problem, and someone will no doubt come up another solution, whether MS like it or not.

Great philosophy - improve security by crippling the OS. :-)

BTW, if you need the speed increased after that, you'll have to look at tweaking the connection. Rummage around dslreports.

Kevin
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: