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