Re: new problem w/workaround attached ( Re: Fixed (was Re: racoo
Matthew Dillon wrote:
> :Hey Jeff,
> :
> :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
> :db> trace
> :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
> :ndis_open_file(d812f924,d812f90c,d812f910,d812f918,ffffffff) at
>
> 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.
Yes, that fixed it :)
>
> 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
I understand. It was just a very, very simple-minded workaround. I suppose
it was useful in that it validated my hypothesis about what was happening.
> 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).
Jeff emailed me before hopping on a plane a week or so ago - he said that
he'd have a look at it. I'm sure that he can craft the right fix :) :) ...
In retrospect I suppose I should have posted to bugs, not submit, but I was
following the thread on ipsec issues we started a while back ...
Cheers,
Andrew.
討論串 (同標題文章)
完整討論串 (本文為第 4 之 4 篇)：