Randomize ping speed / size / destination?

October 11, 2007 11:15 AM

In UNIX (specifically FreeBSD, if it matters), is there a way to *randomize* the interval and/or size and/or destination of pings?

(For example, "at intervals ranging from 500 to 3000 ms, send somewhere between 50 and 200 bytes to any one of these twenty machines: x, x, x...")

If not, is there a utility for Mac OS (10.4, Intel) that's configurable like this?

Here's the man page for ping, which shows you can set a single value for interval and size, but not a range of values.

This is one idea I had for a network connection that is occasionally disconnecting and/or timing out (sometimes possibly due to inactivity, sometimes right in the middle of activity -- it's a little fragile/fiddly to begin with, so there could be multiple reasons).

I do know it's not consistently being kept alive with the old "just keep pinging to maintain activity" trick. So one theory I've come up with is that the ISP, knowing this trick, considers perfectly regular same-size activity to mean "this connection isn't actually active after all and so we should force a disconnect." Might be crazy, but if it's easy to test somehow, it's worth testing....

If you have any instructions, you're talking to someone with only functional/basic UNIX skills (who can get around in a shell when she needs to but usually lives in the Mac GUI).

posted by allterrainbrain to Computers & Internet (9 answers total)

Not sure, but nmap might be able to do this. (It's available through fink, or whatever package management system you use.)
posted by spaceman_spiff at 11:21 AM on October 11, 2007

Best answer: In linux at least (don't have access to a BSD machine right now, this simple bash-script will work:

#!/bin/bash

while true;
do
  t=$(($RANDOM%2500 + 500))
  b=$(($RANDOM%150 + 50))
  ping -c 1 -s $b $1
  usleep $(($t*1000))
done

Save it to e.g. ping.sh, make it executable and call it like ./ping.sh www.example.com

What might not work on BSD is the call to usleep, I don't know if it's Linux specific or not. You could replace it with

  sleep $(($t/1000)) 

instead.

I don't know if it will solve your problem though, as ping packets are easily detected. I.e. it might not be the regularity of your packets that are the problem but that the packets are ICMP-packets. You could instead try to write a simple script that periodically downloads a web page with wget or curl.
posted by rpn at 11:37 AM on October 11, 2007

Best answer: Any scripting language would make this possible. It's possibly obnoxious behavior, but possible. The following cuts some corners -- better to fork the system call and have the child process die immediately after the ping. The sleep is 1-3 seconds after the completion of each ping call, rather than initiating a ping every 500-3000 ms. (Perl's built-in sleep only takes an integer number of seconds. There's a module to sleep for a given number of microseconds; that's left as an exercise.)

#!/usr/bin/perl

my @ips = qw(ip1.com ip2.com ip3.com);

while (1) {
my $ip = $ips[rand scalar @ips];
my $size = 50 * (1 + int(rand(4)));
my $cmd = join ' ', "ping", "-W 0 -c 1", "-s", $size, $ip;
system($cmd);
sleep 1 + int(rand(3));
}

posted by Zed_Lopez at 11:44 AM on October 11, 2007

Response by poster: Excellent point about the packet types, rpn.

Maybe instead I should find a way to semi-randomly simulate tiny occasional bits of http traffic -- like just put up a tiny web page that auto-refreshes at random short intervals, and keep it open in one tab of my browser.

Big thanks to both of you for the script examples -- they make perfect sense (this is an excellent mini-lesson if nothing else).
posted by allterrainbrain at 11:59 AM on October 11, 2007

Best answer:

declare -a PINGHOSTS=(192.168.0.1 192.168.0.2); 
while true; 
do ping -s $[$RANDOM/218+50] ${PINGHOSTS[$RANDOM/(32767/${#PINGHOSTS[@]})]} -c 1;
sleep $[($RANDOM/13+500)/1000];
done

seems to work, but i won't be surprised when someone corrects something in there.

Zed_Lopez, smaller sleep intervals can archived in perl with select:
select(undef,undef,undef,0.1); #sleep for 100 milliseconds

posted by duckstab at 12:01 PM on October 11, 2007

You don't say what type of connection is dropping. Is this a consumer DSL line that's getting a new IP forced on it, or are you having a specific type of session fail while the network is otherwise still working on the same IP address? For instance, if you're having issues with secure shell connections, add this to the bottom of the file ~/.ssh/config :


ServerAliveInterval 120
ServerAliveCountMax 3


I use an Airport Extreme Base Station as my router, and it used to drop my SSH connections after an unpredictable period of inactivity that sounds a lot like what you describe. I added that configuration and my problems went away. There's a corresponding configuration for the SSH daemon if you have access to the server side (it goes in sshd_config, which is likely either in /etc/ or /etc/ssh/):


ClientAliveInterval 120
ClientAliveCountMax 3


This is for SSH2 only, but it works much better than the old SSH1 keepalive ever did. See the manpages for ssh_config and sshd_config for caveats (you probably have to disable TCPKeepAlive for this to work right).

If it's not an SSH issue there may be a similar fix for your actual problem, so can you be more specific?
posted by fedward at 12:02 PM on October 11, 2007

Response by poster: Ha, you would NEVER guess what type of connection this is (without peeking at my previous question, that is).

We have:
a BlackBerry 8700,
acting as a Bluetooth modem for Mac OS X,
connecting to T-Mobile (EDGE),
via a proxy server (!) halfway across the country,
using a third-party BlackBerry utility called Pulse.

(Believe me, after exhaustive googling and experimenting, this is the best way to do everyday phone-as-modem with this model under Mac OS. All more recent models -- or any model under Windows -- are likely to have an easier time of it.)

As I don't need to tell you, connections could be ending for a few different reasons. Actually it's amazing the connections are as stable and high-quality as they are (I'm averaging connections of 50 mins or so, with very stable transfer around 160k down and 60k up... I do always have 5 bars of reception, which I'm sure helps). This was just one of my many theories.
posted by allterrainbrain at 12:43 PM on October 11, 2007

That sound you just heard was me recoiling in horror at such a hack. It is indeed impressive that it works at all, more so that it works as well as it apparently does. Anyway, since there's a black box (two, if you count BlackBerry and T-Mobile separately) between you and your network, you may never find the reason for the disconnections.

Any reason you're not just using a data card? They're not perfect, but I get 1.8Mbps downstream with an HSDPA card from AT&T and it doesn't rely on Bluetooth or BlackBerry's data network so there are two fewer points of failure in the chain. You can get 3G service from AT&T, Sprint, or Verizon for $60/mo, and a USB widget, PC Card, or an ExpressCard, depending on your computer's slots and ports. I pay for it myself as a business expense and find it well worth the write-off. I had an extended DSL outage due to a hardware failure at the other end, and my HSDPA connection stayed nailed up for about four hours at a time.
posted by fedward at 1:33 PM on October 11, 2007

Response by poster: Oh, I'll happily recoil along with you.

I was avoiding the specifics because I knew my choice would take some Explaining & inspire exactly that line of questioning. But now that we're fully derailed and it's clear there's probably not much of a point to my initial theory/question....

I might sound gadgety but I'm just a working artist on a tight enough budget that a $60/mo contract, plus breaking my T-Mo contract, plus buying a 3G phone or card isn't within my reach or advisable. I'm outside the U.S. enough that the $60/mo would be more like $100/mo after taxes given the blocks of time I could actually use it.

The whole point of choosing T-Mobile was that's there's no other affordable solution for someone who needs steady unlimited email usage both in the U.S. and in a string of other random countries for months out of the year.

Planning for when I got back to the U.S., tethering an 8700 was reported to be fiddly but usable. Which is exactly what it is. (And it's an improvement over what I swiched from -- a five-year-old 1xRTT Sprint phone on which I was grandfathered into $10/mo unlimited data because I've actually been doing cell-as-modem ever since their first-gen, c. 14k-down network.)

Perhaps I should be avoiding *any* comment about T-Mo lest the brown-dwellers freak the fuck out again (I made a FPP with a more usable/expanded version of a badly designed T-Mo interface, which was quickly deleted to much alarm and snark because it was too advertising-y), but as it happens I've gone from that initial state of overflowing excitement about T-Mo (and I do admit it worked perfectly for intl email) to a certain resignation.

So:
I'm not using a 3G device & plan because I can't afford to now, but I had logical reasons to choose what might seem like a crazy setup to anybody who doesn't know my needs/budget.

And with that, I think I'm done posting telecom questions for a while. :)
posted by allterrainbrain at 1:26 AM on October 12, 2007