ICMP_UNREACH_NEEDFRAG broken in -current

From: Brian Somers (brian_at_Awfulhak.org)
Date: 09/27/04

  • Next message: Bjoern A. Zeeb: "Re: ICMP_UNREACH_NEEDFRAG broken in -current"
    Date: Mon, 27 Sep 2004 11:36:24 +0100
    To: freebsd-net@FreeBSD.org
    
    

    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@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
          <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
    Don't _EVER_ lose your sense of humour !
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    

  • Next message: Bjoern A. Zeeb: "Re: ICMP_UNREACH_NEEDFRAG broken in -current"

    Relevant Pages

    • freebsd 5.3R and ipx routing troubles
      ... ipx router. ... A network scheme is simple: ... fxp0: flags=8843mtu 1500 ... Adding route to interface fxp3f0 ...
      (freebsd-net)
    • Re: I love TCPIP (not!)
      ... LAN/subnetwork as the OSA feature and the adjacent router, ... such destination. ... entry with a subnetwork route. ... ROUTE DEFAULT 10.1.1.254 ETH1 MTU 8192 ...
      (bit.listserv.ibm-main)
    • Re: pppoe routing problem, default route isnt used for some hosts
      ... "non-working hosts". ... route for this Hosts use the default gw. ... (the connections tests are made from the router, the iface MTUs are correct) ... is, small packets, are always smaller than your MTU. ...
      (freebsd-questions)
    • Re: OSA-Express, 100mb Token-Ring, QDIO, MTU Size Question
      ... What you are suggesting the OSA does would, I think, require too much ... ROUTE DEFAULT 192.168.0.224 OSD1 MTU 4070 ... port on my z/OS 1.7 LPARs to 4070 using the GATEWAY statement (still ...
      (bit.listserv.ibm-main)
    • Re: HUO or restored? (poll)
      ... It has zero issues. ... offered a trade for the same title, taken off route after a little ... If both were the exact same price. ...
      (rec.games.pinball)