I just found these in /tmp:

-rw-------    1 root     root        212992 Feb  8 15:24 6relayd.1813.10.1360365840.core
-rw-------    1 root     root        212992 Feb  8 15:28 6relayd.5302.10.1360366081.core
-rw-------    1 root     root        212992 Feb  8 16:02 6relayd.7842.10.1360368124.core
-rw-------    1 root     root        212992 Feb  8 18:38 6relayd.17531.10.1360377511.core
-rw-r--r--    1 root     root            32 Feb  8 21:35 resolv.conf
-rw-------    1 root     root        212992 Feb  8 21:42 6relayd.32017.10.1360388528.core
-rw-------    1 root     root        212992 Feb  8 23:22 6relayd.9691.10.1360394532.core
-rw-------    1 root     root        212992 Feb  9 10:11 6relayd.27598.10.1360433505.core
drwx------    2 root     root            60 Feb  9 14:00 dropbear-e6d3c692
-rw-------    1 root     root        208896 Feb  9 14:22 6relayd.17656.11.1360448533.core
-rw-------    1 root     root        212992 Feb  9 21:01 6relayd.19682.10.1360472491.core
drwxr-xr-x    3 root     root            60 Feb  9 21:39 usr
-rw-------    1 root     root        212992 Feb 10 01:05 6relayd.6779.10.1360487123.core
-rw-------    1 root     root        212992 Feb 10 14:41 6relayd.4197.10.1360536110.core
-rw-------    1 root     root        212992 Feb 11 01:13 6relayd.19731.10.1360573985.core
-rw-------    1 root     root        212992 Feb 11 14:11 6relayd.22192.10.1360620700.core
-rw-------    1 root     root        212992 Feb 11 18:32 6relayd.11720.10.1360636373.core
-rw-------    1 root     root        212992 Feb 12 07:32 6relayd.6670.11.1360683148.core
-rw-------    1 root     root        212992 Feb 12 11:33 6relayd.28800.10.1360697619.core
-rw-------    1 root     root        212992 Feb 12 14:43 6relayd.10841.10.1360708993.core
-rw-------    1 root     root        212992 Feb 12 19:02 6relayd.30131.10.1360724561.core
-rw-------    1 root     root        212992 Feb 12 20:05 6relayd.5012.10.1360728350.core
-rw-------    1 root     root        212992 Feb 12 22:01 6relayd.9933.10.1360735302.core
-rw-------    1 root     root        212992 Feb 13 01:35 6relayd.29359.10.1360748130.core
-rw-------    1 root     root        212992 Feb 13 05:11 6relayd.13740.10.1360761092.core
-rw-------    1 root     root        212992 Feb 13 07:25 6relayd.25850.10.1360769135.core
-rw-------    1 root     root        212992 Feb 13 09:36 6relayd.5679.10.1360777016.core
-rw-------    1 root     root        212992 Feb 13 16:35 6relayd.7287.10.1360802104.core
-rw-------    1 root     root        212992 Feb 13 17:40 6relayd.12520.10.1360806033.core
-rw-r--r--    1 root     root            39 Feb 13 19:27 upnp.leases
-rw-------    1 root     root        212992 Feb 13 22:41 6relayd.4114.10.1360824095.core
-rw-------    1 root     root        212992 Feb 14 03:40 6relayd.28474.10.1360842031.core
-rw-------    1 root     root        212992 Feb 14 11:40 6relayd.2414.10.1360870811.core
drwxr-xr-x    6 root     root           540 Feb 14 14:36 run
-rw-------    1 root     root        212992 Feb 14 14:49 6relayd.16917.10.1360882151.core
drwx------    2 root     root            60 Feb 14 20:45 dropbear-e343d3d8

yes the wan side. ok seems there is a segfault in 6relayd. will investigate.

- r35608: collectd 5.2.1 test (Luci statistics)

With r35608 I am testing updating collectd from 4.10.8 to 5.2.1. I have already been running 5.2.1 a few days on my private builds and everything seems to work ok for me.

Hello Hnyman
Works fine for me too.
Data are erased on every reboot. Can be archived on a NAS (with syslog server, Synology)?
Soon.

I'm having trouble with port forwarding that worked well previously available.

Firewall is the standard one, there is nothing done by me. (based on changelog, jow made some changes a few days ago, so there might be some new bug.)

What was the last known good version?
And what is the exact rule that fails now?  (my own port-forwards seem to work)

I'm really sorry, I do not remember.

config redirect
    option target 'DNAT'
    option src 'wan'
    option dest 'lan'
    option src_dport '31342-31347'
    option dest_port '31342-31347'
    option src_ip '212.27.38.253'
    option name 'ADSLTV'
    option proto 'tcp udp'
    option dest_ip '192.168.1.2'

