Windows TCP Settings - Follow up - Help with server communication

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

To post messages, you must log in.

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

AuthorMessage
Richard HaselgroveProject Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 11136
Credit: 83,510,937
RAC: 41,350
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.

ID: 1349175 · Report as offensive
Profile ML1
Volunteer tester

Send message
Joined: 25 Nov 01
Posts: 9201
Credit: 5,927,135
RAC: 1,919
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: Mageia5
See & try out for yourself: Linux Voice
The Future is what We all make IT (GPLv3)

ID: 1349192 · Report as offensive
Profile rebest
Volunteer tester
Avatar

Send message
Joined: 16 Apr 00
Posts: 1296
Credit: 40,876,800
RAC: 7,730
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!

ID: 1349206 · Report as offensive
Richard HaselgroveProject Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 11136
Credit: 83,510,937
RAC: 41,350
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.

ID: 1349215 · Report as offensive
David SProject Donor
Volunteer tester
Avatar

Send message
Joined: 4 Oct 99
Posts: 17034
Credit: 20,916,361
RAC: 5,957
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.


ID: 1349217 · Report as offensive
Profile Bernie Vine
Volunteer moderator
Volunteer tester
Avatar

Send message
Joined: 26 May 99
Posts: 8577
Credit: 43,042,842
RAC: 20,957
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!
"Sometimes it is the people no one imagines anything of who do the things that no one can imagine."

ID: 1349260 · Report as offensive
juan BFP
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 5847
Credit: 330,514,374
RAC: 7,698
Panama
Message 1349268 - Posted: 21 Mar 2013, 23:20:31 UTC

+ 1


ID: 1349268 · Report as offensive
Profile SciManStev
Volunteer tester
Avatar

Send message
Joined: 20 Jun 99
Posts: 5844
Credit: 105,982,848
RAC: 3,042
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

ID: 1349269 · Report as offensive
Ivailo Bonev
Volunteer tester
Avatar

Send message
Joined: 26 Jun 00
Posts: 246
Credit: 31,372,476
RAC: 4,186
Bulgaria
Message 1349276 - Posted: 21 Mar 2013, 23:54:36 UTC

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


ID: 1349276 · Report as offensive
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.

ID: 1349321 · Report as offensive
Profile S@NL Etienne Dokkum
Volunteer tester
Avatar

Send message
Joined: 11 Jun 99
Posts: 212
Credit: 29,901,685
RAC: 19,644
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...


ID: 1349327 · Report as offensive
kittymanProject Donor
Volunteer tester
Avatar

Send message
Joined: 9 Jul 00
Posts: 45862
Credit: 814,617,495
RAC: 121,639
United States
Message 1349350 - Posted: 22 Mar 2013, 7:21:40 UTC
Last modified: 22 Mar 2013, 7:22:58 UTC

I have been using the mod on my daily driver (Win 7 64bit) and one of my top crunchers (XP Pro 64bit) since this thread started, and have no negatives to report whatsoever.

Nothing but downloading joy on Seti, and no artifacts noticed on my usual browsing and other activities on the daily driver.

I also recommend the command line route provided by our friend Richard, as it does not require any program download or installation, and does not muck with any settings other than the one required to achieve the desired result.

Nothing but kitty purrs here.


Kitties make wonderful traveling companions on your journey through life.

Have made a few friends in this life.
Most were cats.

ID: 1349350 · Report as offensive
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 :)

ID: 1349365 · Report as offensive
Profile [B^S] madmac
Volunteer tester
Avatar

Send message
Joined: 9 Feb 04
Posts: 1175
Credit: 4,754,897
RAC: 0
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.


ID: 1349366 · Report as offensive
Cosmic_Ocean
Avatar

Send message
Joined: 23 Dec 00
Posts: 2871
Credit: 10,620,139
RAC: 305
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:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

ID: 1349532 · Report as offensive
Profile Link
Avatar

Send message
Joined: 18 Sep 03
Posts: 805
Credit: 1,678,562
RAC: 44
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.
.

ID: 1349612 · Report as offensive
BWX

Send message
Joined: 31 May 03
Posts: 35
Credit: 139,101,122
RAC: 34,392
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?


ID: 1349659 · Report as offensive
Cosmic_Ocean
Avatar

Send message
Joined: 23 Dec 00
Posts: 2871
Credit: 10,620,139
RAC: 305
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:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

ID: 1349689 · Report as offensive
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 :)

ID: 1349706 · Report as offensive
Profile James SotherdenProject Donor
Avatar

Send message
Joined: 16 May 99
Posts: 10133
Credit: 65,619,083
RAC: 34,830
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.


[/quote]

Old James

ID: 1349768 · Report as offensive
Previous · 1 . . . 10 · 11 · 12 · 13 · 14 · Next

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


 
©2016 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.