Hello Boost Users, I am investigating an issue related to Boost.Asio UDP communication and would appreciate any insight. We have a UDP listener implemented with Boost.Asio. The application successfully receives UDP trigger packets via async_receive_from(), verifies the payload, builds an ACK message, and immediately sends the ACK back using async_send_to(). However, the send callback reports: C++1Sent ACK message ... error with err_code: 101Show more lines Error 101 corresponds to: Plain Text1ENETUNREACH (Network unreachable)2`Show more lines Simplified code: C++1mSocket.async_receive_from(2 net::buffer(mData, max_length),3 mSenderEndpoint,4 auto ec, int bytes_recvd {5 if (!ec && bytes_recvd > 0) {6 // Verify trigger7 doSend(ack);8 }9 doReceive();10 });11 12mSocket.async_send_to(13 net::buffer(&ack[0], ack.size()),14 mSenderEndpoint,15 auto err_code, auto bytes_sent {16 if (err_code) {17 std::cout << "send failed: "18 << err_code.value()19 << std::endl;20 }21 });22 Show more lines Observations: UDP trigger packets are received successfully. Message verification succeeds. ACK generation succeeds. async_send_to() fails immediately with err_code = 101. The same endpoint obtained from async_receive_from() is used for ACK transmission. Socket is opened and bound as IPv6: C++1mSocket.open(udp::v6(), ec);2mSocket.bind(udp::endpoint(udp::v6(), port), ec);Show more lines This occurs sporadically after a vehicle wakeup scenario. It looks as if the receive path is already available, but the transmit route is not yet ready. My questions are: Under what conditions can async_send_to() return ENETUNREACH even though packets were successfully received from the same endpoint moments before? Could this be related to IPv4/IPv6 endpoint handling, routing table readiness, or network interface state changes? Is there any Boost.Asio-specific recommendation for handling such transient network conditions? Any suggestions or similar experiences would be greatly appreciated. Thank you. Best regards, Thanh Van Nguyen LG Electronics