WLAN client -> WLAN client ping yields no "echo reply" - macos

My WLAN clients are connected to an AT&T U-Verse Arris NVG589. When I try and ping my Mac on my home WLAN, I don’t get a response.
tcpdump 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Packet Tap), capture size 262144 bytes
A ping from this Mac to www.google.com works:
21:46:20.817743 IP work-mbp.attlocal.net > yv-in-f103.1e100.net: ICMP echo request, id 55595, seq 0, length 64
21:46:20.842309 IP yv-in-f103.1e100.net > work-mbp.attlocal.net: ICMP echo reply, id 55595, seq 0, length 64
21:46:21.820431 IP work-mbp.attlocal.net > yv-in-f103.1e100.net: ICMP echo request, id 55595, seq 1, length 64
21:46:21.844247 IP yv-in-f103.1e100.net > work-mbp.attlocal.net: ICMP echo reply, id 55595, seq 1, length 64
A ping from one Mac to another on the WLAN shows no "echo reply":
21:34:34.994444 IP homempb.attlocal.net > work-mbp.attlocal.net: ICMP echo request, id 12, seq 0, length 16
21:34:35.989923 IP homempb.attlocal.net > work-mbp.attlocal.net: ICMP echo request, id 12, seq 1, length 16
21:34:37.978274 IP homempb.attlocal.net > work-mbp.attlocal.net: ICMP echo request, id 12, seq 2, length 16
21:34:40.213181 IP homempb.attlocal.net > work-mbp.attlocal.net: ICMP echo request, id 12, seq 3, length 16
21:34:41.978188 IP homempb.attlocal.net > work-mbp.attlocal.net: ICMP echo request, id 12, seq 4, length 16
21:34:43.978284 IP homempb.attlocal.net > work-mbp.attlocal.net: ICMP echo request, id 12, seq 5, length 16
El Capitan firewall is disabled.

Turns out the packet filter was enabled and only allowing internet bound ping:
pfctl -a '*' -s rules
showed this rule:
pass out inet proto icmp all keep state
I temporarily disabled the packet filter using:
pfctl -d
and the ping "echo reply" started showing up.

Related

not sure if shell script that opens ports/protocols in the event any are blocked is correct

I'm writing a script that will check/open ports/protocols in the event any are blocked. What I have so far is below. The port/protocol names look strange to me. I would have expected IP addresses, but I've never done this before. Would the host be IP address of the DSLAM? Also, can I run nc without specifying host if it's the current machine? Otherwise, does this script do what is needed?
#!/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
echo -e "############################nnnPresent ports opened on this machine are
$(iptables -nL INPUT | grep ACCEPT | grep dpt)
nCompleted listing...nnn#########################"
#these look funny to me
PORTS=( 123 161 69 "UDP" 80 443 22 8443 8080 23 25 3307 "TCP" "HTTPS" "SNMP" "SFTP" "TFTP")
#modified ip's for public sharing
HOSTS=( "10.x.x.x" "10.x.x.x" "10.x.x.x" "10.x.x.x" "10.x.x.x")
for HOST in "${HOSTS[#]}"
do
for PORT in "${PORTS[#]}"
do
#see which ones need opening...0 is pass (open), 1 fail, 5 timeout; need host still
#alternatively try nmap
nc -z -v -w5 ${HOST} ${PORT}
#if it's not open, then open it
if [ "$?" ne 0 ]; then #shellcheck err this line: Couldn't parse this test expression.
iptables -A INPUT -m tcp -p tcp --dport "$PORT" -j ACCEPT &&
{ service iptables save;
service iptables restart;
echo -e "Ports opened through iptables are n$(iptables -nL INPUT | grep ACCEPT | grep dpt)"; }
else
echo "Port $PORT already open"
fi
done
done
I've been referring to test if port is open, and also open port.
These lines seem odd, OP edit #6 adds an outer for loop which assigns the same value to $HOST on each go-round:
HOSTS=( "10.x.x.x" "10.x.x.x" "10.x.x.x" "10.x.x.x" "10.x.x.x")
for HOST in "${HOSTS[#]}"
do
< stuff ... >
done
Assuming running < stuff ... > four times is not necessary, then
the seven lines above, as written, would be equivalent to:
HOST="10.x.x.x"
< stuff ... >
(Fixed.) Remove the commas from this line:
PORTS=( 123, 161, 69, UDP, 80, 443, 22, 8443, 8080, 23, 25,
3307, TCP, HTTPS, SNMP, SFTP, TFTP)
bash does not use commas to define arrays, and if commas are used
they become chars in the the array data. Example, given the array
exactly as it is above:
echo ${PORTS[0]}
Outputs:
123,

