Post Reply 
Proxomitron reduces RWIN to 32768
Nov. 10, 2005, 12:52 PM
Post: #76
 
z12 Wrote:Since your tweaking, heres a little tid bit on SynAttackProtect, check out the Note:

http://www.microsoft.com/technet/prodtec....mspx#EGAA

Ta! It's for Server 2003 rather than XP sp2, but useful. In XP a DWORD of 2 for SynAttackProtect "delays notifying the Winsock driver until the 3 way handshake is complete."

Kevin
Add Thank You Quote this message in a reply
Nov. 10, 2005, 01:05 PM
Post: #77
 
hi JJoe

JJoe Wrote:
laighleas Wrote:Best I can do - it's nearly 3 am, and I've been having a good slog at this. Brain is about to go on meltdown.
And I thank you for it. :-)

Ta! :-) Got fascinated by the problem for its own sake, and wanted to try and find a meaningful answer.

JJoe Wrote:Sorry about the "harden stack" question. That answer must of took some time. My hope was something in there would explain why you were unaffected.

:-) That's OK. Didn't occur to me till a bit later that perhaps the two tests were approaching things very differently. Anyway, the info might be of some use to someone for something. :-)

Kevin
Add Thank You Quote this message in a reply
Nov. 11, 2005, 07:04 PM
Post: #78
 
laighleas Wrote:Of course, if the server restricts the number of connections to two simultaneous connections (i.e. enforces the spec), and if Proxomitron is trying to open up more than ten connections, (i.e. has more than 10 half-open connections), then you sail straight into the problem with the unmodified sp2 stack, at which point things could start slowing down noticeably.

So you?ve got several factors: the use of XP and large windows, broadband connections, the problems with sp2?s tcpip.sys, and the fact that Proxomitron seems to have been optimised for dial-up connections. About the only way round this would be to increase the size of packets that Proxomitron can send and receive - RFC 1323 allows for receive windows of up to 1 Gb. However, since Scott is no longer around, that?s not possible. :-( Proxomitron can compensate by opening more connections, but to avoid problems there, you?ll need to patch tcpip.sys. Even then, you may occasionally run into servers that enforce the internet spec.

Does that make sense to anyone?

It makes sense to me not being experienced in this area at all. If the following statements are true, I have but one issue/question.

1) With a fully patched XP home SP2 system, and fixed tcpip.sys via lvllord's fix, if I read the data on wininet.dll correctly http://support.microsoft.com/?kbid=320721 the server limit for http & http1 of 4 & 2 go away and the issue of greater than 10 simultaneous connections goes away. Is this correct?

2) So although the tcpip analyzer which is not working today for me for some reason would show an rwin for an xp home sp2 system of 32768 for rwins set above this figure due to the internal rwin of proxo, the true rwin in terms of transfer/download speed is closer to what is shown at dsl reports http://www.dslreports.com/tweaks
for a fully patched xp home sp2 system with tcpip.sys lvllord fix.

In essence the tcpip analyzer is picking up the slowest rwin in the path via proxomitron at 32768 however proxo compensates for its limitation by opening more simultaneous connections and therefor should not impede download speed.

So is the TCPIP Analyzer result misleading for XP home SP2 with proxomitron and maybe should carry a notice or included in "faqs".

It may be instructive to understand what makes XP home SP2 config. different from all the other win o/s especially XP Pro with SP2 which do not have this issue.


Maybe a good test for those who have Win XP home with SP2 using proxomitron, would be to look at the transfer rate of an xp home sp2 system downloading a big file via http before lvllord's fix and then immediately after to see if it makes a difference or to use that page load speed test you mentioned: http://www.numion.com/

I do not personally have this proxo rwin, I'm just curious.

As mentioned earlier, I do not have any training or expertise in this area at all as you can probably tell. For some reason this problem is interesting to me as far as finding the root cause and potential solution.

___________________

Bottom line is Tony made the right decision - BFilter was a no brainer Smile!
Add Thank You Quote this message in a reply
Nov. 12, 2005, 02:18 AM
Post: #79
 
laighleas Wrote:Ta! It's for Server 2003 rather than XP sp2, but useful.

Check the first paragraph on that page:

Quote:Except where noted, the TCP/IP implementation for Windows XP is the same as that for Windows Server 2003.

laighleas Wrote:Now if Windows can send larger packets than Proxomitron can handle, the latter is going to have to fragment the packets.

Proxo doesn't seem to be affecting the Maximum Segement Size (MSS) reported to the server. Since I connect to the internet via my lan, my MSS is 1460, which is the MSS value I see. For Dial up, it should be 536, but I can't verify that. Also with XP, if EnablePMTUDiscovery is disabled, XP sets it to 536.

Quote:EnablePMTUDiscovery

Key: Tcpip\Parameters

Value Type: REG_DWORD?Boolean

