[Feature Request] Add AF_PACKET support to the socket interface

[paulbartell]

Is your feature request related to a problem? Please describe.

Linux/BSD style AF_PACKET / IPPROTO_RAW sockets are useful for implementing custom IP protocols or sending and receiving raw ethernet frames.

@evpopov filed Issue #1011 which prompted me to file this ticket.

Adding AF_PACKET sockets to FreeRTOS+TCP would allow users to extend the capabilities of FreeRTOS+TCP with their own custom protocol implementations in a relatively standard way.

Describe the solution you'd like
Add support for *nix style packet sockets ( AF_PACKET ) with SOCK_RAW and SOCK_DGRAM socket types.

Describe alternatives you've considered
Sending raw ethernet frames is currently possible by sending a eNetworkTxEvent request to FreeRTOS+TCP task, however this API is non-standard and not well documented for this purpose.

Additional context
N/A

[htibosch]

@paulbartell wrote:

@evpopov filed Issue 1011 which prompted me to file this ticket.

After reading the solution given, is there still a need for AF_PACKET / IPPROTO_RAW ?

[paulbartell]

I'm suggesting that we provide a AF_PACKET/IPPROTO_RAW socket interface in addition to the existing option.

[htibosch]

In the beginning of FreeRTOS+TCP it had support for the RAW protocol. But at this moment I wonder if the profits would be bigger that the costs. And it looks like issue 1011 is solved already.

[evpopov]

@paulbartell Maybe because I had done most of my work on Windows, I never got exposed to raw sockets and never got used to using them, but this sounds like a nice feature to have. If +TCP supported raw sockets, I absolutely would have used it in a few of my projects and the best part is that it is and older, more standardized, and well documented feature.
With that being said, I tend to agree with @htibosch that at this point in +TCP's development, maybe adding that feature is not that important. My reasoning is as follows: Once you start implementing protocols at the lower levels, you are usually getting up-close and personal with you OS and I personally wouldn't expect to be able to implement a link level protocol in a completely portable way.
Maybe I'm just getting too "set in my ways" but in those kinds of development, I had always had to deal with not only the entire frame, but also had to have complete control over which interface I'm sending and receiving from. I may be wrong, after reading this man page it appears that you can't explicitly specify the outgoing interface. I may be reading this wrong, but it looks like the OS decides on which interface to enqueue the packet with based on the destination ( ?!?! ) address. Anyways, my point is if I'm implementing things like spanning tree type protocols with their needs for per-port sending/receiving, or may be something like Profinet where I may be using multiple source MAC addresses, I don't think a raw-socket interface would provide me all what I need, so I just shrug it off and use the OS-specific tools. Again I may be wrong simple due to lack of experience with raw sockets....

Great feature request and if this ever materializes into a PR, I'd definitely support it and try to help if I can.