I inserted that rule to my firewall config file and it got accepted quite normally. No errors. Also Luci shows the correct forwarding.

I have to investigate a bit more on my side then.

I think the Luci statistics data directory is set in /etc/config/luci_statistics by the "DataDir" option. If you change that option to your NAS or some other permanent place, the data should probably be kept intact over reboots. (I haven't tested that.)

config statistics 'collectd_rrdtool'
        option enable '1'
        option DataDir '/tmp/rrd'
        option RRARows '100'
        option RRASingle '1'
        option RRATimespans '1hour 1day 1week 1month 1year'

Super!
I have not been able to send data to the NAS but it is quite feasible to the USB stick.

/etc/config/luci_statistics

config 'statistics' 'collectd_rrdtool'
    option 'enable' '1'
    option 'DataDir' '/mnt/storage/rrd'
    option 'RRARows' '100'
    option 'RRASingle' '1'
    option 'RRATimespans' '1hour 1day 1week 1month 1year'

/etc/collectd.conf

LoadPlugin rrdtool
<Plugin rrdtool>
    DataDir "/mnt/storage/rrd"
    RRARows 100
    RRASingle true
    RRATimespan 3600
    RRATimespan 86400
    RRATimespan 604800
    RRATimespan 2678400
    RRATimespan 31622400
</Plugin>

Can you please send me one of those .core files to cyrus-at-openwrt-org and tell me which OpenWrt revision and architecture you've used.

Cyrus, I sent 3 dumps, a tcpdump of the wan side, and information on which build it's running.

Thanks that helped a lot. I commited an update which adds some more sanity checks about the problematic section and might fix the problem. I couldn't really find or reproduce the issue yet.

It will be a few days (probably Friday) before I can get an update applied to see if it fixes the problem..

I just upgrade the router to this:

root@bazzle:~# cat /etc/openwrt_*
DISTRIB_ID="OpenWrt"
DISTRIB_RELEASE="Bleeding Edge"
DISTRIB_REVISION="r35725"
DISTRIB_CODENAME="barrier_breaker"
DISTRIB_TARGET="ar71xx/generic"
DISTRIB_DESCRIPTION="OpenWrt Barrier Breaker r35725"
r35725

which has

6relayd - 2013-02-19-186ebf632dfe48aa7df76f256949eea88067394d

I'll post if it breaks; I'm still getting lots of dnsmasq nameserver updates..

So, 6relayd died again..

OK. I just ordered an atheros router and will run some tests on that later on.

I'm trying to compile up the complete system so I can also do some debug work on it..  I just don't have lots of time (for reference, I've done Linux kernel work (bonding driver in the kernel was mine, for example).

A little waiting, and some debugging shows that..

When the br-lan device returns a 132 (ERRF-KILL), you need to close and then re-open the netlink socket; the bridge is changing config for some reason (WDS? I dunno) and then it's back to normal..

I see so when a netlink-error message with code ERFKILL is returned then the socket must be restarted?

I guess that mainly refers to the rtnl-socket querying for interface addresses. However I still not see how this could cause a SIGBUS or any illegal memory access leading to one.

I just ran 6relayd on a wifi-interface locally then turned rfkill on and off but valgrind couldn't find anything unusual. Could you maybe elaborate a bit more on your finding?

Thanks a lot

(Last edited by CyrusFF on 28 Feb 2013, 08:52)

Hello CyrusFF, first thanks for the light-weight IPV6-Support package.
I don't know if my problem is connected with what tdavis described. But whenever I did "/etc/init.d/network restart" - no matter the configuration changed or not, the 6relayd disappeared from the process list. I have to then did a "/etc/init.d/6relayd start" to get the IPV6 available for my home LAN. Despite that , everything seemed to be working well. I'm using my own build of latest trunk build and using he.net IPV6 broker.

(Last edited by hato on 28 Feb 2013, 14:36)

It is normal that 6relayd restarts when the network is restarted but it should come up again immediately afterwards.
Please check whether there are files beginning with 6relayd and ending with .core in your /tmp and if so please send me a mail to cyrus-at-openwrt-dot-org.

Also please post all further 6relayd-related stuff and related answers here:
https://forum.openwrt.org/viewtopic.php?pid=193291#p193291

Did you by chance install any other memory/CPU intensive packages (i.e. Transmission, netatalk, etc.)? I noticed that 6relayd has a tendency to die due to page allocation errors if the system is under high load and will continue to die over and over again. So I just disabled and stopped running collectd. I'm going to try vnstat for data collection later on today to see if the problem occurs with that package as well.