This is missing logic:
- report average
- don't bother reporting if the results are negligeable
- praise the user if it's improving the situation
- shame the user if it's not improving the situation
* udp-multicast: remove the thread from the multicast thread API
The whole API is parallel & asynchronous we don't need to start a thread ourself,
the implementation probably does when we call start listening already.
* Take copilot advice and call it a handler
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
* cleanup UdpMulticastThread.h preprocessor rules a tiny bit
* bump platform-native to allow for multiple multicast listeners on the same machine
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
* Add UDP multicast support on linux.
Closes#6326
We tested it an it works.
This is really hacky to say the least.
* Add libuv to Linux packaging
* Trunkadunk
* Correct ref
* Add libuv1-dev to setup-native
---------
Co-authored-by: vidplace7 <vidplace7@gmail.com>
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
Since 96ba94843b we don't spray packets to all machines on the network.
So we can allow ourself to raise the TTL limit, this allows users who run L3 IGMP Routing infrastructure to pass meshtastic frames over UDP.
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
The packet.readBytes API is not available on all targets:
- RP2040 & RP2340
- yet to be written portduino API
Instead pass the data buffer as-is.
It also removes a memcpy which do not need to exists.
I've tested it successfully on a tbeam.
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
A smart router or switch is able to snoop the multicast address to
only send the packets to nodes listening on the multicast address.
Before all machines reachable on the L2 layer would receive the packet.
From the manpage:
> arch - print machine hardware name (same as uname -m)
Arch Linux does not have the `arch` alias, only `uname`, so use `uname` to fix this issue:
> ```
> ./bin/build-native.sh: line 18: arch: command not found
> ```
Co-authored-by: Jonathan Bennett <jbennett@incomsystems.biz>
Jorropo
