[bug #66185] ping incorrectly assumes data from ICMP datagram socket to start with an IP header

[Erik Auerswald]

URL:
  <https://savannah.gnu.org/bugs/?66185>

                 Summary: ping incorrectly assumes data from ICMP datagram
socket to start with an IP header
                   Group: GNU Networking Utilities
               Submitter: auerswal
               Submitted: Sat 07 Sep 2024 07:48:36 PM CEST
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sat 07 Sep 2024 07:48:36 PM CEST By: Erik Auerswald <auerswal>
When reading from a raw socket for IPv4, the data begins with an IPv4 header. 
When reading from an ICMP datagram socket for IPv4, the data begins with an
ICMP header.  The current code treats both cases identically, i.e., it
interprets the ICMP header from data read via ICMP datagram socket as an IPv4
header.

One visible result is a wrong reported TTL value:


$ ls -l ./ping/ping
-rwxr-xr-x 1 auerswald auerswald 441880 Sep  7 19:42 ./ping/ping
$ sudo tcpdump -ilo -lnvx 'icmp[icmptype] = icmp-echoreply' &
[1] 26783
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144
bytes
$ ./ping/ping -c1 -s0 -v 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 0 data bytes, id 0x68a2 = 26786
8 bytes from 127.0.0.1: icmp_seq=0 ttl=0
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
19:44:03.671261 IP (tos 0x0, ttl 64, id 53264, offset 0, flags [none], proto
ICMP (1), length 28)
    127.0.0.1 > 127.0.0.1: ICMP echo reply, id 30, seq 0, length 8
        0x0000:  4500 001c d010 0000 4001 acce 7f00 0001
        0x0010:  7f00 0001 0000 ffe1 001e 0000
$ fg
sudo tcpdump -ilo -lnvx 'icmp[icmptype] = icmp-echoreply'
^C
1 packet captured
2 packets received by filter
0 packets dropped by kernel


The reply packet has a TTL of 64, but ping reports a TTL value of 0.







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66185>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature