Sending custom ETH packets

[maxgr0]

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 RawSocket

In order to make this raw socket accept non-IP packets, it would require some refactoring in the following parts:

Make ip_version and ip_protocol both an Option

smoltcp/src/socket/raw.rs

Lines 87 to 88 in 57b1dd4

	ip_version: IpVersion,
	ip_protocol: IpProtocol,

Update the process and dispatch methods to check if we have version/protocol defined

smoltcp/src/socket/raw.rs

Line 341 in 57b1dd4

pub(crate) fn process(&mut self, cx: &mut Context, ip_repr: &IpRepr, payload: &[u8]) {

smoltcp/src/socket/raw.rs

Line 370 in 57b1dd4

pub(crate) fn dispatch<F, E>(&mut self, cx: &mut Context, emit: F) -> Result<(), E>

3. Create a HpgpSocket

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 #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 :)

Cheers!