17

I am acquainting with BSD sockets, and flicking through the man page of sendto, I bumped into MSG_CONFIRM flag, which is quite mysterious to me at the moment.

The description says:

Tell the link layer that forward progress happened: you got a successful reply from the other side. If the link layer doesn't get this it will regularly reprobe the neighbor (e.g., via a unicast ARP). Only valid on SOCK_DGRAM and SOCK_RAW sockets and currently implemented only for IPv4 and IPv6.

After a quick look at the man page of arp, I understand that flagging something MSG_CONFIRM prevents the ARP mapping MAC address ↔ IP address of the remote machine from being considered stale.

Now I am puzzled because I can’t see any reason why I should not put it, and therefore, why didn’t they enforce that directly in the library. Why is the application layer expected to deal with anything that happens down there at the link layer.

So did I miss anything? when should I set it, or not set it?

xaxxon
  • 19,189
  • 5
  • 50
  • 80
qdii
  • 12,505
  • 10
  • 59
  • 116

3 Answers3

14

You should only set the flag if the datagram you're sending is a direct response to a datagram you just received from the same peer.

If you're sending an initial request, or sending a datagram in response to some other event (like user input, or a timeout) then you should not set the MSG_CONFIRM flag.

caf
  • 233,326
  • 40
  • 323
  • 462
  • What should be the default value for initial request if not MSG_CONFIRM? – Lightsout Oct 30 '18 at 19:24
  • 2
    @bakalolo: If you have no flags to set in a call to `sendto()`, you just pass 0 as the `flags` parameter. – caf Oct 31 '18 at 03:01
  • 1
    A source reference for the information in this answer would be nice to have. – Armali Nov 07 '21 at 17:18
  • One source for `MSG_CONFIRM`: https://linux.die.net/man/2/sendto. However, this answer contains more information and better information than that reference. I just wish we had a reference for where this answer got the information. – Gabriel Staples Apr 01 '22 at 19:25
4

The reason to not send it is in case the mac address for the IP changes over time. If you're constantly telling your system not to check, it will continue to send to the same MAC even if the IP address isn't there anymore.

It seems the case for sending it requires a very special situation where you can guarantee things about the recipient of your messages. The overhead of a periodic ARP request is very low, so the benefits are extremely limited.

xaxxon
  • 19,189
  • 5
  • 50
  • 80
  • Ah...the [cryptic man page for `sendto()`](https://linux.die.net/man/2/sendto) is starting to make more sense now!: `MSG_CONFIRM (Since Linux 2.3.15) Tell the link layer that forward progress happened: you got a successful reply from the other side. If the link layer doesn't get this it will regularly reprobe the neighbor (e.g., via a unicast ARP). Only valid on SOCK_DGRAM and SOCK_RAW sockets and currently only implemented for IPv4 and IPv6. See arp(7) for details.` So, NOT including the `MSG_CONFIRM` flag tells the underlying network to keep verifying theMACaddress periodically for this IP. – Gabriel Staples Apr 01 '22 at 19:27
  • 1
    @GabrielStaples it's a little weird to me that it sounds like a user-space process (with SOCK_DGRAM) can directly affect the behavior of the link layer. I'd understand that with SOCK_RAW because you have to have super-user privileges to run that. But the link layer is shared among all processes. (I may be VERY wrong, but that's how I read it) – xaxxon Apr 02 '22 at 21:48
  • @xaxxon: I take it to mean that the _particular datagram_ sent with `MSG_CONFIRM` will not trigger the kernel to reprobe the destination address. Any datagrams sent to that same destination (by the same or other processes) _without_ `MSG_CONFIRM` _will_ trigger the kernel to reprobe the destination address (if the neighbor cache entry is stale). So there is no issue with privileges; a process can't use `MSG_CONFIRM` to prevent other processes from triggering the kernel to reprobe any destination addresses; it can only waive that service for itself. – Matt Whitlock Dec 10 '22 at 04:28
4

This is my attempt at making sense of this after reading the other two answers here.

If you're wondering about when to use the MSG_CONFIRM flag, essentially, all it does is tell the underlying ARP network layer to NOT periodically verify the MAC of the recipient IP (which would update the ARP hardware-MAC-address-to-IP-address mapping), because we are confident the IP we are sending to is the device we think it is, since this message are are sending is in direct response to a message we just received from them! In other words, if in doubt, leave OUT the MSG_CONFIRM flag. Put it in ONLY if the message we are sending is a direct response to a message received, and therefore we want to increase the network efficiency a tiny bit by NOT verifying the MAC again periodically, at the risk that the destination MAC could change and be wrong and no loner match the IP address for the device we think we are sending this message to!

Pros of using MSG_CONFIRM:

  1. It increases the efficiency of the network by NOT having ARP reprobe for the MAC of the destination address.

Cons or risks of using MSG_CONFIRM:

  1. It may mean that if the old device on the network drops off, and a new destination device pops up on the network with the same destination address as the old one, but with a different hardware MAC, we won't know, because MSG_CONFIRM tells ARP not to reprobe that IP address's MAC.

When MSG_CONFIRM can be used:

  1. When our message out is a direct reply to a message we just received in from that device, so we are sure its MAC is still correct.
  2. MSG_CONFIRM in this case can be thought of as a "confirmation" message to the sender that we got their previous message.

Official documentation from here for sendto(): https://linux.die.net/man/2/sendto (emphasis added):

MSG_CONFIRM (Since Linux 2.3.15)

Tell the link layer that forward progress happened: you got a successful reply from the other side. If the link layer doesn't get this it will regularly reprobe the neighbor (e.g., via a unicast ARP). Only valid on SOCK_DGRAM and SOCK_RAW sockets and currently only implemented for IPv4 and IPv6. See arp(7) for details.

So, my rule of thumb is: just don't use it. It has little benefit. But, if you choose to use it, only use it

  1. To reply (via a UDP message) directly to the sender of a UDP message just received via recvfrom(), or equivalent, or
  2. In embedded device networks where you have fixed (static) MAC addresses, IP addresses, and ARP MAC-to-IP mapping, and carefully manually control it all, and care about the tiny bit of network efficiency gain achieved by disabling ARP probing.
Gabriel Staples
  • 36,492
  • 15
  • 194
  • 265