You might consider writing a simple script that issues a "gratuitous" arp to the router and run it in rc.local (or equivalent). <div><br></div><div>Cheers,</div><div><br></div><div>Keith</div><div>KF7DRV</div><div>
Allstar: 2541<br><br><div class="gmail_quote">On Thu, Aug 25, 2011 at 10:01 PM, Kevin Walsh <span dir="ltr"><<a href="mailto:w8khw1@gmail.com">w8khw1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Jim,<br>
<br>
Thanks as always for the timely response.<br>
<br>
My requirement has nothing to do with DHCP. I believe that was the<br>
problem from the earlier post I mentioned, but that's not the problem<br>
herre.<br>
<br>
My BeagleBoard configuration is using a static IP address, the content<br>
 /etc/network/interfaces is posted below:<br>
<br>
#Static IP configuration<br>
auto lo<br>
auto usb0<br>
iface lo inet loopback<br>
iface usb0 inet static<br>
address 172.22.32.132<br>
netmask 255.255.255.0<br>
gateway 172.22.32.1<br>
<br>
<br>
(Note - I attempted to add the hwaddress tag to force a fixed mac<br>
address, but id didn't work.)<br>
<br>
The problem is that when the mac address of a device changes, the<br>
content of the arp table on my firewall can no longer talk to the<br>
BeagleBoard - because the MAC address changed. (IP address equals MAC<br>
address in arp lookup table, right?) If I clear the arp table on the<br>
firewall and then attempt to contact the BeagleBoard at the above<br>
static IP address, it will learn the new MAC address and associate the<br>
new MAC with the static IP. That all works fine until the BeagleBoard<br>
is re-started for whatever reason - and the whole problem above starts<br>
again.<br>
<br>
I would hate to have to put the BeagleBoard outside the firewall and<br>
dedicate a static routable IP address to just this device.<br>
<br>
Hope that helps explain the problem.<br>
<br>
73,<br>
Kevin<br>
W8KHW<br>
<div><div></div><div class="h5"><br>
<br>
<br>
On Thu, Aug 25, 2011 at 11:16 AM, Jim Duuuude <<a href="mailto:telesistant@hotmail.com">telesistant@hotmail.com</a>> wrote:<br>
> This "somewhat misfeature" of Pickle (or at least the Ubuntu distro) was<br>
> never intended. However when it was first pointed out to me a realized<br>
> how much of an incredible blessing in disguise it was.<br>
><br>
> The reason being is: Threre is NEVER, EVER, EVER, *ANY* reason<br>
> why ANYONE should trust a "toy" router to even accurately keep track of<br>
> much less observe static DHCP bindings. That is *JUST NOT* an acceptable<br>
> way of assigning a "static" LAN IP address.<br>
><br>
> Routers that allegedly support this "feature" (boy that's being nice)<br>
> generally<br>
> don't very well and/or stably. I have had NOTHING BUT HEADACHES over<br>
> the year when people attempt to do this. PLEASE, DONT LET IT HAPPEN<br>
> TO YOU.<br>
><br>
> Just assign a *REAL*static LAN IP on the Pickle system. Use the netsetup<br>
> script if you arent comfortable with editing files in the Ubuntu distro.<br>
> Assign<br>
> a LAN IP address that is outside the range that the router assigns DHCP<br>
> addresses. Sometimes, in rare cases, some routers will, by default<br>
> use the entire LAN range for assigning DHCP address. If so you<br>
> will need to configure the router to change this behavior, and "create"<br>
> a range of LAN addresses outside the routers range of DHCP addresses.<br>
><br>
> Believe me, this small amount of extra work when setting up a system<br>
> TOTALLY is worthwhile and WILL save you some major grief in the future.<br>
><br>
> JIM WB6NIL<br>
><br>
>> Date: Thu, 25 Aug 2011 02:21:19 -0400<br>
>> From: <a href="mailto:w8khw1@gmail.com">w8khw1@gmail.com</a><br>
>> To: <a href="mailto:app_rpt-users@ohnosec.org">app_rpt-users@ohnosec.org</a><br>
>> Subject: [App_rpt-users] New ACID release - BeagleBoard MAC Address<br>
>><br>
>> Hi,<br>
>><br>
>> I was wondering if the next pickle image might address the random MAC<br>
>> address issue. I saw there was a thread earlier on the list about this<br>
>> issue, but didn't find a resolution. I have found several references<br>
>> to "patches" that will correct the problem, but haven't really had<br>
>> time to dive into the issue. I did try setting a static MAC in the<br>
>> network config, but that didn't seem to work by itself.<br>
>><br>
>> The main issue I need to resolve is that I create a static NAT<br>
>> translation through my firewall to the BeagleBoard (based on the IP<br>
>> address). The firewall caches the MAC address associated with that IP<br>
>> address in the arp table, so when the BeagleBoard is re-started (and<br>
>> the MAC address changes) it will no longer work through the firewall<br>
>> unless I clear the firewall's arp table.<br>
>><br>
>> 73<br>
>> Kevin<br>
>> W8KHW<br>
>><br>
>> On Mon, Aug 22, 2011 at 6:14 AM, Jim Duuuude <<a href="mailto:telesistant@hotmail.com">telesistant@hotmail.com</a>><br>
>> wrote:<br>
>> > Its there now.. and no, the ISO file generally does not<br>
>> > change when a new release comes out.<br>
>> ><br>
>> > JIM<br>
>> ><br>
>> _______________________________________________<br>
>> App_rpt-users mailing list<br>
>> <a href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a><br>
>> <a href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users" target="_blank">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a><br>
><br>
_______________________________________________<br>
App_rpt-users mailing list<br>
<a href="mailto:App_rpt-users@ohnosec.org">App_rpt-users@ohnosec.org</a><br>
<a href="http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users" target="_blank">http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users</a><br>
</div></div></blockquote></div><br></div>