au-ts
Figure out what to do with the ARP component
Earlier this year we removed the ARP component from the echo server example since it was not necessary since lwIP can handle all the ARP packets.
The component code is now bit-rotted and so we need to figure out whether we want to keep supporting it by at least having a test for it or a separate example, or remove it altogether.
This got raised again while I was cleaning up components to use OS-agnostic wrappers in the network class (https://github.com/au-ts/sddf/pull/491).
Is there any reason to keep the arp component files?
https://github.com/au-ts/sddf/blob/main/network/components/arp.c https://github.com/au-ts/sddf/blob/main/include/sddf/network/arp.h
At the time of making this issue I think the reason we didn't remove it was because different IP stacks may not handle ARP themselves.
It's basically a choice as to whether you assume that clients handle broadcast traffic themselves (and expect it), or whether there is a system wide broadcast traffic handler. Given that we currently multiplex based on MAC addresses, it seems that clients would expect they receive all traffic, including broadcast.
note that forwarding broadcast to clients is potentially problematic. Not only does it make the virt more complex (which may have implications on verification), as it has to refcount buffers, it may also open new attack vectors, where a malicious or buggy client hoards buffers. We shouldn't remove the ARP component unless we're convinced that this is not an issue.
Although it does add complexity, it may not be a bad idea for the virtualiser to be aware of the locations of buffers throughout the system.
Re new attack vectors, I don't believe this is true, since clients are always required to have a copy component which stops clients from being able to hoard buffers (hoarding buffers is always a problem if a copy component is not present, regardless of how we handle broadcast).