From owner-freebsd-bugs Tue Jun 11 18:10:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12657 for bugs-outgoing; Tue, 11 Jun 1996 18:10:05 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12650; Tue, 11 Jun 1996 18:10:03 -0700 (PDT) Resent-Date: Tue, 11 Jun 1996 18:10:03 -0700 (PDT) Resent-Message-Id: <199606120110.SAA12650@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, rhh@ct.picker.com 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 ; 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 X-Send-Pr-Version: 3.2 Subject: bin/1312: automounter hangs on boot Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1312 >Category: bin >Synopsis: automounter hangs on boot >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jun 11 18:10:02 PDT 1996 >Last-Modified: >Originator: Randall Hopper >Organization: Self >Release: FreeBSD 2.1-STABLE i386 >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? >Audit-Trail: >Unformatted: