From owner-freebsd-bugs Wed Feb 22 00:05:47 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id AAA00688 for bugs-outgoing; Wed, 22 Feb 1995 00:05:47 -0800 Received: from dub-img-2.compuserve.com (dub-img-2.compuserve.com [198.4.9.2]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id AAA00682 for ; Wed, 22 Feb 1995 00:05:46 -0800 Received: by dub-img-2.compuserve.com (8.6.9/5.941228sam) id DAA25332; Wed, 22 Feb 1995 03:04:52 -0500 Date: 22 Feb 95 02:59:45 EST From: "Brian O'Connor" <73251.1334@compuserve.com> To: Subject: BOOTP Daemon Message-ID: <950222075944_73251.1334_FHO34-1@CompuServe.COM> Sender: bugs-owner@FreeBSD.org Precedence: bulk Hello there, Greetings from Brunei. I do not have access to net email - apart from Compuserve - we use X.400 (pain), so apologies for submitting a woolly fault report via a non-standard means. In general, FreeBSD has been great to use, and is a very neat package. We have been testing it for over a month with a view to using it as the basis for our BOOTP and DNS servers. Apart from the strange behaviour described below it has been very stable. Please keep up the good work - the results are very nice. Brian *To: FreeBSD-gnats-submit@freebsd.org *Subject: Boot Protocol Daemon Misbehaviour / Abnormality ??? *From: 73251.1334@compuserve.com *Reply-To: 73251.1334@compuserve.com >Submitter-Id: Brian O'Connor SES/243 >Originator: Brian O'Connor SES/243 >Organization: Brunei Shell Petroleum Seria 7082 Negara Brunei Darussalam BORNEO >Confidential: yes >Synopsis: BOOTPD uses wrong source IP address ?? >Severity: non-critical >Priority: medium >Category: misc >Release: FreeBSD 2.0-RELEASE i386 >Class: sw-bug >Environment: Two PCs running FreeBSD 2.0 on a class B Ethernet. FreeBSD under evaluation for use as DNS and BOOTP servers. >Description: The BOOTP daemon uses a wrong source IP address in replies to BOOTPC requests originated by the bootpchk utility contained in (DOS Based) Novell's LAN Workplace for DOS. The bootpchk utility sends out BOOTPC requests to layer 2 and 3 broadcast addresses, using its own IP and MAC addresses. Normally, of course, BOOTPC requests would be originated with an IP address of 0.0.0.0 - as the client doesn't know its IP address! The BOOTPCHK utility listens for replies from multiple BOOTP servers, and compares the results obtained from all servers for inconsistencies. It is a neat idea ! The receiving client does not care about the fact that the reply has come from an "incorrect" IP address - it is just the duplication of IP addresses which worries me, and will muck up our network mgt tools. One BOOTP server uses an IP address 158.161.32.232, and has replied to BOOTPC requests using source 158.161.29.175 and, at another time, 158.161.1.46. Killing the BOOTP daemon and restarting it cures the problem. While this abnormal behaviour is happening the rest of the IP stack seems to behave normally. Does the BOOTP daemon bypass the normal layer 3 routing functions? Most of the time the BOOTP daemon behaves great, and this problem seems to only manifest itself after system bootup with fsck problems. I am starting BOOTP from /etc/rc.local. Perhaps the fsck fix-ups are doing something which upsets the reading of bootptab? Seems unlikely, as this should not change the SOURCE address used in replies from the BOOTP daemon. The second BOOTP server has been running non-stop for 14 days, and so I have not seen the problem manifest itself from that PC. The strange thing is that the network part of the IP address used in the BOOTPS replies is still correct i.e. 158.161., and that the host part of the address corresponds to a host on our network. If the address was getting screwed up in memory, why are only the last two bytes changing? Looks like entries in /etc/bootptab are being taken as the source address for BOOTPS replies intermitenttly. I have not caught any BOOTPS replies on our protcol analysers yet, and am relying upon the BOOTPCHK information to conclude that a problem exists. If BOOTPCHK was the source of the wrong data, why does restarting BOOTPD fix the problem? Makes me suspicious of BOOTPD. >How-To-Repeat: Not really sure, as I have only seen it happen twice - sorry !!!! >Fix: Restart the BOOTP daemon. I have not tried kill -HUP on it, yet.