Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Add AF_PACKET support to the socket interface #1012

Open
paulbartell opened this issue Aug 25, 2023 · 4 comments
Open

[Feature Request] Add AF_PACKET support to the socket interface #1012

paulbartell opened this issue Aug 25, 2023 · 4 comments

Comments

@paulbartell
Copy link
Contributor

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
Copy link
Contributor

htibosch commented Aug 26, 2023

@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
Copy link
Contributor Author

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

@htibosch
Copy link
Contributor

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
Copy link
Contributor

evpopov commented Aug 29, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants