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.
Regards,
Daryl
On 6/14/13 7:03 AM, Dr. Hawkins wrote:
On Thu, Jun 13, 2013 at 4:53 PM, Daryl Williams
<da...@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 :)
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
