http://pastebin.com/raw.php?i=rykHdvBh
bix.hu and www.yahoo.com are "pingable" test sites. 127.0.0.1 could not be pinged [firewall drops all icmp]
i have a "oneliner" that echoes if theres "internet connection or no". $ ping -W 1 -c 2 bix.hu >& /dev/null && ping -W 1 -c 2 www.yahoo.com >& /dev/null && echo "internet connection ok" || echo "no internet connection" internet connection ok $ ping -W 1 -c 2 127.0.0.1 >& /dev/null && ping -W 1 -c 2 www.yahoo.com >& /dev/null && echo "internet connection ok" || echo "no internet connection" no internet connection $ ping -W 1 -c 2 127.0.0.1 >& /dev/null && ping -W 1 -c 2 127.0.0.1 >& /dev/null && echo "internet connection ok" || echo "no internet connection" no internet connection $ ping -W 1 -c 2 bix.hu >& /dev/null && ping -W 1 -c 2 127.0.0.1 >& /dev/null && echo "internet connection ok" || echo "no internet connection" no internet connection $ ping -W 1 -c 2 bix.hu >& /dev/null && ping -W 1 -c 2 www.yahoo.com >& /dev/null && echo "internet connection ok" || echo "no internet connection" internet connection ok $
Ok!
But: if i want the "oneliner" to only go along when theres internet connection: $ while $TORF; do ping -W 1 -c 1 bix.hu >& /dev/null && ping -W 1 -c 1 www.yahoo.com >& /dev/null && TORF=false || TORF=true; done $ while $TORF; do ping -W 1 -c 1 127.0.0.1 >& /dev/null && ping -W 1 -c 1 www.yahoo.com >& /dev/null && TORF=false || TORF=true; done $ while $TORF; do ping -W 1 -c 1 127.0.0.1 >& /dev/null && ping -W 1 -c 1 127.0.0.1 >& /dev/null && TORF=false || TORF=true; done $ while $TORF; do ping -W 1 -c 1 bix.hu >& /dev/null && ping -W 1 -c 1 127.0.0.1 >& /dev/null && TORF=false || TORF=true; done $ while $TORF; do ping -W 1 -c 1 bix.hu >& /dev/null && ping -W 1 -c 1 www.yahoo.com >& /dev/null && TORF=false || TORF=true; done $
It just doesn't work.
Goal: if theres no internet connection, then the oneliner must loop until there is internet connection. if theres internet connection the oneliner ends.
what am i missing?
Le ven 28 jan 2011 03:28:22 CET, kellyremo a écrit:
[ ... ] $ while $TORF; do ping -W 1 -c 1 bix.hu >& /dev/null && ping -W 1 -c 1 www.yahoo.com >& /dev/null && TORF=false || TORF=true; done $
It just doesn't work.
Goal: if theres no internet connection, then the oneliner must loop until there is internet connection. if theres internet connection the oneliner ends.
what am i missing?
try : until ping -W 1 -c 1 bix.hu || ping -W 1 -c 1 www.yahoo.com ; do sleep 5 done >& /dev/null
Note that ping -W 1 is crazy.
On 01/28/11 3:28 AM, kellyremo wrote:
bix.hu and www.yahoo.com are "pingable" test sites. 127.0.0.1 could not be pinged [firewall drops all icmp]
what sort of firewall drops packets on localhost ?!?
yahoo.com is probably a poor choice of targets, as its a widely distributed group of servers, and you likely will be pinging different servers at different times, maybe even in different parts of the world. I would instead suggest using a target at your ISP or backbone provider.
btw, dropping 'all icmp' is bad practice. Internet Control Message Protocol is used for a number of things, including informing applications when a host or port is not accessible. if you drop this, you instead hang for minutes waiting for a response instead of quickly getting back a 'target {host|port} not reachable' error.
anyways, if you drop all ICMP, you won't get any pings from anywheres.
On Fri, Jan 28, 2011 at 7:19 AM, John R Pierce pierce@hogranch.com wrote:
On 01/28/11 3:28 AM, kellyremo wrote:
bix.hu and www.yahoo.com are "pingable" test sites. 127.0.0.1 could not be pinged [firewall drops all icmp]
what sort of firewall drops packets on localhost ?!?
yahoo.com is probably a poor choice of targets, as its a widely distributed group of servers, and you likely will be pinging different servers at different times, maybe even in different parts of the world. I would instead suggest using a target at your ISP or backbone provider.
But it's therefore *very* robust, and less likely to have a particular host drop out.
If you'd like to be paranoid, it's sometimes handy to do a DNS lookup first on your target, and ping the local gateway. those steps can be automated from your local network configuration, they can *read* your local configuration so they work on all hosts you manage, and if things start failing, you can then have it run a "traceroute" against the target.
It also carries some classic attack vectors, such as the "smurf" attack.
btw, dropping 'all icmp' is bad practice. Internet Control Message Protocol is used for a number of things, including informing applications when a host or port is not accessible. if you drop this, you instead hang for minutes waiting for a response instead of quickly getting back a 'target {host|port} not reachable' error.
anyways, if you drop all ICMP, you won't get any pings from anywheres.
Yup. That's why it's common to drop at external firewalls and blocked by NAT from reaching inside your network, to protect less thoroughly protected and critical hosts from distributed denial of service (DDOS) such as the now classic "ping flood" attack. There is generally no good reason to allow external ICMP packets into your local network, except maybe to allow an external monitoring system or VPN connection to verify the presence of a few exposed hosts.
Nico Kadel-Garcia wrote:
Yup. That's why it's common to drop at external firewalls and blocked by NAT from reaching inside your network, to protect less thoroughly protected and critical hosts from distributed denial of service (DDOS) such as the now classic "ping flood" attack. There is generally no good reason to allow external ICMP packets into your local network, except maybe to allow an external monitoring system or VPN connection to verify the presence of a few exposed hosts.
This is a widely held opinion that I strongly disagree with. Blocking all ICMP is not only not needed, but it is not conforming to Internet protocol requirements (RFC 1122, 3.2.2) and makes headaches for sysadmins who have to troubleshoot network issues. Wikipedia puts it succinctly:
Many network security devices block all ICMP messages for perceived security benefits, including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection.
Some implementations of PMTUD attempt to prevent this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for the Transmission Control Protocol (TCP) to operate most efficiently, ICMP Unreachable messages (type 3) should be permitted. A robust method for PMTUD that relies on TCP or another protocol to probe the path with progressively larger packets has been standardized in RFC 4821.
http://en.wikipedia.org/wiki/Path_MTU_Discovery
On Fri, Jan 28, 2011 at 11:19 AM, cpolish@surewest.net wrote:
Nico Kadel-Garcia wrote:
Yup. That's why it's common to drop at external firewalls and blocked by NAT from reaching inside your network, to protect less thoroughly protected and critical hosts from distributed denial of service (DDOS) such as the now classic "ping flood" attack. There is generally no good reason to allow external ICMP packets into your local network, except maybe to allow an external monitoring system or VPN connection to verify the presence of a few exposed hosts.
Many network security devices block all ICMP messages for perceived security benefits, including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a black hole connection.
I'm not sure how the lack of PMTUD is worked around: given the number of environments for which blocking ICMP entirely is standard practice, it can't be *too* much of an issue, can it? I'm deducing, without enough proof, that the upstream ISP's routers have to handle ICMP from the other routers they speak with. But other than that, why should it be supported again? Do household network devices really need to do the path optimization supported by this? They're not multi-homed: perhaps the single gateway that they use helps avoid the issue?
-
cpolish＠surewest.net -
John R Pierce -
kellyremo -
Nico Kadel-Garcia -
Philippe Naudin