From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Xr3OcodU; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 878935A0626 for ; Fri, 03 Apr 2026 12:19:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775211546; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=oCXVGrLeXcXl1YLaGmw3L8cGkfxcYi1VfO7CBNjTf28=; b=Xr3OcodUhLQ5HV/yJmwQFG1yjK3AC1V0naJUUtpda5DuLdBUCYw4DOUZGy9BVko53G9gms c487ecX1xAhhAxLzqntYc0qKOP8GfK/j/ErwiPLMEkm+Z8mUdINbKMliPMkHd1vRLEzHu3 kS6nTVVJCfQOUVpcTGp4Y+4JM6+Ug/8= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-qSIGqB1RP7Wn5Q-tYHgbxQ-1; Fri, 03 Apr 2026 06:19:05 -0400 X-MC-Unique: qSIGqB1RP7Wn5Q-tYHgbxQ-1 X-Mimecast-MFC-AGG-ID: qSIGqB1RP7Wn5Q-tYHgbxQ_1775211544 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4889099769dso14344245e9.3 for ; Fri, 03 Apr 2026 03:19:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775211544; x=1775816344; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oCXVGrLeXcXl1YLaGmw3L8cGkfxcYi1VfO7CBNjTf28=; b=fyRp4LpLjEoFXdeuUIX2WRsrdiepXrScgwDHDXxdqh+Un5i7u5BL8v+t4pjd49kvRl 2RoJltOOzVdYrT9hDXvgFJuI3co/If0ekjyzja9hYsdDIizI9wQFaUdA/BRlPeApyjdA SGbXYbrCy1DLIB57m3IuEiLwQgkXO7xEkgW9Dqe8YUJtUFV8pZ4LWUUqq9jINJ0QqQNN Dt9It23LHRzEvHoF2JFkI2ntA3JDHz5dC0y0YLnTxwLKX7Qp8u1Q4WJWkJJgVYjU6urW vwBLSBkAt7R7qp7aTQIEoXZkoHQGskJI5KaNlgHqkgzuqluV6NrXb6Gh9pd5crmwk4jV PKAw== X-Gm-Message-State: AOJu0YyxFbmFGRMughQO5S5oVjt2CP0nbJ8rJ2I2NE/gjzSNHgRDO42U gGhYr5hM6yeDSzJoIw804X8V/ZfbKlF4X7ZWxRj1Sk9wY7naFkR2cC0PsznKsJGDuXs4nELA7/A sX40WNka5o/gUroUCnqoQblZ4IYtXjC2ocim35ukEr8zBMfo7SHeeQ1fyR5H/dA== X-Gm-Gg: ATEYQzxm3c133LBJojP5NyYczW09PXXTrqu9MXcIDbtsIhaRJzkPVEOrm1YBEBYgHt1 h92kJta6hRz22QsVbaMgKTY5AgoLQqGTjM7S1YBSyIBXSY0ieBFSg1lgkIX+ZFc7kcK0vRH385i g/LBf0bTTVg11Bg1KdAOXjsUgJ0MbO0Kq5TfFf1itTyMXy5DSksdV3oLuqyn5YpRvYZqqVSF16o tIRhZ57T8xXLFOpxPR96X9DzWenUMlOm/S5zi6mf5IBBPitKFK3chb+QfAjZ9hdwXPtK7oKkXle aUAl+vTJN6WwGIZuojmQ7baeat5Sh+dDVLH5wFKvxeBriLykodOcpScavefGpJT/5yLKdxQq45b QnPq+iuOqMhkzuvKD+G4yeGq9i2xc0cPxOIbvU5Uwo9C7LcW50+EJw3g= X-Received: by 2002:a05:600c:5292:b0:47e:e2eb:bc22 with SMTP id 5b1f17b1804b1-488996e0891mr39464505e9.5.1775211543884; Fri, 03 Apr 2026 03:19:03 -0700 (PDT) X-Received: by 2002:a05:600c:5292:b0:47e:e2eb:bc22 with SMTP id 5b1f17b1804b1-488996e0891mr39464045e9.5.1775211543324; Fri, 03 Apr 2026 03:19:03 -0700 (PDT) Received: from [192.168.100.100] (82-64-211-94.subs.proxad.net. [82.64.211.94]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4889cb46adcsm30752045e9.4.2026.04.03.03.19.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Apr 2026 03:19:02 -0700 (PDT) Message-ID: <7c3a617b-3c85-42e4-a88b-1f08f1b9ab1c@redhat.com> Date: Fri, 3 Apr 2026 12:19:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 07/10] pcap: Pass explicit L2 length to pcap_iov() To: Stefano Brivio References: <20260401191826.1782394-1-lvivier@redhat.com> <20260401191826.1782394-8-lvivier@redhat.com> <20260403082032.6470b99f@elisabeth> From: Laurent Vivier Autocrypt: addr=lvivier@redhat.com; keydata= xsFNBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABzSNMYXVyZW50IFZp dmllciA8bHZpdmllckByZWRoYXQuY29tPsLBeAQTAQIAIgUCVgVQgAIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AACgkQ8ww4vT8vvjwpgg//fSGy0Rs/t8cPFuzoY1cex4limJQfReLr SJXCANg9NOWy/bFK5wunj+h/RCFxIFhZcyXveurkBwYikDPUrBoBRoOJY/BHK0iZo7/WQkur 6H5losVZtrotmKOGnP/lJYZ3H6OWvXzdz8LL5hb3TvGOP68K8Bn8UsIaZJoeiKhaNR0sOJyI YYbgFQPWMHfVwHD/U+/gqRhD7apVysxv5by/pKDln1I5v0cRRH6hd8M8oXgKhF2+rAOL7gvh jEHSSWKUlMjC7YwwjSZmUkL+TQyE18e2XBk85X8Da3FznrLiHZFHQ/NzETYxRjnOzD7/kOVy gKD/o7asyWQVU65mh/ECrtjfhtCBSYmIIVkopoLaVJ/kEbVJQegT2P6NgERC/31kmTF69vn8 uQyW11Hk8tyubicByL3/XVBrq4jZdJW3cePNJbTNaT0d/bjMg5zCWHbMErUib2Nellnbg6bc 2HLDe0NLVPuRZhHUHM9hO/JNnHfvgiRQDh6loNOUnm9Iw2YiVgZNnT4soUehMZ7au8PwSl4I KYE4ulJ8RRiydN7fES3IZWmOPlyskp1QMQBD/w16o+lEtY6HSFEzsK3o0vuBRBVp2WKnssVH qeeV01ZHw0bvWKjxVNOksP98eJfWLfV9l9e7s6TaAeySKRRubtJ+21PRuYAxKsaueBfUE7ZT 7zfOwU0EVgUmGQEQALxSQRbl/QOnmssVDxWhHM5TGxl7oLNJms2zmBpcmlrIsn8nNz0rRyxT 460k2niaTwowSRK8KWVDeAW6ZAaWiYjLlTunoKwvF8vP3JyWpBz0diTxL5o+xpvy/Q6YU3BN efdq8Vy3rFsxgW7mMSrI/CxJ667y8ot5DVugeS2NyHfmZlPGE0Nsy7hlebS4liisXOrN3jFz asKyUws3VXek4V65lHwB23BVzsnFMn/bw/rPliqXGcwl8CoJu8dSyrCcd1Ibs0/Inq9S9+t0 VmWiQWfQkz4rvEeTQkp/VfgZ6z98JRW7S6l6eophoWs0/ZyRfOm+QVSqRfFZdxdP2PlGeIFM C3fXJgygXJkFPyWkVElr76JTbtSHsGWbt6xUlYHKXWo+xf9WgtLeby3cfSkEchACrxDrQpj+ Jt/JFP+q997dybkyZ5IoHWuPkn7uZGBrKIHmBunTco1+cKSuRiSCYpBIXZMHCzPgVDjk4viP brV9NwRkmaOxVvye0vctJeWvJ6KA7NoAURplIGCqkCRwg0MmLrfoZnK/gRqVJ/f6adhU1oo6 z4p2/z3PemA0C0ANatgHgBb90cd16AUxpdEQmOCmdNnNJF/3Zt3inzF+NFzHoM5Vwq6rc1JP jfC3oqRLJzqAEHBDjQFlqNR3IFCIAo4SYQRBdAHBCzkM4rWyRhuVABEBAAHCwV8EGAECAAkF AlYFJhkCGwwACgkQ8ww4vT8vvjwg9w//VQrcnVg3TsjEybxDEUBm8dBmnKqcnTBFmxN5FFtI WlEuY8+YMiWRykd8Ln9RJ/98/ghABHz9TN8TRo2b6WimV64FmlVn17Ri6FgFU3xNt9TTEChq AcNg88eYryKsYpFwegGpwUlaUaaGh1m9OrTzcQy+klVfZWaVJ9Nw0keoGRGb8j4XjVpL8+2x OhXKrM1fzzb8JtAuSbuzZSQPDwQEI5CKKxp7zf76J21YeRrEW4WDznPyVcDTa+tz++q2S/Bp P4W98bXCBIuQgs2m+OflERv5c3Ojldp04/S4NEjXEYRWdiCxN7ca5iPml5gLtuvhJMSy36gl U6IW9kn30IWuSoBpTkgV7rLUEhh9Ms82VWW/h2TxL8enfx40PrfbDtWwqRID3WY8jLrjKfTd R3LW8BnUDNkG+c4FzvvGUs8AvuqxxyHbXAfDx9o/jXfPHVRmJVhSmd+hC3mcQ+4iX5bBPBPM oDqSoLt5w9GoQQ6gDVP2ZjTWqwSRMLzNr37rJjZ1pt0DCMMTbiYIUcrhX8eveCJtY7NGWNyx FCRkhxRuGcpwPmRVDwOl39MB3iTsRighiMnijkbLXiKoJ5CDVvX5yicNqYJPKh5MFXN1bvsB kmYiStMRbrD0HoY1kx5/VozBtc70OU0EB8Wrv9hZD+Ofp0T3KOr1RUHvCZoLURfFhSQ= In-Reply-To: <20260403082032.6470b99f@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: BnvVbRp0RLLK-J5cXnUMrGi2rwDVdfIfm-5Fi1JwHrA_1775211544 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: D2GPI3VYUWC3CZSB3CNEQMDDHLLHDJ4Y X-Message-ID-Hash: D2GPI3VYUWC3CZSB3CNEQMDDHLLHDJ4Y X-MailFrom: lvivier@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 4/3/26 08:20, Stefano Brivio wrote: > On Wed, 1 Apr 2026 21:18:23 +0200 > Laurent Vivier wrote: > >> With vhost-user multibuffer frames, the iov can be larger than the >> actual L2 frame. The previous approach of computing L2 length as >> iov_size() - offset would overcount and write extra bytes into the >> pcap file. >> >> Pass the L2 frame length explicitly to pcap_frame() and pcap_iov(), >> and write exactly that many bytes instead of the full iov remainder. >> >> Signed-off-by: Laurent Vivier >> --- >> pcap.c | 37 ++++++++++++++++++++++++++++--------- >> pcap.h | 2 +- >> tap.c | 2 +- >> tcp_vu.c | 9 ++++++--- >> udp_vu.c | 4 +++- >> vu_common.c | 2 +- >> 6 files changed, 40 insertions(+), 16 deletions(-) >> >> diff --git a/pcap.c b/pcap.c >> index a026f17e7974..dfe1c61add9a 100644 >> --- a/pcap.c >> +++ b/pcap.c >> @@ -52,22 +52,38 @@ struct pcap_pkthdr { >> * @iov: IO vector containing frame (with L2 headers and tap headers) >> * @iovcnt: Number of buffers (@iov entries) in frame >> * @offset: Byte offset of the L2 headers within @iov >> + * @l2len: Length of L2 frame data to capture >> * @now: Timestamp >> */ >> static void pcap_frame(const struct iovec *iov, size_t iovcnt, >> - size_t offset, const struct timespec *now) >> + size_t offset, size_t l2len, const struct timespec *now) >> { >> - size_t l2len = iov_size(iov, iovcnt) - offset; >> struct pcap_pkthdr h = { >> .tv_sec = now->tv_sec, >> .tv_usec = DIV_ROUND_CLOSEST(now->tv_nsec, 1000), >> .caplen = l2len, >> .len = l2len >> }; >> + size_t i; >> >> - if (write_all_buf(pcap_fd, &h, sizeof(h)) < 0 || >> - write_remainder(pcap_fd, iov, iovcnt, offset) < 0) >> - debug_perror("Cannot log packet, length %zu", l2len); >> + if (write_all_buf(pcap_fd, &h, sizeof(h)) < 0) { >> + debug_perror("Cannot log packet, packet header error"); >> + return; >> + } >> + >> + for (i = iov_skip_bytes(iov, iovcnt, offset, &offset); >> + i < iovcnt && l2len; i++) { >> + size_t n = MIN(l2len, iov[i].iov_len - offset); >> + >> + if (write_all_buf(pcap_fd, (char *)iov[i].iov_base + offset, >> + n) < 0) { > > This could be written as: > > size_t l = MIN(l2len, iov[i].iov_len - offset), n; > > n = write_all_buf(pcap_fd, (char *)iov[i].iov_base + offset, l); > if (n < 0) { > > same number of lines, but slightly clearer I think. > >> + debug_perror("Cannot log packet"); > > Should we add back the ", length %zu" part, perhaps, using this 'l' > variable? I think it makes a difference if we see we're failing to > capture a reasonably sized 64k packet (disk full or something) compared > to a 100G-length buffer coming from some calculation gone wrong. > >> + return; >> + } >> + >> + offset = 0; >> + l2len -= n; >> + } >> } >> >> /** >> @@ -87,7 +103,7 @@ void pcap(const char *pkt, size_t l2len) >> if (clock_gettime(CLOCK_REALTIME, &now)) >> err_perror("Failed to get CLOCK_REALTIME time"); >> >> - pcap_frame(&iov, 1, 0, &now); >> + pcap_frame(&iov, 1, 0, l2len, &now); >> } >> >> /** >> @@ -110,7 +126,9 @@ void pcap_multiple(const struct iovec *iov, size_t frame_parts, unsigned int n, >> err_perror("Failed to get CLOCK_REALTIME time"); >> >> for (i = 0; i < n; i++) >> - pcap_frame(iov + i * frame_parts, frame_parts, offset, &now); >> + pcap_frame(iov + i * frame_parts, frame_parts, offset, > > Nit: curly brackets for coding style. > >> + iov_size(iov + i * frame_parts, frame_parts) - offset, >> + &now); >> } >> >> /** >> @@ -120,8 +138,9 @@ void pcap_multiple(const struct iovec *iov, size_t frame_parts, unsigned int n, >> * containing packet data to write, including L2 header >> * @iovcnt: Number of buffers (@iov entries) >> * @offset: Offset of the L2 frame within the full data length >> + * @l2len: Length of L2 frame data to capture >> */ >> -void pcap_iov(const struct iovec *iov, size_t iovcnt, size_t offset) >> +void pcap_iov(const struct iovec *iov, size_t iovcnt, size_t offset, size_t l2len) >> { >> struct timespec now = { 0 }; >> >> @@ -131,7 +150,7 @@ void pcap_iov(const struct iovec *iov, size_t iovcnt, size_t offset) >> if (clock_gettime(CLOCK_REALTIME, &now)) >> err_perror("Failed to get CLOCK_REALTIME time"); >> >> - pcap_frame(iov, iovcnt, offset, &now); >> + pcap_frame(iov, iovcnt, offset, l2len, &now); >> } >> >> /** >> diff --git a/pcap.h b/pcap.h >> index dface5df4ee6..c171257cbd73 100644 >> --- a/pcap.h >> +++ b/pcap.h >> @@ -13,7 +13,7 @@ extern int pcap_fd; >> void pcap(const char *pkt, size_t l2len); >> void pcap_multiple(const struct iovec *iov, size_t frame_parts, unsigned int n, >> size_t offset); >> -void pcap_iov(const struct iovec *iov, size_t iovcnt, size_t offset); >> +void pcap_iov(const struct iovec *iov, size_t iovcnt, size_t offset, size_t l2len); >> void pcap_init(struct ctx *c); >> >> #endif /* PCAP_H */ >> diff --git a/tap.c b/tap.c >> index b61199dd699d..007c91864b4e 100644 >> --- a/tap.c >> +++ b/tap.c >> @@ -1105,7 +1105,7 @@ void tap_add_packet(struct ctx *c, struct iov_tail *data, >> struct ethhdr eh_storage; >> const struct ethhdr *eh; >> >> - pcap_iov(data->iov, data->cnt, data->off); >> + pcap_iov(data->iov, data->cnt, data->off, iov_tail_size(data)); > > This leads to a warning from Coverity Scan: > > /home/sbrivio/passt/tap.c:1108:2: > Type: Evaluation order violation (EVALUATION_ORDER) > > /home/sbrivio/passt/tap.c:1108:2: > read_write_order: In argument #4 of "pcap_iov(data->iov, data->cnt, data->off, iov_tail_size(data))", a call is made to "iov_tail_size(data)". In argument #1 of this function, the object "data->off" is modified. This object is also used in "data->off", the argument #3 of the outer function call. The order in which these arguments are evaluated is not specified, and will vary between platforms. > > I'm not sure if we can ever reach this point with a non-pruned iov_tail > so that iov_tail_prune() will actually modify 'off', but just to be > sure I guess we should call iov_tail_size() first, assign its result to > a temporary variable, and use that. In fact, iov_size() will not change after pruning. The couple (cnt, off) will always point to the same offset (but cnt can be higher and off lower). >> >> eh = IOV_PEEK_HEADER(data, eh_storage); >> if (!eh) >> diff --git a/tcp_vu.c b/tcp_vu.c >> index 0cd01190d612..329fa969fca1 100644 >> --- a/tcp_vu.c >> +++ b/tcp_vu.c >> @@ -143,7 +143,8 @@ int tcp_vu_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) >> vu_flush(vdev, vq, flags_elem, 1); >> >> if (*c->pcap) >> - pcap_iov(&flags_elem[0].in_sg[0], 1, VNET_HLEN); >> + pcap_iov(&flags_elem[0].in_sg[0], 1, VNET_HLEN, >> + hdrlen + optlen - VNET_HLEN); > > Same here, curly brackets. > >> >> if (flags & DUP_ACK) { >> elem_cnt = vu_collect(vdev, vq, &flags_elem[1], 1, >> @@ -159,7 +160,8 @@ int tcp_vu_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) >> vu_flush(vdev, vq, &flags_elem[1], 1); >> >> if (*c->pcap) >> - pcap_iov(&flags_elem[1].in_sg[0], 1, VNET_HLEN); >> + pcap_iov(&flags_elem[1].in_sg[0], 1, VNET_HLEN, >> + hdrlen + optlen - VNET_HLEN); > > And here. > >> } >> } >> vu_queue_notify(vdev, vq); >> @@ -464,7 +466,8 @@ int tcp_vu_data_from_sock(const struct ctx *c, struct tcp_tap_conn *conn) >> vu_flush(vdev, vq, &elem[head[i]], buf_cnt); >> >> if (*c->pcap) >> - pcap_iov(iov, buf_cnt, VNET_HLEN); >> + pcap_iov(iov, buf_cnt, VNET_HLEN, >> + dlen + hdrlen - VNET_HLEN); > > And here too. > >> >> conn->seq_to_tap += dlen; >> } >> diff --git a/udp_vu.c b/udp_vu.c >> index 5421a7d71a19..81491afa7e6a 100644 >> --- a/udp_vu.c >> +++ b/udp_vu.c >> @@ -185,6 +185,7 @@ void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx) >> static struct iovec iov_vu[VIRTQUEUE_MAX_SIZE]; >> struct vu_dev *vdev = c->vdev; >> struct vu_virtq *vq = &vdev->vq[VHOST_USER_RX_QUEUE]; >> + size_t hdrlen = udp_vu_hdrlen(v6); >> int i; >> >> assert(!c->no_udp); >> @@ -230,7 +231,8 @@ void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx) >> size_t l4len = udp_vu_prepare(c, iov_vu, toside, dlen); >> if (*c->pcap) { >> udp_vu_csum(toside, iov_vu, iov_cnt, l4len); >> - pcap_iov(iov_vu, iov_cnt, VNET_HLEN); >> + pcap_iov(iov_vu, iov_cnt, VNET_HLEN, >> + hdrlen + dlen - VNET_HLEN); > > And here as well. Or maybe, in all those cases, we could have a 'size' > temporary variable which should make things a bit more obvious. I agree Thanks, Laurent