Following a previous Stack Overflow response, (here) I am trying to check if a particular sentence/string is returned in the response of a io.popen command I’m running..
local function DevicePing(ip)
local handler = io.popen("ping -c 3 " ..ip.. " 2>&1")
local response = handler:read("*a")
print(response)
if string.find(response, "0% packet loss") then
print ("Pings were all successfull.")
else
print ("Pings were all unsuccessfull.")
end
end
DevicePing("192.168.1.180")
But every time I run it, it doesn’t find the requested string/sentence; see the print output below..
PING 192.168.1.180 (192.168.1.180): 56 data bytes
64 bytes from 192.168.1.180: seq=0 ttl=64 time=2.983 ms
64 bytes from 192.168.1.180: seq=1 ttl=64 time=1.620 ms
64 bytes from 192.168.1.180: seq=2 ttl=64 time=2.465 ms
--- 192.168.1.180 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.620/2.356/2.983 ms
Pings were all unsuccessfull.
What am I doing wrong for it not to see ‘0% packet loss‘ is present and say it was successfull?
% is the escape character in Lua patterns.
Use "0%% packet loss" to mean a literal %.
However, this pattern will also matches 100% packet loss. I suggest ", 0%% packet loss".
Also, it won't work in macOS which shows decimals in the report: 0.0% packet loss.
Related
I am trying to solve the below question:
filter the UDP packets having a size equal to 242 bytes.
I looked to this answer udp.length==209 set a filter of packet length in wireshark, but instead of getting packets with length 209 bytes I get packets with length 243 bytes.
screenshot. can anyone explain?
Your image shows a packet like
Frame 243 bytes
'-> Ethernet
'-> IPv4
'-> UDP
'-> Dropbox LAN Sync
Ethernet will be 14 bytes with 6 per src/dst MAC address and 2 bytes for Ethertype.
The IPv4 header will be a minimum of 20 bytes, but could be more with options. It just so happens to be 20 here.
Eth 14 bytes + IP 20 bytes = 34 bytes
243 bytes - 34 bytes of Eth/IP = 209 bytes of UDP data
From last few days traffic on website(https://www.fanspole.com/) is too high, so we are trying to optimise website. One thing I notice was DNS resolve time is too high..
#MacBook-Air ~ $ ping fanspole.com
PING fanspole.com (139.162.35.126): 56 data bytes
64 bytes from 139.162.35.126: icmp_seq=0 ttl=56 time=717.688 ms
64 bytes from 139.162.35.126: icmp_seq=1 ttl=56 time=606.560 ms
64 bytes from 139.162.35.126: icmp_seq=2 ttl=56 time=654.942 ms
64 bytes from 139.162.35.126: icmp_seq=3 ttl=56 time=677.301 ms
64 bytes from 139.162.35.126: icmp_seq=4 ttl=56 time=699.991 ms
Request timeout for icmp_seq 5
64 bytes from 139.162.35.126: icmp_seq=6 ttl=56 time=601.355 ms
64 bytes from 139.162.35.126: icmp_seq=7 ttl=56 time=660.974 ms
64 bytes from 139.162.35.126: icmp_seq=8 ttl=56 time=605.084 ms
--- fanspole.com ping statistics ---
10 packets transmitted, 8 packets received, 20.0% packet loss
round-trip min/avg/max/stddev = 601.355/652.987/717.688/42.087 ms
we are using Linode DNS Manager as of now..
Can someone suggest better alternatives.
This is not a DNS resolution issue, its a network congestion issue.
traceroute to 139.162.35.126 (139.162.35.126), 30 hops max, 60 byte packets
<internal hops removed>
4 10gigabitethernet5-1.core1.lon1.he.net (5.57.80.128) 22.367 ms 22.618 ms 22.841 ms
5 10ge2-9.core1.lon2.he.net (72.52.92.222) 24.056 ms 24.277 ms 24.500 ms
6 100ge1-1.core1.nyc4.he.net (72.52.92.166) 94.769 ms 93.549 ms 93.694 ms
7 100ge14-2.core1.sjc2.he.net (184.105.81.213) 156.692 ms 147.815 ms 147.974 ms
8 * * *
9 * * *
10 xe0-2-0.gw1.sin2.pacnet.net (202.147.52.66) 320.731 ms 321.978 ms 321.950 ms
11 * * *
12 139.162.0.10 (139.162.0.10) 252.825 ms 251.826 ms 251.285 ms
13 li1448-126.members.linode.com (139.162.35.126) 251.746 ms 252.270 ms 251.406 ms
That is a traceroute from London UK - you can see on line 7 when it hits the he.net it starts to pick up latency. By the time it gets to line 10 in pacnet.net its 300+ms
The only option here is to move to a different Linode region or different hosting provider with better/less congested network links.
I have been having occasional lag spikes while playing online realtime games (LoL for example). I ran a tracert to LoL's servers (216.52.241.254):
C:\Windows\system32>tracert -d 216.52.241.254
Tracing route to 216.52.241.254 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.0.1
2 29 ms 29 ms 26 ms 68.84.4.1
3 10 ms 8 ms 10 ms 68.85.80.165
4 9 ms 11 ms 70 ms 68.85.130.85
5 14 ms 15 ms 15 ms 68.86.90.85
6 12 ms 12 ms 11 ms 68.86.82.222
7 13 ms 13 ms 12 ms 66.208.229.142
8 48 ms 13 ms 13 ms 154.54.6.170
9 26 ms 25 ms 26 ms 154.54.31.97
10 44 ms 45 ms 46 ms 154.54.29.222
11 75 ms 74 ms 73 ms 154.54.7.158
12 76 ms 75 ms 75 ms 154.54.47.170
13 76 ms 76 ms 75 ms 154.24.22.122
14 77 ms 74 ms 74 ms 38.104.77.122
15 74 ms 74 ms 75 ms 216.52.241.254
Trace complete.
and did a ping -t to the first few nodes to see if the problem showed up there. I let that run while I was playing, and checked on it whenever I had a lag spike or disconnect. The results for the first two nodes:
Localhost:
C:\Windows\system32>ping -t 192.168.0.1
Pinging 192.168.0.1 with 32 bytes of data:
...omitted...
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.0.1:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
Control-C
^C
Second node:
C:\Windows\system32>ping -t 68.84.4.1
Pinging 68.84.4.1 with 32 bytes of data:
...omitted...
Reply from 68.84.4.1: bytes=32 time=8ms TTL=254
Reply from 68.84.4.1: bytes=32 time=14ms TTL=254
Reply from 68.84.4.1: bytes=32 time=12ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Reply from 68.84.4.1: bytes=32 time=15ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 68.84.4.1: bytes=32 time=11ms TTL=254
Reply from 68.84.4.1: bytes=32 time=11ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Reply from 68.84.4.1: bytes=32 time=8ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Reply from 68.84.4.1: bytes=32 time=9ms TTL=254
Reply from 68.84.4.1: bytes=32 time=14ms TTL=254
Reply from 68.84.4.1: bytes=32 time=10ms TTL=254
Reply from 68.84.4.1: bytes=32 time=15ms TTL=254
Request timed out.
Ping statistics for 68.84.4.1:
Packets: Sent = 2911, Received = 2889, Lost = 22 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 2953ms, Average = 12ms
Control-C
^C
Each line of the results should roughly match the corresponding line in the other in terms of time of ping. Sometimes, I have multiple timeouts like above, while other times, it is only one or two lines with very high latency (>900ms). I also had results for a few more nodes, but those had the same behavior, so I figured the problem was in the second node.
I recently got a new router because Comcast cut off our internet, saying, "You have to upgrade your router. It's outdated and you're not taking advantage of the speedups we've been implementing in your area." I cannot recall if we had this lag spike problem before we got the new router because I spent most of my time at school.
My question is: Is this a problem with my router or with the house's connection to the rest of the internet?
EDIT:
The problem seems to arise only when I am playing. I have been running a ping -t to 68.84.4.1 for the last hour while not playing, and have not seen it timeout a single time. The results are:
Ping statistics for 68.84.4.1:
Packets: Sent = 3477, Received = 3476, Lost = 1 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 88ms, Average = 10ms
Over the entire hour, the max latency was 88ms, and only 1 packet was lost.
There can be a number of reasons that cause games to lag on a machine besides the internet connection.
Assuming that the problem lies in your connection
The first point is most relevant to your question, rest are just suggestions
Perform a "full" Speedtest: the data you provided only tells half of the story, do a proper speed test using some online service like Speedtest.net by Ookla. Network games have high bandwidth requirements so take a note of the (total) bandwidth that comes to your home. If no other devices and/or program is consuming your network bandwith, you shall have a similar value. you may also do a DNS speed test using Namebench
Use a Wired Connection: A wireless connection will always add latency to bandwidth. Disconnect from the router and use a wired connection directly to the computer. Also, if others are using the router at the same time, it is possible that there are too many people grabbing for the same bandwidth.
However if that is not possible make sure that the router is properly configured. It must be in the right position, at the right elevation, wireless channel etc for optimal performance.
There are number of guides available online which you can follow.
Also look out for any new wireless networks in your area that may interfere with your signal.
Try a different router firmware, as some routers have broken firmware and don't perform well on excess load , give Gargoyle or OpenWRT a chance if you are desperate.
Close down other applications that use the internet
Optimize your game settings: All popular online games have network settings, its just a case of finding them. Search online for a guide to tweaking your game.
Turn on Compound TCP, which increases the TCP window much quicker than the traditional TCP algorithms allow for. This means that when a sudden burst of larger packets comes in, or goes out, Windows adjusts its settings faster than normal to compensate for it, allow for faster data transfer on broadband connections and lower latency while gaming.
netsh int tcp set global congestionprovider=ctcp
Enable UPnP on your router: This will automatically route the correct data to the correct ports.
Experiment at different days and time for lags
Try a Speed optimizer like SG TCP Optimizer
Lastly make sure that you have the latest Drivers installed and are
using compatible hardware.
I am currently trying to connect my DIY DC77 clock to ntpd (using Ubuntu). I followed the instructions here: http://wiki.ubuntuusers.de/Systemzeit.
With ntpq I can see the DCF77 clock
~$ ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+dispatch.mxjs.d 192.53.103.104 2 u 6 64 377 13.380 12.608 4.663
+main.macht.org 192.53.103.108 2 u 12 64 377 33.167 5.008 4.769
+alvo.fungus.at 91.195.238.4 3 u 15 64 377 16.949 7.454 28.075
-ns1.blazing.de 213.172.96.14 2 u - 64 377 10.072 14.170 2.335
*GENERIC(0) .DCFa. 0 l 31 64 377 0.000 5.362 4.621
LOCAL(0) .LOCL. 12 l 927 64 0 0.000 0.000 0.000
So far this looks OK. However I have two questions.
What exactly is the sign of the offset? Is .DCFa. ahead of the system clock or behind the system clock?
.DCFa. points to refclock-0 which is a DIY DCF77 clock emulating a Meinberg clock. It is connected to my Ubuntu Linux box with an FTDI usb-serial adapter running at 9600 7e2. I verified with a DSO that it emits the time with jitter significantly below 1ms. So I assume the jitter is introduced by either the FTDI adapter or the kernel. How would I find out and how can I reduce it?
Part One:
Positive offsets indicate time in the client is behind time on the server.
Negative offsets indicate that time in the client is ahead of time on the server.
I always remember this as "what needs to happen to my clock?"
+0.123 = Add 0.123 to me
-0.123 = Subtract 0.123 from me
Part Two:
Yes the USB serial converters add jitter. Get a real serial port:) You can also use setserial and tell it that the serial port needs to be low_latency. Just apt-get setserial.
Bonus Points:
Lose the unreferenced local clock entry. NO LOCL!!!!
I'm working on a multiplayer game. The principle is simple, each of the two players sends each other periodically 512 bytes every 50 milliseconds.
The problem is that about every 20-30 seconds players stop receiving data for sometimes one but sometimes even up to 20 seconds (though, sending had not been interrupted).
At first I thought that this is caused by a slow network connection on either my side or on the side of my remote PC which I use for debugging.
But then I noticed that all network traffic on my side slows down at the same times when the game stops receiving data.
So I started ping <my-local-router> and this is what it shows me:
When the game isn't running:
...
64 bytes from 192.168.1.1: icmp_req=4520 ttl=64 time=4.89 ms
64 bytes from 192.168.1.1: icmp_req=4521 ttl=64 time=7.96 ms
64 bytes from 192.168.1.1: icmp_req=4522 ttl=64 time=10.5 ms
64 bytes from 192.168.1.1: icmp_req=4523 ttl=64 time=7.21 ms
64 bytes from 192.168.1.1: icmp_req=4524 ttl=64 time=8.10 ms
64 bytes from 192.168.1.1: icmp_req=4525 ttl=64 time=3.37 ms
64 bytes from 192.168.1.1: icmp_req=4526 ttl=64 time=5.12 ms
64 bytes from 192.168.1.1: icmp_req=4527 ttl=64 time=3.29 ms
...
When the game is running:
...
64 bytes from 192.168.1.1: icmp_req=47 ttl=64 time=6.99 ms
64 bytes from 192.168.1.1: icmp_req=48 ttl=64 time=1.69 ms
64 bytes from 192.168.1.1: icmp_req=49 ttl=64 time=2.60 ms
64 bytes from 192.168.1.1: icmp_req=50 ttl=64 time=2.88 ms
64 bytes from 192.168.1.1: icmp_req=52 ttl=64 time=9210 ms
64 bytes from 192.168.1.1: icmp_req=53 ttl=64 time=17144 ms
64 bytes from 192.168.1.1: icmp_req=54 ttl=64 time=16214 ms
64 bytes from 192.168.1.1: icmp_req=55 ttl=64 time=15372 ms
64 bytes from 192.168.1.1: icmp_req=56 ttl=64 time=14482 ms
64 bytes from 192.168.1.1: icmp_req=57 ttl=64 time=13486 ms
64 bytes from 192.168.1.1: icmp_req=58 ttl=64 time=12511 ms
64 bytes from 192.168.1.1: icmp_req=59 ttl=64 time=11546 ms
64 bytes from 192.168.1.1: icmp_req=60 ttl=64 time=10591 ms
64 bytes from 192.168.1.1: icmp_req=61 ttl=64 time=9626 ms
64 bytes from 192.168.1.1: icmp_req=62 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_req=63 ttl=64 time=3.33 ms
...
It seems that the game is causing the router to become unresponsive.
I don't have any P2P running on my local PC, but that doesn't even sound relevant since I don't experience the slowback when the game isn't running.
I'm new to UDP programming and I'm getting clueless with this, especially since the 512 bytes every 50ms seems like quite a small bandwidth to me (when I do run P2P, it easily runs 1.5MB/s).
This might have been my router dying and needing a replacement or something fishy in my wireless drivers, as I've noticed more network freezes lately even at times when the application wasn't running.