a *fast* check for whether another machine is on the local network?

Daryl Williams daryl at synergetic-data.com
Fri Jun 14 12:58:06 EDT 2013

I tested this on my mac laptop with both a wired and wireless interface, 
running mountain lion, using the following command:

$ route get default

the result was:

1. with both interfaces up the route command picked the wired interface 
and reported the gateway was up.

2. unplugged the wired interface and the route command picked the 
wireless interface and reported the gateway was up.

3. turned off the wireless interface, and left the wired interface 
unplugged and the route command reported the error: route: writing to 
routing socket: not in table.

4. turned on the wireless interface, left the wired interface unplugged 
and turned off the wireless gateway. The route command immediately 
reported the same error:  route: writing to routing socket: not in table.

5. turned the wireless gateway back on and the route command immediately 
reported the default gateway was up.

So it seems like this approach might be viable. However, you will still 
need that controlled timeout and once you get the ip address of the 
current gateway the ping will probably be the easiest cross platform 
command to use to determine the current gateway status.

As far the windows box, you might want to try either vmware or virtual 
box, both offer very good machine virtualization.



On 6/14/13 7:03 AM, Dr. Hawkins wrote:
> On Thu, Jun 13, 2013 at 4:53 PM, Daryl Williams
> <daryl at synergetic-data.com> wrote:
>> If I am understanding correctly you might try using either the netstat or
>> route commands to find your default gateway, and if there is none then save
>> things to the local database.
> doesn't give me the timeout issues again--if the laptop is opened in
> the new location, won't the old router still be on the list, and need
> to be checked?
>> The problem with this approach will be determining the right syntax to use
>> for the current platform your code is running on. Unfortunately the syntax
>> is a bit different from windows to os x to linux, but they will all report
>> on the routing tables, including the default router, at which point you just
>> need to parse the command output (again different from platform to platform)
>> an take the appropriate action. The output can be rather detailed and
>> verbose, but should not too hard to parse.
> This isn't too big of a problem--I already have OS based switches
> lying around the code.  I guess I'll have to buy a windows machine for
> the first time in my life to do some testing of that code on, though .
> . .
> After going through all of these, it sounds like the controlled
> timeout is the way to go--when this stack comes to the front, it does
> a check.  If it thinks it's not on the VPN already, it just continues
> to use the local cache db--unless it sees "something"? new telling it
> that the VPN is back, in which case it tries.  If it thinks it should
> be on VPN, it pings for good measure with the 1s/50ms timeout.  Hmm,
> this can be delayed until the first db write, too.   So the only time
> the user gets hit for the whole second is when he actually changes
> from VPN to no VPN (blocked, no internet, whatever).
> Thank you to all.  I now know more things I never expected to learn :)

More information about the Use-livecode mailing list