[boost] Fw: Question about Boost.Asio async_send_to returning error 101 (Network unreachable)

31 Jul 2026

      ________________________________
From: THANH VAN NGUYEN/LGEDV CONNECTIVITY SERVICE TEAM <thanh13.nguyen@lge.com>
Sent: Friday, July 31, 2026 1:40 PM
To: boost@lists.boost.org <boost@lists.boost.org>
Subject: Fw: Question about Boost.Asio async_send_to returning error 101 (Network unreachable)

________________________________
From: THANH VAN NGUYEN/LGEDV CONNECTIVITY SERVICE TEAM
Sent: Friday, July 31, 2026 1:35 PM
To: boost@lists.boost.org <boost@lists.boost.org>
Subject: Question about Boost.Asio async_send_to returning error 101 (Network unreachable)

Hello Boost Team,
I am investigating an issue related to Boost.Asio UDP communication and would appreciate your guidance.
We have a UDP listener/sender implementation using boost::asio::ip::udp::socket. In our field logs, the application successfully receives UDP packets, validates them, generates an ACK message, and then calls async_send_to() to send the ACK back to the sender.
However, the send callback reports:
Plain Text
1
Sent ACK message for contextID: xxx error with err_code: 101
Show more lines
Error code 101 corresponds to:
Plain Text
1
Network unreachable
Show more lines
Relevant code:
C++
mSocket.async_send_to(
net::buffer(&ack[0], ack.size()),
mSenderEndpoint,
[uto err_code, auto bytes_sent {
if ((!err_code) && (bytes_sent > 0U)) {
LOGI("Sent ACK success");
} else {
LOGE("Send ACK failed, err_code=%d",
err_code.value());
}
});
Additional observations:

  *   UDP packets are successfully received through async_receive_from().
  *   mSenderEndpoint is obtained from the received packet.
  *   Message validation succeeds before sending ACK.
  *   The socket is opened and bound using IPv6:

C++
mSocket.open(udp::v6(), ec);
mSocket.bind(udp::endpoint(udp::v6(), port), ec);
My questions are:

  1.  Under what conditions can async_send_to() return error 101 even though async_receive_from() successfully received packets from the same endpoint?
  2.  Could this be related to IPv4/IPv6 endpoint mismatch, routing changes, or interface availability during asynchronous transmission?
  3.  Is there any recommended way to obtain more detailed diagnostics from Boost.Asio for this situation?

Any insight would be greatly appreciated.
Thank you for your support.
Best regards,
Thanh Van Nguyen
LG Electronics