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
