I want a fast (as in less than a second, not 'computer fast') way of checking if a particular private IP is present on the LAN.
I need this for use in a match construct in an SSH config file, e.g.:-
# # # odin may be remote or local from t430 # Match host odin exec "sh -c 'hostNotLocal 192.168.0.104'" ProxyCommand ssh cheddar nc -q0 localhost 51234
Currently 'hostNotLocal' is:-
#!/bin/bash # # # Test if specified host is ping'able # ! ping -c 1 $1 >>/dev/null 2>&1
The problem with this is that on any LAN except one using 192.168.0.xxx it takes several seconds to decide that 192.168.0.104 isn't there.
For any nit-pickers, yes I know if I just happen to be connected to a LAN which isn't where 'my' 192.168.0.104 is I'll get a false positive but I can live with that. I just want a fast way of knowing that 192.168.0.104 *isn't* there.
On 22/02/17 13:50, Chris Green wrote:
I want a fast (as in less than a second, not 'computer fast') way of checking if a particular private IP is present on the LAN.
[SNIP]
---- cut here ---- ~ $ nmap -sn 10.0.1.254
Starting Nmap 6.40 ( http://nmap.org ) at 2017-02-22 14:16 GMT Nmap scan report for 10.0.1.254 Host is up (0.00078s latency). Nmap done: 1 IP address (1 host up) scanned in 0.00 seconds
~ $ nmap -sn 10.0.1.80
Starting Nmap 6.40 ( http://nmap.org ) at 2017-02-22 14:17 GMT Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.00 seconds
---- cut here ----
If it's there it's faster, so just change your logic...
Cheers, Laurie.
On Wed, Feb 22, 2017 at 02:22:17PM +0000, Laurie Brown wrote:
On 22/02/17 13:50, Chris Green wrote:
I want a fast (as in less than a second, not 'computer fast') way of checking if a particular private IP is present on the LAN.
[SNIP]
---- cut here ---- ~ $ nmap -sn 10.0.1.254
Starting Nmap 6.40 ( http://nmap.org ) at 2017-02-22 14:16 GMT Nmap scan report for 10.0.1.254 Host is up (0.00078s latency). Nmap done: 1 IP address (1 host up) scanned in 0.00 seconds
~ $ nmap -sn 10.0.1.80
Starting Nmap 6.40 ( http://nmap.org ) at 2017-02-22 14:17 GMT Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.00 seconds
---- cut here ----
If it's there it's faster, so just change your logic...
You've illustrated my problem perfectly! That 3 seconds delay is the same delay I see using my original ping method.
I need to find out, fast, if 192.168.0.104 isn't on the LAN I'm connected to. To do this I have to run your second case above which takes, like my ping, 3 seconds to execute.
It's not possible to 'change the logic'. The ssh config file has the following in it:-
Match host odin exec "hostNotLocal 192.168.0.104" ProxyCommand ssh cheddar nc -q0 localhost 51234
Host odin HostName 192.168.0.104
Simply reversing the logic to:-
Match host odin exec "hostIsLocal 192.168.0.104" HostName 192.168.0.104
Host odin ProxyCommand ssh cheddar nc -q0 localhost 51234
Makes no difference at all. The hostIsLocal command will take 3 seconds to fail when it's not local and I'm no better off.
On 22/02/17 15:25, Chris Green wrote:
On Wed, Feb 22, 2017 at 02:22:17PM +0000, Laurie Brown wrote: You've illustrated my problem perfectly! That 3 seconds delay is the same delay I see using my original ping method.
I need to find out, fast, if 192.168.0.104 isn't on the LAN I'm connected to. To do this I have to run your second case above which takes, like my ping, 3 seconds to execute.
[SNIP] Makes no difference at all. The hostIsLocal command will take 3 seconds to fail when it's not local and I'm no better off.
Why is a 3 second delay a problem?
Possible alternatives. Try to open some sort of connection to the address you want to test, using pythion, or SSH or Telnet or something else and investigate any timeout options.
Interrogate dhcp logs and see last time a machine was active - if it's recent, assume it's there.
Have each machine announce its presence on boot and at regular short intervals after to some central log of machines. Interrogate this for the required machine.
Have a machine regularly ping everything to work out who is there and who isn't. Log it and use that log.
Run something during the boot up process to work out the location of this machine and deduce if these machines are going to be local or remote.
Fundamentally rearrange your network addressing.
Use DynDns or similar dynamic dns address tools for each machine and always access the machines by their dyndns name.
Mess around with the hosts file, do the logic in there to substitute the local/remote address for machines.
Modify your network setup and include a bridge or VPN so somehow, each machine always has the same IP address.
Live with a 3 second delay.
That should keep you going for a bit!
Steve
On Wed, 22 Feb 2017 15:50:16 +0000 steve-ALUG@hst.me.uk allegedly wrote:
Why is a 3 second delay a problem?
+1
Fundamentally rearrange your network addressing.
or fundamentally rearrange his requirements.
Live with a 3 second delay.
+1 again
That should keep you going for a bit!
Don't bank on. I /guarantee/ that he will be back very shortly with one of two follow ups.
1 - he asks a solution to an even more obscure (possibly dumb) scenario; or
2 - he "solves" his own requirement in a way which involves a wierd network configuration and/or some incredibly peculiar scripting and posts it here.
He usually does.
Cheers
Mick
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
On Wed, Feb 22, 2017 at 04:08:33PM +0000, mick wrote:
On Wed, 22 Feb 2017 15:50:16 +0000 steve-ALUG@hst.me.uk allegedly wrote:
Why is a 3 second delay a problem?
+1
Fundamentally rearrange your network addressing.
or fundamentally rearrange his requirements.
Live with a 3 second delay.
+1 again
That should keep you going for a bit!
Don't bank on. I /guarantee/ that he will be back very shortly with one of two follow ups.
1 - he asks a solution to an even more obscure (possibly dumb) scenario; or
2 - he "solves" his own requirement in a way which involves a wierd network configuration and/or some incredibly peculiar scripting and posts it here.
Thank you for the vote of confidence! :-)
I would point out that the solution to my last query came from here and was rather obvious, nothing peculiar at all, just a firewall setting I had forgotten about.
On Wed, Feb 22, 2017 at 03:50:16PM +0000, steve-ALUG@hst.me.uk wrote:
On 22/02/17 15:25, Chris Green wrote:
On Wed, Feb 22, 2017 at 02:22:17PM +0000, Laurie Brown wrote: You've illustrated my problem perfectly! That 3 seconds delay is the same delay I see using my original ping method.
I need to find out, fast, if 192.168.0.104 isn't on the LAN I'm connected to. To do this I have to run your second case above which takes, like my ping, 3 seconds to execute.
[SNIP] Makes no difference at all. The hostIsLocal command will take 3 seconds to fail when it's not local and I'm no better off.
Why is a 3 second delay a problem?
Because I get fed up waiting! :-) It's not a disaster by any means, just annoying.
On Wed, 22 Feb 2017 15:25:41 +0000 Chris Green cl@isbd.net allegedly wrote:
You've illustrated my problem perfectly! That 3 seconds delay is the same delay I see using my original ping method.
I need to find out, fast, if 192.168.0.104 isn't on the LAN I'm connected to. To do this I have to run your second case above which takes, like my ping, 3 seconds to execute.
WTF do you need to find out in 3 seconds? Will the world end if it takes longer?
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
Chris,
This does it in exactly one second, if that's any use:
ping -c1 n.n.n.n -w1
(just look for "100% packet loss" in the output).
You're probably looking at implementing something using an ICMP library to get any faster.
Simon
On 22/02/17 15:25, Chris Green wrote:
On Wed, Feb 22, 2017 at 02:22:17PM +0000, Laurie Brown wrote:
On 22/02/17 13:50, Chris Green wrote:
I want a fast (as in less than a second, not 'computer fast') way of checking if a particular private IP is present on the LAN.
[SNIP]
---- cut here ---- ~ $ nmap -sn 10.0.1.254
Starting Nmap 6.40 ( http://nmap.org ) at 2017-02-22 14:16 GMT Nmap scan report for 10.0.1.254 Host is up (0.00078s latency). Nmap done: 1 IP address (1 host up) scanned in 0.00 seconds
~ $ nmap -sn 10.0.1.80
Starting Nmap 6.40 ( http://nmap.org ) at 2017-02-22 14:17 GMT Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.00 seconds
---- cut here ----
If it's there it's faster, so just change your logic...
You've illustrated my problem perfectly! That 3 seconds delay is the same delay I see using my original ping method.
I need to find out, fast, if 192.168.0.104 isn't on the LAN I'm connected to. To do this I have to run your second case above which takes, like my ping, 3 seconds to execute.
It's not possible to 'change the logic'. The ssh config file has the following in it:-
Match host odin exec "hostNotLocal 192.168.0.104" ProxyCommand ssh cheddar nc -q0 localhost 51234 Host odin HostName 192.168.0.104Simply reversing the logic to:-
Match host odin exec "hostIsLocal 192.168.0.104" HostName 192.168.0.104 Host odin ProxyCommand ssh cheddar nc -q0 localhost 51234Makes no difference at all. The hostIsLocal command will take 3 seconds to fail when it's not local and I'm no better off.
On 22 February 2017 at 16:34, Simon Ransome simon@nosher.net wrote:
This does it in exactly one second, if that's any use:
ping -c1 n.n.n.n -w1
(just look for "100% packet loss" in the output).
ping also returns 0 on success and 1 on failure so checking $? is simpler than grepping the output.
You can get a sub-second test using fping: $ sudo apt-get install fping $ fping -c1 -t100 123.123.123.123
123.123.123.123 : xmt/rcv/%loss = 1/0/100% $ echo $? 1 $ fping -c1 -t100 8.8.8.8 8.8.8.8 : [0], 84 bytes, 9.79 ms (9.79 avg, 0% loss)
8.8.8.8 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 9.79/9.79/9.79 $ echo $? 0
fping also does nice things like pinging multiple hosts if needed.
On Wed, Feb 22, 2017 at 04:58:05PM +0000, Mark Rogers wrote:
On 22 February 2017 at 16:34, Simon Ransome simon@nosher.net wrote:
This does it in exactly one second, if that's any use:
ping -c1 n.n.n.n -w1
(just look for "100% packet loss" in the output).
ping also returns 0 on success and 1 on failure so checking $? is simpler than grepping the output.
You can get a sub-second test using fping: $ sudo apt-get install fping $ fping -c1 -t100 123.123.123.123
123.123.123.123 : xmt/rcv/%loss = 1/0/100% $ echo $? 1 $ fping -c1 -t100 8.8.8.8 8.8.8.8 : [0], 84 bytes, 9.79 ms (9.79 avg, 0% loss)
8.8.8.8 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 9.79/9.79/9.79 $ echo $? 0
fping also does nice things like pinging multiple hosts if needed.
I'm already using the return value in ssh config, as I showed before:-
#!/bin/bash # # # Test if specified host is ping'able # ! ping -c 1 $1 >>/dev/null 2>&1
The above (or the -w parameter for standard ping) is all I need to quicken the response enough. A one second delay is probably fine so I'll go with the -w1 with ping solution for the moment. If I get really impatient I can use fping as above! :-)
Thanks all.
On Wed, Feb 22, 2017 at 04:34:37PM +0000, Simon Ransome wrote:
Chris,
This does it in exactly one second, if that's any use:
ping -c1 n.n.n.n -w1
(just look for "100% packet loss" in the output).
You're probably looking at implementing something using an ICMP library to get any faster.
Excellent, thank you, what a nice simple solution. I use ping's exit value to decide whether the system is there on not.
By the way everyone I was just trying this out and realised that the delay I was originally finding annoying was 10 seconds rather than just 3. A one second delay is fine.
On 22 Feb 13:50, Chris Green wrote:
I want a fast (as in less than a second, not 'computer fast') way of checking if a particular private IP is present on the LAN.
Now, assuming that your network interface has to come up first, and that it won't randomly change location between, there'll be a call to /etc/network/if-up.d/blah once the interface is up... So, the *obvious* thing to do, is do the test in there, and then cache the result, use that cached result for your test and your test is then sub 1 second.
Not exactly rocket science. It's an obvious case for only check on connection to a network.
Thanks,
-
Brett Parker -
Chris Green -
Laurie Brown -
Mark Rogers -
mick -
Simon Ransome -
steve-ALUG＠hst.me.uk