Не формируются ICMP echo request
Все выполняю на маршрутизаторе.
Есть интерфейс eth5
Покажи вывод ip route, у тебя скорее всего ответ уходит через другой интерфейс.
Даже если уходит, разве я не должен увидеть ICMP echo request?
Что здесь непонятно? 🙂 Адресация в пределах сети идёт не по IP, а по MAC. MAC неизвестен, пинг слать некому
Может я туплю, но в последнем дампе не вижу ARP ответов. Пингуемый комп в той-же подсети что и роутер, значит роутер должен отправлять IP пакеты сразу целевому хосту по L2 (а не отправлять пакет другому роутеру, что-бы тот разбирался), но он не может получить L2 адрес пингуемого хоста, а значит не может составить L2 пакет в который нужно засунуть соответствующий IP пакет.
разве я не должен увидеть ICMP echo request?
Верно ARP ответов нет!, поэтому ICMP echo request и не формируется?
разве я не должен увидеть ICMP echo request?
Ещё раз, в пределах сети адресация идёт по MAC адресу. MAC адреса ты не знаешь. Письмо отправишь «на деревню дедушке»?
Ну а как он сформируется-то, если ведро не знает что писать в поле DST MAC (или как-там его) ethernet-фрэйма?
Нет, я всё понимаю. Пятница, день тяжёлый, зимний авитаминоз…
Понял, дополняя тему. Приобрели туннель у провайдера между двумя географически распределенными зданиями и вот эта ситуация. Эскалирую проблему ему.
Да, подозревая ответы, я хотел убедиться. Спасибо!
У меня порт провайдера через локальный vlan заведен на маршрутизатор. Я вижу в eth5 как удаленная, моя, железка долбиться с ARP, Request who-has
А dlink случайно не твой?
А в этот vlan больше ничего не воткнуто? В дампе какой-то DHCP трафик засветился. Что вообще слышно из порта провайдера? Может на том конце просто IP другой, или ещё что-то.
Я вижу в eth5 как удаленная, моя, железка долбиться с ARP, Request who-has
Наоборот. Это с твоего eth5 уходят ARP запросы
«RFC 1812, pages 80 and 82:
The ICMP Destination Unreachable message is sent by a router in response to a packet which it cannot forward because the destination (or next hop) is unreachable or a service is unavailable. Examples of such cases include a message addressed to a host which is not there and therefore does not respond to ARP requests, and messages addressed to network prefixes for which the router has no valid route.»
Вы уверены, что провайдер дал вам именно L2 туннель?
Icmp no response found wireshark что это
The trace file shows several times «no response found» followed by «reply in xxx» and «Request in xxx»
From reviewing your capture.
Apply a display filter of «icmp» and it may make it easier to see.
An IPv4 ping is implemented using ICMP echo request and ICMP echo reply packets. When Wireshark sees either one of these packets it attempts to find the the expected peer packet in the current trace file. The system sending the request includes an id and a seq field. The seq field typically increments by one with each subsequent request. The reply packet simply echos these values back to the sender of the request where they are correlated and reported to the user.
Within Wireshark the value of the seq field, by default, is displayed twice delimited by a «/» character; once as big-endian number and the other as little-endian number. The seq is displayed twice because some ping implementations (e.g. Microsoft Windows) write the seq number field into the packet in a different byte order then your typical *nix systems do.
Wireshark attempts to do request/response tracking.
In the case of «Echo (ping) request» packets, if the peer packet is found, the message «(reply in xxx)» is displayed where xxx is the packet number of peer echo reply packet. But if the reply packet is not seen then the message «(no response found)» is displayed.
In the case of the Echo (ping) reply packets, if the peer packet is found the message «(request in xxx)» is displayed where xxx is the packet number of the peer echo requests packet. There is no «(no request found)» message displayed when no corresponding request can be found for a reply.
Here is where is gets interesting.
Your trace file shows lots of ping reply packets that have no «(request in xxx)» messages in them. Unless you have something spoofing ICMP echo replies (very unlikely), this implies the packet trace was captured from a point or interface where it did not see the request that solicited the reply. This can happen when you have multiple nic interfaces on a host and the request was received on one interface but the reply exits on a different interface (the one you were capturing).
But focusing on the few packets where you did have ICMP Echo requests, you in fact have two copies of each request followed by two copies of each reply which can cause some confusion. Specifically look at frames 10, 11, 12 and 13.
Packet Filter Analysis for ICMP in Wireshark
ICMP or Internet Control Message Protocol is Internet or Network layer protocol. In general it is used to check the reachability of a host or router in a network.
Who uses ICMP?
Ping or traceroute uses ICMP as inner protocol. Ping uses ICMP echo request and ICMP echo reply messages to check whether destination host is reachable or not.
Types of ICMP packet?
In general two types of ICMP packet
How to get ICMP packet in Wireshark?
Step1: We can use ping tool to get ICMP request and reply.
Step2: Open command line or terminal in Windows or Linux respectively.
Step3: Run Wireshark.
Step4: Run below command
Make sure you have internet connection or ping will be failedJ. Here is the snapshot for successful ping to Google. We can see 0% loss. That means ICMP request packets = ICMP reply packets.
Here are the more details:
In this case we ping to Google web site. Instead we can do ping to ip address also.
ping 192.168.1.1 [This is my router IP address]
Here is successful ping to my router
Step5: Stop Wireshark and put “ICMP” as filter in Wireshark.
Analysis on ICMP:
Let’s check what happens in Wireshark when we ping to Google or 192.168.1.1.
Here is the ICMP request and reply packets for Google ping.
Note: We have to put filter ‘icmp’ as we are interested only in ICMP packets.
Number of ICMP request: From capture we can see there are 4 ICMP request packets.
Check the marked packets.
Number of ICMP reply: From capture we can see there are 4 ICMP reply packets.
Check the marked packets.
ICMP Request:
Now select ICMP request packet in Wireshark and look into IPv4 layer.
As this is ICMP request packet so we can see source IP as my system IP address and destination IP as Google’s one IP address. Also IP layer mentioned the protocol as ICMP.
Here is the screenshot
Now for the same packet select ICMP part in Wireshark.
We can see below important fields:
Here is the screenshot
ICMP Reply:
Now select ICMP reply packet in Wireshark and look into IPv4 layer.
As this is ICMP reply packet so we can see destination IP as my system IP address and source IP as Google’s one IP address. Also IP layer mentioned the protocol as ICMP.
Here is the screenshot
Now for the same packet select ICMP part in Wireshark.
We can see below important fields:
Here is the screenshot
Now let’s see ICMP request and ICMP reply side by side in a picture.
*Red means it’s different
*Green means it’s same.
Special observation:
What happens if IP address is not reqachable:
Let’s ping some ip address which is not accessible. So we will see below output.
Here is the snapshot for Wireshark
That means we did not receive any ICMP reply for any ICMP request.
Simple Conclusion:
So if we want to check any IP or website is reachable or not, we can use ping or traceroute which internally use ICMP protocol.
Quick Reference:
If interested to know other types of ICMP, follow below link
About the author
Bamdeb Ghosh
Bamdeb Ghosh is having hands-on experience in Wireless networking domain.He’s an expert in Wireshark capture analysis on Wireless or Wired Networking along with knowledge of Android, Bluetooth, Linux commands and python. Follow his site: wifisharks.com
RELATED LINUX HINT POSTS
Linux Hint LLC, [email protected]
1210 Kelly Park Cir, Morgan Hill, CA 95037
Icmp no response found wireshark что это
First time here? Check out the FAQ!
I Receive a «No Response found» message from Wireshark.
When the Datalength is 68 or under 68 I dont get these messages.
Comments
Can you paste the output of Help->About Wireshark here.
I cant Upload Data because I dont have enough Points.
3 Answers
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.
Comments
It looks as though the key for matching transactions (beyond the basic conversation) consists of: (1) the IP checksum (2) ID & sequence number (i.e. next 2 16-bit fields) (3) possible VLAN Id
But this part of packet-icmp.c could be a lot clearer.
This question discusses the reason for both BE and LE representations.
https://bugs.wireshark.org/bugzilla/s.
There has been some recent work on the checksum check.
Perhaps add a preference to ignore checksum then match on basic IP info, ICMP ID and ICMP Seq.
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!».
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».
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.
Comments
No. It works just as @Jaap stated. The checksums are expected to match, but they don’t. When matching requests to replies, I took the approach of trying to make the heuristics as strong as possible to avoid accidentally matching replies to the wrong request, but of course when the RFC’s aren’t followed, things like this are the result.
Some possible solutions:
You are correct Chris, Wireshark does indeed work as Jaap stated.
Would a Wireshark user be better served with enhanced ICMP reply matching code here? I’m not really convinced anything needs to change. But more than once I have had to personally explain that Wireshark was not technically wrong in this exact case.
If a change is made to match truncated ICMP echo replies to their full size requests, then the Info column should be augmented and/or an expert info generated to indicate that less bytes than the requested number of bytes was received to make it obvious that this reply is not technically correct in the sense of RFC 792.
Would a Wireshark user be better served with enhanced ICMP reply matching code here?
Yes, probably so. While technically not the expected response, the user is probably just mainly concerned about connectivity. Can I reach a host and can the host reach me? And what is the round-trip delay in reaching that host? So to be more flexible, one of bullets 2, 3 or 4 I mentioned above should probably be considered.
