From rhh@ct.picker.com  Tue Jun 11 18:01:22 1996
Received: from central.picker.com (central.picker.com [144.54.31.2])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA12259
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 11 Jun 1996 18:01:21 -0700 (PDT)
Received: from ct.picker.com by central.picker.com with smtp
	(Smail3.1.28.1 #3) id m0uTeE3-0004rmC; Tue, 11 Jun 96 20:55 EDT
Received: from stealth.ct.picker.com ([144.54.61.10]) by ct.picker.com (4.1/SMI-4.1)
	id AA01399; Tue, 11 Jun 96 20:55:27 EDT
Received: (from rhh@localhost) by stealth.ct.picker.com (8.6.12/8.6.9) id UAA00705; Tue, 11 Jun 1996 20:55:46 GMT
Message-Id: <199606112055.UAA00705@stealth.ct.picker.com>
Date: Tue, 11 Jun 1996 20:55:46 GMT
From: rhh@ct.picker.com
Reply-To: rhh@ct.picker.com
To: FreeBSD-gnats-submit@freebsd.org, rhh@ct.picker.com
Subject: automounter hangs on boot
X-Send-Pr-Version: 3.2

>Number:         1312
>Category:       bin
>Synopsis:       automounter hangs on boot
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 11 18:10:02 PDT 1996
>Closed-Date:    Thu Aug 10 11:10:05 PDT 2000
>Last-Modified:  Thu Aug 10 11:18:56 PDT 2000
>Originator:     Randall Hopper
>Release:        FreeBSD 2.1-STABLE i386
>Organization:
Self
>Environment:

        2.1.0-STABLE with dial-up SLIP connection to corporate intranet
        where DNS server lives.  SLIP link is not up all the time.

>Description:

     I believe I've found a possible bug in the way netmasks are computed
in amd.  The bug in question causes a few spurious DNS lookups
which, on my dial-up subnet, hangs the machine for a while during boot
while the DNS requests issued by amd time out.  The bug and the workarounds
I've found are detailed below.

>How-To-Repeat:

     The specific network setup I'm working with is:

     Subnet Mask         : 255.255.255.240            (4-bit hostids)

     Router Host elmer   : 144.54.61.1, 144.54.61,17  (3 interfaces)
     Host stealth        : 144.54.61.10               (interface 1)
     Host voyager        : 144.54.61.18               (interface 2)
     Dial-up host                                     (interface 3)

I have the following entry in /etc/networks on all machines:

     net1            144.54.61.0
     net2            144.54.61.16

elmer is a router to several subnets.  stealth is on "net1" and voyager is
on "net2".


     However, when I start amd on stealth, it does a getnetbyaddr on the
network "0.144.54.61", which it "doesn't" find in the file, so it falls
back and and does a gethostbyaddr on 144.54.61.0.  This results in two PTR?
queries which also fail or time out (depending on whether the dial-up link
is up or not).

>Fix:
	
WORKAROUNDS:

     One work-around for now is to just put a (seemingly) bogus net1 entry
in /etc/networks:

     net1            144.54.61
     net2            144.54.61.16

Another is to just "ifconfig down" the route to the DNS server on subnet
machines while they're bringing up amd.

THE FIX:

     The underlying problem seems to be that wire.c:getwire() in the amd
source doesn't determine "mask" correctly when the number of bits in the
hostid isn't 8.  For Class B addresses, it starts with the 0xFFFF0000
netmask and increases that 8 bits at a time (?why?).  It computes this mask
from the subnet (?), and then applies it TO the subnet.  In net1's case
above it ends up with a 0xFFFFFFFF mask and in "net2"'s case it ends up
with a 0xFFFFFF00 mask.

     I don't know whether this is a bug, or correct (albeit strange)
behavior documented in an RFC somewhere.  To compute "mask", why not start
with the raw subnet "mask" (as opposed to subnet address), and shift it
right 8 bits so long as the low 8 bits are 0?

>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@lcs.mit.edu>
To: rhh@ct.picker.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: bin/1312: automounter hangs on boot
Date: Wed, 12 Jun 1996 11:52:12 -0400

 <<On Tue, 11 Jun 1996 20:55:46 GMT, rhh@ct.picker.com said:
 
 >      The underlying problem seems to be that wire.c:getwire() in the amd
 
 Probably the `wire' stuff should just go away; networks are rapidly
 evolving towards a state where this doesn't make a whole lot of sense.
 
 -GAWollman
 
 --
 Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
 wollman@lcs.mit.edu  | Shashish is the bonding of hearts in spite of distance.
 Opinions not those of| It is a bond more powerful than absence.  We like people
 MIT, LCS, ANA, or NSA| who like Shashish.  - Claude McKenzie + Florent Vollant
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 20:32:27 PDT 1996 
State-Changed-Why:  

Confirm Status 
State-Changed-From-To: feedback->open 
State-Changed-By: scrappy 
State-Changed-When: Mon Nov 4 06:23:06 PST 1996 
State-Changed-Why:  

Problem Still Exists: 

No, the problem still exists, to my knowledge. 

I'm not on the latest -current, but I just grabbed the latest wire.c and it 
appears that the relevent section of code hasn't changed. 

Thanks, 

Randall Hopper 
rhh@ct.picker.com 

State-Changed-From-To: open->suspended 
State-Changed-By: phk 
State-Changed-When: Mon Apr 13 02:15:29 PDT 1998 
State-Changed-Why:  
->suspended 
State-Changed-From-To: suspended->closed 
State-Changed-By: johan 
State-Changed-When: Thu Aug 10 11:10:05 PDT 2000 
State-Changed-Why:  
Amd has been contrib-ified while 3.x was current. 
The problematic file wire.c do not exists any more. 

New problem reports should be sent to the 
am-util devel mailing list: amd-dev@majordomo.cs.columbia.edu. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=1312 
>Unformatted:
