• Matteo Croce's avatar
    icmp: don't fail on fragment reassembly time exceeded · 258bbb1b
    Matteo Croce authored
    The ICMP implementation currently replies to an ICMP time exceeded message
    (type 11) with an ICMP host unreachable message (type 3, code 1).
    
    However, time exceeded messages can either represent "time to live exceeded
    in transit" (code 0) or "fragment reassembly time exceeded" (code 1).
    
    Unconditionally replying to "fragment reassembly time exceeded" with
    host unreachable messages might cause unjustified connection resets
    which are now easily triggered as UFO has been removed, because, in turn,
    sending large buffers triggers IP fragmentation.
    
    The issue can be easily reproduced by running a lot of UDP streams
    which is likely to trigger IP fragmentation:
    
      # start netserver in the test namespace
      ip netns add test
      ip netns exec test netserver
    
      # create a VETH pair
      ip link add name veth0 type veth peer name veth0 netns test
      ip link set veth0 up
      ip -n test link set veth0 up
    
      for i in $(seq 20 29); do
          # assign addresses to both ends
          ip addr add dev veth0 192.168.$i.1/24
          ip -n test addr add dev veth0 192.168.$i.2/24
    
          # start the traffic
          netperf -L 192.168.$i.1 -H 192.168.$i.2 -t UDP_STREAM -l 0 &
      done
    
      # wait
      send_data: data send error: No route to host (errno 113)
      netperf: send_omni: send_data failed: No route to host
    
    We need to differentiate instead: if fragment reassembly time exceeded
    is reported, we need to silently drop the packet,
    if time to live exceeded is reported, maintain the current behaviour.
    In both cases increment the related error count "icmpInTimeExcds".
    
    While at it, fix a typo in a comment, and convert the if statement
    into a switch to mate it more readable.
    Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    258bbb1b
icmp.c 29.8 KB