Windows TCP Settings - Follow up - Help with server communication


log in

Advanced search

Message boards : Number crunching : Windows TCP Settings - Follow up - Help with server communication

Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · Next
Author Message
Richard HaselgroveProject donor
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8760
Credit: 52,711,348
RAC: 23,533
United Kingdom
Message 1349175 - Posted: 21 Mar 2013, 18:57:13 UTC - in response to Message 1349065.

Can someone tell me more about the security issue with timestamps?

Sorry, parked this in the rush, and never came back to it.

In a word, no. As with many subjects on the internet, when you search for it, you find vastly more pananoid or ignorant questions than you find answers. I don't pretend that my original comment was rigorous, or even necessarily accurate - I was just attempting to provide some counter-examples, to suggest that reporting RFC1323 to Microsoft as if the non-default implementation was a bug was perhaps wide of the mark.

The security implication I'd picked up in my reading/research was that some *server operators* - i.e. nothing of what follows is of any concern to home users - were worried that 'black hats' could deduce from the time stamps on TCP packets how long it had been since the server was last rebooted, or even how long since security patches had been applied. If attackers knew or could deduce that a particular security patch was missing, they might be able to use the exploit the patch was designed to block, and get into the server that way.

Apart from not applying to us (if anyone should worry, it's the boyz in the lab), further thinking and reading suggests to me that the theory is bullshit. It seems to rely on there being some connection between 'timestamps' in the RFC1323/TCP sense, and timestamps like your works clocking-in and clocking-out card - in other words, wall-clock time.

If you read s4.2.2 Timestamp Clock on page 19-20 of http://www.ietf.org/rfc/rfc1323.txt, you'll see that no such correlation is required or even implied. A TCP timestamp is simply a number, which steadily increases. It has no particular starting point, and no particular rate of increase. They do suggest it should increase neither 'too fast' nor 'too slow' - but say 'the maximum acceptable clock frequency is one tick every 59 nanoseconds'. The 'goldilocks' speed (they seem to imply, writing 20 years ago) is a clock which ticks about once every millisecond: at that speed, the numbers are recycled and cease to have any meaning every 24.8 days.

Overall, I'm sure there are better ways of hacking into a server - like bribing the cleaners to collect any post-it notes with passwords written on them.

Profile ML1
Volunteer tester
Send message
Joined: 25 Nov 01
Posts: 8572
Credit: 4,232,837
RAC: 984
United Kingdom
Message 1349192 - Posted: 21 Mar 2013, 19:18:11 UTC - in response to Message 1349175.
Last modified: 21 Mar 2013, 19:28:25 UTC

Richard,

Thanks for a good answer. So more a case of paranoia over substance. Pre-Linux-2.1 is an awful long time ago for the defaults (timestamps on) not to have been very thoroughly tested by the big bad world!

Which still leaves the question of why timestamps available but defaulted to off for Windows. I can't believe it's any concern for the small overhead vs benefit. To be worried about deducing uptime seems overly paranoid. Curious...


Happy fun crunchin',

Regards,
Martin
____________
See new freedom: Mageia4
Linux Voice See & try out your OS Freedom!
The Future is what We make IT (GPLv3)

Profile rebestProject donor
Volunteer tester
Avatar
Send message
Joined: 16 Apr 00
Posts: 1296
Credit: 33,247,604
RAC: 9,728
United States
Message 1349206 - Posted: 21 Mar 2013, 19:45:24 UTC

A follow on question:

I switched back to running BOINC 6.10.60 because 1) my downloads were hanging which 2) kicked in the ridiculously long project backoff times in BOINC 7.X.X. The hangups have been largely eliminated by adopting the TCP fix. My transfer rates are glacial, but downloads are now consistent. For those of you running the newer BOINC Windows versions, does the TCP fix help with your backoff situation?
____________

Join the PACK!

Richard HaselgroveProject donor
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8760
Credit: 52,711,348
RAC: 23,533
United Kingdom
Message 1349215 - Posted: 21 Mar 2013, 20:00:51 UTC - in response to Message 1349206.

A follow on question:

I switched back to running BOINC 6.10.60 because 1) my downloads were hanging which 2) kicked in the ridiculously long project backoff times in BOINC 7.X.X. The hangups have been largely eliminated by adopting the TCP fix. My transfer rates are glacial, but downloads are now consistent. For those of you running the newer BOINC Windows versions, does the TCP fix help with your backoff situation?

Yes. I run a machine with Windows 7, BOINC (currently) v7.0.58, and two GTX 670 GPUs. I spread the GPUs across multiple projects, so I don't have to download enough SETI to keep them fully occupied - but they can still get through a lot. My first request after the overnight network upgrade outage yielded something like 44 new tasks (IIRC). They just plodded down the line, slow but steady, and I've given up even bothering to check whether they arrived safely. I've never had a stuck queue since I was told about RFC1323 (take a bow, those who tracked it down), which is why I've been so enthusiastic about promoting it.

