We have the requirement to send/receive ethernet frames with a custom type/protocol for HomePlug AV (0x88e1). Using a raw socket does not really work as it drops packets which are neither IPv4 or IPv6.
At the moment, we use smoltcp v0.11.0 through embassy-net in an embedded device.
In my view, there are multiple possible solutions to the issue:
1. Directly talk to the ETH device
This would work in theory and we already verified that this works. The problem here is that we also need to expose an IPv6 socket for follow-up communication (after the HomePlug matching procedure is done) and its a way better solution to use this amazing library instead of crafting something ourselves.
Another possible combination is that we first talk directly with the ETH device and then spin up our IPv6 socket using smoltcp. This actually runs into timing issues as we then might receive some packets on IPv6 before the IPv6 socket is created.
2. Refactor the RawSocket
In order to make this raw socket accept non-IP packets, it would require some refactoring in the following parts:
This would mean to create an entire new socket with all validation and features to be fully compliant with the HomePlug AV protocol. From the number of changes and complexity/effort most probably similar to https://github.com/smoltcp-rs/smoltcp/pull/902 so also a lot of effort for the maintainers to review as its kinda specific.
4. Create a CustomSocket
This is similar to the third option above but might not require so much specific knowledge for reviewing as the user could just specify e.g. an ether_type and the routing will be based on this while putting the validation and "handling" of packets to the user.
Summary
Overall it would be really nice to get this sorted out with the best-possible outcome while not stressing the maintainers more than needed with reviews and so on.
If we agree on a direction we could work on a PR over here and submit it or we can also sponsor this ticket to be solved - the second option here is most probably faster but totally depending on capacity. I'am also in the matrix channel for any questions :)
Description
We have the requirement to send/receive ethernet frames with a custom type/protocol for HomePlug AV (
0x88e1). Using a raw socket does not really work as it drops packets which are neither IPv4 or IPv6. At the moment, we use smoltcp v0.11.0 through embassy-net in an embedded device.In my view, there are multiple possible solutions to the issue:
1. Directly talk to the ETH device
This would work in theory and we already verified that this works. The problem here is that we also need to expose an IPv6 socket for follow-up communication (after the HomePlug matching procedure is done) and its a way better solution to use this amazing library instead of crafting something ourselves.
Another possible combination is that we first talk directly with the ETH device and then spin up our IPv6 socket using smoltcp. This actually runs into timing issues as we then might receive some packets on IPv6 before the IPv6 socket is created.
2. Refactor the
RawSocketIn order to make this raw socket accept non-IP packets, it would require some refactoring in the following parts:
Make
ip_versionandip_protocolboth anOptionhttps://github.com/smoltcp-rs/smoltcp/blob/57b1dd4b158327c31edebd3260d90bf5c3b1452d/src/socket/raw.rs#L87-L88Update the
processanddispatchmethods to check if we have version/protocol defined https://github.com/smoltcp-rs/smoltcp/blob/57b1dd4b158327c31edebd3260d90bf5c3b1452d/src/socket/raw.rs#L341https://github.com/smoltcp-rs/smoltcp/blob/57b1dd4b158327c31edebd3260d90bf5c3b1452d/src/socket/raw.rs#L370
3. Create a
HpgpSocketThis would mean to create an entire new socket with all validation and features to be fully compliant with the HomePlug AV protocol. From the number of changes and complexity/effort most probably similar to https://github.com/smoltcp-rs/smoltcp/pull/902 so also a lot of effort for the maintainers to review as its kinda specific.
4. Create a
CustomSocketThis is similar to the third option above but might not require so much specific knowledge for reviewing as the user could just specify e.g. an
ether_typeand the routing will be based on this while putting the validation and "handling" of packets to the user.Summary
Overall it would be really nice to get this sorted out with the best-possible outcome while not stressing the maintainers more than needed with reviews and so on. If we agree on a direction we could work on a PR over here and submit it or we can also sponsor this ticket to be solved - the second option here is most probably faster but totally depending on capacity. I'am also in the matrix channel for any questions :)
Cheers!