Hi all,
While working on Address Sanitizer, I realized pg pcap replay was not padding
runt frames to 60-bytes before handing them to ethernet-input. With a real NIC,
we should never get packets smaller than 60-bytes.
This means we process very short Ethernet frames in make test. It is very
comm
Hi Ben.
Isn't it amazing how timing is everything. Would you believe this issue
came up in discussion yesterday? I was suggesting the use of alternate
interfaces, such as over tap/veth/af_packet over pg in tests.
If the behavior is changed, it should probably be done in a backward
compatible way
FWIW, I recently hit a bug during a demo that I would have caught but for lack
of padding by pg in UT. In my case I had tested full spread of packet sizes
using the UT framework, but hadn't done it thoroughly enough with real
interfaces and so got bit by b->current_length > iplen with small ip p
> Unless there are real world scenarios where the device pg is emulating
> returns < 60b frames I think it would be good just to fix pg to pad. If
> code breaks based on this, wouldn't that code also break when used in
> production? :)
Packet recirculating from a tunnel (eg. ethernet inner of a vx
ganne) via Lists.Fd.Io
Sent: Tuesday, October 29, 2019 11:20 AM
To: Christian Hopps ; Paul Vinciguerra
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] pg (missing) ethernet padding
> Unless there are real world scenarios where the device pg is emulating
> returns < 60b frames I think it would be
