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;

Reply via email to