tree 4affd6fbe37d686cd0ab119699fe07f85925f338
parent 9867b3b20d40a065c71c9147b90a2669a7c1a219
author achernya <achernya@google.com> 1670012927 -0800
committer Copybara-Service <copybara-worker@google.com> 1670012975 -0800

Produce correct ICMP6 Echo Reply when pinging magic link-local address

Bonnet's implementation of IcmpReachableInterface internally produces
ICMP6 Echo Requests directed at a link-local address that is
replied-to by the server directly, without relying on other network
elements. However, we were previously constructing the ICMP6 Echo
Reply incorrectly, putting in the entire packet (as is expected for
ICMP errors) rather than its body.

This would produce non-sensical output when used with `ping6`, namely

```
# ping6 -i 0.1 fe80::71:626f:6e65%qbone0 -c 1
PING fe80::71:626f:6e65%qbone0(fe80::71:626f:6e65) 56 data bytes
Warning: time of day goes back (-3758166514911134782us), taking countermeasures.
Warning: time of day goes back (-3758166514911134731us), taking countermeasures.
112 bytes from 2002:a17:51a:2b52:b0:79c:f9be:5968: icmp_seq=1 ttl=255 time=0.000 ms
wrong data byte #16 should be 0x10 but was 0x0
#16     0 0 0 0 0 0 0 0 fe 80 0 0 0 0 0 0 0 0 0 71 62 6f 6e 65 80 0 fa c3 3a fb 0 1
#48     4f 53 8a 63 0 0 0 0

--- fe80::71:626f:6e65%qbone0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.000/0.000/0.000/0.000 ms
```

This changes corrects the `body` passed through to actually be that of
the ICMP6 Echo Request, which includes both the UNIX timeval and the
counter of padding when using standard iputils ping6.

This is really an entirely cosmetic issue, but it should also fix the
confusion Wireshark has when looking at packet captures over QBONE,
where it is not able to line up the request and reply since the data
don't match.

PiperOrigin-RevId: 492531951