Bug in EDP multicast example (IPv4 + IPv6)? - Mapped address wrong (IDFGH-8200)

[hurricanefrog]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v4.4.2

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

PowerShell

Development Kit.

Custom Board (Olimex ESP32-POE based)

Power Supply used.

External 3.3V

What is the expected behavior?

Using the UDP Multicast example:
https://github.com/espressif/esp-idf/tree/master/examples/protocols/sockets/udp_multicast

With the configuration of Multicast IP type: IPv4 & IPv6, Obtain IPv6 address enabled and Preferred IPv6 Type set to "Local Link Address`. the (mapped?) IPv4 packets don't appear in Wireshark, and a socat instance running on a different machine in UDP multicast listener mode (as per README) doesn't receive anything.

Apparently, getaddrinfo returns something unexpected. The log should say it sends to ffff:232.10.11.12 (verified with a quick cygwin program which calls getaddrinfo)

What is the actual behavior?

Log says the IPv6-mapped-IPv4 address is :: (see log below).

Steps to reproduce.

1. Configure the example examples/protocols/sockets as above
2. Compile, flash and monitor
3. Connect board to ethernet

Debug Logs.

I (2961) esp_netif_handlers: example_connect: eth ip: 192.168.20.108, mask: 255.255.255.0, gw: 192.168.20.1
I (2961) example_connect: Got IPv4 event: Interface "example_connect: eth" address: 192.168.20.108
I (3461) example_connect: Got IPv6 event: Interface "example_connect: eth" address: fe80:0000:0000:0000:c249:efff:fe0a:508f, type: ESP_IP6_ADDR_IS_LINK_LOCAL
I (3461) example_connect: Connected to example_connect: eth
I (3471) example_connect: - IPv4 address: 192.168.20.108
I (3471) example_connect: - IPv6 address: fe80:0000:0000:0000:c249:efff:fe0a:508f, type: ESP_IP6_ADDR_IS_LINK_LOCAL
I (3481) multicast: Configured IPV6 Multicast address FF02::FC
I (3491) multicast: Configured IPV4 Multicast address 232.10.11.12
I (3501) multicast: Socket set IPV6-only
I (13501) multicast: Sending to IPV6 (V4 mapped) multicast address :: port 3333 (232.10.11.12)...
I (13501) multicast: Sending to IPV6 multicast address FF02::FC port 3333...

What's strange is the :: multicast address - getaddrinfo does something unexpected due to the link-local address maybe?

More Information.

Cygwin program for comparison:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <netinet/in.h>

#define UDP_PORT 13

int main()
{
    char addrbuf[256];
    struct addrinfo hints = {
        .ai_flags = AI_PASSIVE,
        .ai_socktype = SOCK_DGRAM,
    };
    struct addrinfo *res;
    hints.ai_family = AF_INET6; // For an IPv4 socket with V4 mapped addresses
    hints.ai_flags |= AI_V4MAPPED;
    int err = getaddrinfo("232.10.11.12",
                          NULL,
                          &hints,
                          &res);
    if (err < 0)
    {
        printf("getaddrinfo() failed for IPV4 destination address. error: %d", err);
        return 1;
    }
    if (res == 0)
    {
        printf("getaddrinfo() did not return any addresses");
        return 2;
    }
    ((struct sockaddr_in6 *)res->ai_addr)->sin6_port = htons(UDP_PORT);

    inet_ntop(res->ai_family, &((struct sockaddr_in6 *)res->ai_addr)->sin6_addr, addrbuf, sizeof(addrbuf) - 1);
    printf("Sending to IPV6 (V4 mapped) multicast address %s port %d (%s)...", addrbuf, UDP_PORT, "xxx");

    return 0;
}

[xueyunfei998]

dns.txt

hi @hurricanefrog

Thanks for pointing out this bug.

This is a fixed patch.

[AxelLin]

@xueyunfei998
How is the status for the fix? It has been in Reviewing state for more than 6 months!!

[xueyunfei998]

hi @AxelLin

Mr is ready and can be merged next week.