N9JFE David SProject donor
Volunteer tester
Avatar
Send message
Joined: 4 Oct 99
Posts: 12465
Credit: 14,824,986
RAC: 4,219
United States
Message 1349217 - Posted: 21 Mar 2013, 20:12:10 UTC - in response to Message 1349175.
Last modified: 21 Mar 2013, 20:12:38 UTC

Can someone tell me more about the security issue with timestamps?

Sorry, parked this in the rush, and never came back to it.

In a word, no. As with many subjects on the internet, when you search for it, you find vastly more pananoid or ignorant questions than you find answers. I don't pretend that my original comment was rigorous, or even necessarily accurate - I was just attempting to provide some counter-examples, to suggest that reporting RFC1323 to Microsoft as if the non-default implementation was a bug was perhaps wide of the mark.

That much I already understood.

The security implication I'd picked up in my reading/research was that some *server operators* - i.e. nothing of what follows is of any concern to home users - were worried that 'black hats' could deduce from the time stamps on TCP packets how long it had been since the server was last rebooted, or even how long since security patches had been applied. If attackers knew or could deduce that a particular security patch was missing, they might be able to use the exploit the patch was designed to block, and get into the server that way.

Apart from not applying to us (if anyone should worry, it's the boyz in the lab), further thinking and reading suggests to me that the theory is bullshit.

Thanks for a clear explanation. I mostly understood it (although I don't think I would be further enlightened by clicking the link), well enough to believe that last sentence.

I now feel comfortable ignoring the issue.
____________
David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.


Profile Bernie Vine
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 26 May 99
Posts: 7124
Credit: 28,507,699
RAC: 22,761
United Kingdom
Message 1349260 - Posted: 21 Mar 2013, 22:47:36 UTC

I've never had a stuck queue since I was told about RFC1323 (take a bow, those who tracked it down),

100% agree!
____________


Today is life, the only life we're sure of. Make the most of today.

juan BFBProject donor
Volunteer tester
Avatar
Send message
Joined: 16 Mar 07
Posts: 5471
Credit: 313,429,273
RAC: 129,945
Brazil
Message 1349268 - Posted: 21 Mar 2013, 23:20:31 UTC

+ 1
____________

Profile SciManStevProject donor
Volunteer tester
Avatar
Send message
Joined: 20 Jun 99
Posts: 4894
Credit: 83,863,808
RAC: 16,122
United States
Message 1349269 - Posted: 21 Mar 2013, 23:21:08 UTC - in response to Message 1349260.

I've never had a stuck queue since I was told about RFC1323 (take a bow, those who tracked it down),

100% agree!

+1

Steve
____________
Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

Ivailo Bonev
Volunteer tester
Avatar
Send message
Joined: 26 Jun 00
Posts: 241
Credit: 26,664,967
RAC: 5,706
Bulgaria
Message 1349276 - Posted: 21 Mar 2013, 23:54:36 UTC

+1 Definetely much more consistant downloads from S@H now, thanks.
____________

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Profile DeadVirus
Send message
Joined: 20 Mar 13
Posts: 1
Credit: 220,965
RAC: 0
United States
Message 1349321 - Posted: 22 Mar 2013, 5:08:18 UTC - in response to Message 1349276.

Worked for me! 11k-15k average now.

Profile S@NL Etienne Dokkum
Volunteer tester
Avatar
Send message
Joined: 11 Jun 99
Posts: 174
Credit: 17,401,838
RAC: 8,234
Netherlands
Message 1349327 - Posted: 22 Mar 2013, 6:05:49 UTC

works like a charm ! Tried it on 1 PC last night and this morning it DL'ed all and is back to the 200 tasks limit...
____________
http://allprojectstats.com/sig2393779.gif

alan
Avatar
Send message
Joined: 18 Feb 00
Posts: 131
Credit: 401,606
RAC: 0
United Kingdom
Message 1349365 - Posted: 22 Mar 2013, 8:04:27 UTC
Last modified: 22 Mar 2013, 8:05:20 UTC

Positive results on my machine. All downloads now complete in one continuous operation, AP's taking about 30 minutes but no lost connections. The lack of retries alone is a big win all round, good for me and good for the SETI download servers.

I'm running XP and used the command line method suggested by Richard Haselgrove, setting the single variable Tcp1323Opts to 3 to set both windows scaling and timestamps to be ON. No negative effects on any other network activity - and this is a general purpose machine, the one I'm typing this reply on :)

Profile [B^S] madmac
Volunteer tester
Avatar
Send message
Joined: 9 Feb 04
Posts: 1155
Credit: 3,904,246
RAC: 2,092
United Kingdom
Message 1349366 - Posted: 22 Mar 2013, 8:08:32 UTC

Just thought I let you know cleared my cache at the end of the day, then did Shift Ctrl + Enter and it worked must have used return the first time weird or what.
____________

Cosmic_Ocean
Avatar
Send message
Joined: 23 Dec 00
Posts: 2326
Credit: 8,868,377
RAC: 888
United States
Message 1349532 - Posted: 22 Mar 2013, 18:25:17 UTC

Just wanted to report that all is well here, too, as evidenced by..



Not a single one of those stalled or timed-out.
____________

Linux laptop uptime: 1484d 22h 42m
Ended due to UPS failure, found 14 hours after the fact

Profile Link
Avatar
Send message
Joined: 18 Sep 03
Posts: 838
Credit: 1,577,462
RAC: 160
Germany
Message 1349612 - Posted: 22 Mar 2013, 21:55:39 UTC - in response to Message 1349206.

A follow on question:

I switched back to running BOINC 6.10.60 because 1) my downloads were hanging which 2) kicked in the ridiculously long project backoff times in BOINC 7.X.X. The hangups have been largely eliminated by adopting the TCP fix. My transfer rates are glacial, but downloads are now consistent. For those of you running the newer BOINC Windows versions, does the TCP fix help with your backoff situation?

