"Sending" a 0-length packet on an Ethernet interface is not something I have ever heard of anyone wanting to do. If someone wants some kind of "event packet", they just create a short packet with at least one header in it.
There are corner-case test programs for p4c that p4testgen generates input packets and expected output packets, where this can happen.
While recently testing one of these programs using p4testgen, as part of p4c's CI test suite, on an Ubuntu 24.04 system, I encountered a BMv2 crash due to an assert statement firing while running such a test. p4lang/p4c#5130
For a while now, when p4testgen generates such a test, it replaces the 0-length output packet with a 4-byte packet having contents 02000000 in hexadecimal, because many Ubuntu Linux systems apparently have a behavior in BMv2 and/or its pcap library that cause it to send a 0-length packet as that particular 4-byte packet.
If it is true that this was a pcap library bug, and that it has been fixed in Ubuntu 24.04, these p4c tests will begin failing once p4c CI has been enabled for Ubuntu 24.04.
The recommendation I am giving here is NOT high priority. It is a corner-case check for something that I don't expect to happen in real production systems, but seems useful for enabling some of these funkier p4testgen cases to continue working (with a small corresponding change in p4testgen): modify BMv2 so that if a 0-length packet with 0 unparsed bytes is output by the deparser, drop it. No 0-length packet should ever be sent to an output port, nor recirculated. If logging is enabled, there should be a message in the log that such a packet was encountered and it is being dropped, as an aid to those debugging the behavior.
"Sending" a 0-length packet on an Ethernet interface is not something I have ever heard of anyone wanting to do. If someone wants some kind of "event packet", they just create a short packet with at least one header in it.
There are corner-case test programs for p4c that p4testgen generates input packets and expected output packets, where this can happen.
While recently testing one of these programs using p4testgen, as part of p4c's CI test suite, on an Ubuntu 24.04 system, I encountered a BMv2 crash due to an assert statement firing while running such a test. p4lang/p4c#5130
For a while now, when p4testgen generates such a test, it replaces the 0-length output packet with a 4-byte packet having contents
02000000in hexadecimal, because many Ubuntu Linux systems apparently have a behavior in BMv2 and/or its pcap library that cause it to send a 0-length packet as that particular 4-byte packet.If it is true that this was a pcap library bug, and that it has been fixed in Ubuntu 24.04, these p4c tests will begin failing once p4c CI has been enabled for Ubuntu 24.04.
The recommendation I am giving here is NOT high priority. It is a corner-case check for something that I don't expect to happen in real production systems, but seems useful for enabling some of these funkier p4testgen cases to continue working (with a small corresponding change in p4testgen): modify BMv2 so that if a 0-length packet with 0 unparsed bytes is output by the deparser, drop it. No 0-length packet should ever be sent to an output port, nor recirculated. If logging is enabled, there should be a message in the log that such a packet was encountered and it is being dropped, as an aid to those debugging the behavior.