On Thu, Jan 28, 2016 at 06:14:45PM +, Nicolas Pernas Maradei wrote:
> Hi Dror,
>
> Good catch. What you are saying makes sense and it is also explained in
> pcap's documentation. Was your setup unusual though?
> This might sound like a silly question but I don't remember seeing that
> issue an
Hi,
I'm just adding the Acked-by line to the patch. Apologise I missed that one
earlier.
Nico.
On 28/01/16 11:09, Dror Birkman wrote:
> The actual captured length is header.caplen, whereas header.len is
> the original length on the wire.
>
> Signed-off-by: Dror Birkman
> Acked-by: Nicolas Per
On Thu, Jan 28, 2016 at 06:14:45PM +, Nicolas Pernas Maradei wrote:
> Hi Dror,
>
> Good catch. What you are saying makes sense and it is also explained in
> pcap's documentation. Was your setup unusual though?
> This might sound like a silly question but I don't remember seeing that
> issue an
Hi Nicolas,
Thanks.
I tried to test my application with a pcap file I had, but got weird
results, so I wrote back the rte_mbufs in pcap format and hex compared it
to my input pcap. Only then I noticed that my original pcap had frames that
were captured with a length smaller than the frame length.
Hi Dror,
Good catch. What you are saying makes sense and it is also explained in
pcap's documentation. Was your setup unusual though?
This might sound like a silly question but I don't remember seeing that
issue and I should have since your fix is correct.
Nico.
On 28/01/16 11:09, Dror Birkman
The actual captured length is header.caplen, whereas header.len is
the original length on the wire.
Signed-off-by: Dror Birkman
---
Without this fix, if the captured length is smaller than the original
length on the wire, mbuf will contain incorrect data.
drivers/net/pcap/rte_eth_pcap.c | 12
6 matches
Mail list logo
