No multicast reception on IMX1064

[jchabod]

Describe the bug

We are using UDP multicast in our application. We are facing issue with receiving MC packets on IMX1064RT, whereas this is correctly working for other targets (several STM32 :H7 and H7-NUCLEO series)

For information, we raised a similar issue in 2020 which lead to a functional fix (#See #26584 and suggested patch for imx1064 #26585).
However, after a few month we once again are unable to receive any MC packet.

• Zephyr : v2.7.1 SHA=e4da3e528088a34a9989f5a50e7ed3149d57de92([EDIT : also checked on v3.0.0])
• targets: mimxrt1064_evk and stm32h735g_disco

Some additionnal information:

• Note: I need to patch boards/arm/stm32h735g_disco/stm32h735g_disco.dtsfile to get network interface activated:

$git show
commit 90e3a3d87bcabd8d5e637cfcaf0746e08c6df717 (HEAD -> s2opc_zephyr_v300)
Author: Jeremie Chabod <jeremie.chabod@systerel.fr>
Date:   Thu Apr 7 14:53:29 2022 +0200

    [S2OPC/ZEPHYR] Add missing network in STM32H7xxx description

diff --git a/boards/arm/stm32h735g_disco/stm32h735g_disco.dts b/boards/arm/stm32h735g_disco/stm32h735g_disco.dts
index 1867493182..424cc96926 100644
--- a/boards/arm/stm32h735g_disco/stm32h735g_disco.dts
+++ b/boards/arm/stm32h735g_disco/stm32h735g_disco.dts
@@ -105,6 +105,7 @@
                     &eth_txd0_pb12
                     &eth_txd1_pb13>;
        pinctrl-names = "default";
+       status = "okay";
 };
 
 &sdmmc1 {

• I tried to instrument ETH driver level, and it seems that MC packets do not even reach net layer (probably implying that the root cause is a non-functional MULTICAST registration)

To Reproduce

• See reproducer
• Use an external device to send any MC UDP packets on group "232.1.2.101:4840"

Expected behavior

• The Zephyr program should show incoming packet sizes (on STMH735 this shows for example: )
  
• On IMX, no packet is received
  

Additional context
basic_multicast_test.zip

[fabiobaltieri]

@jchabod would you be able to bisect down to a specific commit?

[jchabod]

@fabiobaltieri I had it working on V2.3 and V2.3 up to v3.0.0 is 19K commits... I don't think I'll have time for that .
However, I'll try to at least identify on which version this works.

Don't you think it possible that there is a NETWORK flag I missed in configuration?

[jchabod]

I have been looking into history, and I found out that in v2.4 / v2.5 (where I had MC reception OK on IMX), the net_if_ipv4_maddr_join function did not exist.

We thus used the following intrusive function to have MC reception working:

(However, I have not been able to rebuild ith Zephyr V2.5, and patch below does not make the job on V3.0.0...)

static void P_MULTICAST_enet_add_mcast(struct net_if* ptrNetIf, struct in_addr* pAddr)
{
    const struct ethernet_api* api = net_if_get_device(ptrNetIf)->driver_api;

    if (net_ipv4_is_addr_mcast(pAddr))
    {
        const struct ethernet_config ethernetconfig = {
            .filter =
                {
                    .set = 1,                                        //
                    .type = ETHERNET_FILTER_TYPE_SRC_MAC_ADDRESS,    //
                    .mac_address = {{0x01U,                          //
                                     0x00U,                          //
                                     0x5EU,                          //
                                     (pAddr->s_addr >> 8) & 0x7FU,   //
                                     (pAddr->s_addr >> 16) & 0xFFU,  //
                                     (pAddr->s_addr >> 24) & 0xFFU}} //
                },                                                   //
        };

        if (api->set_config != 0)
        {
            int res = api->set_config(net_if_get_device(ptrNetIf), //
                                      ETHERNET_CONFIG_TYPE_FILTER, //
                                      &ethernetconfig);            //
            (void) res;
#if P_MULTICAST_DEBUG == 1
            if (res != 0)
            {
                printk("\r\nP_MULTICAST: Error on set config driver api with SET ETHERNET_CONFIG_TYPE_FILTER\r\n"); //
            }
            else
            {
                printk("\r\nP_MULTICAST: Set config driver api with SET ETHERNET_CONFIG_TYPE_FILTER :-)\r\n"); //
            }
#endif
        }
        else
        {
#if P_MULTICAST_DEBUG == 1
            printk("\r\nP_MULTICAST: Error set config driver api not defined\r\n"); //
#endif
        }
    }
}

[fabiobaltieri]

@fabiobaltieri I had it working on V2.3 and V2.3 up to v3.0.0 is 19K commits... I don't think I'll have time for that . However, I'll try to at least identify on which version this works.

Can't you bisect? That should be 13 steps or so.

Don't you think it possible that there is a NETWORK flag I missed in configuration?

If we can identify the commit it may help, or maybe check if there's some other upstream multicast enabled feature that works that is enabling something?

@rlubos any comment on this?

[rlubos]

It seems that Zephyr v2.6 brought IGMPv2 support (see #34579), perhaps it's related. I think however that the actual culprit would be hard to identify w/o using a bisect, there are simply too many changes since 2.3 to guess where's the problem (please note that not everyone has particular hardware to reproduce the problem).

[dleach02]

@jchabod, is there a test case or sample in the Zephyr tree that reproduces this problem or is it just your application?

[hakehuang]

@jchabod can you share you test application?looks like the CONFIG_NET_IPV4_IGMP is need to support multi-cast

[jchabod]

Hi, the reproducer is attached in the ticket description above.
The same application works fine on STM but not on IMX1064.

I'll try with CONFIG_NET_IPV4_IGMP and give you quick feedback.

[jchabod]

I made the test with CONFIG_NET_IPV4_IGMP, but nothing changed...

I "visually" see the ETH led blinking on IMX, but no packet is received on ETH stack:

I've instrumented what I suppose is the entry point of network reception (ethernet.c) static enum net_verdict ethernet_recv(struct net_if *iface,struct net_pkt *pkt) and I confirm no MC packet reaches that point. This make me think there is something at driver level.

[jchabod]

Note: I used the following python3 script (windows) to send MC packets (of course, you may need to update local IP address):

#!python
import socket, time, datetime

def send_mc():
    ITF_ADDR="192.168.42.12"
    MCAST_GRP = '232.1.2.101'
    MCAST_PORT = 4840
    # regarding socket.IP_MULTICAST_TTL
    # ---------------------------------
    MULTICAST_TTL = 10

    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, MULTICAST_TTL)

    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, socket.inet_aton(ITF_ADDR))

    while True:
        sock.sendto(b"robot", (MCAST_GRP, MCAST_PORT))
        print("Sent msg at %s" % datetime.datetime.now())
        time.sleep(1.0)
    
    
