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 common, because scapy does not pad either so any packet we build with scapy will only contains the bytes we define (eg. our process for learning remote hosts MAC address in make test is generating only Ethernet headers - 14-bytes). This cause 2 issues : 1) we do not catch bugs where we check that payload len advertised by protocols == received packet payload length. This is not very common but it happens 2) it makes make test non-deterministic: there is a lot of places (esp. in L2 code) where we assume it is safe to load & test values in the 1st 60-bytes. The assumption is correct but with current pg behavior it means we branch based on uninitialized values, so 2 identical make test runs could trigger different codepath
Does anyone see a drawback to change pg to pad pcap replay frames with 0 up to 60-bytes? Best ben
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14375): https://lists.fd.io/g/vpp-dev/message/14375 Mute This Topic: https://lists.fd.io/mt/39414067/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
