Herbert Xu writes:
>
> [NETFILTER]: Clear GSO bits for TCP reset packet
>
> The TCP reset packet is copied from the original. This
> includes all the GSO bits which do not apply to the new
> packet. So we should clear those bits.
>
> Spotted by Patrick McHardy.
>
> Signed-off-by: Herbert Xu <
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 08:51:58 +1100
> On Tue, Feb 13, 2007 at 12:34:13PM -0800, David Miller wrote:
> >
> > I'm kind of challenged for time as I'll be out of town from
> > Wednesday until Sunday, so if someone could cook up the TSO
> > variable of the patch f
On Tue, Feb 13, 2007 at 12:34:13PM -0800, David Miller wrote:
>
> I'm kind of challenged for time as I'll be out of town from
> Wednesday until Sunday, so if someone could cook up the TSO
> variable of the patch for pre-GSO kernels I'd appreciate it.
Sure, here is the patch for any kernel prior to
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 04:51:21 +1100
> On Tue, Feb 13, 2007 at 03:34:43PM +0100, Patrick McHardy wrote:
> >
> > The callpath shows the REJECT target sending a TCP reset.
> > I'm guessing it has something to do with skb_copy_expand
> > copying the gso fields.
>
On Tue, Feb 13, 2007 at 03:34:43PM +0100, Patrick McHardy wrote:
>
> The callpath shows the REJECT target sending a TCP reset.
> I'm guessing it has something to do with skb_copy_expand
> copying the gso fields.
Indeed. We need to reset the GSO bits there since the new
packet is nothing like the
Patrick McHardy writes:
> Herbert Xu wrote:
> > Mike Accetta <[EMAIL PROTECTED]> wrote:
> >
> >>Obviously the code believes it can assume that there are always multiple
> >>sk_buff's in the chain. The stack trace seems to implicate iptables in
> >>the scenario (twice) if that means anything. Any
Herbert Xu wrote:
> Mike Accetta <[EMAIL PROTECTED]> wrote:
>
>>Obviously the code believes it can assume that there are always multiple
>>sk_buff's in the chain. The stack trace seems to implicate iptables in
>>the scenario (twice) if that means anything. Any ideas about what may
>>be going wro
Mike Accetta <[EMAIL PROTECTED]> wrote:
>
> Obviously the code believes it can assume that there are always multiple
> sk_buff's in the chain. The stack trace seems to implicate iptables in
> the scenario (twice) if that means anything. Any ideas about what may
> be going wrong here? There is i
In 2.6.20 (and at least 2.6.19) we occasionally see a crash in
tcp_tso_segment() which looks like it is occuring because the sk_buff
chain has only a single element. Based on the register dump, the code
looks to be crashing at the statement
th = skb->h.th;
in the loop
do {
