Provide configuration controls for ARP and ICMP handling

[pkelsey]

Currently ARP and ICMP messages, in nearly all cases, are ignored by libuinet instances. This is a holdover from the original libuinet applications in which ARP and ICMP processing were mostly of no interest. It's time to provide libuinet applications some controls for configuring ARP and ICMP handling behavior, especially now that users are interested in running libuinet in traditional mode (non-passive, non-promiscuous sockets) where regular ARP behavior and ping responses are desirable.

This issue is commonly encountered when trying to run bin/echo with a non-promiscuous listen. For example,

./echo -i <some_interface> -l 192.0.2.1 -p 1234

The above instance won't respond to pings, and to connect to it, one has to manually make an entry for 192.0.2.1 in the arp table of the client machine.

[caladri]

I'd just amend that to note that even with a promiscuous listen, you still have to have L2 and L3 connectivity towards the host running the application, which means all of the same issues.

[pkelsey]

Agreed, wanting regular ARP and ICMP behavior is not restricted to applications using non-promiscuous listens.

I think as far as the API is concerned, it should remain the default to be silent with respect to ARP and ICMP messages, but there should be controls to modify that behavior (and ideally, be able to intervene in ARP/ICMP processing in an application specific way), and some example programs (like bin/echo) should use those controls to enable 'normal' ARP and ICMP processing.

[caladri]

Those sound like both good long-term goals and a good set of reasonable next-steps. I've always felt that a packet processor alongside libuinet is the only reasonable configuration, and I wonder whether it makes sense to do some work to provide some kind of tasting-hooking mechanism for inbound packets, and to provide some library hooks which will do things like ARP and ICMP, but also provide the ability to do funkier things. Of course, I have a lot of thoughts about what this might look like, but wanted to note that other kinds of L2 and L3 tomfoolery, and even other L4 stacks, may want to be applied alongside libuinet in the same process. (Though obviously using VALE to distribute packets to multiple TCP-only libuinet applications in different processes, and having the packet processor do the flow splitting, etc., etc., is the ultimate configuation, both for reasons of load and flexibility and ease of debugging and so on.)