bootpd / arp table update problem

bootpd / arp table update problem

Post by Kevin Cousi » Sat, 27 May 1995 04:00:00



We have an i486 with NetBSD 1.0 installed. This box is serving bootp
requests to a dozen or so embedded clients.

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?

--Kevin.

--

--Kevin.

"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


 
 
 

bootpd / arp table update problem

Post by Curt Samps » Sat, 27 May 1995 04:00:00




>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.

cjs
--

Internet Portal Services, Ltd.     Beside the willow'd river bank
Vancouver, BC   (604) 257-9400     Repose I, still and thinking...

 
 
 

bootpd / arp table update problem

Post by Kevin Cousi » Sat, 03 Jun 1995 04:00:00




>>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.

"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


 
 
 

bootpd / arp table update problem

Post by Curt Samps » Sat, 03 Jun 1995 04:00:00




>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?

This is something that should definitely go back to the bootpd
maintainer (who is currently Gordon Ross, of sun3-port fame :-)).

However, there are two choices of what to put in. The more portable
method is to use system() and call the arp program. The better
method (though one subject to change if NetBSD changes) is to add
a new section to the bootpd code that uses the same techniques as
arp.c to muck about with the arp table.

Offhand, I can't say which is preferable, only which is easier.

cjs
--

Internet Portal Services, Ltd.     Beside the willow'd river bank
Vancouver, BC   (604) 257-9400     Repose I, still and thinking...

 
 
 

bootpd / arp table update problem

Post by Christos Zoul » Sat, 03 Jun 1995 04:00:00





>>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?

>This is something that should definitely go back to the bootpd
>maintainer (who is currently Gordon Ross, of sun3-port fame :-)).

>However, there are two choices of what to put in. The more portable
>method is to use system() and call the arp program. The better
>method (though one subject to change if NetBSD changes) is to add
>a new section to the bootpd code that uses the same techniques as
>arp.c to muck about with the arp table.

>Offhand, I can't say which is preferable, only which is easier.

Long time ago I sent a patch that made entries in sbin/arp [util.c]
to make the arp interface easier to use. I still have the patches and
I can port them to current. What does `core' think of this?

The routines were arp_open, arp_add, arp_delete, arp_get, arp_close?

christos

 
 
 

bootpd / arp table update problem

Post by Alan Strassbe » Sat, 03 Jun 1995 04:00:00




>We have an i486 with NetBSD 1.0 installed. This box is serving bootp
>requests to a dozen or so embedded clients.

>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'.

        This is fixed in the latest bootpd and solved this problem
        for me using BSD/OS.

        The latest bootpd is available from:
        ftp://firewall.mc.com/pub/bootp-2.4.3.tar.Z

        And the patches to add DHCP are found:
        ftp://nimbus.anu.edu.au/pub/tridge/samba/contributed/DHCP.patch

                                        alan
--
-------------

Lockheed Martin - Santa Cruz, California.

 
 
 

1. ARP table does not update

Dear All,
I have this problem on several Sun on our LAN.
When our LAN manager replaces the firewall box that divides
2 parts of the same LAN or the dns box
(same ip-address but different mac-address)
my SUNs can not reach the other part of the network, while other
linux box could reach one to each other on the same 2 branches of the
network.
It seems that those computer do not recognize that
the couple ip-address mac-address has change.
When I reboot, than everything work fine again.

Unfortunately I missed the chance to delete the ARP entry
from the table and see what happen.

Do you have any suggestion for fixing the problem?

Thanks in advance
   Marco

2. OpenServer 5 (and Linux) install question (FAQ?)

3. ARP table update

4. Microsoft Mouse Problem

5. ARP table not getting updated

6. Linux Document Management

7. ARP table do not update

8. DEC 3000 300L

9. bootpd for Solaris 2.x -- bootpd.c source problem?

10. bootpd arp probs?

11. BOOTPD and ARP errors

12. ARP Table problems.

13. Problems with ARP tables