bert hubert wrote: > On Wed, Sep 13, 2006 at 08:44:21PM +0200, Patrick McHardy wrote: > > >>Are you using TSO on the outgoing device? If so please try to log the >>packet using iptables to see if it really is a TSO packet. > > > Good catch! I turned off TSO and things are working fine again. > > Is this a known problem, should it be documented or fixed? I'm more than > willing to write up some warnings should this be a good idea.
It appears to be intentionally, but I don't see a reason for it. Can you try if this patch makes it work as expected?
[PACKET]: Don't truncate non-linear skbs with mmaped IO Non-linear skbs are truncated to their linear part with mmaped IO. Fix by using skb_copy_bits instead of memcpy. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> --- commit 6e184976552a407c331f9b4e52b2c26fcae46ee7 tree 1bb4fc2b65179a51e795dc07908277b83cc0921a parent 9f737633e6ee54fc174282d49b2559bd2208391d author Patrick McHardy <[EMAIL PROTECTED]> Thu, 14 Sep 2006 11:59:09 +0200 committer Patrick McHardy <[EMAIL PROTECTED]> Thu, 14 Sep 2006 11:59:09 +0200 net/packet/af_packet.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index f9cef36..4172a52 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -626,8 +626,6 @@ static int tpacket_rcv(struct sk_buff *s if ((int)snaplen < 0) snaplen = 0; } - if (snaplen > skb->len-skb->data_len) - snaplen = skb->len-skb->data_len; spin_lock(&sk->sk_receive_queue.lock); h = (struct tpacket_hdr *)packet_lookup_frame(po, po->head); @@ -644,7 +642,7 @@ static int tpacket_rcv(struct sk_buff *s status &= ~TP_STATUS_LOSING; spin_unlock(&sk->sk_receive_queue.lock); - memcpy((u8*)h + macoff, skb->data, snaplen); + skb_copy_bits(skb, 0, (u8*)h + macoff, snaplen); h->tp_len = skb->len; h->tp_snaplen = snaplen;