Hello everytime I type the Command in the CMD-prompt ping 8.8.8.8 -l «X»
X= Above 68
I Receive a «No Response found» message from Wireshark.
When the Datalength is 68 or under 68 I dont get these messages.
Could you tell me why this happen ?
Hmm, RFC 792 says on page 15: «The data received in the echo message must be returned in the echo reply message». If not, the checksum will be different, which is part of the key to match the ICMP echo requests and responses.
If there’s a valid reason to limit the payload size (e.g. anti DDOS), it may be needed to tweak the PDU matching code.
Google’s DNS server’s truncate a ping reply to a maximum payload of 68 bytes regardless of the size of the request.
On a windows system if you initiate a ping to 8.8.8.8 with a length value greater than 68 (e.g. 69), Microsoft’s ping will indicate that the ping is successful, but Wireshark’s analysis reports «no response found!».
C:>ping -l 69 8.8.8.8
Pinging 8.8.8.8 with 69 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 69) time=26ms TTL=54
Reply from 8.8.8.8: bytes=68 (sent 69) time=13ms TTL=54
Reply from 8.8.8.8: bytes=68 (sent 69) time=12ms TTL=54
Reply from 8.8.8.8: bytes=68 (sent 69) time=23ms TTL=54
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 26ms, Average = 18ms
C:>
But there’s a subtle addition to the Microsoft’s ping Reply report. Note that it indicates «bytes=68 (sent 69)».
On a macOS system a ping to 8.8.8.8 with a length of 69 also indicates a reply was received but in this case an second line follows each reply message reporting «wrong total length 96 instead of 97».
$ ping -c 4 -s 69 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 69 data bytes 76 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=18.353 ms wrong total length 96 instead of 97 76 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=18.038 ms wrong total length 96 instead of 97 76 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=15.280 ms wrong total length 96 instead of 97 76 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=22.787 ms wrong total length 96 instead of 97 --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 15.280/18.614/22.787/2.689 ms $
Pinging other commonly accessible sites, for example two open DNS server addresses of 1.1.1.1 and 9.9.9.9, does not appear to have this reply size downgrade behavior.
There’s a few things to consider here:
The 8.8.8.8 servers only reply with the first 68 octets of the ping request’s payload for lengths greater than 68, is this in fact a successful ping? Perhaps.
Could Wireshark’s ping analysis be enhanced to report on the reply as successful but we have a length discrepancy? Perhaps.
Testing locally with a dev build of Wireshark I see the same. The target only returns 68 bytes of data and I think the ICMP dissector is not matching up the responses with the request due to the size difference.
I can’t see anything about this in bugzilla, please raise an issue there and attach a capture showing the problem.
Please start posting anonymously — your entry will be published after you log in or create a new account.
Уважаемые форумчане, подскажите кто и что знает.
Есть сервер, условно «А» — основной(source), от которого идут все IP на другие сервера, а так же 15 других(destination ip) условно «1,2,3,4» и тд.
Появилась очень странная проблема, которая не поддаётся никакой логике.
Появились потери пакетов, именно на IP которые идут в туннель.
Например
155.44.33.22 — находится на сервере «А», по GRE идёт в сервер «1»
При пинге 155.44.33.22, есть потери примерно 20%.
Между серверами «А» и «1», при прямой проверке связи, вообще всё отлично.
Но, при проверке пинга внутри туннеля, по локальному адресу например 192.168.0.50, есть потери, от чего потери идут уже и на внешнем адресе.
Что очень интересно, то если проблема появляется, то только в таком виде:
64 bytes from 155.44.33.22: icmp_seq=215 ttl=51 time=61.221 ms
64 bytes from 155.44.33.22: icmp_seq=216 ttl=51 time=54.311 ms
64 bytes from 155.44.33.22: icmp_seq=217 ttl=51 time=49.040 ms
64 bytes from 155.44.33.22: icmp_seq=218 ttl=51 time=51.325 ms
Request timeout for icmp_seq 219
64 bytes from 155.44.33.22: icmp_seq=220 ttl=51 time=49.756 ms
64 bytes from 155.44.33.22: icmp_seq=221 ttl=51 time=53.280 ms
64 bytes from 155.44.33.22: icmp_seq=222 ttl=51 time=52.730 ms
64 bytes from 155.44.33.22: icmp_seq=223 ttl=51 time=52.830 ms
Request timeout for icmp_seq 224
64 bytes from 155.44.33.22: icmp_seq=225 ttl=51 time=54.453 ms
64 bytes from 155.44.33.22: icmp_seq=226 ttl=51 time=51.656 ms
64 bytes from 155.44.33.22: icmp_seq=227 ttl=51 time=53.333 ms
64 bytes from 155.44.33.22: icmp_seq=228 ttl=51 time=52.741 ms
Request timeout for icmp_seq 229
64 bytes from 155.44.33.22: icmp_seq=230 ttl=51 time=51.533 ms
64 bytes from 155.44.33.22: icmp_seq=231 ttl=51 time=59.256 ms
64 bytes from 155.44.33.22: icmp_seq=232 ttl=51 time=50.136 ms
64 bytes from 155.44.33.22: icmp_seq=233 ttl=51 time=53.572 ms
Request timeout for icmp_seq 234
64 bytes from 155.44.33.22: icmp_seq=235 ttl=51 time=51.787 ms
64 bytes from 155.44.33.22: icmp_seq=236 ttl=51 time=51.866 ms
64 bytes from 155.44.33.22: icmp_seq=237 ttl=51 time=51.229 ms
64 bytes from 155.44.33.22: icmp_seq=238 ttl=51 time=50.872 ms
Request timeout for icmp_seq 239
Видно закономерность потери пинга.
Тоже самое по локальному IP, между серверами на которых туннель.
64 bytes from 192.168.0.50: icmp_seq=85 ttl=64 time=7.79 ms
64 bytes from 192.168.0.50: icmp_seq=86 ttl=64 time=7.75 ms
64 bytes from 192.168.0.50: icmp_seq=87 ttl=64 time=7.77 ms
64 bytes from 192.168.0.50: icmp_seq=88 ttl=64 time=7.75 ms
64 bytes from 192.168.0.50: icmp_seq=90 ttl=64 time=7.74 ms
64 bytes from 192.168.0.50: icmp_seq=91 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=92 ttl=64 time=7.76 ms
64 bytes from 192.168.0.50: icmp_seq=93 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=95 ttl=64 time=7.95 ms
64 bytes from 192.168.0.50: icmp_seq=96 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=97 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=98 ttl=64 time=7.88 ms
64 bytes from 192.168.0.50: icmp_seq=100 ttl=64 time=7.77 ms
64 bytes from 192.168.0.50: icmp_seq=101 ttl=64 time=7.74 ms
64 bytes from 192.168.0.50: icmp_seq=102 ttl=64 time=7.74 ms
64 bytes from 192.168.0.50: icmp_seq=103 ttl=64 time=7.76 ms
64 bytes from 192.168.0.50: icmp_seq=105 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=106 ttl=64 time=7.75 ms
64 bytes from 192.168.0.50: icmp_seq=107 ttl=64 time=7.76 ms
Каждый 5 пакет, потеря.
Буфер сетевой карты увеличил до максимальных значений, в dmesg никаких проблем нет от слова совсем. Правила iptables кристально чисты. Что это может быть и что делать?
При этом, проблема частичная, она может не затрагивать часть туннелей, пинг по ним будет без потерь, а потом опять так же их затронуть, начнутся потери на какой-то период, а другие при этом начнут работать без потерь, и так по кругу.
irqbalance стоит, руками в прерывания не лазил, нагрузка 40-50к pps всего, до 100мбc, обычно 50.
Нагрузка на канал, в моменты потери пинга, падает до 20мбc, из 40-50, т.е грубо говоря в половину, но не полностью.
забыл уточнить, еще есть bridge интерфейс, на сервере крутится несколько виртуалок через proxmox, а так как основной настроен как «inet manual», то и туннель работает через интерфейс vmbr0
Возможна ли проблема здесь?
Open
Issue created Mar 24, 2023 by
no response found for ICMP
Summary
If you try to ping google servers with size over 100 or 1000 bytes, google truncate the packet. In this case, the size of the response, is not the same from the request packet. Wireshark does not recognize the responses as reply packets, because the reply does not include the request payload.
Steps to reproduce
Just execute: ping -c 3 -s 1000 8.8.8.8
What is the current bug behavior?
Wireshark does not recognize the reply packets as valid packets.
What is the expected correct behavior?
Wireshark must found the response packets associated to the flow
Build information
Wireshark 4.0.3 (Git v4.0.3 packaged as 4.0.3-1~ubuntu22.04.0~ppa1).
Copyright 1998-2023 Gerald Combs <gerald@wireshark.org> and contributors.
Licensed under the terms of the GNU General Public License (version 2 or later).
This is free software; see the file named COPYING in the distribution. There is
NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) using GCC 11.3.0, with GLib 2.72.4, with PCRE2, with zlib
1.2.11, with Qt 5.15.3, with libpcap, with POSIX capabilities (Linux), with
libnl 3, with Lua 5.2.4, with GnuTLS 3.7.3 and PKCS #11 support, with Gcrypt
1.9.4, with Kerberos (MIT), with MaxMind, with nghttp2 1.43.0, with brotli, with
LZ4, with Zstandard, with Snappy, with libxml2 2.9.13, with libsmi 0.4.8, with
QtMultimedia, without automatic updates, with SpeexDSP (using system library),
with Minizip, with binary plugins.
Running on Linux 5.19.0-35-generic, with AMD Ryzen 7 5700U with Radeon Graphics
(with SSE4.2), with 35907 MB of physical memory, with GLib 2.72.4, with PCRE2
10.39 2021-10-29, with zlib 1.2.11, with Qt 5.15.3, with libpcap 1.10.1 (with
TPACKET_V3), with c-ares 1.18.1, with GnuTLS 3.7.3, with Gcrypt 1.9.4, with
nghttp2 1.43.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.4.8, with
libsmi 0.4.8, with LC_TYPE=en_US.UTF-8, binary plugins supported.
Edited Mar 24, 2023 by dragonxtek
I set up 3 CentOS servers, configured server2 as router between 192.168.1.0/24 and 30.0.0.0/24, but ping can’t get through.
I tried ping 192.168.1.62 from server1, according to tcpdump on server3, ICMP request is received, but it doesn’t generate ICMP response.
23:36:06.436243 IP 30.0.0.2 > 192.168.1.62: ICMP echo request, id 23570, seq 2838, length 64
23:36:07.436212 IP 30.0.0.2 > 192.168.1.62: ICMP echo request, id 23570, seq 2839, length 64
Setup
Servers
-
server1:
- eth0 — 30.0.0.2
-
server2:
- eth0 — 192.168.1.61
- eth0:0 — 30.0.0.1
-
server3:
- eth0 — 192.168.1.62
Routing
-
route info on server1:
- 0.0.0.0 30.0.0.1
-
route info on server3:
- 30.0.0.0/24 192.168.1.61
slm
15.3k12 gold badges109 silver badges123 bronze badges
asked Aug 30, 2013 at 15:42
1
I was receiving ICMP packets but did not see them go out. The problem was related to the traffic traversing multiple interfaces and reverse path filtering being on by default…
I’ve enabled martian source logging first:
$ echo 1 >/proc/sys/net/ipv4/conf/eth2/log_martians
Then there are several options for what to do with them… I’m enabling loosely handling them:
$ sysctl net.ipv4.conf.all.rp_filter=2
See these for details:
- http://lartc.org/howto/lartc.kernel.html
- https://access.redhat.com/site/solutions/53031
slm
15.3k12 gold badges109 silver badges123 bronze badges
answered Apr 9, 2014 at 19:20
AXE LabsAXE Labs
4,0514 gold badges29 silver badges29 bronze badges
1
Run tcpdump with -e flag and see if the destination MAC address is correct.
answered Aug 27, 2015 at 10:30
FoamyBeerFoamyBeer
2215 silver badges7 bronze badges
0
I’m building my own packets and sending them through a raw socket. The packet is apparently A-OK, but I’m not getting any replies.
Sequence block is generated with a for loop.
Identifier block is generated randomly.
This is the information I get from Wireshark. This is true for every IP I try to ping to, even local.
asked Jun 22, 2017 at 8:32
You can check a couple of things.
1 check if the packet you have constructed is correct. I mean offsets, header length etc. Because if not,
the recipient will simply discard it
2 check if the packet is actually reaching the destination. Try tcpdump on the recipient.
3 once you know the packet is correct. Check other troubleshoot at other layers. Like if the host is doing an arp for dmac or are you supplying it in the packet. If arp, then does the destination reply. If manual is it the correct value. Does the sender have a route to destination. Does the destination have a return route. There are many possibilities if you post the outcome of above scenerios someone here can help you
answered Jun 22, 2017 at 8:43
john john
1,2373 gold badges12 silver badges20 bronze badges
2