Stephen Hemminger wrote:
No, the correct fix is to make IP input not accept any options from the
device.
OK.
Does this work?
Yes it does. Thank you very much.
--
Guillaume
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
M
On Fri, 14 Jul 2006 19:04:01 +0200
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote :
> > Isn't the skb owned by netem at that point...
> >
> Thank you, that makes sense to me.
> But then the loopback device reinjects the skb without cleaning skb->cb.
>
> The attached p
Stephen Hemminger wrote :
Isn't the skb owned by netem at that point...
Thank you, that makes sense to me.
But then the loopback device reinjects the skb without cleaning skb->cb.
The attached patch solves the problem for me (netem on lo). Maybe the
correct solution would be to make a skb->d
On Fri, 14 Jul 2006 16:34:30 +0200
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Is it a known problem that the Netem qdisc is very unreliable on the
> loopback (unlike on a true NIC)?
>
> This seems to come from its usage of skb->cb which conflicts with IPCB.
> For instance, the
Hello,
Is it a known problem that the Netem qdisc is very unreliable on the
loopback (unlike on a true NIC)?
This seems to come from its usage of skb->cb which conflicts with IPCB.
For instance, the field
IPCB(skb)->opt.optlen becomes non-null and memory corruption follows.
I ``worked aroun
