Re: /etc/rc.d/location script issues... (location.sh)

Peter,

Peter Losher wrote:
> So I have been using Lars Eggert's location.sh (v1.25) script (seen at 
> http://www.isi.edu/larse/etc.html), and it's just what I am looking for 
> as I am usually at several sites, with a mix of wireless and wired net 
> access. (esp. now that I can use the Broadcom NIC on my Inspiron 5100 in 
> -current - Yay!)  However I have some issues, and I wondered whether 
> anyone has come across them, and if they got around them.
> 
> First - is there any way to specify what interfaces get probed by the 
> script?  With my wireless card, I have three possible NIC's - the 
> wireless card (wi0), the on-board Broadcom BCM4401 (bfe0), and the 
> support for a Firewire NIC (fwe0).  Now I don't ever see myself plugging 
> in a Firewire NIC anytime soon, so I would rather not have that 
> interface probed.  I have tried setting "network_interfaces="wi0 bfe0 
> lo0"" in rc.conf, but it looks like location.sh doesn't honor it.

it probes all interfaces it finds, except loopback. I had not thought 
about limiting this, but if you have a patch to restrict probing to 
$network_interfaces, please send it to me.

> Second - Anyone get this around 10 times when each interface doesn't get 
> a response to a ping?
> 
> Can't grep /var/run/dhclient.leases : No such file or directory
> (another reason why I don't want fwe0 probed, it's another delay)

There's probably some error redirection into /dev/null missing. You can 
also try lowering probe_delay.

> Third - How do you find out what IP should be probed?.  I have been able 
> to detect wireless hubs/AP's just fine, but esp. on wired nets, I have 
> tried probing switches, default route, etc. and I get no ping response.

Probing works best with the arping port installed. The ping/shcp probes 
don't work in many cases. If you don't have arping installed, I strongly 
recommend it.

Good peers for probing are nodes at a given location that don't change 
IP addresses often, e.g., routers and servers.

Lars
-- 
Lars Eggert <[email protected]>           USC Information Sciences Institute