ValidRange: 0, 1 (false, true)

Default: 1 (true)

Description: When this parameter is set to 1 (true) TCP attempts to discover the Maximum Transmission Unit (MTU), or largest packet size, over the path to a remote host. By discovering the Path MTU (PMTU) and limiting TCP segments to this size, TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs. Fragmentation adversely affects TCP throughput and network congestion. Setting this parameter to 0 (not recommended) causes an MTU of 576 bytes to be used for all connections that are not to destinations on a locally attached subnet.


laighleas Wrote:Proxomitron seems to have been optimised for dial-up connections

I agree.

laighleas Wrote:About the only way round this would be to increase the size of packets that Proxomitron can send and receive - RFC 1323 allows for receive windows of up to 1 Gb.

While it may be possible to fake xp into using a larger MTU, I doubt any routers will pass frames larger than 1500 bytes, resulting in fragmentation. You can increase the size of the receive buffer up to 1GB, but this brings us right back where we are now. No matter what registry setting I have for the window size, proxo sets it to 32768.

Peakaboo Wrote:So is the TCPIP Analyzer result misleading for XP home SP2 with proxomitron and maybe should carry a notice or included in "faqs".

For me, the window size reported at http://www.speedguide.net:8117/ are correct. I have verified this with Ethereal, using XP Pro, SP2.

Peakaboo Wrote:It may be instructive to understand what makes XP home SP2 config. different from all the other win o/s especially XP Pro with SP2 which do not have this issue.

As I noted above, I use XP Pro SP2 and have the issue. In fact, I find it hard to believe that users of other win os's don't have this problem. As has been noted before, the results at dslreports are different than those reported by speedguide, with the same settings. Speedguide is looking at the TCP header, I don't know what bbr is looking at since you need sun java to test, and I don't have it.

Any test that does not report the rwin as advertised via the TCP header is meaningless.

Mike
Add Thank You Quote this message in a reply
Nov. 12, 2005, 03:55 AM
Post: #80
 
z12 Wrote:[As I noted above, I use XP Pro SP2 and have the issue. In fact, I find it hard to believe that users of other win os's don't have this problem.

Well, having done a bit of Googling, the default RWIN for Win9x and NT is apparently 8760 and for Me/2k and XP 17520 (presumably sp1), all of which are less than Proxomitron's setting of 32768. XP Home and Pro however have dynamic settings for RWIN - the others being static - though the scaling for large Window sizes isn't apparently enabled by default. 65535 is the highest achievable without scaling.

Now some gamers noticed that installing sp2 changed both the RWIN and the MTU, unoptimising their machines from their POV. OTOH, other folk noticed that their cable connection speeded up. That's probably where our main problem lies.

"While it may be possible to fake xp into using a larger MTU, I doubt any routers will pass frames larger than 1500 bytes, resulting in fragmentation. You can increase the size of the receive buffer up to 1GB, but this brings us right back where we are now. No matter what registry setting I have for the window size, proxo sets it to 32768. "

Well, this is why I said we need kuruden's opinion - he's actually built this sort of filter, and has undoubtedly analysed Proxomitron. We're only having a guess at what it's doing, where as he undoubtedly knows. Can someone tap him on the shoulder and ask him to contribute? Hell, there may or may not be stuff here relevant to the design of Proximodo. Does anyone know what the RWIN is for Proximodo?

"Any test that does not report the rwin as advertised via the TCP header is meaningless."

I'd go with that. I'd like to know how dslreport's tester does its business though - but that will take one of the java folk round here.

As to Peakaboo's question:

1) With a fully patched XP home SP2 system, and fixed tcpip.sys via lvllord's fix, if I read the data on wininet.dll correctly http://support.microsoft.com/?kbid=320721 the server limit for http & http1 of 4 & 2 go away and the issue of greater than 10 simultaneous connections goes away. Is this correct?

The limits are, according to Internet specifications, 2 established connections - though how many servers actually enforce this is another matter. :-) OTOH, it's another case of default settings in the registry. MS tell you how to fiddle with it in one of their technical notes, but then cop out and tell you that you're breaking internet specs - this from a company that does its own thing on specs when it feels like it. :-) Anyway, if the standards are enforced, other potential connections outside those two have to wait half open, i.e. not yet established because the three way handshake hasn't been completed, and the limit on those simultaneous half-open connections is, in sp2, a maximum of ten. It was, in earlier OS, 50. So you could get a bottle neck on top of the smaller RWIN. Increase the number of simultaneous established connections, and the number of allowed simultaneous half-open connections, and your bottleneck vanishes or is at least reduced. You won't affect the RWIN of Proxomitron, but you'll have lots of simultaneous connections offsetting that chokepoint. It's a bit like sucking a thick milkshake through a straw - you can either increase the size of the straw or use several straws of the same size.

