Hello world support for UDP broadcasts over the LAN on ESP32 #5779
Conversation
caveman99
force-pushed
the
udp-broadcast
branch
from
6377265 to
f368025
Compare
src/mesh/udp/UdpMulticastThread.h
Outdated
| int32_t runOnce() override | ||
| { | ||
| canSleep = true; | ||
| // TODO: Might consider a heartbeat for discovery or keep alive? |
There was a problem hiding this comment.
I would align this with the store&forward heartbeat mechanism. Could also include a display symbol for the available transports in the long term.
src/mesh/Router.cpp
Outdated
| @@ -624,6 +630,12 @@ void Router::handleReceived(meshtastic_MeshPacket *p, RxSource src) | |||
| // After potentially altering it, publish received message to MQTT if we're not the original transmitter of the packet | |||
| if ((decoded || p_encrypted->pki_encrypted) && moduleConfig.mqtt.enabled && !isFromUs(p) && mqtt) | |||
| mqtt->onSend(*p_encrypted, *p, p->channel); | |||
| #endif | |||
| #if HAS_UDP_MULTICAST | |||
| if ((decoded || p_encrypted->pki_encrypted) && !isFromUs(p) && udpThread && | |||
There was a problem hiding this comment.
I think this logic should be different than for MQTT. The reason for MQTT it is also sending everything it receives is because MQTT is used not only for transport (bridging) but also as client. So a packet directed towards you, which is not rebroadcasted, also ends up on the MQTT server. For UDP I think we should only use onSend() when the Router sends, and thus remove the isFromUs() there.
There was a problem hiding this comment.
I was thinking about this as well. It makes sense to remove the isFromUs check
There was a problem hiding this comment.
I meant to remove isFromUs(p) from Router::send() and remove the complete block out of Router::handleReceived() (since packets received via UDP already arrive here). This way it only sends via UDP if it would via LoRa.
However, if you want it to always rebroadcast over UDP (without decrementing the hop limit, before adding yourself to the traceroute, etc.) then we could do it the same as for MQTT. So depends on whether we see this as a normal hop or more a virtual one.
|
Very cool. Eventually we could use this also for control packets like Request-To-Send to better coordinate between multiple nodes without LoRa overhead. There's some tricky things here since we have only one |
caveman99
force-pushed
the
udp-broadcast
branch
from
f368025 to
2530cda
Compare
|
Looks like this should be able to work with the RAK13800 ETH Board as well? If so, and how i am reading this PR is... ability to say join, 1-2 or 3 nodes on the same network and allow them to send the packets to/from each other to pass messages around the network? Is that the intention or just one of?
UDP Multicast wont go across "interfaces", Tailscale, doesnt support Multicast/Broadcast UDP tailscale/tailscale#11134 OpenVPN and WireGuard "kinda can" with a helper application such as https://github.com/synfinatic/udp-proxy-2020 |
Couple of remarks:
I have this hardcoded to the address
IPAddress(224, 0, 0, 69), which seems to be fine (for now). I have also pegged the port to4403because we know this port already on the TCP api side of things.I would like to test this out over something like a Tailscale VPN to see if it can work over such network boundaries potentially. I'm not too well versed in lower level socket communications, so we'll see. I'd also like to make a client proxy mode for this too, so that we can enable BLE and serial only devices to play as well.
The easiest way to test this locally is to join a couple of ESP32 nodes to your Wifi and set
lora.tx_enabledto false