Windows command line, how to filter with pipe

I'm trying to filter ping stats in windows command line using pipe. What I want is to get the 'time' of each ping.
"ping -n 1 -w 1000 " + ip
prints
Pinging 216.52.241.254 with 32 bytes of data:
Reply from 216.52.241.254: bytes=32 time=82ms TTL=240
Ping statistics for 216.52.241.254:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 82ms, Maximum = 82ms, Average = 82ms
The output I'm looking for from that would just be 82.
and my attempt with findstr "ping -n 1 -w 1000 " + ip + ' | findstr time=[0-9]*' prints:
Reply from 216.52.241.254: bytes=32 time=83ms TTL=240
The output should just be 83 this time.
I've tried using grep ?("time=")[0-9]*ms but on top of that line probably not being right I don't think windows grep includes conditionals

How to get output of ping command without Ping statistics?

For example, in Windows 7 output of command
ping -n 1 ::1
is following:
Pinging ::1 with 32 bytes of data:
Reply from ::1: time<1ms
Ping statistics for ::1:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Is it possible to get output without Ping statistics (without the last four lines in this case or without two lines in case if destination host is unreachable)?
Maybe using this command:
ping -n 1 ::1 | find "string to search"
The currently accepted answer would filter out 'Request timed out' errors. Instead, use findstr /B R, which only outputs lines that start with R:
ping -n 1 ::1 | findstr /B R

Pinging 192.0.2.2 Receives a Response...but shouldn't

I'm using the windows batch script function ping 192.0.2.2 -n 1 -w 10000 > nul on my local machine (Windows 7) in a command prompt to test its functionality. The explanation of the function is here: "How to wait in a batch script?".
I've used 192.0.2.2 because it is considered a reserved IP address, so there should be no response. But instead, my results are inconsistent - sometimes I get a response with the error "Destination net unreachable."
C:\Users\MrF>ping 192.0.2.2 -n 1 -w 10000
Pinging 192.0.2.2 with 32 bytes of data:
Reply from 10.10.251.2: Destination net unreachable.
Ping statistics for 192.0.2.2:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
C:\Users\MrF>ping 192.0.2.2 -n 1 -w 10000
Pinging 192.0.2.2 with 32 bytes of data:
Request timed out.
Ping statistics for 192.0.2.2:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
C:\Users\MrF>ping 192.0.2.2 -n 1 -w 10000
Pinging 192.0.2.2 with 32 bytes of data:
Request timed out.
Ping statistics for 192.0.2.2:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
C:\Users\MrF>ping 192.0.2.2 -n 1 -w 10000
Pinging 192.0.2.2 with 32 bytes of data:
Request timed out.
Ping statistics for 192.0.2.2:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
C:\Users\MrF>ping 192.0.2.2 -n 1 -w 10000
Pinging 192.0.2.2 with 32 bytes of data:
Reply from 10.10.251.2: Destination net unreachable.
Ping statistics for 192.0.2.2:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
C:\Users\MrF>ping 192.0.2.2 -n 1 -w 10000
Pinging 192.0.2.2 with 32 bytes of data:
Request timed out.
Ping statistics for 192.0.2.2:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
C:\Users\MrF>
Unfortunately, the function only waits 10 seconds when the ping is lost. Pings that receive a response don't wait at all. This has lead to some frustrating lack of functionality in my scripts that require wait commands. How can I fix this? Why is it happening?
That is not a link local or LAN reserved IP range, but it is routable (although no one should ever route to it). See this whois info for full details. A link local 169.254 range IP would give more consistent, reliable results. See this answer for further explanation.
Edit: I see what you mean. Even my previous 169.254 solution is subject to the same inconsistency. Well, really, the biggest benefit to pinging a bogus IP with the -w switch is so you can pause in milliseconds. If you're pausing in whole seconds (such as ten seconds in your example above), just
ping -n 11 localhost >NUL
... where 11 is N+1 seconds to pause. That command will pause for 10 seconds.
Alternatively, you could use the timeout /t 10 /NOBREAK >NUL command if your script will be run on Vista or newer.
If you need fraction-of-a-second pausing, you could always employ VBScript or JScript.
#if (#CodeSection == #Batch) #then
#echo off
setlocal
set /P "=Pausing 1.5 seconds."<NUL
call :sleep 500
set /P "=."<NUL
call :sleep 500
set /P "=. "<NUL
call :sleep 500
echo Done.
goto :EOF
:sleep <milliseconds>
cscript /nologo /e:JScript "%~f0" "%~1"
goto :EOF
#end // end Batch / begin JScript
WSH.Sleep(WSH.Arguments(0) * 1);
Windows has many wait commands, I use waitfor. But there is choice and timeout as well.
Maybe stop searching the internet. Ping is a silly idea. What would happen if all 175,000 computers at my work all started pinging at the same time.
waitfor /t 99999 Fred

