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

   kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT

diff --git a/FAQ b/FAQ
index ba87de21652d56a79d7058d06b2f8a962cf39ac1..cb0a956a6f83da3c7eb3d5850e2f1f7a520ea7b2 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -673,3 +673,31 @@ A: No, so long as the machines internal clock (as reported by "date -u") remains
    setting the TZ envirionment variable appropriately. See your OS's documentation
    for more details.
 
+Q: Why do we get the following warning at run time:
+
+   kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT
+
+A: 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.
+
+   Rather than fix sendto() to just have BSD behaviour they added SO_BSDCOMPAT to
+   turn BSD behaviour on/off on a per socket basis.
+
+   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.
+
+   We still have customers that have kernels that require SO_BSDCOMPAT to operate.
+   We therefore cannot remove the setsockopt(SO_BSDCOMPAT) call.
+
+   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.
+
+   In short, the Linux developers should either, remove the #define for
+   SO_BSDCOMPAT, and/or remove the warning.
+

diff --git a/FAQ.xml b/FAQ.xml
index 625cfb22aa6643c382a3d1fa07cc5391b52ab258..ff07ae7c8992f0956569c8d8774eb420f8b49fd4 100644 (file)
--- a/FAQ.xml
+++ b/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>