Well, in my case of BOINC 6.12.34 it helps for sure, since I applied the fix BOINC decided not to use any backoffs at all, at least not for fole transfers. Looking like that in my log:

22/03/2013 22:47:55 rosetta@home Started download of rb_03_12_36962_70171_h002__synp_aah002_07_05.200_v1_3.gz
22/03/2013 22:54:33 Project communication failed: attempting access to reference site
22/03/2013 22:54:33 rosetta@home Temporarily failed download of rb_03_12_36962_70171_h002__synp_aah002_07_05.200_v1_3.gz: HTTP error
22/03/2013 22:54:35 rosetta@home Started download of rb_03_12_36962_70171_h002__synp_aah002_07_05.200_v1_3.gz
22/03/2013 22:54:38 Internet access OK - project servers may be temporarily down.

A 0-2 second backoff is OK to me.
____________
.

BWX
Send message
Joined: 31 May 03
Posts: 35
Credit: 94,577,398
RAC: 37,860
United States
Message 1349659 - Posted: 23 Mar 2013, 1:45:15 UTC

Worked great for me on W7 both 32 and 64 bit.

Had raised the simultaneous download to 8 as Cosmic below. Changed back to default 2 as is no longer needed.

I wonder if everybody making this fix also would go back to 2 would help with congestion?
____________

Cosmic_Ocean
Avatar
Send message
Joined: 23 Dec 00
Posts: 2326
Credit: 8,868,377
RAC: 888
United States
Message 1349689 - Posted: 23 Mar 2013, 4:53:51 UTC - in response to Message 1349659.

Worked great for me on W7 both 32 and 64 bit.

Had raised the simultaneous download to 8 as Cosmic below. Changed back to default 2 as is no longer needed.

I wonder if everybody making this fix also would go back to 2 would help with congestion?

Actually, mine's set for 10. It is rare that I get more than 1 or 2 at a time anyway. It's mostly just useful for when AP doesn't get split for a few days and then I need to rebuild my cache.
____________

Linux laptop uptime: 1484d 22h 42m
Ended due to UPS failure, found 14 hours after the fact

Profile Swordfish
Avatar
Send message
Joined: 5 Aug 06
Posts: 72
Credit: 3,012,670
RAC: 0
United Kingdom
Message 1349706 - Posted: 23 Mar 2013, 7:22:25 UTC

Working great on my 3 windows 8 machines.

No more having to hit the retry , especially on astropulse wu's.

Thanks guys, for the info :)

Profile James Sotherden
Avatar
Send message
Joined: 16 May 99
Posts: 9026
Credit: 36,975,853
RAC: 20,792
United States
Message 1349768 - Posted: 23 Mar 2013, 12:23:51 UTC

Richard I just used your command prop on my Win7 and Vista machines.
Thank You. It was easy to do and it works.

I know download speed isnt what this command line is about, But watching my two computers I see that the speed is very consistent. Before I put the command line in Id start off at 10KBps and it would slow to a crawl then go to retry.

Those of you who havent done this yet, It will make a huge differance. Ive had AP retrys on both of my machines that would last days. Now they are allmost gone.

I think you have a winner.
____________

Old James

Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · Next

Message boards : Number crunching : Windows TCP Settings - Follow up - Help with server communication

Copyright © 2014 University of California