Networking: added CAN multicast UDP network gateway

[tridge]

This allows the PPPGW peripherals to act as CAN multicast gateways, which allows any device on the ethernet network to interact with CAN devices on the flight controllers CAN networks It also means we can configure and update the PPPGW peripherals without knowing the IP address it is configured for, as we can use DroneCAN GUI tool with interface mcast:0 or mcast:1 to get at CAN1 or CAN2 and configure parameters

This gateway is enabled in both AP_Periph with PPPGW and in the network enabled AP_Periph bootloader, which means this can also be used to update the firmware on the AP_Periph PPPGW device

This costs about 450 bytes, which comes from the change to the hal.can API to allow registration of more than one callback. We could have a new API that only appears when this option is enabled, but it would be a duplicate of the current register function, just with a new cb targets, maybe cb_mcast.

[magicrub]

You had me at update FW....

[timtuxworth]

If I run this "behind" a Raspberry PI on the plane - so not exposing the IP address of the device directly (e.g. I use a proxy to forward the web server and mavp2p to forward the mavlink traffic over a different interface), how would I forward the CAN traffic?

[tridge]

how would I forward the CAN traffic?

the multicast traffic can be fwded over the link if your IP radio allows that. I'm thinking we may need to have an option to set the TTL to 1 so it doesn't get fwded

note you can use the existing network port fwding to fwd mavlink and then use mavcan

[Ryanf55]

Setting up CAN on companion computers is hard. This is a nice alternative.

[peterbarker]

@bugobliterator is reviewing this - hopefully done soon!

[robertlong13]

This is the PR that caused the issues with DroneCAN over MAVLink described in #28175

[robertlong13]

Specifically, it was either 4a102e2f2be3f977840dd85050c74a1c4ea03ba2 or cc930bd49f1af9a1228573a87e92c84c5c8e8333