Re: new problem w/workaround attached ( Re: Fixed (was Re: racoon still also broken) )

[Andrew Atrens <atrens@xxxxxxxxxxxxxxxxxx>]

4.iA5Hiv6h029287@xxxxxxxxxxxxxxxxxxxx>
User-Agent: KNode/0.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 61
NNTP-Posting-Host: 47.128.22.223
X-Trace: 1099679495 crater_reader.dragonflybsd.org 742 47.128.22.223
Xref: crater_reader.dragonflybsd.org dragonfly.submit:2050

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.