[Bug 207208] ping has a problem with fragmented replies

[anonymous]

bugzilla-noreply at freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207208
> 
> --- Comment #3 from Jasper Siepkes <jasper at siepkes.nl> ---
> Thanks for the prompt response Maxim.
> 
> I did some checks:
> 
> # sysctl net.inet.ip.maxfragsperpacket net.inet.ip.maxfragpackets
> net.inet.ip.maxfragsperpacket: 16
> net.inet.ip.maxfragpackets: 8192
> 
> Those are the defaults I believe. Also double checked any modifications to ICMP
> and IP related stuff in loader.conf or sysctl.conf. 
> 
> ----8<-----------------------
> # netstat -sp ip
> ip:
>         5136257 total packets received
>         0 bad header checksums
>         0 with size smaller than minimum
>         0 with data size < data length
>         0 with ip length > max ip packet size
>         0 with header length < data size
>         0 with data length < header length
>         0 with bad options
>         0 with incorrect version number
>         0 fragments received
>         0 fragments dropped (dup or out of space)
>         0 fragments dropped after timeout
>         0 packets reassembled ok
>         254049 packets for this host
>         12 packets for unknown/unsupported protocol
>         0 packets forwarded (0 packets fast forwarded)
>         0 packets not forwardable
>         0 packets received for unknown multicast group
>         0 redirects sent
>         702407 packets sent from this host
>         0 packets sent with fabricated ip header
>         0 output packets dropped due to no bufs, etc.
>         0 output packets discarded due to no route
>         31 output datagrams fragmented
>         62 fragments created
>         22 datagrams that can't be fragmented
>         0 tunneling packets that can't find gif
>         0 datagrams with bad address in header
> # netstat -sp icmp
> icmp:
>         0 calls to icmp_error
>         0 errors not generated in response to an icmp message
>         0 messages with bad code fields
>         0 messages less than the minimum length
>         0 messages with bad checksum
>         0 messages with bad length
>         0 multicast echo requests ignored
>         0 multicast timestamp requests ignored
>         Input histogram:
>                 echo reply: 1
>                 destination unreachable: 7282
>                 time exceeded: 1
>         0 message responses generated
>         0 invalid return addresses
>         0 no return routes
>         ICMP address mask responses are disabled
> ----8<-----------------------
> 
> I ran the tests again so the single 'echo reply' received is the normal size
> and the "time exceeded" is the one with the larger payload.
> 
> The host I used is behind NAT (PAT) so that could indeed be a problem. However
> I just now also did the test on another host which isn't behind NAT (pinged
> another host in its network segment) and he also had the problem.
> 
> I will install a vanilla VM today and do some tests to see if this really is an
> issue or I messed up somewhere else in the config.
> 

that's a good start but you haven't said much about the problem yet

ipv6 ipv4 ping ?  what bsd version ?  what firewall ?  what does your 
route table look like ?

 > "The host I used is behind NAT (PAT) ..."

you have to disable your firewall, ANY kernel tampering (that's 
difficult) that is "meant to make it more secure", and insure ICMP 
send/reply in particular is not being jammed by anything

also invite the idea that it's not ping's fault: it could be a poorly 
operated router somewhere

but there's a small chance someone is packet hacking to change the 
protocols en-routes, such that on arrival the pakcets are rejected for 
legitimate reasons (but were not sent that way)

such a problem could be hard to trace down so work by ruling out the 
quicker and simple things (ie, no firewall, trying different bsd or 
linux or diff ping version from older bsd, different kernel)

only after ruling out what is and isn't a problem can you go forward to 
point your finger in the code to blame at (and submitt a patch(1) for) 
or - ask more questions about