send_mc()

[hakehuang]

@jchabod ,

please check the eth_mcux_init(const struct device *dev) in out eth_mcux.c, the myltucase is defined, if you have special address to monitor you need add accrodingly.

static void 
{
        struct eth_context *context = dev->data;
        const enet_buffer_config_t *buffer_config = dev->config;
        enet_config_t enet_config;
        uint32_t sys_clock;
#if defined(CONFIG_PTP_CLOCK_MCUX)
        uint8_t ptp_multicast[6] = { 0x01, 0x1B, 0x19, 0x00, 0x00, 0x00 };
        uint8_t ptp_peer_multicast[6] = { 0x01, 0x80, 0xC2, 0x00, 0x00, 0x0E };
#endif
#if defined(CONFIG_MDNS_RESPONDER) || defined(CONFIG_MDNS_RESOLVER)
        /* standard multicast MAC address */
        uint8_t mdns_multicast[6] = { 0x01, 0x00, 0x5E, 0x00, 0x00, 0xFB };
#endif

and according to https://datatracker.ietf.org/doc/html/rfc1112 yo should specifice a multicase address starting with (01:00:5e)

[hakehuang]

Note: I used the following python3 script (windows) to send MC packets (of course, you may need to update local IP address):

#!python
import socket, time, datetime

def send_mc():
    ITF_ADDR="192.168.42.12"
    MCAST_GRP = '232.1.2.101'
    MCAST_PORT = 4840
    # regarding socket.IP_MULTICAST_TTL
    # ---------------------------------
    MULTICAST_TTL = 10

    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, MULTICAST_TTL)

    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, socket.inet_aton(ITF_ADDR))

    while True:
        sock.sendto(b"robot", (MCAST_GRP, MCAST_PORT))
        print("Sent msg at %s" % datetime.datetime.now())
        time.sleep(1.0)
    
    
