Reduce Autotalks link layer dependency

[riebl]

The current Autotalk link layer of socktap depends a lot on the Autotalks SDK which also changes its API from time to time. Due do license restrictions we cannot even compile the Autotalks link layer as part of our CI. Thus, I would like to reduce the dependency on proprietary APIs in Vanetza. For example, we could move the Autotalks code to a separate binary which exposes the V2X radio interface via UNIX domain sockets. Only the helper binary would depend on the Autotalks API then.

[riebl]

The data structure passed over the UNIX domain socket might look like this:

struct UnixDomainSocketFrame
{
    uint8_t addr_len = 6; /*< actually used bytes for source and destination addresses */
    uint8_t source_addr[6];
    uint8_t destination_addr[6];
    uint16_t data_len = 0; /*< occupied bytes in data array */
    uint8_t data[2048];
};

These fields are sufficient to replicate the existing features covered by EthernetHeader. The socktap application would connect as client to a "link layer server" which forwards the frame to the actual radio. It is up to the server to set radio specific parameters (ITS-G5, C-V2X, etc.). There may be multiple open server sockets for different purposes (different radios, different priorities, etc.).

Do you think we should add some more fields to the frame structure @khevessy?

[khevessy]

Shouldn't be the priority also somehow parameter of the transmission? Frankly it is not clear to me how this and the other radio specific parameters are set in this architecture.

[riebl]

Right, priority might also be a field of the frame. I suggest to add a uint8_t user_priority interpreted according to 802.1D. The server can then map this priority to a suitable radio-specific parameter.

Parameters not included in the frame structure need to be decided and set by the server implementation, e.g. setting them to fixed values in the simplest case. Variations not covered by frame parameters could be covered by switching the domain socket. For example, there might be a socktap.its_g5.sock (backed by an ITS-G5 radio) and a socktap.cv2x.sock (C-V2X radio).