Lucien Zürcher

Exactly the issue, From the example, A is a router with two interfaces and the function `coap_join_mcast_group_intf()` would elegantly prevent that 😇 .

Let me verify, disabling `IPV6_MULTICAST_LOOP` on the sending socket worked, thought i am not sure disabling it on the receiving socket will work, the ibm docs say: > ... The...

So disabling via `coap_join_mcast_group_intf()` wont work, since if I use `coap_session_create_client()` to send the udp multicast message, it will open a new socket which does not configure `IPV6_MULTICAST_LOOP`, aka. `IPV6_MULTICAST_LOOP`...

You probably have understood it fully, but just to ensure we are on the same page, here a test implementation to verify: https://github.com/BitFis/example-multicast , If i have two sockets on...

Works for me, thought do you want to provide an option to enable loopback if desired? Aka. provide the new api anyways?

After checking further and having a few discussions, I would recommend not disabling `IPV6_MULTICAST_LOOP` when creating the client type sockets. In case its disabled no other local process will be...

Will verify this, thanks. A side question, there is currently no functionality which detects duplicate messages via message id?

Hello, its a bit off topic of this issue, but I am thinking of server side in context of **[RFC7252 - 4.5. Message Deduplication](https://datatracker.ietf.org/doc/html/rfc7252#section-4.5)**. ``` The recipient SHOULD acknowledge each...

Thank you for the update, I hope I will be able to verify soonish. Otherwise feel free to close this issue in the next few weeks. We can reopen accordingly.

@mrdeep1 not quite sure of the changes in #1502, I believe this could fix it. But just to ensure, we require to send the multicast message on the same port...