**** BEGIN LOGGING AT Thu Feb 23 02:59:58 2012 Feb 23 04:59:34 jow_laptop: the fix turned out to be trivial. Feb 23 08:04:33 jow_laptop: is firewall or iptables broken right now? Feb 23 08:12:15 blogic * r30689 /trunk/target/linux/lantiq/patches/850-etop_irq.patch: [lantiq] fixes etop locking issue Feb 23 08:12:17 blogic * r30690 /trunk/target/linux/generic/ (3 files in 3 dirs): [atm] drop backported patches as they cause regressions and oopses Feb 23 08:29:24 philipp64|laptop: no idea about the tty foo, also no idea about the iptables Feb 23 08:29:53 I suspect you have the change that removes -rdynamic but not the one that folds SNAT/DNAT into iptables Feb 23 08:30:20 therfore DNAT and SNAT targets are broken in your case due to symbols not exported by iptables Feb 23 08:59:38 ah... damn it. Feb 23 09:00:04 sysupgrade would be really, really nice to have working right now. Feb 23 09:00:37 now I have to pull a box from a rack, pop the cover, remove the CF, reflash it, reconfigure it, put it back... sigh. Feb 23 09:02:03 what about just dd'ing a preconfigured image? Feb 23 09:04:13 I can try, but dd to a mounted filesystem often causes a panic. Feb 23 09:05:33 sysupgrade does the same... Feb 23 09:12:24 doesn't it unmount the filesystem first? Feb 23 09:13:16 so, how do I know if I have the right revision for a working firewall? Feb 23 09:24:46 just in case there's a syntax error, etc. in my config, how do I debug the firewall script? Feb 23 09:25:01 is there a way to see it plumbing rules, etc? Feb 23 09:25:28 common sense Feb 23 09:25:40 just make sure to have no syntax error ? Feb 23 09:26:42 I have a *lot* of rules. it's easy for a typo to sneak in. Feb 23 09:27:04 some of the init scripts have built in debugging support, don't they? Feb 23 09:27:22 FW_TRACE=1 fw reload Feb 23 09:27:39 http://wiki.openwrt.org/doc/uci/firewall#debug.generated.rule.set Feb 23 09:38:41 thanks. looking. Feb 23 09:39:14 huh. it's not including /etc/firewall.user Feb 23 09:41:25 oh. Feb 23 09:41:45 except that /etc/firewall.user isn't a UCI script. duh. Feb 23 12:49:01 jow * r30691 /trunk/package/iwinfo/ (7 files in 3 dirs): [package] iwinfo: implement netlink scanning code, rework IE parsing code Feb 23 13:00:40 swalker: no i did not see the git from nico... :( Feb 23 13:46:23 jow * r30692 /trunk/package/iwinfo/src/ (13 files in 3 dirs): [package] iwinfo: replace internal constant mode strings with enums Feb 23 16:26:59 moo Feb 23 18:51:04 jow * r30693 /trunk/package/iwinfo/ (Makefile src/include/iwinfo.h src/iwinfo_wl.c): [package] iwinfo: fix wl backend, unsigned -> signed for mcs idx, revision bump after latest abi changes Feb 23 19:04:53 nbd: got the uci fix done. Feb 23 19:06:08 jow_laptop: found a bug in the firewall. if the firewall.user file has any issues (such as not being a shell script!) no failure seems to be reported... it just silently fails. Feb 23 19:06:17 not a bug Feb 23 19:06:51 config, option, list are actually shell procedures parsing uci on the fly Feb 23 19:07:10 therfore no error gets triggered if you write uci in firewall.user Feb 23 19:07:33 if you put syntax errors or invalid commands there they will get reported Feb 23 19:08:54 I'm confused... so firewall.user *can* include uci procedures, or not? Feb 23 19:09:04 it can but they'll have no effect Feb 23 19:09:09 ah. Feb 23 19:09:11 since parsing is done at this stage Feb 23 19:10:01 one could probably redefine config(), option() and list() prior to sourcing firewall.user Feb 23 19:10:14 make those procedures emit an error and then let them unset themselves Feb 23 19:10:54 or maybe just unset them Feb 23 19:14:05 yeah, was just thinking the same. Feb 23 19:14:20 philipp64|laptop pong, thanks for new image on ftp, i will check it Feb 23 19:15:43 btw, if you specify a src_dport in a 'redirect' but no dest_port, does dest_port default to src_dport? Feb 23 19:15:51 or vice versa? Feb 23 19:21:00 jow * r30694 /trunk/package/firewall/ (Makefile files/lib/core_init.sh): [package] firewall: bail out if uci is used in firewall include files Feb 23 19:22:11 philipp: you have a lot of involvement here. I'm just wondering about what your general interest in OpenWrt is Feb 23 19:23:35 philipp64|laptop: dest_port is needed and src_dport defaults to dest_port Feb 23 19:24:34 Chocks: I run it at home... I occasionally will help other people set it up as a firewall/wap/asterisk appliance. Feb 23 19:25:04 jow_laptop: that works too. ok. just trying to simplify my uci-defaults scripts. Feb 23 19:26:49 Chocks: plus I have a bit of hardware that no one else seems to maintain... Feb 23 19:27:06 I know that feeling Feb 23 19:38:08 and as someone who spent decades building routers... it's a hobby that's hard to give up. :-) Feb 23 19:45:18 a whole lot more fun than authoring RFCs eh? ;) Feb 23 19:47:29 Olipro: it was fun at the time.... I think I was 21 or 22, and we had no idea how big the Internet would be. Feb 23 19:47:55 the best RFC's are the ones that describe implementations. :-) Feb 23 19:53:14 philipp64|laptop after "Booting the Kernel" screen goes black and nothing happen on VGA, i will boot with serial on to log the output. Feb 23 19:53:59 probably because the fbdev is initializing the framebuffer, but we still need a module to emulate a console... Feb 23 19:54:38 what does lsmod say? Feb 23 19:55:40 build #134 of cobalt is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/134 Feb 23 20:28:14 juhosg * r30695 /trunk/target/linux/ramips/image/Makefile: ramips: image: allow to build board specific initramfs images Feb 23 20:28:16 juhosg * r30696 /trunk/target/linux/ramips/image/Makefile: ramips: image: add MkImageLzma wrapper Feb 23 20:28:17 juhosg * r30697 /trunk/target/linux/ramips/image/Makefile: ramips: image: simplify Makefile a bit Feb 23 20:28:18 juhosg * r30698 /trunk/target/linux/ramips/image/Makefile: ramips: image: use the GENERIC_4M template for the V11ST-FE board Feb 23 20:28:19 juhosg * r30699 /trunk/target/linux/ramips/image/Makefile: ramips: image: introduce mkcmdline helper Feb 23 20:28:21 juhosg * r30700 /trunk/target/linux/ramips/image/Makefile: ramips: image: use generic template for the WR6202, OMNIEMB, W502U boards Feb 23 20:28:24 juhosg * r30701 /trunk/target/linux/ramips/image/Makefile: ramips: image: merge F5D8235V{1,2} templates Feb 23 20:28:25 juhosg * r30702 /trunk/target/linux/ramips/image/Makefile: ramips: image: pass mtdlayout variables by value Feb 23 20:28:26 juhosg * r30703 /trunk/target/linux/ramips/image/Makefile: ramips: image: introduce mkmtd/{,phys,spi} helpers Feb 23 20:28:27 juhosg * r30704 /trunk/target/linux/ramips/image/Makefile: ramips: image: use GENERIC_4M template for the ALL0256N board Feb 23 20:28:28 juhosg * r30705 /trunk/target/linux/ramips/image/Makefile: ramips: image: cleanup and sort templates/profiles Feb 23 20:28:30 juhosg * r30706 /trunk/target/linux/ramips/image/Makefile: ramips: image: increase minimum kernel partition size to 896k Feb 23 20:39:17 build #130 of ps3 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ps3/builds/130 Feb 23 20:44:19 build #130 of pxcab is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/pxcab/builds/130 Feb 23 21:32:21 build #125 of ppc40x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/125 Feb 23 23:18:42 nbd: ping Feb 23 23:18:47 Chocks: peng Feb 23 23:19:24 trying to update at91. there is a .boot_params field used in the existing 2.6.x platform defs. Feb 23 23:19:34 but it's not there in 3.2.5, do you know why? Feb 23 23:19:41 no idea Feb 23 23:19:46 i've never looked at at91 Feb 23 23:21:29 ok, trying to see if it was an openwrt/generic thing or what Feb 23 23:44:35 build, bitch! Feb 24 00:27:29 the bitch built Feb 24 00:34:37 the bitch didn't boot Feb 24 02:49:45 nbd: found the problem Feb 24 02:51:23 nbd: i had upgraded to a newer compat-wireless version, and some of the package/mac80211/patches were already applied Feb 24 02:51:39 nbd: i found most of these because patch didn't apply them Feb 24 02:52:12 but in one case, it decided to apply the patch to the wrong function, because it looked similar Feb 24 02:52:43 apparently patch can get creative with -f Feb 24 02:53:51 nbd: the file already had the patch applied, so patch helpfully found a different place in the file to apply the change Feb 24 02:56:15 nbd: so it put a check for test_sta_flag(sta, WLAN_STA_RATE_CONTROL) in rate_control_rate_init, which is the function which sets the WLAN_STA_RATE_CONTROL flag in the first place Feb 24 02:56:33 nbd: crazy times ;-) **** ENDING LOGGING AT Fri Feb 24 02:59:58 2012