send_mc()

I meet error with your script

sudo python ./mcast_send.py 
Traceback (most recent call last):
  File "./mcast_send.py", line 23, in <module>
    send_mc()
  File "./mcast_send.py", line 15, in send_mc
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, socket.inet_aton(ITF_ADDR))
  File "/usr/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 99] Cannot assign requested address

[jchabod]

I used the following python3

You will need some changes to run it under python27

[hakehuang]

I used the following python3

You will need some changes to run it under python27

@jchabod , thanks for this message, now I can send multicast message, and this looks like not a driver issue, nor stack issue, and just because you need some code to process your own multicast protocol.
If you enalbe the CONFIG_ETH_MCUX_PROMISCUOUS_MODE=y, then you cwill be able to get those mutlcast package from our driver, however it will not be processed as there is no protocol stack.
in our eth_mcu.c driver the mutlicast supporting are only available for mdns and gptpv2, for another protocol, you need change the driver and process the protocol accordingly.

[jchabod]

If you enalbe the CONFIG_ETH_MCUX_PROMISCUOUS_MODE=y

Thanks @hakehuang
Indeed that works!

I can see packets reaching in ethernet_recv and my application sucessfully receives MC UDP packets!

I have 2 small questions before closing this subject, maybe you can help quickly:

• (How) was I supposed to find out that I needed CONFIG_ETH_MCUX_PROMISCUOUS_MODE=y ? Did I miss something in documentation or does this shows that this information is somehow missing somewhere?
• How does this come to work on STM32 without this flag? (Maybe it partially depends on HAL)
• I did not understand clearly the in our eth_mcu.c driver reference. Did you mean ZEPHYR or NXP ? (Yes I know, that actually makes 3 questions)

Anyway thank for support and help !

[hakehuang]

(How) was I supposed to find out that I needed CONFIG_ETH_MCUX_PROMISCUOUS_MODE=y ? Did I miss something in documentation or does this shows that this information is somehow missing somewhere?

you need some ethernet concept https://www.sciencedirect.com/topics/computer-science/promiscuous-mode , however in your case the promiscuous-mode is only a workaround. by default the net card will drop all package that is not targetting to itself, but with promiscuous mode, it will forward all packages it receives.

How does this come to work on STM32 without this flag? (Maybe it partially depends on HAL)

I check the stm32 driver code, they have a special setting which by default accepte all multicast pacakge, but in our driver, we need explicitely add filter or using promiscuous mode. see code below in stm32 ethernet driver

    uint32_t tmp = heth->Instance->MACFFR;

    /* disable multicast filtering */
    tmp &= ~(ETH_MULTICASTFRAMESFILTER_PERFECTHASHTABLE |
         ETH_MULTICASTFRAMESFILTER_HASHTABLE |
         ETH_MULTICASTFRAMESFILTER_PERFECT);

    /* enable receiving all multicast frames */
    tmp |= ETH_MULTICASTFRAMESFILTER_NONE;

    heth->Instance->MACFFR = tmp;

    /* Wait until the write operation will be taken into account:
     * at least four TX_CLK/RX_CLK clock cycles
     */
    tmp = heth->Instance->MACFFR;
    k_sleep(K_MSEC(1));
    heth->Instance->MACFFR = tmp;