From those figures, OS below XP were never in any danger of exceeding the limits on Proxomitron's window. Presumably sp1 could have done, but for some reason (probably Microsoft's default registry settings) it didn't. Installation of sp2 on the other hand has been observed to to increase speed on cable connections, and sent a load of gamers back to retweak their machines for internet gaming.

"As mentioned earlier, I do not have any training or expertise in this area at all as you can probably tell. For some reason this problem is interesting to me as far as finding the root cause and potential solution."

Well, I'm not an IT professional - I'm an archaeologist by training, though archaeologists do use computers as well as shovels. :-) I just got interested enough in this stuff, years ago, to try research it and understand it, mostly by getting my hands dirty, listening to other folk, picking folks' brains, experimenting with the damned things, occasionally going "what if?" and getting daft jobs at work, such as the boss telling me, 4 hours before he's due to go, "On this trip I want to access the internet - you've got a laptop and a mobile phone, sort it", back in the days when this was almost unheard of. Nothing like being asked the impossible for a learning curve! :-) And no, we didn't have the relevant software to hand. :-) Even got round to building a PC from spares back in the days of 386s. :-) Plus rarely having any support service, cos I was originally using second hand machines, so you have to learn how to dig yourself out of problems, cos no one else will. On the only occasion I did have a support contract, it lasted 3 months, cos the company refused to support the machine any further if I got rid of the crap Me they insisted on selling me (I wanted 2000 or NT) and replaced it with XP. So fine - I told them to stuff it, got rid of Me and installed XP, upgraded drivers, software, the lot. This machine has been disowned by its vendor ever since. :-) It's Not As Per Original Spec as far as software goes. :-) Give me a bit of money and it will be less of the original spec as far as hardware goes. :-)

In short, basically bugger around with the things, pick brains, read and somewhere along the line you learn things. Not as much as an IT professional, but enough to get by. As for programming - well I take my hats off to the likes of Kye-U, Sidki and the others round here who develop the Java filters. I've about got my head round HTML filtering, but that's as far as it goes.

Kevin
Add Thank You Quote this message in a reply
Nov. 12, 2005, 04:56 AM
Post: #81
 
BTW, the link to gamer's comments on sp2 is as follows:

http://forums.3dgamers.com/showthread.php?t=2778

Kevin
Add Thank You Quote this message in a reply
Nov. 12, 2005, 05:07 AM
Post: #82
server/xp sp2 throttle back to lowest rwin in chain
Two things I noticed in looking back on this thread:
1)
mambo Wrote: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".

Sidki's latest filter set (6/9/05) & his 10/16/05 update to the 6/9/05 filter set can be found here: http://www.geocities.com/sidki3003/prox-down.html

can anyone confirm what mambo did as posted on page 4 of this thread 3rd post from top?

2) Mike has been successful at getting the correct rwin from tcpip analyzer when he sticks a buffer like bfilter in passive mode or analogx proxy in between proxo and his browser.

I find it interesting that some with xp sp2 pro have the problem like z12 (Mike) and others do not see this issue like hpguru and that no other os except xp home with sp2 is reporting this issue.

Personally, I'm seeing scaled rwin of 128480 which is well above the 32768 presumed limit of proxo on a win95 machine. I'm seeing proxo open on normal browsing 4 to about 13 tcp connections.

*******************************************

Seems like given a certain config --> xp sp2 is reading the slower rwin of proxo at 32768 (if proxo in fact has this internal rwin) and the tcpip header is picking up this slower rwin if nothing buffers or intercedes.

In a way this makes sense to me because proxo was built during dial-up and probably not with broadband in mind - if the slowest link in the chain is at 32768 (proxo internal rwin) then I think I read somewhere that servers and xp throttles back to the lowest rwin in the chain. I'll try and find the link I think it was a discussion of 2003 server.

The major question which may hold the answer to a solution is what is different between the config setup of z12 vs hpguru's set up. Both are using xp pro sp2 and z12 experiences the rwin slow down while hpguru does not.


Occam's Razor: says if possible compare the two setups to isolate any major differences. Test the differences one by one till a solution is found. Sounds easy in theory anyway Smile!

I'd like to think Scott is probably smiling down and saying... all you have to do to resolve this is...
Add Thank You Quote this message in a reply
Nov. 13, 2005, 07:04 AM
Post: #83
Re: server/xp sp2 throttle back to lowest rwin in chain
Peakaboo Wrote:The major question which may hold the answer to a solution is what is different between the config setup of z12 vs hpguru's set up. Both are using xp pro sp2 and z12 experiences the rwin slow down while hpguru does not.

Occam's Razor: says if possible compare the two setups to isolate any major differences. Test the differences one by one till a solution is found. Sounds easy in theory anyway Smile!

I'd like to think Scott is probably smiling down and saying... all you have to do to resolve this is...

