diff --git a/FAQ/network.sgml b/FAQ/network.sgml
index feca80bd63..6bb054f39f 100644
--- a/FAQ/network.sgml
+++ b/FAQ/network.sgml
@@ -1,4 +1,4 @@
-<!-- $Id: network.sgml,v 1.5 1998-01-17 14:12:59 brian Exp $ -->
+<!-- $Id: network.sgml,v 1.6 1998-01-20 22:48:19 brian Exp $ -->
 <!-- The FreeBSD Documentation Project -->
 
   <sect>
@@ -322,12 +322,16 @@ default            10.0.0.2           UGSc        0        0      tun0
         <p>Occasionally, just after connecting, you may see messages in
         the log that say "magic is the same".  Sometimes, these
         messages are harmless, and sometimes one side or the other
-        exits.
+        exits.  Most ppp implementations cannot survive this problem, and
+        even if the link seems to come up, you'll see repeated configure
+        requests and configure acknowledgements in the log file until
+        ppp eventually gives up and closes the connection.
 
         <p>This normally happens on server machines with slow disks that
         are spawning a getty on the port, and executing ppp from a
-        login script or program after login.  The reason is that in
-        the time taken between getty exiting and ppp starting, the
+        login script or program after login.  I've also heard reports
+        of it happening consistently when using slirp.  The reason is
+        that in the time taken between getty exiting and ppp starting, the
         client-side ppp starts sending Line Control Protocol (LCP)
         packets.  Because ECHO is still switched on for the port on
         the server, the client ppp sees these packets "reflect" back.
@@ -348,18 +352,25 @@ default            10.0.0.2           UGSc        0        0      tun0
         Meanwhile, the client, who no longer sees the reflections,
         becomes happy just in time to see a hangup from the server.
 
-        <p>The only way to circumvent this is to put the following line
-        in your ppp.conf file:
+        <p>This can be avoided by allowing the peer to start negotiating
+        with the following line in your ppp.conf file:
 
         <verb>
           set openmode passive
         </verb>
 
-        <p>This tells ppp to wait for the server to initiate LCP negotiations.
-        Some servers may never initiate negotiations.  If this is the case,
-        please report it as a bug (using send-pr).  Ppp will need to be
-        adjusted so that the user can configure a variable delay before
-        initiating LCP negotiations.
+        <p>This tells ppp to wait for the server to initiate LCP
+        negotiations.  Some servers however may never initiate negotiations.
+        If this is the case, you can do something like:
+
+        <verb>
+          set openmode active 3
+        </verb>
+
+        <p>This tells ppp to be passive for 3 seconds, and then to start
+        sending LCP requests.  If the peer starts sending requests during
+        this period, ppp will immediately respond rather than waiting for
+        the full 3 second period.
 
       <sect2>
         <heading>Ppp locks up shortly after connecting</heading>