NODE a42a7340SSL Challenge: Are we in trouble?
"Peter Trei" <trei@process.com>Fri, 25 Aug 95 07:24:04 PDT
Well, the server appears to be unable to serve cgi scripts - I get
'500 - server error' whenever I try. I cannot report the ~500 segments
I swept overnight, nor get new keyspace.
I thing it's gotten to the point where the server is the bottleneck on
this operation - we seem to have plenty of cpu for sweeps. This will
damage our primary goal - to demonstrate how fast 40 bits can be
swept.
Piete, Adam, could you put a note on the /bute/ root page describing the
server status?
Thanks
Peter Trei
Senior Software Engineer
Purveyor Development Team
Process Software Corporation
trei@process.com
NODE ce38cb4fRe: SSL Challenge: Are we in trouble?
mlm@skyrr.is (Magnus Logi Magnusson)Fri, 25 Aug 95 07:53:51 PDT
> Well, the server appears to be unable to serve cgi scripts - I get
> '500 - server error' whenever I try. I cannot report the ~500 segments
> I swept overnight, nor get new keyspace.
>
But what also is realy anoying, when I get through I only get 3 keyspaces,
even though I request 16. I can understand the limit probably caused
by the guy yesterday who requested 50000 keyspaces 1f-something to
ce-something, but I think 3 is way to low.
> I thing it's gotten to the point where the server is the bottleneck on
> this operation - we seem to have plenty of cpu for sweeps. This will
> damage our primary goal - to demonstrate how fast 40 bits can be
> swept.
>
I and a coworker have 4 pentiums (not much compared to some of you) but they
are idleing most of the time...
> Piete, Adam, could you put a note on the /bute/ root page describing the
> server status?
Yeah.. whats up?
Logi.
--
Magnus Logi Magnusson
System programmer, State and Municipal Data processing center, Iceland
E-mail: mlm@skyrr.is & mlm@rhi.hi.is
NODE d87fb96aRe: SSL Challenge: Are we in trouble?
Piete Brooks <Piete.Brooks@cl.cam.ac.uk>Fri, 25 Aug 95 09:01:31 PDT
> But what also is realy anoying, when I get through I only get 3 keyspaces,
> even though I request 16.
Sorry about that -- someone misconfigured their system and walked through the
address sspaxce asking for ranges (size 3) and then discarding them and asking
for more.
I wasn't really expecting such small holes, so kept the allocation code REAL
SIMPLE -- it give the user *upto* the requested amount from the first chunk.
I see this is a bit of a bummer for you :-((
I may tweak it to look in subsequent blocks ....
>> Piete, Adam, could you put a note on the /bute/ root page describing the
>> server status?
> Yeah.. whats up?
As I said earlier, phase (1) and (2) are upsetting phase (3) ...
Basically the WWW interface was calling the SKSP interface and wedging.
WWW then used up all its permitted processes, so the WWW server died.
[[ PERL gurus out there: how can I avoid the "sh -c" process in
$out = `cmd -a 'arg 1'`;
]]
I have freed the ACK blockage, and made the allocate code not try quite so
hard, and now our WWW server is back in the land of the living.
The SKSP server is still seeing null sessions which time out after half a
minute -- a bit of a bummeer :-(
The hosts concerned are decent citizens most of the time (I think ...)
"|23" means "23 seconds after the call started". Any ideas ?
5/08/25 13:59:07 12992 18.43.0.244 {0,0} |11 HELO 1 bal@mit.edu Brian A.
LaMacchia,NE43-431,3-0290,868-8042 ++ TIMEOUT ||31
95/08/25 13:59:38 12992 198.68.45.155 {0,0} ++ TIMEOUT ||31
95/08/25 14:01:48 12992 192.232.101.8 {0,0} |1 HELO 1 rgvb@alewife.kodak.com
Richard G. von Blucher with ROC UID, GID |2 COMM brc0.14 [dlkt]: brloop0.2 |8
INFO ++ TIMEOUT ||31
95/08/25 14:02:19 12992 128.93.8.103 {0,0} ++ TIMEOUT ||31
95/08/25 14:03:06 12992 198.68.45.155 {0,0} ++ TIMEOUT ||31
95/08/25 14:03:50 12992 128.52.36.30 {0,0} |1 HELO 1 lethin@ai.mit.edu Rich
Lethin ++ TIMEOUT ||31
95/08/25 14:05:29 12992 134.95.80.15 {0,0} ++ TIMEOUT ||31
95/08/25 14:06:13 12992 192.232.101.8 {0,0} |1 HELO 1 rgvb@alewife.kodak.com
Richard G. von Blucher with ROC UID, GID |6 COMM brc0.14 [dlkt]: brloop0.2 |6
INFO |17 WORK 2977 |29 KEYS 2977 1 ==> 2977 51a8 3 ++ TIMEOUT ||32
95/08/25 14:06:55 12992 198.68.45.155 {0,0} |0 HELO 1 jcastle@in-system.com
Jim Castleberry ++ TIMEOUT ||31
95/08/25 14:07:32 12992 204.249.46.33 {0,0} ++ TIMEOUT ||31
95/08/25 14:12:48 12992 163.173.128.233 {0,0} ++ TIMEOUT ||31
95/08/25 14:14:05 12992 204.5.88.180 {0,0} |15 HELO 1 Duncan@hasp.com Duncan J
Watson |15 COMM brc0.14 [dLkt]: brl0.04 |18 INFO |26 WORK 29de ++ TIMEOUT ||31
95/08/25 14:15:23 12992 129.69.116.124 {0,1} |0 HELO 1
floeff@mathematik.uni-stuttgart.de Siegfried Loeffler |0 COMM brc0.14 [dlLkt]:
brl0.04 |0 INFO ++ TIMEOUT ||31
95/08/25 14:16:30 12992 204.215.255.3 {0,0} ++ TIMEOUT ||31
95/08/25 14:17:33 12992 128.93.8.7 {0,0} |1 HELO 1 damien.doligez@inria.fr
Damien Doligez |1 COMM brc0.14 [dlLkt]: brl0.04 ++ TIMEOUT ||31
95/08/25 14:21:12 12992 18.43.0.111 {0,0} ++ TIMEOUT ||31
95/08/25 14:31:35 12992 128.52.36.32 {0,1} |11 HELO 1
lethin@almond-fr.ai.mit.edu Rich Lethin ++ TIMEOUT ||31
95/08/25 14:33:51 12992 193.197.24.49 {0,0} |9 HELO 1 cg@bofh.lake.de Cees de
Groot ++ TIMEOUT ||31
95/08/25 14:34:27 12992 202.30.52.1 {0,0} |2 HELO 1 jschoi@seodu.co.kr Choi
Jaeseon |18 COMM brc0.08: brloop0.2 ++ TIMEOUT ||31
95/08/25 14:35:05 12992 18.151.0.165 {0,0} |13 HELO 1 zeno@madman.MIT.EDU
Richard Duffy ++ TIMEOUT ||31
95/08/25 14:36:28 12992 155.100.229.31 {0,0} ++ TIMEOUT ||32
95/08/25 14:38:02 12992 128.93.8.81 {0,0} |0 HELO 1 damien.doligez@inria.fr
Damien Doligez ++ TIMEOUT ||31
95/08/25 14:38:33 12992 155.100.229.31 {0,0} |0 HELO 1
zinc@zifi.genetics.utah.edu zinc,over there,666-HATE,666-LOVE, ++ TIMEOUT ||32
95/08/25 14:39:12 12992 129.13.109.39 {1,0} |0 HELO 1 an121660@anon.penet.fi
Olaf Erb,,, |1 COMM brc0.14 [dlLkt]: brl0.03 |3 INFO |15 WORK 2977 ++ TIMEOUT
||31
95/08/25 14:40:40 12992 198.82.200.50 {0,0} |13 HELO 1
millner@millner.bevc.blacksburg.va.us Robert Millner,,,(540)961-4321, ++
TIMEOUT ||31
95/08/25 14:41:24 12992 18.43.0.163 {0,0} |0 HELO 1 bal@mit.edu Brian A.
LaMacchia,NE43-431,3-0290,868-8042 |14 COMM brc0.12: brl0.04 |23 INFO ++
TIMEOUT ||31
95/08/25 14:43:02 12992 204.215.85.69 {0,0} |2 HELO 1
chrisg@glass.lplizard.com Leaping Lizard Software |3 COMM brc0.14 [lkntvV] |27
INFO ++ TIMEOUT ||31
95/08/25 14:45:40 12992 18.43.0.184 {0,0} ++ TIMEOUT ||31
95/08/25 14:54:32 12992 128.93.8.124 {0,0} |0 HELO 1 damien.doligez@inria.fr
Damien Doligez |2 COMM brc0.14 [dlLkt]: brl0.04 ++ TIMEOUT ||31
95/08/25 15:00:28 12992 128.174.241.76 {0,0} ++ TIMEOUT ||31
95/08/25 15:03:19 12992 204.5.89.50 {0,0} |12 HELO 1 duncan@hasp.com Duncan
|12 COMM brc0.14 [dlLkt]: brl0.04 |13 INFO ++ TIMEOUT ||31
95/08/25 15:03:51 12992 128.93.8.133 {0,0} |24 HELO 1 damien.doligez@inria.fr
Damien Doligez ++ TIMEOUT ||32
95/08/25 15:05:37 12992 18.43.0.166 {0,0} ++ TIMEOUT ||31
95/08/25 15:06:57 12992 204.215.255.3 {0,0} ++ TIMEOUT ||31
95/08/25 15:07:33 12992 128.2.198.78 {0,0} |1 HELO 1
hgobioff@GS207.SP.CS.CMU.EDU Howard Gobioff |2 COMM brc0.13 [dlLkt]: brl0.04
|11 INFO |26 WORK 2977 |29 KEYS 2977 1 ==> 2977 566f 3 ++ TIMEOUT ||32
95/08/25 15:09:55 12992 204.249.46.33 {0,0} |12 HELO 1 mike@uac.net Michael
|15 COMM brc0.14 [dlLkt]: brl0.04 |22 INFO ++ TIMEOUT ||31
95/08/25 15:14:05 12992 204.215.255.3 {0,0} ++ TIMEOUT ||31
95/08/25 15:16:59 12992 158.152.9.126 {0,0} ++ TIMEOUT ||31
95/08/25 15:17:30 12992 204.5.88.2 {0,0} |20 HELO 1 duncan@hasp.com Duncan J
Watson ++ TIMEOUT ||31
95/08/25 15:18:08 12992 140.78.101.30 {0,0} |3 HELO 1
burge@cast.uni-linz.ac.at Mark Burge |8 COMM brc0.08: brloop0.2 ++ TIMEOUT ||31
95/08/25 15:19:02 12992 128.93.8.7 {0,0} |0 HELO 1 damien.doligez@inria.fr
Damien Doligez |14 COMM brc0.14 [dlLkt]: brl0.04 ++ TIMEOUT ||31
NODE 24782f41Re: SSL Challenge: Are we in trouble?
Ian Goldberg <iagoldbe@calum.csclub.uwaterloo.ca>Fri, 25 Aug 95 14:39:28 PDT
> [[ PERL gurus out there: how can I avoid the "sh -c" process in
> $out = `cmd -a 'arg 1'`;
> ]]
>
open(CMD, "-|") || exec 'cmd', '-a', 'arg 1';
$out = <CMD>; ## Gets one line
close(CMD);
Use
$out = join('',<CMD>);
instead of the second line above to get the whole output at once.
---------.. ._ _.------------
Ian Goldberg University of Waterloo Computer Science Club
iagoldberg@csclub.uwaterloo.ca
unsigned bar(unsigned a){return a?bar(a<<1)<<1|a>a<<1>>1:1>>1;}
NODE e0bd2374Re: SSL Challenge: Are we in trouble?
Piete Brooks <Piete.Brooks@cl.cam.ac.uk>Fri, 25 Aug 95 08:26:10 PDT
> Well, the server appears to be unable to serve cgi scripts - I get
> '500 - server error' whenever I try. I cannot report the ~500 segments
> I swept overnight, nor get new keyspace.
Try again ...
> I thing it's gotten to the point where the server is the bottleneck on
> this operation
Has been on & off for some time :-((
> - we seem to have plenty of cpu for sweeps. This will damage our primary
> goal - to demonstrate how fast 40 bits can be swept.
Well, my tertiary goal ...
> Piete, Adam, could you put a note on the /bute/ root page describing the
> server status?
Done.
In brief -- you guessed it -- upgrade to http://www.brute.cl.cam.ac.uk/ftp/pub/
brute/brclient 0.16 and ACK should go a lot quicker, and as people move over
to using 0.16, so will allocates ...