<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 24, 2014 at 3:23 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Fri, Jan 24, 2014 at 6:08 PM, Steve Jenson <<a href="mailto:stevej@fruitless.org" target="_blank">stevej@fruitless.org</a>> wrote:<br>
> Hi everybody,<br>
><br>
> I've been using cerowrt as a secondary wifi network (just a single AP for<br>
> now) for a few weeks now. Recently, my wndr3800 got stuck in a bad state and<br>
> eventually rebooted. I've had this happen a few times now and am looking for<br>
> ways to debug the issue. I'm new to cerowrt and openwrt so any advice is<br>
> appreciated.<br>
><br>
> Since I use it as a secondary network, this is no way critical.<br>
<br>
</div>Yea! I appreciate caution before putting alpha software on your gw.<br>
<div><br>
> I'm not<br>
> looking for free tech support but I couldn't find anything on the wiki about<br>
> troubleshooting. I'd love to start a page and write some shell scripts to<br>
> diagnose and report issues. I know that a cerowrt router is meant to be a<br>
> research project rather a consumer device but these things seem helpful<br>
> regardless.<br>
<br>
</div>Sure, let me know your wiki account. I have been lax about granting<br>
access of late as the signup process is overrun by spammers.</blockquote><div><br></div><div>My username is stevej on the wiki. Thanks! </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
> Please let me know if you'd prefer I not email the list with these issues or<br>
> if you'd rather I used trac or a different forum.<br>
><br>
<br>
</div>The list is where most stuff happens. Also in the irc channel.<br>
<br>
If it gets to where it needs to be tracked we have a bugtracker at<br>
<br>
<a href="http://www.bufferbloat.net/projects/cerowrt/issues" target="_blank">http://www.bufferbloat.net/projects/cerowrt/issues</a><br>
<br>
The first question I have is: Are you on comcast? Cerowrt<br>
had a dhcpv6-pd implementation that "just worked" from feburary through<br>
december. Regrettably they changed the RA announcement interval<br>
to a really low number around then... and this triggers a firewall reload<br>
every minute on everything prior to the release I point to below.<br>
<br>
If there is a memory leak somewhere that would have triggered it.</blockquote><div><br></div><div>I am on AT&T ADSL2+ with a Motorola NVG510 modem. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div>> In this state, I can connect to the cerowrt base station via wifi but am<br>
> unable to route packets to the internet. I can connect to :81 and see the<br>
> login page but logging in results in a lua error at `/cgi-bin/luci`<br>
><br>
><br>
> /usr/lib/lua/luci/dispatcher.lua:448: Failed to execute function<br>
> dispatcher target for entry '/'.<br>
> The called action terminated with an exception:<br>
> /usr/lib/lua/luci/sauth.lua:87: Session data invalid!<br>
> stack traceback:<br>
> [C]: in function 'assert'<br>
> /usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch'<br>
> /usr/lib/lua/luci/dispatcher.lua:195: in function<br>
> </usr/lib/lua/luci/dispatcher.lua:194><br>
><br>
> I can ssh into the device and cat various log files until the router hangs<br>
> and reboots. here's a few relevant lines from my terminal history before the<br>
> device rebooted (I'm assuming a watchdog kicked in and rebooted it).<br>
><br>
> root@buffy2-1:~# ping <a href="http://google.com" target="_blank">google.com</a><br>
> ping: bad address '<a href="http://google.com" target="_blank">google.com</a>'<br>
> root@buffy2-1:~# free<br>
> total used free shared buffers<br>
> Mem: 126336 110332 16004 0 5616<br>
> -/+ buffers: 104716 21620<br>
> Swap: 0 0 0<br>
> root@buffy2-1:~# uptime<br>
> 02:08:54 up 2 days, 1:26, load average: 0.10, 0.21, 0.17<br>
> root@buffy2-1:~# dmesg<br>
> [ 0.000000] Linux version 3.10.24 (cero2@snapon) (gcc version 4.6.4<br>
> (OpenWrt/Linaro GCC 4.6-2013.05 r38226) ) #1 Tue Dec 24<br>
> 10:50:15 PST 2013<br>
> [skipping some lines]<br>
><br>
> [ 13.156250] Error: Driver 'gpio-keys-polled' is already registered,<br>
> aborting...<br>
> [ 19.414062] IPv6: ADDRCONF(NETDEV_UP): ge00: link is not ready<br>
> [ 19.421875] ar71xx: pll_reg 0xb8050010: 0x11110000<br>
> [ 19.429687] se00: link up (1000Mbps/Full duplex)<br>
> [ 22.140625] IPv6: ADDRCONF(NETDEV_UP): sw00: link is not ready<br>
> [ 23.351562] IPv6: ADDRCONF(NETDEV_CHANGE): sw00: link becomes ready<br>
> [ 23.757812] ar71xx: pll_reg 0xb8050014: 0x11110000<br>
> [ 23.757812] ge00: link up (1000Mbps/Full duplex)<br>
> [ 23.773437] IPv6: ADDRCONF(NETDEV_CHANGE): ge00: link becomes ready<br>
><br>
> root@buffy2-1:~# ifconfig<br>
> ge00 Link encap:Ethernet HWaddr 2C:B0:5D:A0:C5:B1<br>
> inet addr:192.168.1.138 Bcast:192.168.1.255 Mask:255.255.255.0<br>
> inet6 addr: fe80::2eb0:5dff:fea0:c5b1/64 Scope:Link<br>
> inet6 addr: 2602:30a:2cdb:330:2eb0:5dff:fea0:c5b1/64 Scope:Global<br>
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br>
> RX packets:1469670 errors:0 dropped:8 overruns:0 frame:0<br>
> TX packets:547733 errors:0 dropped:0 overruns:0 carrier:0<br>
> collisions:0 txqueuelen:1000<br>
> RX bytes:229243410 (218.6 MiB) TX bytes:57304808 (54.6 MiB)<br>
> Interrupt:5<br>
><br>
> lo Link encap:Local Loopback<br>
> inet addr:127.0.0.1 Mask:255.0.0.0<br>
> inet6 addr: ::1/128 Scope:Host<br>
> UP LOOPBACK RUNNING MTU:65536 Metric:1<br>
> RX packets:23689 errors:0 dropped:0 overruns:0 frame:0<br>
> TX packets:23689 errors:0 dropped:0 overruns:0 carrier:0<br>
> collisions:0 txqueuelen:0<br>
> RX bytes:2612713 (2.4 MiB) TX bytes:2612713 (2.4 MiB)<br>
><br>
> pimreg Link encap:UNSPEC HWaddr<br>
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00<br>
> UP RUNNING NOARP MTU:1472 Metric:1<br>
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br>
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0<br>
> collisions:0 txqueuelen:0<br>
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)<br>
><br>
> se00 Link encap:Ethernet HWaddr 2E:B0:5D:A0:C5:B0<br>
> inet addr:172.30.42.1 Bcast:172.30.42.31 Mask:255.255.255.224<br>
> inet6 addr: 2602:30a:2cdb:330:2eb0:5dff:fea0:c5b1/64 Scope:Global<br>
<br>
</div></div>How are you assigning your ipv6 addresses?<br></blockquote><div><br></div><div>It's been a while since I messed with this but I think IPv6 is assigned thanks to 6relayd? My modem has IPv6 enabled but no DHCPv6 options that I can find. Here's how cerowrt is configured.<br>
</div><div><br></div>root@buffy2-1:/overlay/etc/config# cat 6relayd<br>config server 'default'<br> option fallback_relay 'rd dhcpv6 ndp'<br> list network 'ge00'<br> list network 'ge01'<br>
list network 'gw00'<br> list network 'gw01'<br> list network 'gw10'<br> list network 'gw11'<br> list network 'se00'<br> list network 'sw00'<br> list network 'sw10'<br>
option rd 'relay'<br> option dhcpv6 'relay'<br> option ndp 'relay'<br> option master 'ge00'<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div><br>
> inet6 addr: fe80::2cb0:5dff:fea0:c5b0/64 Scope:Link<br>
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br>
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br>
> TX packets:191740 errors:0 dropped:0 overruns:0 carrier:0<br>
> collisions:0 txqueuelen:1000<br>
> RX bytes:0 (0.0 B) TX bytes:42184988 (40.2 MiB)<br>
> Interrupt:4<br>
><br>
> sw00 Link encap:Ethernet HWaddr 2C:B0:5D:A0:C5:B0<br>
> inet addr:172.30.42.65 Bcast:172.30.42.95 Mask:255.255.255.224<br>
> inet6 addr: 2602:30a:2cdb:330:2eb0:5dff:fea0:c5b1/64 Scope:Global<br>
> inet6 addr: fe80::2eb0:5dff:fea0:c5b0/64 Scope:Link<br>
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br>
> RX packets:70239 errors:0 dropped:0 overruns:0 frame:0<br>
> TX packets:286967 errors:0 dropped:0 overruns:0 carrier:0<br>
> collisions:0 txqueuelen:1000<br>
> RX bytes:15590189 (14.8 MiB) TX bytes:127357293 (121.4 MiB)<br>
><br>
> root@buffy2-1:~# less /var/log/babeld.log<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> send: Cannot assign requested address<br>
> send: Cannot assign requested address<br>
> send: Cannot assign requested address<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> netlink_read: recvmsg(): No buffer space available<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
> Couldn't determine channel of interface sw00: Invalid argument.<br>
<br>
</div></div>This is a problem in babel detecting the channel on a "normal"<br>
rather than a mesh interface. It's bugged me a long while, but<br>
haven't got around to finding what triggers it. Might "fix" it by<br>
acquiring the channel at babel start time from /etc/config/wireless.<br>
<br>
It messes up the diversity routing calculation, grump.<br>
<br>
There is a possibility a logfile got really big, but this one<br>
generally doesn't, but I should turn off logging in some<br>
future release...</blockquote><div><br></div><div>I believe I've tracked down part of what's going on. It looks like my tmpfs is filling up 100% and then the device enters a bad state:</div><div><br></div><div>After 24 hours, with tmpfs at 50%, babeld.log is the largest file by far in tmpfs and the only file that appears to be growing (based on `du`). It takes about 48 hours from reboot to fill up tmpfs on my device.</div>
<div><br></div><div>
<p class=""># sort babeld.log | uniq -c |sort -rn |head<br></p></div><div>
<p class=""> 503236 Couldn't determine channel of interface sw00: Invalid argument.</p>
<p class=""> 1376 netlink_read: recvmsg(): No buffer space available</p>
<p class=""> 3 send: Cannot assign requested address</p></div><div><div><p class=""># wc -l babeld.log</p><p class="">504617 babeld.log</p></div></div><div>I sped up system failure by using `dd` to fill up tmpfs and the system became immediately unusable.</div>
<div><br></div><div>This also explains the luci session store errors as sessions are stored in tmpfs.</div><div><br></div><div>The other buffer issues may or may not be related to this.</div><div><br></div><div>Best,</div>
<div>Steve</div></div></div></div>