Data Capture Issue using expect in tcl

I have one doubt in expect. I want to store the result of command in a string variable. Can anyone tell me what is the mistake in my code? It is not working. I have used expect_out(buffer) but its not working.
#!/usr/bin/expect
package require Expect
set Argu1 [lindex $argv 0]
set Argu2 [lindex $argv 1]
if {$argc == 2} {
if {[regexp {^(\d|[1-9]\d|1\d\d|2[0-4]\d|[2][5][0-5])\.(\d|[1-9]\d|1\d\d|2[
0-4]\d|[2][5][0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|[2][5][0-5])\.(\d|[1-9]
\d|1\d\d|2[0-4]\d|[2][5][0-5])$} $Argu1 match ]} {
puts "VALID IP-ADDRESS"
set timeout $Argu2-1
spawn ping $Argu1
expect "Expect"
set string $expect_out(buffer)
puts $string
puts "SUCCESS"
exit
} else {
puts "INVALID IP-ADDRESS"
}
} else {
puts "YOU HAVE TO GIVE TWO ARGUMENTS\n FIRST ARGUMENT SHOULD BE
IP-ADDRESS \n SECOND ARGUMENT SHOULD BE THE NUMBER OF PACKETS
YOU WANT TO SEND"
}
I'm reluctant to answer your question, as you haven't responded to my answer on another question. However, seeing as nobody else has responded, I'll try to help you out.
I don't think you need to use $expect_out(buffer) here. Assuming that a ping returning "0% loss" or "0% packet loss" means the ping was successful, you could try the following (untested). Obviously, you can change the "0%" to whatever you want to signify success.
#!/usr/bin/expect
package require Expect
set Argu1 [lindex $argv 0]
set Argu2 [lindex $argv 1]
if {$argc == 2} {
if {[regexp {^(\d|[1-9]\d|1\d\d|2[0-4]\d|[2][5][0-5])\.(\d|[1-9]\d|1\d\d|2[
0-4]\d|[2][5][0-5])\.(\d|[1-9]\d|1\d\d|2[0-4]\d|[2][5][0-5])\.(\d|[1-9]
\d|1\d\d|2[0-4]\d|[2][5][0-5])$} $Argu1 match ]} {
puts "VALID IP-ADDRESS"
set timeout $Argu2-1
spawn ping $Argu1
expect {
"0%" {puts "The IP address was successfully pinged"}
"default" {puts "Could not ping this IP address"}
}
exit
} else {
puts "INVALID IP-ADDRESS"
}
} else {
puts "YOU HAVE TO GIVE TWO ARGUMENTS\n FIRST ARGUMENT SHOULD BE
IP-ADDRESS \n SECOND ARGUMENT SHOULD BE THE NUMBER OF PACKETS
YOU WANT TO SEND"
}
The reason I suggest "0%" is as follows. If you do a successful ping from a Windows machine you will see something like this (note the "0% loss"):
C:\Documents and Settings\Brian>ping 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
From a Unix machine, it might look like this (note the "0% packet loss") :
[brian#rex 4]$ ping -c 1 192.168.1.87
PING 192.168.1.87 (192.168.1.87) 56(84) bytes of data.
64 bytes from 192.168.1.87: icmp_seq=0 ttl=64 time=42.1 ms
--- 192.168.1.87 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 42.153/42.153/42.153/0.000 ms, pipe 2
You could pick many indicators of a successful ping, I chose the fact that there was a 0% loss of packets (a clear indicator of success). The expect command searches the result of the ping and if it finds "0%", it outputs "The IP address was successfully pinged".

Resources