ICMP_UNREACH_NEEDFRAG broken in -current

[Brian Somers]

It seems that the code to handle ICMP_UNREACH_NEEDFRAG is broken in -current,
although it doesn't seem broken in RELENG_5 - which is odd as the code in
ip_icmp.c looks the same :(

I have a fairly standard scenario:
                                             -
                           172.16.10.201/24 -|
    [route add 172.16.0.0/24 172.16.10.212]  |
                                             |
                                             |--- 172.16.10.212/24     -
                                             |    194.242.157.46/28 ---|
                                             -                         |
                                                                       |
                                             -    80.177.173.150/32 ---|
                                             |--- 172.16.0.1/24        -
                                             |
                              172.16.0.5/24 -|
             [route add default 172.16.0.1]  -

The outside network segment is an IPSEC configuration with gif interfaces
on the endpoints, and an MTU of 1280.  Internal network MTUs are 1500.
172.16.0.5 is running -current, everything else is running RELENG_5.

When I send tcp traffic from 172.16.0.5 -> 172.16.10.201 the link dies.
172.16.0.5 sees the ICMP-must-fragment messages coming back from 172.16.0.1,
but continues to use the default route with an MTU of 1500.

On 172.16.0.5, ``route add 172.16.10.0/24 172.16.0.1 -mtu 1280'' fixes
the problem (traffic flows ok *both* ways), although 172.16.10.201 still
looks broken (route get -n 172.16.0.5 says the mtu is 1500!!).

The problem seems to be in netinet/ip_icmp.c where ntohs(icp->icmp_nextmtu)
has a value of zero:

                        mtu = ntohs(icp->icmp_nextmtu);
                        if (!mtu)
                                mtu = ip_next_mtu(mtu, 1);

which returns another zero and nothing interesting happens (cvs blame says
Andre (cc'd) last touched these lines, but I don't think the problem came
from that change!).

So what's it supposed to do?  I would suspect it should be getting a route
to icmpsrc, cloning it if it's not a host route, then setting the route mtu
to ip_next_mtu(rt->rt_rmx.rmx_mtu, 1).

Comments/suggestions/flames?

-- 
Brian <brian at Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
      <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !