Merge branch '1928-handle-EPROTO-v9_16' into 'v9_16'

Resolve "error: socket.c:1540: unexpected error:"

See merge request isc-projects/bind9!4032

CHANGES

@@ -1,3 +1,6 @@
+5494.	[bug]		Silence the EPROTO syslog message on older systems.
+			[GL #1928]
+
 5493.	[bug]		Fix off-by-one error when calculating new hashtable
 			size. [GL #2104]
 

doc/notes/notes-current.rst

@@ -40,3 +40,8 @@ Bug Fixes
 - In rare circumstances, named would exit with assertion failure when the number
   of nodes stored in the red-black-tree exceeds the maximum allowed size of the
   internal hashtable.  [GL #2104]
+
+- Silence spurious system log messages for EPROTO(71) error code that has been
+  seen on older operating systems where unhandled ICMPv6 errors result in a
+  generic protocol error being returned instead of the more specific error code.
+  [GL #1928]

lib/isc/unix/socket.c

@@ -1528,6 +1528,16 @@ doio_recv(isc__socket_t *sock, isc_socketevent_t *dev) {
 		SOFT_OR_HARD(EHOSTUNREACH, ISC_R_HOSTUNREACH);
 		SOFT_OR_HARD(EHOSTDOWN, ISC_R_HOSTDOWN);
 		SOFT_OR_HARD(ENOBUFS, ISC_R_NORESOURCES);
+		/*
+		 * Older operating systems may still return EPROTO in some
+		 * situations, for example when receiving ICMP/ICMPv6 errors.
+		 * A real life scenario is when ICMPv6 returns code 5 or 6.
+		 * These codes are introduced in RFC 4443 from March 2006,
+		 * and the document obsoletes RFC 1885. But unfortunately not
+		 * all operating systems have caught up with the new standard
+		 * (in 2020) and thus a generic protocol error is returned.
+		 */
+		SOFT_OR_HARD(EPROTO, ISC_R_HOSTUNREACH);
 		/* Should never get this one but it was seen. */
 #ifdef ENOPROTOOPT
 		SOFT_OR_HARD(ENOPROTOOPT, ISC_R_HOSTUNREACH);