I have what I believe is a somewhat obscure question. I have a very specific use case here, so please consider this question purely academic.
I have a device (running Linux 2.4 kernel) which transmits IP UDP multicast packets via Ethernet. I need to be able to control the destination MAC address of the frames. Normally, when sending a UDP multicast frame via a regular UDP socket, the destination MAC is automatically derived by means of the standard mapping, which is basically 01:00:5E:XX:XX:XX, where XX represent the last 3 octets (actually 23 bits I think) of the IP. For unicast frames, the destination MAC is obviously obtained via ARP.
My question is:
If I add a static ARP entry for the multicast IP, is there a guarantee that the system will use that destination MAC instead of the standard mapping? I’ve tested this out on the system and it does seem to work, but I was curious if this is a defined behavior.
I would have expected UDP multicast packets to bypass the whole ARP table lookup mechanism as an optimization, but apparently that’s not the case.
It seems like it does in fact scan the static ARP table even for multicast packets. However, it will not transmit an ARP request if it doesn’t find an entry. Instead, it seems to fall back to the standard mapping. This is a sensible behavior to me.
I’ve tried to navigate the kernel IP stack source to better understand where the decision is made about whether to do an ARP lookup or not, but I’m having a little trouble.
If someone could point me to where this decision is made in the kernel source, that would be greatly appreciated. From what I gather now, the packet first goes to udp_sendmsg in “udp.c”. Then, from there, it gets handed off to “ip_output.c”. I'm not sure where the ARP lookup happens though.