sgbotsford

It would be nice if the graph had a proper time axis on it. This way if you are testing a satellite link with several tests back to back, followed by several hours of nothing, they would show up properly.

It also allows you to pick out the best times to run large downloads.

Big key feature however is so taht you can give the small claims court a printout showing how screwed up your ISP is at meeting the terms of your agreement.

Yeah, I could do it myself in excel, but having the online version makes it easy to show a general trend, and gives it more credibility.

Having vertical lines for days, weekends shaded in a somewhat different color, and dates running on the bottom for long range plots.

The second form should work.

Try adding a -v or -vv and see if the diagnostics reveal anything.

The first two thoughts: You set the new port, but didn't restart the daemon. Or your fingers lead their own life and xxxx in your command is NOT the new port on your server.

Check using something like nmap or hping to see that ssh is running on the port you want. If it's not, then scan to see if ssh is running on another port.

A third possibility is that ssh is set up to refuse root access (this is the default.)

Can you login with password? e.g. ssh -p xxxx [email protected]

***

General note: Always have two ways to access a remote machine. Change only one at a time. Make sure that change survives a reboot. Now change the other one.

I'd like a command line version of this. Otherwise I'll close the window by mistake, and then I won't get results, because it won't be running.

Ideally I'd something like:

testmynet
-u {string} username (required)
-c {string} connection name (required)
-l {pathname} path/to/logfile
-n {number} number of times to run
-i {time unit } interval between runs. Interval is from the END of the previous run.
-j {time unit} jitter. Random variation in when to run.
-min {number} mininum data size
-max {number} maximum data size
-auto base size on history.
-s servername

-d {direction: up, down, both}

The -j flag allows things like this:

testmynet -i 2:00 -j 0:30 this waits a random amount of time up to 30 minutes before running the test. If unspecified, j should default to something like 1/4 of the interval. This will prevent 5000 cron jobs all over the world hitting you at exactly 11 a.m.

If -i is set to zero, and n > 1 the tests will be back to back, but there is an implied -j of 1 minute per megabyte before the tests start.

The server can tell the client. "Busy now. Try in 5" and the client will wait 5 minutes and try again.

If you decide to do this, you also need some protection.
There are two risks:
1. Someone sets this up, and ignores it, and it runs whenever their machine is on. This is a mild waste of resources, except it's helping you build your database.
2. Some ISP who your records have really pissed off launches a DoS attack on you.

I would suggest something like this:

Set up dns records for tmn1.testmy.net tmn2.testmy.net qfmp.testmy.net

If you get hammered too hard, change the server names, or disable that user. By having a yearly server name change and announcing it on your site, you filter out risk #1.

I would also have a firewall setup that would allow me to block connections from an abusive player at the first SYN packet. pf, under any of the BSD unixes can be set up to do this.

An additional feature to prevent abuse.

Require the client to perform a complex calculation. This should be time consuming enough that it becomes unreasonable to run multiple copies of the client program.

testmynetclient: I want to run a test.
server:Very well, here is your challenge.
client: goes away and calculates for a while.
client: Here is the response to your challenge
server: go ahead. What are the test parameters?



Examples of difficult calculations:

Given the seed as the starting string into md5, what is the millionth iteration feeding each output of md5 as the seed for the next call. (It may have to be billionth -- you want the computational time to be comparable to the download time on an average connection.)

At your end you have to make the same calculations -- but you can save your results.

So pick a seed. Iterate it a billion times, but record all the results. (You could save space by recording only every thousanth result.)

When a client attaches you pick it's seed from the file, then look 1 million lines later for the expected reply.

The client can be programmed to have a wait call during each iteration. This will mean that the client won't annoy the client's owner, sucking up too many cpu cycles. This would allow you to reduce the number of required iterations.

You also set it up so that the server will not accept multiple connections from one IP address. This may be a problem with NATed networks.