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: 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: 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)
    • routing bug?
      ... I am experiencing some weird routing phenomena. ... When I open a UDP socket and send datagrams to an address ... switch from going out the route specific interfaceto going out ... fxp0: flags=8843mtu 1500 ...
      (freebsd-stable)
    • 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)