[Commotion-dev] [OTI-Tech] LTS Testing Update

Wed Apr 24 22:53:14 UTC 2013

Sorry to respond to myself, but ...

- "spurious" dhcp client requests are not so spurious. The udhcpc client
arguments are not as intuitive as "this programmer" would like them to
be. I.e., it appears that I misread. The options that we give udhcpc on
start up mean that it will fork to the background when it obtains a
lease and continue to periodically refresh that lease. Mystery solved.

Will

On 04/24/2013 06:49 PM, Will Hawkins wrote:
> A few notes to consider after some testing today with LTS and at the office:
> 
> - Collectd "stalled" one of the nodes at LTS (where collectd is still
> enabled)
> 
> - Stations seem to lose their mind w.r.t IBSS RSN and authorization. I'm
> watching debugging output from wpa_supplicant on one of the nodes in the
> office to see if I can determine the problem. Of course, it's working
> great now :-)
> 
> - luci_splash got itself into a nice "wedge" on one of the LTS nodes. I
> am going to do my best to get it unstuck. If we continue to see the
> problem, we'll have to take a hard look at pushing the splash rewrite to
> a higher priority.
> 
> Will
> 
> On 04/24/2013 04:26 PM, Ben West wrote:
>> Hi Will,
>>
>> I just checked config on a node again (running Attitude Adjustment circa
>> r35xxx), and I found these lines in /etc/crontabs/root which had been
>> commented out:
>>
>> #* * * * *      /usr/sbin/ff_olsr_test_gw.sh
>> #*/5 * * * *    /usr/sbin/ff_olsr_watchdog
>>
>> So, be on the lookout for ff packages that deploy these scripts,
>> although unfortunately it's not clear /which/ package includes these
>> particular files.  Maybe freifunk-common?
>>
>> On Wed, Apr 24, 2013 at 2:28 PM, Will Hawkins
>> <hawkinsw at opentechinstitute.org <mailto:hawkinsw at opentechinstitute.org>>
>> wrote:
>>
>>     Thanks for your response, Ben. We just recompiled an image w/o most of
>>     the ff software. We are now testing that image to see if things are any
>>     better. We will definitely note how ff-watchdog may be useful and how
>>     ff-gw-check is the likely culprit ;-)
>>
>>     Will
>>
>>     On 04/24/2013 02:17 PM, Ben West wrote:
>>     > The Freifunk watchdog package is actually a rather handy package,
>>     since
>>     > it will monitor any process you want (via periodic cronjob) and
>>     restart
>>     > that service if the active process disappears (aka crashes).  To my
>>     > knowledge, it doesn't directly start/stop any network interfaces.
>>      But,
>>     > ff-watchdog does need to be configured to monitor the processes
>>     you care
>>     > about, and to not conflict with any other watchdog-style task.  That
>>     > conflict may be indirectly causing interfaces to go down or even olsrd
>>     > to stop in absence of a needed interface.
>>     >
>>     > Its config file is /etc/config/freifunk-watchfog, and here is an
>>     example
>>     > config I've used (for node using coovachilli):
>>     >
>>     > config process
>>     >     option process 'dropbear'
>>     >     option initscript '/etc/init.d/dropbear'
>>     >
>>     > config process
>>     >     option process 'crond'
>>     >     option initscript '/etc/init.d/cron'
>>     >
>>     > config process
>>     >     option process 'olsrd'
>>     >     option initscript '/etc/init.d/olsrd'
>>     >
>>     > config process
>>     >     option process 'chilli'
>>     >     option initscript '/etc/init.d/coovachilli'
>>     >
>>     > Are you sure you weren't having problems with the ff-gw-check package
>>     > instead?  I.e. un-installed that package at the same time as
>>     > un-stinalling ff-watchdog?  I think the gw-check package /will muck/
>>     > with default routes and possibly also restart active network
>>     interfaces
>>     > if it can't get a successful ping to freifunk.net
>>     <http://freifunk.net> <http://freifunk.net>
>>     > or something.
>>     >
>>     > On Wed, Apr 24, 2013 at 8:07 AM, Dan Staples
>>     > <danstaples at opentechinstitute.org
>>     <mailto:danstaples at opentechinstitute.org>
>>     > <mailto:danstaples at opentechinstitute.org
>>     <mailto:danstaples at opentechinstitute.org>>> wrote:
>>     >
>>     >     Moving this discussion to commotion-dev...
>>     >
>>     >     When I was previously setting the wireless interfaces to use
>>     channel 9
>>     >     instead of channel 5, the freifunk watchdog would routinely
>>     bring down
>>     >     the wireless interfaces. And I have no idea why. The only way
>>     I got it
>>     >     to work was uninstalling ff-watchdog. So see if that may be a
>>     reason why
>>     >     wireless interfaces are unavailable...there should be a note
>>     about it in
>>     >     logread.
>>     >
>>     >     I've also noticed that something is killing olsrd on DR1
>>     nodes, without
>>     >     any clue in the log. The routing table will still have stale
>>     routes in
>>     >     it, indicating that olsrd isn't exiting cleanly. I wonder if
>>     it's being
>>     >     killed by the out-of-memory watchdog. When I was
>>     troubleshooting this
>>     >     before, I wrote a quick script that ran as a cronjob every
>>     minute, and
>>     >     it would pgrep olsrd. If olsrd was running, it would redirect
>>     the output
>>     >     of top into ~/top.out. If olsrd wasn't running, it would move
>>     the last
>>     >     ~/top.out as well as logread into a separate directory. That way,
>>     >     whenever olsrd was killed, there would be a record of top the
>>     minute
>>     >     before it crashed, as well as the log. Would this be useful for
>>     >     troubleshooting the LTS nodes?
>>     >
>>     >
>>     >
>>     > --
>>     > Ben West
>>     > http://gowasabi.net
>>     > ben at gowasabi.net <mailto:ben at gowasabi.net>
>>     <mailto:ben at gowasabi.net <mailto:ben at gowasabi.net>>
>>     > 314-246-9434 <tel:314-246-9434> <tel:314-246-9434 <tel:314-246-9434>>
>>     >
>>     >
>>     > _______________________________________________
>>     > Commotion-dev mailing list
>>     > Commotion-dev at lists.chambana.net
>>     <mailto:Commotion-dev at lists.chambana.net>
>>     > https://lists.chambana.net/mailman/listinfo/commotion-dev
>>     >
>>     _______________________________________________
>>     Commotion-dev mailing list
>>     Commotion-dev at lists.chambana.net
>>     <mailto:Commotion-dev at lists.chambana.net>
>>     https://lists.chambana.net/mailman/listinfo/commotion-dev
>>
>>
>>
>>
>> -- 
>> Ben West
>> http://gowasabi.net
>> ben at gowasabi.net <mailto:ben at gowasabi.net>
>> 314-246-9434
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
> 