Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yoyo.aarnet.edu.au!spasun.tpa.com.au!myall.awadi.com.au!myall!kcousins From: kcousins@awadi.com.au (Kevin Cousins) Newsgroups: comp.unix.bsd.netbsd.misc Subject: Re: bootpd / arp table update problem Date: 2 Jun 95 00:34:07 Organization: AWA Network Engineering Lines: 39 Message-ID: <KCOUSINS.95Jun2003407@desertoak.awadi.com.au> References: <KCOUSINS.95May26125242@desertoak.awadi.com.au> <3q54us$cp1@stud.Direct.CA> NNTP-Posting-Host: desertoak.awadi.com.au In-reply-to: curt@cynic.portal.ca's message of 26 May 1995 17:59:56 GMT > In article <KCOUSINS.95May26125242@desertoak.awadi.com.au>, > Kevin Cousins <kcousins@awadi.com.au> wrote: > >>It appears that initially everything goes along fine, until one of >>the clients is reset and performs its bootp request again. >> >>At that point, bootpd complains about 'arp failed, exit code 0x100'. >> >>'arp -a' lists MAC address of the client whose request failed as >>'(incomplete)'. >> >>Deleting the offending entry from the arp table temporarily corrects >>the problem. >> >>What gives? Has anyone seen this behaviour before? > > I have. The bootpd is using a system() call to arp(8) to add the arp > entry for that host to the arp table so that it can send back the > reply. It can't add the arp entry if it's already there. Just hack > the source to do an `arp -d' just before it does the `arp -a' to > try to add the arp entry. Well spotted, Curt. Eventually we got brave, found the problem and wound up putting that exact same hack in place. Now it works, sweet as a button. So, who else needs to be notified of this? Is this fix worthy of being bundled in a patch release? -- --Kevin. kcousins@awadi.com.au "Scientists [in Paris] have found that, instead of building up to a grand climax, the uranium-fission chain reaction runs down like an unwound watch." - Scientific American, May, 1940 CT iv- u+(-) c 1/1/2 r@ f? h-- p++ o+ s+ d y+ CWF w-