From: Paul Jakma <[EMAIL PROTECTED]>
Date: Wed, 10 May 2006 21:17:33 +0100 (IST)
> On Wed, 10 May 2006, David S. Miller wrote:
>
> > When you have a rule installed that will add MD5, just mark the
> > route as not being TSO capable.
>
> Ah, didn't realise this could be done with netfilter. What
On Wed, 10 May 2006, David S. Miller wrote:
When you have a rule installed that will add MD5, just mark the
route as not being TSO capable.
Ah, didn't realise this could be done with netfilter. What's the
magic incantation? :)
What's the problem?
None, that's perfect - we just didn't kno
From: Paul Jakma <[EMAIL PROTECTED]>
Date: Wed, 10 May 2006 21:07:31 +0100 (IST)
> Is there a better way to deal with TSO besides documenting:
>
> "disable TSO on all interfaces which /ever/ potentially could be used
> to reach TCP-MD5 authenticated BGP peers."
>
> ?
When you have a rule inst
On Wed, 10 May 2006, David S. Miller wrote:
This is by design. Netfilter looks at full TSO frames,
That explains it.
Once you add MD5 checksums to the TCP packet, TSO can no longer be
used on that path, so you'll have to disable TSO either in the
route or via some other means.
Ok.
Is th
From: Chris Caputo <[EMAIL PROTECTED]>
Date: Wed, 10 May 2006 18:44:30 + (GMT)
> Does this sound like a bug or by design?
>
> Does it make sense that ip_queue mangled packets be subjected to TSO,
> given that the TCP header can be messed with by the user mode code?
This is by design. Netfi
Environment is 2.6.16.9 with e1000 NICs.
Paul and I (as part of the Quagga project) are working on a user mode
method for doing BGP MD5 checksums using ip_queue. All is working except
when TSO is enabled I am seeing some problems.
It appears that when TSO is enabled, ip_queue can be used to ma
