IPAddress for Gen3 UDP

Troubleshooting
1

Hello,

I’m wondering why this:

static IPAddress remoteIP(192, 168, 0, 1);

doesn’t work (results in -1 from .sendPacket()), yet from the post: Sending data with mesh devices this works fine:

const uint8_t remoteAddr[33] = {0x00, 0x64, 0xff, 0x9b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 192, 168, 0, 1, 6};
static IPAddress remoteIP((const HAL_IPAddress&)remoteAddr);
2

The mesh uses IPv6.

3

Okay, I get that. Conceptually though when sending UDP it doesn’t seem like I should have to know if the mesh is using IPv6 or even a non-IP protocol. I know my gateway has an IPv4 address, and is hooked in to a non-IPv6 network. When I .sendPacket() to an external IP address I’m expecting that I’m sending that packet out of the gateway. I’m not thinking of how it gets routed to a gateway.

Perhaps I see it in a strange way, but I suspect others might as well. The Mesh is like one big device to me. I don’t really need to know how it’s connect, just that it is. I can send messages between nodes with the Mesh. class, and messages out of the Mesh with UDP/TCP. Imagine Particle decides that IPv6 isn’t working and they switch to EzIP, should that break all my UDP/TCP code?

At the very least the docs should be updated, as the code they show doesn’t work in https://docs.particle.io/reference/device-os/firmware/xenon/#sendpacket-. It would be nice to have some big warnings on that that IPv4 address will not work from a non-gateway node (will they work from a gateway node? can the gateway also use the ipv6 version? see how having to know the internals of the mesh routing raises my cognitive load?)

4

In testing it seems that I have to flash a different firmware to my gateway than I can flash to my other nodes to get ipv4 address to work.