Pico W Multicast API differences vs. standard Ethernet APIs

[sstaub]

When I have a look to the Wifi library I found some weirdness in WIFIUdp.h
Multicast starts with:
uint8_t beginMulticast(IPAddress interfaceAddr, IPAddress multicast, uint16_t port);
that is different to all other libraries which use
virtual uint8_t beginMulticast(IPAddress, uint16_t);
The interfaceAddr is the the local Ip and shouldn't extra configured.

There is also a extra function for begin sending Multicast

virtual int beginPacketMulticast(IPAddress multicastAddress,
                                     uint16_t port,
                                     IPAddress interfaceAddress,
                                     int ttl = 1);

This extra function is normal also not necessary and wrong. The interfaceAddress is given by local ip.
ttl = 1 (time to life) is wrong, you should use the given standard by lwip (I think it is 256).
At least ttl = 1 says the packet dies after one hop.
Here also normally you use
virtual int beginPacket(IPAddress ip, uint16_t port);

[earlephilhower]

I'm by no means a TCP/IP expert, so thanks for the input. FWIW this code was copied from the ESP8266 core where the current functions do seem to be working properly. In the OTA patch, in fact, I've added mDNS which I believe uses multicast, and at least there it's functional.

Or are you suggesting the API is not matching other (non-ESP) WiFi/Ethernet libraries?

Maybe you could submit a PR with your changes, to make it clearer the concern you're having? (And make it easier to fix 😄 )

[sstaub]

Hope I will find some time for it. I need to dig in deeper because I'm not using lwip causing many other problems.
The API is used for following libraries: Ethernet, Ethernet3 (my own library), WIFINna, STM32Ethernet (lwip based) and others.

[oddstr13]

The ESP8266 core is weird and non-standard in many ways, and often requires special-casing in the precompiler to deal with.
It is not unlikely that the mentioned libraries are checking for the presence of ESP8266, and not being aware of this core having copied that API.

It might be desirable to look at the ESP32 core, as I think that one is more Arduino standard, or other cores/libraries implementing IP networking.

[earlephilhower]

Alas, I’m more familiar with the 8266 since I’ve been a maintainer there for years. I’ve tried to undo the weirdness that has crept in to the API(normally for good reasons, or because we were the first to do something), but the LWIP side of things I never really looked at.

Is this just saying the API here needs to be fixed, or that the actual implementation is broken aside from the API issues?

[oddstr13]

I'm not that familliar with the recent changes in the 8266 or Arduino in general, as I haven't been doing much arduino stuff the past few years. Getting back into it a little now, as this core looked like an easy way to get started with the PicoW, and I already had config management for the ESP8266 from an older project.

I have spotted some weirdness in rhe implementation for setting the multicast output interface for IPv6 packets, but that shouldn't really matter before there are several interfaces in play.

It should be trivial to implement the beginMulticast(ip, port), as LWIP can figure out which interface it's supposed to go out, at least for IPv6.

Do we currently have AP+STA? If not, the multicast routing stuff might not even matter all that much at the moment.

[earlephilhower]

Do we currently have AP+STA? If not, the multicast routing stuff might not even matter all that much at the moment.

No, AP+STA is not supported by the CYW43 driver. Not sure if it's just a driver issue or if the chip can't actually do it.

[earlephilhower]

@sstaub As I said, I'm no UDP expert but I think I see the reason for the extra IP addresses in the function prototypes. The ESP8266 (and this core, eventually) allows more than one network interface(say, AP + STA routing). So it is possible that there are multiple "local IPs" hence the option. I believe IP_ADDR_ANY as a default might just do the trick in single and multiple interfaces mode.

Is there some example that I could try any changes on using the original Arduino APIs?

[sstaub]

@earlephilhower Ok I understood the problem with multiple Interfaces.
Maybe there should an overloaded multicastBegin() function using the 'IP_ADDR_ANY' and TTL=255
inside the function.

_ctx->setMulticastInterface(interfaceAddress);
_ctx->setMulticastTTL(ttl);

in the function, so it should possible to use beginPacket() instead beginPaketMulticast().
maybe this function will work:

uint8_t WiFiUDP::beginMulticast(IPAddress multicast, uint16_t port, int ttl = 255) {
    if (_ctx) {
        _ctx->unref();
        _ctx = 0;
    }

    _ctx->setMulticastInterface(IP_ADDR_ANY);
    _ctx->setMulticastTTL(ttl);

    if (igmp_joingroup(IP_ADDR_ANY, multicast) != ERR_OK) {
        return 0;
    }

    _ctx = new UdpContext;
    _ctx->ref();
    ip_addr_t addr = IPADDR4_INIT(INADDR_ANY);
    if (!_ctx->listen(&addr, port)) {
        return 0;
    }

    return 1;
}

I worked on multicast library for sACN (DMX lighting protocol) some years ago but must be rewrite.
In the moment I have no time for this because of my regular job.
So a short explanation what beginMulticast() do, is that the multicast address must join an igmp(v2) multicast group.therefore the multicast address must in a valid range 224.0.0.0 thru 239.255.255.255
The sending and receiving is like a normal UDP packet and you can use any UDP example with small changes for the multicast address. Sending and receiving UDP is much simpler than TCP because it works without any connection handling.
For testing connections I use https://packetsender.com
Hope this helps