I did not understand clearly the in our eth_mcu.c driver reference. Did you mean ZEPHYR or NXP ? (Yes I know, that actually makes 3 questions)

sorry it shall be eth_mcux.c, which is the adapt driver in zephyr drivers for NXP hal ethernet driver in hal module.

[jchabod]

It seems all clear to me !

Many thanks again for your time and explanations.

[dleach02]

I'm converting this issue to a discussion

It looks like the STM32 may, by default, enable promiscuous mode in their drivers. Not sure. But enabling promiscuous mode is a bit of a sledgehammer solution because now the application will need to filter everything when the HW could be filtering the multicast frames for you.

[dleach02]

Take a look at net_if_mcast_monitor() function.

/**

• @brief Call registered multicast monitors
• @param iface Network interface
• @param addr Multicast address
• @param is_joined Is this multicast address joined (true) or not (false)
  */
  void net_if_mcast_monitor(struct net_if *iface, const struct net_addr *addr,
  bool is_joined);

If you have a custom multicast you are trying to receive this would setup the HW to use this filter.

[jchabod]

That seems to be a very interesting entry point.
I'll look into that

[ptiza-v-nebe]

If this is still open question I think I have found the culprit. As dleach02 states it has to do with this monitor mechanism. The problem was that eth_mcux.c (zephyr 2.7) adds multicast addresses only in case of ipv6 addresses (big big facepalm). I made simple rewrite of the callback function and eth_iface_init to support both ipv4 and ipv6:

in drivers/ethernet/eth_mcux.c

//#if defined(CONFIG_NET_IPV6)
static void net_if_mcast_cb(struct net_if *iface,
			    const struct net_addr *addr,
			    bool is_joined)
{
	const struct device *dev = net_if_get_device(iface);
	struct eth_context *context = dev->data;
	struct net_eth_addr mac_addr;

	if (addr->family == AF_INET6) {
		net_eth_ipv6_mcast_to_mac_addr(&addr->in6_addr, &mac_addr);
	}

	if (addr->family == AF_INET) {
		net_eth_ipv4_mcast_to_mac_addr(&addr->in_addr, &mac_addr);
	}

	if (is_joined) {
		ENET_AddMulticastGroup(context->base, mac_addr.addr);
	} else {
		ENET_LeaveMulticastGroup(context->base, mac_addr.addr);
	}
}
//#endif /* CONFIG_NET_IPV6 */

static void eth_iface_init(struct net_if *iface)
{
	const struct device *dev = net_if_get_device(iface);
	struct eth_context *context = dev->data;

//#if defined(CONFIG_NET_IPV6)
	static struct net_if_mcast_monitor mon;

	net_if_mcast_mon_register(&mon, iface, net_if_mcast_cb);
//#endif /* CONFIG_NET_IPV6 */

	net_if_set_link_addr(iface, context->mac_addr,
			     sizeof(context->mac_addr),
			     NET_LINK_ETHERNET);

	/* For VLAN, this value is only used to get the correct L2 driver.
	 * The iface pointer in context should contain the main interface
	 * if the VLANs are enabled.
	 */
	if (context->iface == NULL) {
		context->iface = iface;
	}

#if IS_ENABLED(CONFIG_NET_DSA)
	dsa_register_master_tx(iface, &eth_tx);
#endif
	ethernet_init(iface);
	net_if_flag_set(iface, NET_IF_NO_AUTO_START);

	context->config_func();
}

As you can see, there are configs for ipv6 that are now commented out (before that fix the ipv4 family was just ignored!). Now it is possible to add ipv4 multicast addresses without promiscous mode! Maybe the authors of eth_mcux.c can share what was the idea of disabling ipv4 multicasting? Did it had some deeper reason?