[JJDSNT]

An Echo Request to ff02::1 was counted as answered (netstat -s: "message responses generated") but no reply reached the wire; a request to AROS's own link-local address was answered. The request came in as a multicast frame, so its mbuf was marked M_MCAST, and the reply, made from it with its packet header (icmp6_echo_copy()), kept the mark: ip6_output() did not clear it for a unicast destination, and the interface sent the reply to the asker's MAC address as a multicast (S2_MULTICAST), which the device refused.

ip6_output() now clears M_BCAST and M_MCAST for a destination that is not a group, as FreeBSD's does. RFC 4443 section 4.2: a reply to a request sent to a group SHOULD be sent, from a unicast address of the interface the request came in by - which icmp6_reflect() already chooses.

The host pinging ff02::1%aros0 for 4 s (aros-matter tests/ipv6/mcast_echo_amiga.sh, tcpdump on the tap):

	master	this PR
AROS m68k, emulated A3000 + A2065	0 replies	4, from its link-local address
hosted AROS	0 replies	4, from its link-local address
unicast echo to the link-local address	2 of 2	2 of 2

The cunit suite passes (cunit-net-acd's first test can fail when it is the first program after startnet, on master too: a separate test fix). ip6_output.o: +18 bytes of text on the 68000. bsdsocket.library 5.48 (kernel v0.87).

[Kalamatee]

The IPv6 part is right. With the host pinging ff02::1%aros0, AROS gave no reply before and gives 4 of 4 now, from its link-local address (RFC 4443 section 4.2). Unicast is unchanged. One change before this goes in.

1. IPv4 has the same fault: fix it in this PR. A ping to 224.0.0.1 over the same tap gets no reply either. icmp_input() reflects the request in its own mbuf (ICMP_ECHO -> icmp_reflect()), so the reply keeps the M_MCAST of the frame it came in as. ip_output() sets M_MCAST for a group destination (netinet/ip_output.c, the IN_MULTICAST() branch) and clears M_BCAST for a destination that is not broadcast, but never clears M_MCAST for a unicast one. The reply then goes to the asker's MAC address as a multicast, which the device refuses. Clear it before the IN_MULTICAST() test, as in ip6_output():

   if(!IN_MULTICAST(ntohl(ip->ip_dst.s_addr)))
       m->m_flags &= ~M_MCAST;

   With that line, the ping to 224.0.0.1 got 4 replies of 4, from 10.0.0.2. Say in the commit message that both families are fixed.

Note: this PR and #2284 both take version.h from 5.47 to 5.48. Whichever goes in second has to take the next number.