Maybe hpguru can send the proxo filter set he uses to z12 to see if that will narrow the difference. If it does not work I'm sure he will get great pleasure by saying next.

Easy and worth a shot if both are game.
Add Thank You Quote this message in a reply
Nov. 13, 2005, 07:26 AM
Post: #84
 
The problem is that the filter set doesn't have anything to do with it. I see this when proxo is bypassed.

Mike
Add Thank You Quote this message in a reply
Nov. 13, 2005, 04:59 PM
Post: #85
 
z12 Wrote:The problem is that the filter set doesn't have anything to do with it. I see this when proxo is bypassed.

Mike

maybe your filter & set up doesn't have anything to do with it.

maybe hpguru is doing something you are not in conjunction with his filter set.

the fallacy is assuming something will not have an impact if you are truly guessing as to what the problem is - which despite all the expertise is what is going on.

example is the buffer (bfilter) you placed between proxo & your browser -

is it possible hpguru is doing something in his set up, not just his filter set but in conjunction with his filter set which is also acting as a buffer...

your choice not to explore all possibilities.

128480 Smile!

the 1st challenge would be to get hpguru to stop laughing long enough to help you mimic what he is doing different if anything.

the 2nd challenge would be to get your system to mimic as closely as possible his - since you have the problem and he does not. this would entail exploring not only his filter set but version of proxo used, firewall, browser, versions of sp2 if multiple versions exist etc - long process which may or may not provide any fruit.

at the end of the day we are still left with hpguru does not have the problem and you do.
Add Thank You Quote this message in a reply
Nov. 13, 2005, 08:34 PM
Post: #86
 
Peakaboo Wrote:the fallacy is assuming something will not have an impact if you are truly guessing as to what the problem is - which despite all the expertise is what is going on.

I agree. Guessing wasn't getting it done, so I decided to disassemble proxo's code and have a look for myself.

Based on the code, its clear that there is a setsockopt function call that hard codes 32768 for the rcv buffer size. Why this function call has no effect on pre XP OS's, I can only guess.

However, I can change the rcv buffer size to whatever I want by editing the hard coded value. Currently my rwin is 513920 as reported by speedguide and verifed with ethereal.

BTW, thats with my filter set. Smile!

Mike
Add Thank You Quote this message in a reply
Nov. 13, 2005, 08:40 PM
Post: #87
 
Mike

Well, for criminy's sake, share the dope with the rest of us! Microphone

Can you at least give us the byte offset where the new value must be placed (in the exe file)? And what would that new value be, hmmmm? Also, can we use something like Resource Hacker, or do we have to get down and dirty with Debug, in the command line environment? Pervert

P.S. Nice going! Cheers


Oddysey

I'm no longer in the rat race - the rats won't have me!
Add Thank You Quote this message in a reply
Nov. 13, 2005, 09:23 PM
Post: #88
 
z12 Wrote:
Peakaboo Wrote:the fallacy is assuming something will not have an impact if you are truly guessing as to what the problem is - which despite all the expertise is what is going on.

I agree. Guessing wasn't getting it done, so I decided to disassemble proxo's code and have a look for myself.

Based on the code, its clear that there is a setsockopt function call that hard codes 32768 for the rcv buffer size. Why this function call has no effect on pre XP OS's, I can only guess.

However, I can change the rcv buffer size to whatever I want by editing the hard coded value. Currently my rwin is 513920 as reported by speedguide and verifed with ethereal.

BTW, thats with my filter set. Smile!

Mike

nice going Mike Smile!

hope this can be easily shared with others in some way after you feel comfortable with the change.

I'm sure you will want to test it out good first to insure no ill effects of changing the hard coded buffer size in proxo.

No need to guess anymore - but re: other os not having the issue, probably something in the os or setup masks or defeats the hard coded buffer - no matter, now we know thanks to you.

Too bad, I was looking forward to hearing hpguru say next again. LMAO Wink
Add Thank You Quote this message in a reply
Nov. 13, 2005, 10:43 PM
Post: #89
 
Basically, I became aware of a "patch" to fix the problem by a fellow UOPF member. I was curious to to see what it did. Thats how I came to find the setsockopt function call with the hard coded rcvbuf size. The patch is still being discussed.

I just wanted to point out that the problem is not dependent on the filter set.

Mike
Add Thank You Quote this message in a reply
Nov. 14, 2005, 03:12 AM
Post: #90
 
z12 Wrote:I just wanted to point out that the problem is not dependent on the filter set.

Mike

Just so my point is not missed, my thrust was to look for the variables which nullified the dependency.

The assumption was without express permission that whatever was in proxo had to stay. The workaround was to id what was different in hpguru's setup ie. variables which nullified the dependency. You found one yourself in putting bfilter in between proxo and your browser.

Anyway it will be interesting to see how this is handled unless the proxo program is somehow now considered public domain. Smile!
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: