[CUWiN-Dev] Rev. 4085 disappearing default routes

[tom]

----- Original Message ----- 
From: "David Young" <dyoung at pobox.com>
To: <cu-wireless-dev at cuwireless.net>
Sent: Tuesday, July 18, 2006 8:09 PM
Subject: Re: [CUWiN-Dev] Rev. 4085 disappearing default routes


> On Tue, Jul 18, 2006 at 08:00:25PM -0500, David Young wrote:
>> On Tue, Jul 18, 2006 at 05:08:06PM -0500, tom wrote:
>> > I put a build of rev. 4085 made by Dan Blah on the downtown Urbana 
>> > network
>> > today. There's some funkiness with the routing that I don't understand.
>>
>> The wrong SSID, and a missing 10/16 address do not help:
>>
>> ath0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
>>         ssid domainname.tld
>>         powersave off
>>         bssid 02:02:6f:20:ed:44 chan 11
>>         address: 00:02:6f:20:ed:46
>>         media: IEEE802.11 autoselect mode 11b adhoc
>>         status: active
>>         inet 169.254.237.70 netmask 0xffff0000 broadcast 169.254.255.255
>>         inet6 fe80::202:6fff:fe20:ed46%ath0 prefixlen 64 scopeid 0x1
>>
>> Looks like pulling nodeconfig up to the trunk may have broken stuff.
>> Bryan, do you have time to look at this?
>>
>> I was looking at the routes in Zebra at 115 W. Main, (telnet localhost
>> 2601; type password 'wireless'; type 'show ip route') and they were
>> all marked 'inactive', for no apparent reason at all.  Stupid Zebra.
>> I restarted Zebra and many changed from 'inactive' to 'ath0', which is
>> what I expect.
>>
>> Tom, on the gateway, you had accidentally started a second hslsd
>> instance by typing 'hslsd status'.  I don't think it made any functional
>> difference.  You meant '/etc/rc.d/hslsd status'.  I will fix hslsd so
>> it errors-out if there are extra arguments, it's not user-friendly as-is.
>
> Aha!  It may be a problem that when we upgrade a node, the /etc/cuw_config
> from the last-good partition is copied to the new partition.  The upgrade
> script may need smartening-up to convert a configuration in the old
> style to the new style.
>
> Dave
>

Yarg, forgot to check the obvious. So you think the cuw_config file's format 
change is the cause? Do we usually need to copy settings over when upgrading 
(I can see why it would of course be useful, but don't the upgrades usually 
contain a working cuw_config file?). Could we build an upgrade file that had 
a good new version, to avoid having to write a script to convert the file 
from one format to another [not sure which is more complicated, just a 
thought].

Tom