**** BEGIN LOGGING AT Mon Apr 05 02:59:56 2010 Apr 05 03:08:13 nico * r20716 /packages/net/appweb/Makefile: [packages] appweb: not ported to avr32 (yet) Apr 05 03:25:26 cshore: ping? Apr 05 07:15:06 build #49 of brcm_2_4 is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/brcm_2_4/builds/49 Apr 05 10:25:59 would there be a way to have the rspro switch pass multicast to eth1, without ar8316 switch support? Apr 05 10:26:22 if not, backfire wont even be usable with rspro Apr 05 10:30:04 you should highlight me ;-) Apr 05 10:30:45 stintel: and no, there won't be - any way I can think of needs configuration of the switch Apr 05 10:31:51 too bad Apr 05 10:32:04 although, since the rs pro redboot allows write access to the ar71xx registers, you could probably write a boot script for it that sets the correct register in the switch Apr 05 10:32:10 guess I can start looking for other hardware then :( Apr 05 10:40:16 sigh, bloody atheros / ubiquiti, just feel like throwing away my rspro right now Apr 05 10:44:49 gmorning Apr 05 10:45:31 stintel: btw, what's the problem with building your own image? Apr 05 10:46:13 and I am sure the ar8316 support code will get into trunk eventually Apr 05 10:47:23 stintel: you can always use a trunk snapshot once KanjiMonster's ar8316 patches are committed, and they'll probably be backported into the backfire branch Apr 05 10:47:58 I was told it was unlikely that they would be in the 10.03 release, probably in a next point release Apr 05 10:48:25 I have several customers waiting for a device like the rspro, but they need vlan and/or multicast, and I will not sell them anything that isn't "stable" Apr 05 10:48:33 so I need to find other hardware Apr 05 10:49:19 ah I see Apr 05 10:49:38 even the releases aren't necessarily stable.. if you build your own image based off the stable branch, then test it out for a while, it's likely to be just as good as waiting for the next release Apr 05 10:51:22 stintel: what about using the backfire relase tag with just the ar8316 patches? Apr 05 10:53:29 possibilities, but then again I dont feel liek sponsoring atheros nor ubiquiti anymore, if that's their idea of "support" (releasing something then let the community figure out the bits and pieces) Apr 05 10:59:22 I can understand you, I don't like it either. Do you already know with what you'll replace the rs pro? Apr 05 11:00:46 not yet, I'll start looking soon Apr 05 11:01:53 I'll let you know when I find anything Apr 05 11:02:07 maybe some retail thing based on ar71xx Apr 05 11:02:21 saves me the assembly too :) Apr 05 11:05:07 I don't know if common with other manufacturers, but at least d-link seems to be fond of replacing ar71xx with ralink chips currently Apr 05 11:08:54 I have terrible experience with any dlink device I ever touched, so to me dlink doesnt exist anymore :P Apr 05 11:12:14 this was more meant as evidence that atheros isn't really loved by manufacturers either ;) Apr 05 11:15:05 well it sucks coz I've always liked their hardware :( Apr 05 11:22:22 build #49 of brcm47xx is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/49 Apr 05 11:41:21 <_trine> stintel, I like my wndr3700 Apr 05 11:53:48 build #36 of au1000 is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/au1000/builds/36 Apr 05 11:57:19 updated openwrt/upstream, http://home.comcast.net/~sdwalker/packages.shtml Apr 05 12:04:42 [florian]: ping Apr 05 12:06:57 build #48 of sibyte is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/48 Apr 05 12:17:26 _trine: thx Apr 05 12:18:24 _trine: the switch is supported ? Apr 05 13:51:29 jow * r20717 /trunk/package/switch/ (Makefile files/switch.sh): [package] switch: explicitely clear port mappings in unsused vlans (#7082) Apr 05 13:52:16 jow * r20718 /branches/backfire/package/switch/ (Makefile files/switch.sh): [backfire] merge r20717 Apr 05 14:04:34 build #46 of octeon is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/46 Apr 05 14:04:59 build #51 of brcm63xx is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/51 Apr 05 15:19:22 build #36 of ramips is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ramips/builds/36 Apr 05 15:26:41 build #51 of avr32 is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/avr32/builds/51 Apr 05 15:32:15 is it ok, if I assign the asus rt-n16 ticket to myself (as I'm working on it)? Apr 05 15:42:21 rtz2: yes Apr 05 16:29:56 holy crap Apr 05 16:30:00 since when does make[3] -C target/linux install Apr 05 16:30:05 take hours Apr 05 16:30:18 Weedy: it shouldn't Apr 05 16:30:25 since there are missing symbols and you run w/o V=99 Apr 05 16:31:51 build #36 of s3c24xx is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/36 Apr 05 16:35:10 Last login: Mon Apr 5 16:31:59 Local time zone must be set--see zic manual page 2010 on tty1 Apr 05 16:35:14 zomfg ~ # Apr 05 16:47:20 build #45 of ep93xx is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/45 Apr 05 16:58:38 cshore: ping? Apr 05 17:01:24 philipp64: pong Apr 05 17:01:29 howdy. Apr 05 17:02:00 I understand you know the startup scripts pretty well? I'm trying to bring up a new target... the soekris net5501 (the net4501 and net4801 are no longer manufactured). Apr 05 17:02:30 problem is that it hangs just after loading up cs5535_gpio.ko (which seems to fail). Apr 05 17:02:55 can't tell what it's trying to do next when it hangs. is there a way to add tracing to the scripts? Apr 05 17:05:45 https://lists.openwrt.org/pipermail/openwrt-devel/2010-March/006446.html is a thread entitled " Howto debug init scripts like preinit. I suggest you read that thread Apr 05 17:06:49 do you load cs5535_gpio specially, or just with the regular kernel module load? Apr 05 17:07:56 init happens in two stages...preinit which is before multiuser and init in which the rootfs has been mounted Apr 05 17:09:17 preinit's job is to take care of essential like setting up the tmpfs and initializing the flash and mounting the rootfs Apr 05 17:13:37 I built the net5501 as a subtarget, and it uses several kmod targets, including nsc_gpio, cs5535_gpio, and pc8736x_gpio... though looking at a running system, on cs5535_gpio is loaded. Apr 05 17:15:59 philipp64: the module loading happens after preinit mounted the rootfs, you can enter failsafe and do something like this to trace down the issue: Apr 05 17:15:59 grep ^[a-z0-9] /etc/modules.d/* | while read mod; do echo "loading [$mod]"; insmod $mod; done Apr 05 17:19:49 did that.... but lsmod doesn't show any modules as being loaded. Apr 05 17:20:11 is /proc mounted? Apr 05 17:20:25 yes. Apr 05 17:20:38 xMff: proc is mounted before failsafe Apr 05 17:20:48 /proc/modules empty as well? Apr 05 17:20:53 fyi: set -x doesn't work... Apr 05 17:21:15 xMff: yes Apr 05 17:21:29 sounds like some general kernel issue then Apr 05 17:23:14 I also noticed that cs5535_gpio.ko gets assigned priority 90, but nsc_gpio was assigned 40. how do these get chosen? Apr 05 17:24:01 it is specified with the AutoLoad macro in the module package definition Apr 05 17:43:26 uploaded new diffs... ftp://ftp.redfish-solutions.com/pub/net5501.patch ... rebuilding now. Apr 05 17:43:55 btw, bad things happen when you type "cat /proc/kmsg" ... Apr 05 17:45:57 philipp64: that's not normal Apr 05 17:46:11 cshore: read the thread, most of it made sense... but not sure why /dev/console isn't present earlier. Apr 05 17:46:40 philipp64: where should it come from? Apr 05 17:47:42 couldn't say... what's involved in getting it set up, other than the mknod? Apr 05 17:48:04 philipp64: well, the tmpfs has to get mounted on /dev Apr 05 17:48:09 philipp64: but that's it Apr 05 17:55:52 anything obviously wrong stand out in the diffs? Apr 05 18:00:21 jow * r20719 /branches/backfire/feeds.conf.default: [backfire] switch LuCI feed to v0.9.0 tag Apr 05 19:03:36 well, I'm at a dead-end. Apr 05 19:37:22 and a friend and I were working on a wrt400n wiki page. It got deleted with "Now stop this!" ? Apr 05 19:37:39 xMff: ^ Apr 05 19:38:12 LetoTo: sorry for that, it was a troll - I reverted the page to its previous state Apr 05 19:38:50 thanks Apr 05 19:39:06 we were about to add more info to the page (started out as a copied page for similar setup) Apr 05 19:40:51 xMff: is there any interest in infos from upcoming routers gained from fcc filings? And if yes, where do they belong? Apr 05 19:41:02 I figured, apparently the user in question does not understand that such pages need time for completion Apr 05 19:41:29 KanjiMonster: you mean for the toh? Apr 05 19:41:36 yeah Apr 05 19:42:04 why noz Apr 05 19:42:07 *why not Apr 05 19:42:13 this is of course more like "not yet clear whether it runs linux at all", and is mosty missing information about flash, ram, etc Apr 05 19:42:39 yeah and if they become supported they could be quickly reused Apr 05 19:43:09 but I would rather like some rewriting effort for older popular devices, like fonera or the wl500g* Apr 05 19:54:25 swalker: ping Apr 05 20:27:05 I'm trying to add IPsec functionality to OpenWrt with StrongSwan... so far I've made an init script to pull values from UCI, create an ipsec.conf, and start the tunnels, so far so good Apr 05 20:27:41 the problem I have is that StrongSwan adds some firewall rules via an updown script, and I'm trying to make sure these rules stick around even if the firewall is restarted Apr 05 20:28:26 StrongSwan's updown script is fairly robust so I didn't want to heavily modify it or remove it Apr 05 20:29:04 so I was wondering what you guys thought would be the cleanest way to do this? Apr 05 20:30:18 aport: I'm having the same problem with miniupnpd Apr 05 20:30:44 I'm thinking we need to be able to save our special chains and restore them Apr 05 20:30:49 I agree Apr 05 20:31:12 right now /etc/init.d/firewall stop just blows out everything Apr 05 20:31:26 firewall includes are supposed to be the workaround for this Apr 05 20:31:43 but for dynamic rules they don't really work so well Apr 05 20:31:46 but only works for non-dynamic right Apr 05 20:31:47 right Apr 05 20:32:09 would iptables save/restore help...and just add back a link to the chain? Apr 05 20:32:35 yeah you could probably generate a firewall include based on iptables-save Apr 05 20:33:47 nbd, xMff, what do you think of making iptables save/restore part of the base system? Apr 05 20:34:16 I suppose in the firewall UCI you could specify chains to save and restore Apr 05 20:34:43 aport: that sounds workable to me Apr 05 20:34:48 I'm going to try it Apr 05 20:35:10 I'll have to modify the strongswan updown to add rules to a "strongswan_forward" chain instead of "FORWARD" Apr 05 20:35:32 but that would be a trivial task and well worth it if uci_firewall could save/restore that chain Apr 05 20:36:01 build #43 of cobalt is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/cobalt/builds/43 Apr 05 20:38:18 aport: yes...now you don't have to survive reboots, right, just restart of the network/firewall Apr 05 20:38:26 ? Apr 05 20:39:13 I suspect for surviving reboots you have to copy the save to the flash somewhere, since the /var by default is a symlink to the /tmp on tmpfs Apr 05 20:39:49 aport: but that's hard on the flash anyway, so better if now necessary Apr 05 20:39:55 now=not Apr 05 20:41:47 cshore, I don't have to survive reboots because the ipsec init/strongswan will load the dynamic rules on bootup (after the firewall starts) Apr 05 20:42:03 so as of right now whenever I make firewall changes or anything, I just reboot the unit Apr 05 20:42:27 the issue shows up when the firewall is restarted after dynamic rules have been added Apr 05 20:42:33 right....same here Apr 05 20:42:56 well I'm going to get working on this, I'll post my patches here when I get something functional Apr 05 20:43:02 I'll probably do it the wrong way :P Apr 05 20:43:11 although I could save UPnP state across reboots, I think it's better not to Apr 05 20:43:13 ok Apr 05 20:46:41 cshore, what are the miniupnpd chains called? Apr 05 20:51:12 MINIUPNP Apr 05 20:51:35 all caps Apr 05 20:51:54 just the one chain Apr 05 20:54:29 so I suppose the UCI in firewall would have to have the name of the chain to save, then the name of the parent chain where it's included Apr 05 21:11:00 there's obviously going to be some bash string matching / regex stuff that is beyond me Apr 05 21:11:07 but I have something really basic working Apr 05 21:14:38 I think preserving user chains would already help Apr 05 21:19:46 xMff, is there a system to do this right now? Apr 05 21:22:18 aport: afaik not Apr 05 21:22:52 aport: could we define where the chains are to be added (since that shouldn't change)? Apr 05 21:23:15 cshore, I've noticed that when using iptables-save, the location of the chain is in the output Apr 05 21:23:23 eg, iptables -A FORWARD -j MINIUPNPD Apr 05 21:23:44 this will probably never work Apr 05 21:23:55 erm nvm Apr 05 21:23:58 well, for my single purpose this works for me Apr 05 21:24:06 depends on the order of course Apr 05 21:24:13 this is quick and dirty, emphasis on dirty because I'm terrible at writing good code Apr 05 21:24:15 http://pastebin.com/qK8jDy7w Apr 05 21:24:23 but in /etc/config/uci I added Apr 05 21:24:34 config save; option chain strongswan_forward Apr 05 21:25:01 when I restart the firewall all of my strongswan rules are in the right place, so I'm happy Apr 05 21:25:17 feel free to modify/improve/delete/ignore my changes Apr 05 21:26:26 that whole stuff is an inherent problem of the iptables design imho Apr 05 21:26:50 on the one hand it lats you create the same rules multiple times Apr 05 21:27:12 and on the other hand it lacks some kind of wildcard support when matching/deleting rules Apr 05 21:27:27 *lets Apr 05 21:27:31 yep, the rule has to be exact to delete it Apr 05 21:27:56 the usual workaround is to put such rules into yet another chain so that you can always flush and rebuild the chain contents Apr 05 21:27:56 so just clearing out everything and starting fresh seems to be the most trouble-free way of doing it Apr 05 21:28:13 this is also the reason why there are so many of them with the uci firewall Apr 05 21:29:02 I thought about another kind of workaround Apr 05 21:29:09 xMff: what's that? Apr 05 21:29:11 aren't you LuCI guys working on a firewall daemon? Apr 05 21:29:36 we have the iptables comment match in the base iptables package now, with that you can annotate rules with freetext comments Apr 05 21:30:10 you can use that later to grep for specifc rules, find their index number and use that to remove rules by index instead of the exect same command repeated Apr 05 21:31:36 yes, there has been work on a firewall daemon but I stopped this for now because I am not sure whether it is the right approach, hardcoded rulesets and such, no easy way to edit something directly on the device Apr 05 21:32:35 one the other hand it allows some tricks which would be quite resource intensive when done with shell scripts... such as iterating all rules and implement some kind of wildcard matching Apr 05 22:38:42 jow * r20720 /trunk/target/linux/generic-2.4/patches/630-netfilter_comment.patch: [brcm-2.4] add kernel support for iptables comment match Apr 05 22:54:19 jow * r20721 /branches/backfire/target/linux/generic-2.4/patches/630-netfilter_comment.patch: [backfire] merge r20720 Apr 05 23:00:30 ping stintel Apr 05 23:00:39 sorry -EDEST Apr 05 23:00:49 ping KanjiMonster Apr 05 23:01:02 xMff: pong Apr 05 23:01:38 KanjiMonster: the v2 patch series for AR8316 support is still the latest? Apr 05 23:01:46 yeah Apr 05 23:01:57 since there were no comments yet Apr 05 23:03:00 There are some things I want to change, but my plan is to wait with it till its committed (to not "reset" the review timer ;-) Apr 05 23:03:20 jow * r20722 /trunk/target/linux/ (10 files in 5 dirs): (log message trimmed) Apr 05 23:03:20 [PATCH 1/2] Add support for the ar8316 switch. Apr 05 23:03:20 This patch enhances the ar8216 driver with ar8316 support and fixes some minor Apr 05 23:03:20 issues with the ar8216 driver itself. It should not break anything, but isn't Apr 05 23:03:20 tested on ar8216 devices. Apr 05 23:03:20 [PATCH 2/2] ar71xx: Add the ar8316 driver to rs pro/rb-450g. Apr 05 23:03:21 Add the ar8216 driver to the ar71xx target, and add network Apr 05 23:03:28 ^ Apr 05 23:03:29 yay :D Apr 05 23:06:40 jow * r20723 /branches/backfire/target/linux/ (7 files in 5 dirs): [backfire] merge r20722 Apr 05 23:06:56 this will make stintel happy Apr 05 23:09:13 I think so Apr 05 23:14:56 thanks for the work on this btw Apr 05 23:15:55 you're welcome - it was a good exercise Apr 05 23:35:42 otoh, stintel is now in a dilemma ;-) Apr 05 23:46:16 whoa :) Apr 05 23:46:22 you guys paranormal or what Apr 05 23:46:36 I somehow felt that I had to attach my screen :P Apr 05 23:46:47 *g* Apr 05 23:48:46 ;) Apr 05 23:49:04 thanks guys Apr 06 00:01:26 xMff: so did you finally unpack your rspro then ? :) Apr 06 00:02:07 my deed here is done. good night ;) Apr 06 00:02:14 gn KanjiMonster :) Apr 06 00:07:55 nbd: your git repository only contains trunk, or can I get the backfire branch from there as well ? Apr 06 00:08:55 nbd * r20724 /branches/backfire/target/linux/ar71xx/image/Makefile: ar71xx: remove pb92 images in backfire, the port is incomplete Apr 06 00:10:20 stintel: i recently added backfire there as well Apr 06 00:10:25 git://nbd.name/backfire.git Apr 06 00:10:53 nbd: thanks Apr 06 00:11:44 * stintel does some more rtfm on git :) Apr 06 00:12:52 nbd * r20725 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/mach-pb92.c: ar71xx: fix ethernet on final pb92 board (previous value was based on a preliminary version) Apr 06 00:24:12 nice, my telco is updating vdsl2 modems to allow watching tv on pc. they're learning. Apr 06 00:51:37 nico * r20726 /trunk/package/busybox/ (Makefile config/util-linux/Config.in): package/busybox: enable blkid, mkswap & swaponoff applets, enable uuid/volumeid support, bumb release number Apr 06 00:52:52 nico * r20727 /trunk/package/block-mount/Makefile: package/block-mount: disable config options altering busybox configuration, fix dependencies Apr 06 01:02:14 nico * r20728 /branches/backfire/package/ (3 files in 3 dirs): [backfire] backport r20726 & r20727 Apr 06 01:44:44 sweet, finally managed to apply my kvm patches again after I messed up my local git branch Apr 06 02:28:33 thepeople: pong Apr 06 02:29:16 swalker: I was thinking about your package status page again Apr 06 02:29:36 wondering what it would take to get it completly scripted Apr 06 02:30:19 thepeople: it mostly is now Apr 06 02:32:41 I was thinking about having it autogenerated daily if it could be finished Apr 06 02:38:46 thepeople: checking upstreams daily or generating the output or both? Apr 06 02:39:20 both, maybe weekly, daily is a bit often now that I think about it Apr 06 02:40:15 what should I do about #7094? It can't be fixed until we have a dependency / event / hotplug based init instead of the mix of hotplug and init we have now Apr 06 02:41:07 cshore: I am taking those tickets, it is on my todo Apr 06 02:44:15 thepeople: do you know what you're going to do to solve it? Apr 06 02:45:40 cshore: I was considering hotpluggin startup, but that may have some serious performace issues, otherwise see if something like upstart can be inegrated Apr 06 02:45:44 into busybox Apr 06 02:47:03 the only way that I can see our issues being fixed is event driven startup Apr 06 02:48:23 I agree....are you are aware the Luci2 people are working on one? Apr 06 02:48:51 yes, but it is standalone Apr 06 02:49:07 we have already grown to much in the default image IMO Apr 06 02:51:16 one person's bloat is another's essential feature Apr 06 02:51:37 i know Apr 06 02:55:56 That's why I think the 2/8 people should be forking....you make different design and coding decisions when you are going for absolute minimal space Apr 06 02:56:58 4/16 will be soon as well at this rate..... Apr 06 02:57:39 4/16 will fit LuCI and a few extras Apr 06 02:58:05 which gives you a pretty decent value-added router Apr 06 02:58:13 the current default image is 3MB Apr 06 02:59:06 ok nvm Apr 06 02:59:11 With Luci I get 3.6 or 3.8....just enough for the minimum number of jffs2 blocks free Apr 06 02:59:11 it is 2.4 Apr 06 02:59:24 maybe using linktime code generation for busybox or so may help **** ENDING LOGGING AT Tue Apr 06 02:59:56 2010