Q: Why do we get the following warning at run time:

kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT

FAQ.xml

@@ -17,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: FAQ.xml,v 1.4.8.6 2007/01/12 04:22:53 marka Exp $ -->
+<!-- $Id: FAQ.xml,v 1.4.8.7 2007/01/31 23:54:15 marka Exp $ -->
 
 <article class="faq">
   <title>Frequently Asked Questions about BIND 9</title>
@@ -1209,6 +1209,7 @@ named_cache_t: for files modifiable by named - $ROOTDIR/var/{tmp,named/{slaves,d
 	</para>
       </answer>
     </qandaentry>
+
     <qandaentry>
       <question>
 	<para>
@@ -1239,6 +1240,7 @@ zone "list.dsbl.org" {
         </programlisting>
       </answer>
     </qandaentry>
+
     <qandaentry>
       <question>
 	<para>
@@ -1272,5 +1274,51 @@ zone "list.dsbl.org" {
 	</para>
       </answer>
     </qandaentry>
+
+    <qandaentry>
+      <question>
+	<para>
+	  Why do we get the following warning at run time:
+<programlisting>kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT</programlisting>
+	</para>
+      </question>
+      <answer>
+	<para>
+          The early Linux kernels broke sendto() by having it return     
+          that a ICMP unreachable had be received for non connected
+          UDP sockets.  This made non connected UDP sockets work like
+          connected UDP socket which is fine when you are only talking
+          to one destination.  Named however talks to multiple
+          destinations and it caused problems.
+	</para>
+	<para>
+          Rather than fix sendto() to just have BSD behaviour they added
+          SO_BSDCOMPAT to turn BSD behaviour on/off on a per socket basis.
+	</para>
+	<para>
+          Later they decided to make BSD behaviour the default and
+          to aggressively trackdown application that used SO_BSDCOMPAT
+          by issuing a warning.  This is the sort of things vendors
+          do in alpha/beta stages of a release so that their code is
+          clean.  They then turn the warning *off* for release code.
+	</para>
+	<para>
+          We still have customers that have kernels that require
+          SO_BSDCOMPAT to operate.  We therefore cannot remove the
+          setsockopt(SO_BSDCOMPAT) call.
+	</para>
+	<para>
+          Now most/all portable applications that use SO_BSDCOMPAT use it
+          conditionally manner so just removing SO_BSDCOMPAT from the
+          header file would be safe as long as the binary was not to
+          be moved between systems.  BIND's use is conditional.
+	</para>
+	<para>
+	  In short, the Linux developers should either, remove the #define for
+	  SO_BSDCOMPAT, and/or remove the warning.
+	</para>
+      </answer>
+    </qandaentry>
+
   </qandaset>
 </article>