[Cerowrt-devel] 3.3.6-2

[Dave Taht]

On Fri, May 25, 2012 at 7:41 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Robert,
>
> since I see the same log file on my router as Jim, I just want to report my observations below.
>
> On May 24, 2012, at 11:58 AM, Robert Bradley wrote:
>
>> On 24/05/12 19:15, Jim Gettys wrote:
>>> On 05/24/2012 02:12 PM, Sebastian Moeller wrote:
>>>> Hi Jim,
>>>>
>>>> good point, I will go and see whether that is the cause for my crashes… Will return to this post if/when I have new data in either direction…
>>> If you do, see if you can grab the babeld.conf file and add it to:
>>> https://www.bufferbloat.net/issues/392
>>>
>>
>> I don't know if it helps at all, but it looks like Babel's failing to obtain channel information for the guest interfaces (gw00 and gw10).

I am cc'ing the babel-users list. So it appears that the second
interface on a wireless radio,
does not report channel information reliably, OR babeld is not getting
it on the second interface
for some reason.

...sensing the channel is important so that diversity routing works.

Going back to vacation now.

>
>        True, in my case I had set the 2.4GHz radio to auto channel select, which does not seem to work well with either babeld or its specific configuration.
>
>> Are these disabled on your routers at the moment?  I suppose in the worst case you could try setting an explicit channel for both of the non-mesh guest interfaces and see if the logs clear up (or somehow pass "-L /dev/null" to babeld).
>
>        After setting the 2.4GHz channel to 1 instead of auto /tmp/babeld.log still grows with the same entries. And on a WNDR3700v2 there are 30840 KB of tmpfs on /tmp so the babeld.log size of 256KB should not by itself cause the router to crash. That said, while testing this hypothesis by filling most of /tmp (dd if=/dev/zero of=/tmp/delete_me bs=1024 count=30000, so that around 340KB stayed free) the router reliably went first into OOM and the rebooted itself. Might it be that the size of the /tmp filesystem is too large if actually used? If I naively add the VSZs of most processes I end up at around 90% of available memory, so worst case there actually only seems to be room for a much smaller /tmp than 30MB. . Maybe restricting /tmp to 6000 KB might make this problem go away (or hooking up a swap device). Does this reasoning sound sane? Once I figure out how to reduce the size of /tmp I will test this.
>
>
>>
>> I'm assuming the ad-hoc mesh links are working fine, since gw01/gw11 aren't present in the log fragment.
>
>        In my case I do not know as I never tried to test with a mesh client.

kill babel if you aren't using it, see what happens.

/etc/init.d/babeld disable
/etc/init.d/babeld stop


>
> best
>        Sebastian
>
>> --
>> Robert Bradley
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net