The gateway is behaving like it should and sending "Host Unreachable" to indicate that it couldn't resolve 172.16.30.3 via ARP anymore.)Īnother thing I found curious is that the ICMP traffic is in one direction using different destination ports. (Edit: Looking at the full trace that OP posted in a now-deleted reply, the FIN is sent after ~60s idle, so it looks like a somewhat-normal situation where the client host established a whole bunch of TCP connections and exchanged a normal request/reply at first, but then disconnected from Wi-Fi without closing them – or something along those lines. (Wireshark dissects the payload as a nested IP packet so that you could see the information, but it cannot distinguish the "depth" of the dissected fields, so the entire captured packet receives a tcp.dport = 443 property regardless of how deep the TCP header is.)īy looking at the ICMP payload (the "returned" packet), you can see that the HTTPS server at 192.168.15.4:443 was trying to send a TCP FIN to the client host 172.16.30.3, but either the client host is down and the gateway couldn't do an ARP lookup, or the packet was blocked by the gateway, so the undelivered packet is being returned to the web server. the original TCP packet that caused this error). So the port numbers reported by Wireshark aren't for the ICMP packet itself but for its payload (i.e. ![]() To allow the receiving host to associate the error report with some specific socket or connection, each error packet must include the original packet's network-layer and transport-layer headers. They do not use TCP, but they were caused by a TCP packet. ![]() According to the ICMP message type ( 3 "Destination Unreachable"), these are not monitoring but error packets (which is the most common use of ICMP).
0 Comments
Leave a Reply. |