Date: Fri, 17 Jun 2005 12:08:53 -0400 From: Bruce Ashfield <bruce.ashfield@gmail.com> To: freebsd-stable@freebsd.org Subject: fxp0: discard oversize frame leads to icmp 36: ip reassembly time exceeded Message-ID: <3bd6b93c0506170908aa7abd4@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi all, I've been searching through archives and many freebsd resources and can't= =20 seem to find a solution to the problem that I'm currently seeing. I thought= =20 I'd check here before hacking the kernel to try and fix it myself, just in= =20 case the fix is already out there and just eluding me :) I'm running a 5.4-STABLE freebsd firewall. Everything is pretty standard,= =20 DSL -> firewall -> clients. I'm using pppoe and providing NAT and other=20 goodies to the machines behind the firewall. Nothing too fancy. All my services are passing nicely through the firewall, except one=20 application. VNC/Timbuktu when run over a VPN connection. I've been trying= =20 to fix the problem by restricting mtu size, I've got tcpmssfixup and have= =20 clamped the size on the client Window's box as well. Nothing works, but the= =20 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 trie= d=20 all kinds of tcp/ip tuning options. Nothing helped. So during yet another= =20 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= .=20 So it looks like my nic is dropping the packets as they are detected as too= =20 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= =20 saw the answer "upgrade to the latest 5-release", which I *should* already= =20 be running. The message comes from /sys/net/if_ethersubr.c and obviously it= =20 is calculating the MAX size of the packet incorrectly or I've still got=20 something misconfigured. I also poked around in the fxp driver, but didn't= =20 see anything obvious. So before I go off doing some more extensive hacking, I thought I'd see if= =20 anyone could point me at the problem or maybe even show me the patch I=20 couldn't find :) I've included some potentially relevant dumps below, Thanks, Bruce -------------------------------------- fwe0: flags=3D108943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 15= 00 options=3D8<VLAN_MTU> inet6 fe80::40:63ff:fe04:2c40%fwe0 prefixlen 64 scopeid 0x1 ether 02:40:63:04:2c:40 ch 1 dma 0 vr0: flags=3D8843<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 10.255.255.255<http://10.255.255.255>; ether 00:40:63:dd:62:2f media: Ethernet autoselect (10baseT/UTP) status: active fxp0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1448 options=3D8<VLAN_MTU> 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=3D108810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 <http://127.0.0.1>; netmask 0xff000000 tun0: flags=3D8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448 inet 66.x.x.x --> 66.x.x.x netmask 0xffffff00 Opened by PID 222 --=20 "Thou shalt not follow the NULL pointer, for chaos and madness await thee a= t=20 its end"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bd6b93c0506170908aa7abd4>