fxp0: discard oversize frame leads to icmp 36: ip reassembly time
exceeded
Bruce Ashfield
bruce.ashfield at gmail.com
Fri Jun 17 16:08:54 GMT 2005
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,
Thanks,
Bruce
--------------------------------------
fwe0: flags=108943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=8<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=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
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=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1448
options=8<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=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 127.0.0.1 <http://127.0.0.1> 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"
More information about the freebsd-stable
mailing list