new problem w/workaround attached ( Re: Fixed (was Re: racoon still also broken) )
dillon at apollo.backplane.com
Fri Nov 5 09:45:51 PST 2004
:I've got a esp/transport link between my laptop and my work pc.
:My work pc then NATs onto the nortel intranet.
:This almost works.
:Having one problem with MTU. When I transfer data between the laptop
:and some other box on the intranet, big packets (1514 bytes) coming
:from the intranet, heading to the laptop get dropped by the work pc.
:This is because these have the DF bit set, and 1514 bytes + ah and esp
:overhead is too big to send through to the laptop. If I force-clear the
:DF bit, everything seems to work.. I've attached my hacked ip_output.c.
:It's a HACK that needs refining, but it works for me right now.
:A second problem, I get a familiar looking panic when I try using the
:ether.bridge example script to 'bridge' ndis0 and xl0 -
:pa assertion: cred == td->td_proc->p_ucred in vn_open
:syncing disks... 6 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
:giving up on 4 buffers
:Debugger("busy buffer problem")
:Stopped at Debugger+0x3e: movb $0,in_Debugger.0
:Debugger(c0418b05,4,4,4,14) at Debugger+0x3e
:boot(100,c04b1700,c043dbb4,d812f364,d5928000) at boot+0x265
:poweroff_wait(c043dbb4,c03f69c4,0,d2989a00,1) at poweroff_wait
:vn_open(d812f478,1,0,d9eff490,d812f910) at vn_open+0x40
Try removing the assertion on line 96 of kern/vfs_vnops.c and tell me
if that works. If it does I will remove the assertion permanently.
That assertion is a bit stale, I don't think it is needed any more.
Your MTU patch for DF is a pretty bad hack, we can't actually commit
that. What we probably need to do is to have IPSEC specific code to
clear the DF bit on the modified packet when the packet is modified,
rather then unconditionally clearing it in the ip_output path (which
will break TCP's mtu path discovery algorithm).
More information about the Submit