When ping-ip's result compared to wireshark's packets, the content length of the packets is actually not right

[Talbot3]

sent 40 bytes to 203.119.204.187
received 60 bytes from 203.119.204.187
data: 4514`2800`7ab7000053018255cb77ccbbc0a811c500004b5200010a096162636465666768696a6b6c6d6e6f7071727374757677616263646566676869

ENV: Node 12.4.0 OS: macos mojave 10.14.5

[stephenwvickers]

@OrangeBook can you please give more detail. I don't understand what the problem is from your description.

[Talbot3]

there is all description. just check the 3th and 4th bytes is not right from node-raw-socket.
packet's 3th and 4th bytes is length of packet right ?

[stephenwvickers]

@OrangeBook so the length in the data printed above would be 40, i.e. 0x28. That's the length of the sent packet, perhaps you are printing the sent packet?

Can you share the program you are using to display this data so I can look further?

[Talbot3]

@OrangeBook so the length in the data printed above would be 40, i.e. 0x28. That's the length of the sent packet, perhaps you are printing the sent packet?

should not so, maybe mixed return and send packet

Can you share the program you are using to display this data so I can look further?

@stephenwvickers , just run demo on node-raw-socket/example/ping.js

[stephenwvickers]

@Talbot3 The example program works for me.

[Talbot3]

yea, but my mean is the 2800 data wrong.but i didn't know how to fix it on this repo

[dancrumb]

I just created https://stackoverflow.com/questions/74448657/why-might-wireshark-and-nodejs-disagree-about-a-packets-contents and was pointed to this issue.

I also see this on macOS (so, perhaps this is macOS related).

I've run the ping example in the following ways:

• As my regular user
• As root
• As root, with the OSX path of switching to SOCK_DGRAM disabled

In every instance, the ICMP reply comes back with the length set to 0x2800 instead of 0x0040.

Even setting aside the Wireshark evidence, the reply packet is wrong for a few reasons:

1. The length is incorrect... 0x2800 is about 10kB not the 60b that actually comes back
2. The checksum is incorrect for a length of 0x2800 (but it's the correct checksum for 0x0040).

[dancrumb]

I've created a SSCCE here: https://github.com/dancrumb/sscce-raw-socket-ping

[dancrumb]

Hmmm - this seems pertinent :/

https://cseweb.ucsd.edu//~braghava/notes/freebsd-sockets.txt

Specifically:

Reading from RAW sockets
------------------------
- ip_len does not include the IP header's length.  recvfrom() however
returns the packet's true length.  To get the true ip_len field do:
iphdr->ip_len += iphdr->ip_hl << 2;

- You may only read from RAW sockets bound with a protocol other than
IPPROTO_RAW

- ip_len is in host byte order

- You may only read packets for protocols or subprotocols that the kernel
does not process.  This includes things such as ICMP_ECHOREPLY and
ICMP_TIMESTAMP as well as nonstandard protocol numbers.