fxp0: discard oversize frame leads to icmp 36: ip reassembly time exceeded

From: Bruce Ashfield (bruce.ashfield_at_gmail.com)
Date: 06/17/05

  • Next message: David Sze: "Re: FreeBSD MySQL still WAY slower than Linux"
    Date: Fri, 17 Jun 2005 12:08:53 -0400
    To: freebsd-stable@freebsd.org

    Hi all,

    I've been searching through archives and many freebsd resources and can't
    seem to find a solution to the problem that I'm currently seeing. I thought
    I'd check here before hacking the kernel to try and fix it myself, just in
    case the fix is already out there and just eluding me :)

    I'm running a 5.4-STABLE freebsd firewall. Everything is pretty standard,
    DSL -> firewall -> clients. I'm using pppoe and providing NAT and other
    goodies to the machines behind the firewall. Nothing too fancy.

    All my services are passing nicely through the firewall, except one
    application. VNC/Timbuktu when run over a VPN connection. I've been trying
    to fix the problem by restricting mtu size, I've got tcpmssfixup and have
    clamped the size on the client Window's box as well. Nothing works, but the
    symptom I was seeing and was trying to solve was:

    > icmp 36: ip reassembly time exceeded

    As dumped from tcpdump on my pppoe tunnel. I searched high and low and tried
    all kinds of tcp/ip tuning options. Nothing helped. So during yet another
    debugging session I noticed:

    > fxp0: discard oversize frame (ether type 8864 flags 3 len 1470 > max 1462)

    In my logs. Funny how that message matched the ip re-assembly errors 1 to 1.
    So it looks like my nic is dropping the packets as they are detected as too
    large and that propagates up and then I see my icmp message. Makes sense.

    I've seen this problem mentioned in other freebsd forums, but I most often
    saw the answer "upgrade to the latest 5-release", which I *should* already
    be running. The message comes from /sys/net/if_ethersubr.c and obviously it
    is calculating the MAX size of the packet incorrectly or I've still got
    something misconfigured. I also poked around in the fxp driver, but didn't
    see anything obvious.

    So before I go off doing some more extensive hacking, I thought I'd see if
    anyone could point me at the problem or maybe even show me the patch I
    couldn't find :)

    I've included some potentially relevant dumps below,




    inet6 fe80::40:63ff:fe04:2c40%fwe0 prefixlen 64 scopeid 0x1
    ether 02:40:63:04:2c:40
    ch 1 dma 0
    vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1448
    inet6 fe80::240:63ff:fedd:622f%vr0 prefixlen 64 scopeid 0x2
    inet 10.10.x.x netmask 0xff000000 broadcast<>
    ether 00:40:63:dd:62:2f
    media: Ethernet autoselect (10baseT/UTP)
    status: active
    fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1448
    inet6 fe80::202:b3ff:fe24:8182%fxp0 prefixlen 64 scopeid 0x3
    ether 00:02:b3:24:81:82
    media: Ethernet autoselect (10baseT/UTP)
    status: active
    plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
    lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
    inet <> netmask 0xff000000
    tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
    inet 66.x.x.x --> 66.x.x.x netmask 0xffffff00
    Opened by PID 222

    "Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
    its end"
    freebsd-stable@freebsd.org mailing list
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

  • Next message: David Sze: "Re: FreeBSD MySQL still WAY slower than Linux"