**** BEGIN LOGGING AT Sat Apr 09 02:59:58 2011
Apr 09 03:31:49 <russell--> nbd: /me dirclean'd and rebuilt ... fixed!  thanks!
Apr 09 06:10:05 <builder_> build #2 of xburst is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/2
Apr 09 06:47:19 <builder_> build #2 of ar71xx is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/ar71xx/builds/2
Apr 09 07:36:41 <builder_> build #4 of at91 is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/4
Apr 09 07:50:39 <builder_> build #2 of ep93xx is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/2
Apr 09 07:55:01 <builder_> build #4 of ubicom32 is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/4
Apr 09 07:58:20 <trine_> a question :- when router modifications are published on the wiki should it not be the case that the authors nick should also be included so it would be able to some extent to judge the quality of the information?
Apr 09 07:59:41 <russell--> nbd: http://www.redhat.com/archives/phil-list/2004-March/msg00001.html
Apr 09 08:03:16 <russell--> also: http://stackoverflow.com/questions/4766768/unhandled-forced-unwind-causes-abort
Apr 09 08:39:15 <philipp64|laptop> what the hell...
Apr 09 08:41:33 <loswillios> philipp64|laptop: any reason why you didn't upgrade x86 to .38?
Apr 09 09:08:42 <philipp64|laptop> yeah, 3 reasons in fact: (1) most of the other platforms are still at 2.6.37, (2) the squashfs4 code hasn't been tested sufficiently in 2.6.38, and (3) I've submitted netdev fixes that aren't in .2 but will be in .3...
Apr 09 09:11:43 <loswillios> ah, ok
Apr 09 09:47:36 <russell--> libmicrohttpd should depend on libgcrypt
Apr 09 10:07:23 <russell--> build depend, that is. libmicrohttpd chokes on not finding gcrypt.h or something
Apr 09 10:10:24 <builder_> build #2 of octeon is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/2
Apr 09 10:18:22 <gzanan> aMule not  working on AR71xx? I've tried couple times.
Apr 09 10:19:01 <loswillios> that doesn't say much without an error message
Apr 09 10:20:38 <gzanan> http://pastebin.com/tAHvtEws
Apr 09 10:22:07 <gzanan> http://pastebin.com/tAHvtEws
Apr 09 10:22:27 <loswillios> try running it with verbose logging or 'strace amuled' to see why it aborts
Apr 09 10:37:40 <gzanan> Here is verbose logging:
Apr 09 10:37:41 <gzanan> http://pastebin.com/GkREc49b
Apr 09 10:39:53 <KanjiMonster> gzanan: try strace as loswillios suggested
Apr 09 10:47:08 <gzanan> ok
Apr 09 10:47:17 <gzanan> Here is strace resulte
Apr 09 10:48:05 <gzanan> ftp://sutuo.tk/up/amule.txt
Apr 09 11:46:10 <mazilo> Is there a unixodbc equivalent package on OpenWRT? I am looking for an sql.h file needed to compile freeswitch with '--enable-core-odbc-support' switch.
Apr 09 12:58:49 <CIA-83> hauke * r26540 /packages/libs/mysql/Makefile:
Apr 09 12:58:49 <CIA-83> mysql: fix a compile error on some host systems.
Apr 09 12:58:49 <CIA-83> conf_to_src.c uses C++ functions so we should use g++ for compiling.
Apr 09 12:58:49 <CIA-83> The CFLAGS, CPPFLAGS and LDFLAGS for host build should be used and not the for target builds.
Apr 09 12:58:49 <CIA-83> This closes #8342
Apr 09 13:04:43 <CIA-83> hauke * r26541 /packages/libs/cyrus-sasl/ (4 files in 2 dirs):
Apr 09 13:04:43 <CIA-83> cyrus-sasl: update to version 2.1.23.
Apr 09 13:04:43 <CIA-83> Make must be run two times to work around a bug described here:
Apr 09 13:04:43 <CIA-83> http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2008-June/001414.html
Apr 09 13:06:29 <CIA-83> hauke * r26542 /trunk/package/linux-atm/Makefile:
Apr 09 13:06:29 <CIA-83> linux-atm: package atm-diagnostics with atmdump, atmdiag, etc.
Apr 09 13:06:29 <CIA-83> If your ISP is pushing their own DSL equipment (which many do to contain support costs), they won't be
Apr 09 13:06:29 <CIA-83> forthcoming with your various settings: encapsulation, VPI/VCI, etc.
Apr 09 13:06:29 <CIA-83> These you might have to discover yourself. The easiest way to do this is with atmdiag and atmdump.
Apr 09 13:06:29 <CIA-83> Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Apr 09 15:01:07 <xMff> Hauke: that cyassl workaround is quite crappy
Apr 09 15:01:20 <Hauke> xMff: yes
Apr 09 15:01:34 <xMff> Hauke: sorry cyrus-sasl
Apr 09 15:01:50 <Hauke> do you know a better way?
Apr 09 15:01:51 <xMff> wouldn't it be better to patch it?
Apr 09 15:02:01 <xMff> I haven't looked at the problem yet
Apr 09 15:03:06 <Hauke> xMff: yes ;-) I haven't  looked into the build scripts for cyrus-sasl, but there are many bugreport with this problem but no better solution for this.
Apr 09 15:03:34 <xMff> okay
Apr 09 15:04:25 <Hauke> xMff: this bug is in there since ~4 years
Apr 09 15:04:43 <xMff> high quality software
Apr 09 15:04:47 <xMff> :)
Apr 09 15:06:45 <CIA-83> hauke * r26543 /trunk/tools/firmware-utils/src/trx2edips.c:
Apr 09 15:06:45 <CIA-83> firmware-utils: fix endianness bugs in firmware generation program.
Apr 09 15:06:45 <CIA-83> Should make it work on big endian systems again, I do not have such a system.
Apr 09 15:06:45 <CIA-83> This closes #9093.
Apr 09 15:21:55 <russell--> weird
Apr 09 15:22:26 * russell-- is getting a ruby-ssl build failure on a debian machine, but skates right through on a gentoo box
Apr 09 15:22:38 <CIA-83> nbd * r26544 /trunk/package/mac80211/patches/550-mac80211_remove_wds_sta_flag.patch: mac80211: fix reading the station flags in debugfs
Apr 09 15:22:42 <CIA-83> nbd * r26545 /trunk/package/mac80211/patches/521-ath9k_fix_ap_ps_buffering.patch: ath9k: properly count retries when frames are filtered due to excessive retries when a client is not in powersave mode
Apr 09 15:29:05 <CIA-83> hauke * r26546 /packages/net/ipupdate/patches/ (100-name_conflict.patch 200-byteorder.patch):
Apr 09 15:29:05 <CIA-83> ipupdate: fix endianness-issue
Apr 09 15:29:05 <CIA-83> Thank you Sven Roederer for the patch.
Apr 09 15:29:05 <CIA-83> This closes #9066.
Apr 09 15:30:30 <Hauke> russell--: is one of them i386 and the other amd64?
Apr 09 15:31:04 <russell--> debian is amd64 and gentoo is i386 in this case
Apr 09 15:31:31 <russell--> i just snagged a patch from debian/ubuntu land, build testing now
Apr 09 15:31:58 <russell--> http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/4f1040d2463fbfcc?fwc=1
Apr 09 15:38:12 <Hauke> russell--: this fixes your problem?
Apr 09 15:39:06 <russell--> seemed to (after trimming the outer patch layer)
Apr 09 15:39:15 <russell--> at least it compiles now
Apr 09 15:44:02 <russell--> this applies directly to the packages feed: http://www.personaltelco.net/~russell/0001-snagged-debian-patch-for-ruby-ssl-build-issue.patch
Apr 09 15:47:37 <CIA-83> nbd * r26547 /trunk/toolchain/uClibc/patches-0.9.32/200-no_forced_unwind.patch: uClibc: forced unwind for pthread_cancel handling is broken and triggers spurious abort() calls from libgcc. disable it and use the other method instead
Apr 09 15:49:37 <nbd> russell--: i did find quite a few references to the segfault-after-pthread_cancel issue yet, but that issue seems entirely unrelated to our case
Apr 09 15:50:19 <russell--> okay
Apr 09 15:50:27 * russell-- just wondering if it had other implications
Apr 09 15:51:01 <russell--> and what caused it to suddenly appear at r25800
Apr 09 15:51:27 <nbd> no idea, maybe a switch from gcc 4.3.3+cs to linaro?
Apr 09 15:52:00 <nbd> either way, i found the fixes referenced in the bug descriptions that you mentioned
Apr 09 15:52:06 <nbd> and they were already in uclibc
Apr 09 15:52:27 <nbd> also, the bug description was mostly about segfault at pthread_cancel time, not abort
Apr 09 15:52:28 <russell--> there was something about static linking of gcclib or whatever
Apr 09 15:52:39 <russell--> libgcc
Apr 09 15:53:59 <nbd> yeah, but i tested everything related to loading of libgcc and the error path there wasn't triggered
Apr 09 15:54:11 <russell--> okay
Apr 09 15:54:13 <nbd> maybe the libgcc issue wasn't the cause, it just made the race condition easier to trigger
Apr 09 15:54:35 <russell--> when you said it was looking for symbols, alarm bells went off
Apr 09 15:54:47 <nbd> yes, but i added lots of debug stuff to that specific codepath
Apr 09 15:54:53 <nbd> and all of the symbols were found
Apr 09 15:55:16 <russell--> okay
Apr 09 15:55:29 <nbd> i think it's likely that the race condition was there even before
Apr 09 15:55:32 <nbd> it just didn't trigger
Apr 09 15:55:39 <russell--> oh, so explain to me how the fcntl(__LINE__,0) thing works?
Apr 09 15:55:41 <nbd> because i had to put quite a bit of load on my device to even be able to trigger it
Apr 09 15:55:51 <nbd> well, all it does is issue a system call
Apr 09 15:55:55 <nbd> with two integer arguments
Apr 09 15:56:01 <russell--> and you see that with strace?
Apr 09 15:56:02 <nbd> yes
Apr 09 15:56:05 <russell--> cool
Apr 09 15:56:34 <nbd> and because __LINE__ usually is big enough to not hit any real open filedescriptor, it does nothing
Apr 09 15:56:40 <russell--> yeah
Apr 09 15:56:41 <nbd> but the line number shows up in strace as the first argument then
Apr 09 15:57:11 <russell--> right, is the second argument actually represent a real command?
Apr 09 15:57:37 <nbd> it's interpreted as one, but i don't remember which one
Apr 09 15:57:43 <russell--> okay
Apr 09 15:57:44 <nbd> i could have used close() as well
Apr 09 15:57:51 <nbd> or any other call
Apr 09 15:57:54 <russell--> yeah
Apr 09 15:57:54 <nbd> just picked a random one
Apr 09 15:58:04 <nbd> one that was unlikely to show up in that code
Apr 09 15:58:19 <russell--> clever
Apr 09 15:58:32 <russell--> where did you learn that one?
Apr 09 15:59:00 <nbd> learn what?
Apr 09 15:59:06 <russell--> that trick
Apr 09 15:59:14 <nbd> nowhwere, it was just a spontaneous idea
Apr 09 15:59:19 <russell--> cool
Apr 09 15:59:42 <CIA-83> hauke * r26548 /trunk/package/kernel/modules/block.mk:
Apr 09 15:59:42 <CIA-83> kernel: add scsi cdrom support
Apr 09 15:59:42 <CIA-83> This closes #9125.
Apr 09 16:02:38 <russell--> btw, looks like someone last night reported a similar looking problem with amule
Apr 09 16:02:57 <russell--> ftp://sutuo.tk/up/amule.txt
Apr 09 16:11:16 <CIA-83> hauke * r26549 /packages/net/openl2tp/ (3 files in 2 dirs):
Apr 09 16:11:16 <CIA-83> openl2tp: update to 1.8
Apr 09 16:11:16 <CIA-83> Thank you НКВД for the patch.
Apr 09 16:11:16 <CIA-83> This closes #9155.
Apr 09 16:17:02 <builder_> build #2 of rdc is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/rdc/builds/2
Apr 09 16:19:21 <CIA-83> hauke * r26550 /packages/net/openswan/patches/ (3 files):
Apr 09 16:19:21 <CIA-83> openswan: add fix for 2.6.38
Apr 09 16:19:21 <CIA-83> With 2.6.38.2 #include linux/config.h dont work anymore. It the same issue like Changeset r26237.
Apr 09 16:19:21 <CIA-83> Thank you heil for the patch.
Apr 09 16:19:21 <CIA-83> This closes #9156.
Apr 09 16:42:28 <builder_> build #4 of brcm63xx is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/4
Apr 09 16:46:53 <CIA-83> hauke * r26551 /packages/net/openswan/Makefile:
Apr 09 16:46:53 <CIA-83> openswan: fix recursive dependency in config.
Apr 09 16:46:53 <CIA-83> Warning! Found recursive dependency: PACKAGE_kmod-ipv6 PACKAGE_kmod-ipv6
Apr 09 17:25:48 <philipp64|laptop> xMff: ping
Apr 09 17:35:24 <builder_> build #2 of iop32x is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/iop32x/builds/2
Apr 09 17:40:24 <CIA-83> hauke * r26552 /trunk/target/linux/generic/ (config-2.6.35 config-2.6.36 config-2.6.37 config-2.6.38): kernel: add missing config options
Apr 09 17:57:17 <builder_> build #2 of gemini is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/2
Apr 09 18:16:46 <builder_> build #3 of ps3 is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/3
Apr 09 18:22:44 <philipp64|laptop> somehow I always just miss the people I need to talk to... sigh.
Apr 09 18:26:30 <CIA-83> nbd * r26553 /trunk/target/linux/atheros/config-2.6.37: atheros: enable CONFIG_IP17XX_PHY to add back switch support for the DIR-300
Apr 09 18:26:35 <CIA-83> nbd * r26554 /trunk/target/linux/atheros/patches-2.6.37/ (100-board.patch 105-ar2315_pci.patch):
Apr 09 18:26:35 <CIA-83> atheros: fix ath5k support on ar2315/2317
Apr 09 18:26:35 <CIA-83> - Use physical addresses definition for AR2315 the same way as AR5312. Fixes ioremap
Apr 09 18:26:35 <CIA-83> - Fix dma mapping for AHB bus (only use the PCI DMA offset for PCI devices)
Apr 09 18:26:36 <CIA-83> Based on patches by Wojciech Dubowik
Apr 09 18:26:39 <CIA-83> nbd * r26555 /trunk/target/linux/atheros/patches-2.6.37/100-board.patch: atheros: fix up empty radio data mac address (based on patch from #8601)
Apr 09 18:26:43 <CIA-83> nbd * r26556 /trunk/target/linux/atheros/patches-2.6.37/ (6 files): atheros: merge a few patches into the right place
Apr 09 18:48:24 <CIA-83> juhosg * r26557 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/mach-db120.c:
Apr 09 18:48:24 <CIA-83> ar71xx: Fix mac address offset for AR934x
Apr 09 18:48:24 <CIA-83> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Apr 09 18:48:27 <CIA-83> juhosg * r26558 /trunk/target/linux/ar71xx/config-2.6.37: ar71xx: sync kernel configuration
Apr 09 18:48:29 <CIA-83> juhosg * r26559 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/setup.c: ar71xx: cleanup SoC detection code
Apr 09 18:48:30 <CIA-83> juhosg * r26560 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/setup.c: ar71xx: show the SoC type earlier
Apr 09 18:48:33 <CIA-83> juhosg * r26561 /trunk/target/linux/ar71xx/files/ (4 files in 3 dirs):
Apr 09 18:48:33 <CIA-83> ar71xx: rename ar934x_ref_freq to ar71xx_ref_freq
Apr 09 18:48:33 <CIA-83> Also initialize that for each SoC and print its value along with the
Apr 09 18:48:33 <CIA-83> other frequencies.
Apr 09 18:48:35 <CIA-83> juhosg * r26562 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/mach-ubnt.c: ar71xx: fix section mismatch
Apr 09 18:52:06 <philipp64|laptop> nbd: can you look at my 2 remaining patches please?
Apr 09 19:03:27 <builder_> build #3 of pxcab is complete: Failure [failed compile_3]  Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/3
Apr 09 19:22:08 <CIA-83> nbd * r26563 /trunk/package/mac80211/patches/460-ath5k_fix_tx_status_reporting.patch: ath5k: fix tx status reporting
Apr 09 19:40:00 <builder_> build #4 of s3c24xx is complete: Failure [failed compile_10]  Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/4
Apr 09 19:52:32 <builder_> build #2 of adm5120 is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/adm5120/builds/2
Apr 09 20:00:07 <philipp64|laptop> which package contains /usr/lib/iptables/libxt_conntrack.so ?
Apr 09 20:03:20 <russell--> philipp64|laptop: maybe look in here? include/netfilter.mk
Apr 09 20:04:25 <philipp64|laptop> I did. it's a little unclear... "conntrack" is listed as being in both ipt-core and ipt-conntrack.
Apr 09 20:05:36 <philipp64|laptop> or rather, that's what package/kernel/modules/netfilter.mk says.
Apr 09 20:05:42 <russell--> iptables-mod-conntrack-extra maybe?
Apr 09 20:05:52 <philipp64|laptop> too bad there's no equivalent to "yum whatprovides ..."
Apr 09 20:05:56 * russell-- dredged the build log
Apr 09 20:06:17 <philipp64|laptop> or even "rpm -qa --filesbypkg"
Apr 09 20:06:42 * russell-- uses this as a build command: time make -j17 BUILD_LOG=1 IGNORE_ERRORS=m V=99
Apr 09 20:06:55 <russell--> keeps logs of builds to peruse afterwards
Apr 09 20:09:38 <philipp64|laptop> yeah, I build with logging too... but the logs are sometimes a little hard to read... especially for the modules.
Apr 09 20:09:48 <philipp64|laptop> doing a quick "locate" I get: build_dir/linux-x86_geos/iptables-1.4.10/ipkg-install/usr/lib/iptables/libxt_conntrack.so
Apr 09 20:10:22 <philipp64|laptop> but it's not in any ipkg-x86/
Apr 09 20:12:19 <russell--> for m in ipt_connbytes ipt_connmark ipt_conntrack ipt_helper ipt_recent ipt_CONNMARK xt_connbytes xt_connmark xt_conntrack xt_helper xt_recent xt_CONNMARK; do if [ -f /aux/src/openwrt/build_dir/linux-atheros/iptables-1.4.10/ipkg-install/usr/lib/iptables/lib${m}.so ]; then cp -fpR /aux/src/openwrt/build_dir/linux-atheros/iptables-1.4.10/ipkg-install/usr/lib/iptables/lib${m}.so /aux/src/openwrt/staging_dir/target-mips_uClibc-0.9.32/root-athe
Apr 09 20:14:13 <philipp64|laptop> so it's part of the intrinsic image then and not a "ipkg" that gets installed over it.
Apr 09 20:16:10 <philipp64|laptop> but if that's the case, it should be on my system... it's not.
Apr 09 20:18:04 <russell--> do you have iptables-mod-conntrack-extra installed?
Apr 09 20:18:18 <philipp64|laptop> it's not part of extra, is it?
Apr 09 20:21:02 <russell-->  opkg files iptables-mod-conntrack-extra
Apr 09 20:21:29 <russell--> /usr/lib/iptables/libxt_conntrack.so
Apr 09 20:22:14 <philipp64|laptop> ok...  do I also need CONFIG_PACKAGE_libnetfilter-conntrack ?
Apr 09 20:22:42 <russell--> there are two parts to all that stuff, the kmod part and the userspace stuff
Apr 09 20:24:13 <philipp64|laptop> yeah... I was installed iptables-mod-conntrack... thought that was all I needed.
Apr 09 20:27:32 <philipp64|laptop> *had
Apr 09 20:29:56 <philipp64|laptop> so iptables-mod-conntrack doesn't actually contain conntrack... that's broken.
Apr 09 20:35:57 <builder_> build #3 of atheros is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/atheros/builds/3
Apr 09 21:11:49 <CIA-83> nbd * r26564 /trunk/package/mac80211/patches/ (3 files): ath5k: add a few fixes that improve performance
Apr 09 21:25:23 <builder_> build #3 of uml is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/3
Apr 09 21:36:42 <got_milk> trying to build r26564, while building iptables the build fails out with:
Apr 09 21:37:03 <got_milk> mv: cannot stat 'libiptc/.deps/libip4tc.Tpo': No such file or directory
Apr 09 21:43:16 <russell--> got_milk: have you tried a {clean,compile} ?
Apr 09 21:43:37 <got_milk> yeah, cleaned before i started
Apr 09 21:43:40 <got_milk> always do, it's a habit
Apr 09 21:43:41 <got_milk> lol
Apr 09 21:44:17 <russell--> i can say that i haven't seen that in my recent builds
Apr 09 21:44:58 <philipp64|laptop> got_milk: when was the last build that succeeded?
Apr 09 21:45:09 <philipp64|laptop> any firewall hackers around?  I got a quick question...
Apr 09 21:45:34 <got_milk> philipp64|laptop: 26476
Apr 09 21:45:46 <got_milk> last time I built, anyway
Apr 09 21:46:24 <philipp64|laptop> hmmm.... 90 commits to pour over...
Apr 09 21:46:32 <xMff> philipp64|laptop: pong
Apr 09 21:47:10 <philipp64|laptop> ah, excellent.... I figured out the redirect issue... just one minor problem... I know what rule I need to add... just not how to add it via the fw scripting.
Apr 09 21:47:12 <got_milk> i'll give it another go to make sure i'm not insane
Apr 09 21:47:31 * russell-- thinks got_milk is insane ;-)
Apr 09 21:48:09 <got_milk> even i'm not surprised
Apr 09 21:48:10 <got_milk> :D
Apr 09 21:48:24 <russell--> got_milk: what is your target?
Apr 09 21:48:28 <got_milk> ar71xx
Apr 09 21:48:55 <russell--> i just build r26563 from scratch and i didn't see that
Apr 09 21:48:58 <philipp64|laptop> xMff: http://fpaste.org/16vR/
Apr 09 21:49:07 <got_milk> yeah, it just built fine
Apr 09 21:49:09 <got_milk> what the hell
Apr 09 21:49:11 <got_milk> :|
Apr 09 21:49:18 <xMff> parallel build?
Apr 09 21:49:22 * got_milk is committing himself to an insane asylum
Apr 09 21:49:33 <got_milk> xMff: could be, I'm building with 9 jobs
Apr 09 21:49:40 <philipp64|laptop> so how do I generate "iptables -A input_{$src} -m conntrack --ctstate DNAT -j ACCEPT" ?
Apr 09 21:50:00 <philipp64|laptop> the incoming re-direct will match this rule.
Apr 09 21:50:13 <philipp64|laptop> but I only need to generate it once per zone, obviously.
Apr 09 21:50:46 <philipp64|laptop> (and it means that xt_conntract actually needs to be in the conntrack package... since firewall will depend on it.)
Apr 09 21:51:33 <russell--> got_milk: there should be a make --harder option
Apr 09 21:52:55 <got_milk> all is well now at any rate
Apr 09 21:53:34 <philipp64|laptop> xMff: any words of wisdom?
Apr 09 21:54:39 <xMff> philipp64|laptop: you can use the same rule that is already there just with "-m conntrack --ctstate DNAT" added in the redirect case
Apr 09 21:56:00 <philipp64|laptop> can you show me in the fpaste?
Apr 09 21:58:07 <xMff> http://paste.openwrt.org/kneh9wPf/
Apr 09 22:08:07 <philipp64|laptop> thanks. I'll try it.  how does the ipt-debug patch look?
Apr 09 22:09:27 <builder_> build #3 of ar7 is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/3
Apr 09 22:10:51 <philipp64|laptop> also, can we kick off the build of x86 that failed yesterday with Hauke's patch (r26552) since that should fix it?
Apr 09 22:10:56 <xMff> hadn't time to take a look
Apr 09 22:10:57 <russell--> hmm. /me about to build a test image for ubiquiti bullet M5HP, do i need to configure an ethernet driver?
Apr 09 22:11:20 <xMff> ?
Apr 09 22:13:39 <russell--> xMff: who is that ? for?
Apr 09 22:14:05 <xMff> for philipp64|laptop
Apr 09 22:14:08 <russell--> k
Apr 09 22:14:27 <philipp64|laptop> ah, I thought it was about the ethernet driver...
Apr 09 22:15:07 <philipp64|laptop> so builder_ ran the x86 build yesterday and failed because of the missing CONFIG_COPS symbol... but that was in commit r26552.
Apr 09 22:15:19 <philipp64|laptop> so I figure if we restart it, it should succeed this time.
Apr 09 22:15:40 <philipp64|laptop> don't know when the last time that x86 built successfully... since that symbol was missing going back to 2.6.32.
Apr 09 22:16:06 <philipp64|laptop> who owns builder?
Apr 09 22:24:26 <philipp64|laptop> xMff: so what was the "?" about specifically?  I've several balls in the air...
Apr 09 22:57:28 <CIA-83> nbd * r26565 /trunk/package/mac80211/patches/ (463-ath5k_fix_slottime.patch 463-ath9k_fix_slottime.patch): ath5k: rename a misnamed patch
Apr 09 22:57:32 <CIA-83> nbd * r26566 /trunk/package/mac80211/patches/ (5 files): ath5k: add some more performance improvements
Apr 09 23:05:09 <philipp64|laptop> and... my DSL line flaps again... grrr...
Apr 09 23:05:36 <philipp64|laptop> whoever invented the bridge-tap should have been hung by their thumbs.
Apr 09 23:15:30 <philipp64|laptop> xMff: still not exactly right...  generating the wrong rule...
Apr 09 23:17:20 <philipp64|laptop> it's generating: iptables --table filter --insert zone_wan 1 --jump ACCEPT -m conntrack --ctstate  DNAT -p tcp --dport 22
Apr 09 23:18:07 <philipp64|laptop> the "-p tcp --dport 22" isn't needed... and indeed this rule should only be generated once, regardless of the number of redirects.
Apr 09 23:23:13 <xMff> I disagree
Apr 09 23:23:42 <xMff> if you have additional qualifiers like source mac, source address, source ports etc. you want those rules to be as specific as possible
Apr 09 23:24:01 <xMff> it might be redundant in your simple case here but might not for more complex rules
Apr 09 23:24:29 <CIA-83> hauke * r26567 /trunk/ (include/netfilter.mk package/kernel/modules/netfilter.mk):
Apr 09 23:24:29 <CIA-83> iipt-debug: create bundle of netfilter modules for debugging
Apr 09 23:24:29 <CIA-83> Add a bundle for including commonly useful modules for IPtables debugging and development.
Apr 09 23:24:29 <CIA-83> For now, it just contains xt_TRACE.ko
Apr 09 23:24:29 <CIA-83> Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Apr 09 23:26:42 <CIA-83> hauke * r26568 /trunk/package/kernel/modules/sound.mk: sound: do not pack ac97_bus.ko and snd-ac97-codec.ko into two packages.
Apr 09 23:29:39 <philipp64|laptop> xMff: yes, but those are done here: iptables --table nat --insert zone_wan_prerouting 1 --jump DNAT -p tcp --dport 22001 --to-destination :22
Apr 09 23:29:59 <xMff> no
Apr 09 23:30:26 <philipp64|laptop> the "defaults" include: iptables --table filter --append INPUT --jump ACCEPT -m state --state RELATED,ESTABLISHED
Apr 09 23:30:36 <philipp64|laptop> why shouldn't the defaults also include local redirects?
Apr 09 23:30:51 <xMff> defaults?
Apr 09 23:30:52 <CIA-83> hauke * r26569 /trunk/package/kernel/modules/crypto.mk: crypto: The if statement for twofish did not work, deflate depends on zlib_deflate
Apr 09 23:31:02 <xMff> they should not!
Apr 09 23:31:35 <xMff> having some redirect rule introduce a filter rule that accepts all traffic would be a desaster
Apr 09 23:32:07 <xMff> that goes against the whole cncept we followed for the firewall and we also had tickets for such occurences so we actually tightended up the forward rules even more
Apr 09 23:32:19 <xMff> do not rely on dnat rules
Apr 09 23:32:20 <philipp64|laptop> ok, I just ran the following: http://paste.openwrt.org/GCOnbijJ/ look for the message "Loading defaults".
Apr 09 23:32:46 <xMff> that has nothing to do with this discussion here
Apr 09 23:33:17 <xMff> I *dont want* a generic forward rule that allows everything that once passed a dnat
Apr 09 23:33:27 <xMff> I *dont want* a single rule for multiple dnats
Apr 09 23:33:58 <xMff> I *do want* my forward rules that are created in conjuntion with dnat rules to be *as specific as possible*, *including all quilifiers that are applicable*
Apr 09 23:34:46 <xMff> and finally, a rule with more matches is not wrong, its just more specific
Apr 09 23:35:03 <CIA-83> hauke * r26570 /trunk/ (10 files in 3 dirs):
Apr 09 23:35:03 <CIA-83> kernel: add symbols, small fixes
Apr 09 23:35:03 <CIA-83> * Some module should be loaded later to load them after the modules they are depending on
Apr 09 23:35:03 <CIA-83> * add some more missing config symbols
Apr 09 23:35:03 <CIA-83> * make CS5535 build again
Apr 09 23:36:55 <xMff> this is mainly prevent accidential leaks or gaps in the firewall due to some rules generated as side effect of a simple dnat
Apr 09 23:37:02 <xMff> and dnat itself is no security feature
Apr 09 23:37:08 <CIA-83> hauke * r26571 /trunk/target/linux/at91/config-default: at91: add some missing config options
Apr 09 23:42:52 <philipp64|laptop> ok, so I'll put those arguments back in... and post the patch.
Apr 09 23:43:20 <xMff> the problem with the generic catch all rules is that they might have unintended side effects
Apr 09 23:43:33 <xMff> especially since they're added quite early
Apr 09 23:44:06 <philipp64|laptop> well, since I don't know how the rest of the redirection works, I'm not going to disagree.
Apr 09 23:44:06 <xMff> btw, here's such a ticket https://dev.openwrt.org/ticket/6249
Apr 09 23:44:13 <xMff> almost the same thing
Apr 09 23:44:21 <philipp64|laptop> we could have used connection marking, of course, but then you have to start assigning bit #'s.
Apr 09 23:44:30 <xMff> yep
Apr 09 23:44:37 <xMff> and its going to collide with qos
Apr 09 23:44:45 <CIA-83> hauke * r26572 /trunk/package/acx-mac80211/Makefile: acx-mac80211 needs some header files from compat-wireless to build
Apr 09 23:49:05 <philipp64|laptop> posted... http://patchwork.midlink.org/patch/882/
Apr 09 23:50:47 <philipp64|laptop> xMff: next question...  do we want to add a "option trace on" option to 'redirect' and 'rule' that would cause them to get flagged for tracing via xt_TRACE?
Apr 09 23:51:21 <xMff> sure
Apr 09 23:51:22 <philipp64|laptop> or do we figure that anyone who is debugging the firewall can add such rules manually themselves?
Apr 09 23:51:33 <xMff> I think that too
Apr 09 23:51:44 <philipp64|laptop> so which is it? :-)
Apr 09 23:52:13 <CIA-83> hauke * r26573 /trunk/package/mac80211/patches/070-add_eeprom_def.patch: mac80211: fix compile with older kernel versions
Apr 09 23:52:28 <xMff> adding trace support probably isn't worth it
Apr 09 23:52:40 <xMff> unless you can do it in just a few lines
Apr 09 23:53:10 <philipp64|laptop> I did this via.... iptables -t raw -I PREROUTING 1 -i nas0 -p tcp --dport 22 -j TRACE  for instance.
Apr 09 23:54:22 <philipp64|laptop> well, in this case, 22001... since for a redirect port you'd use src_dport on ingres (PREROUTING) and dest_port as the --sport in the -I OUTPUT rule on egress.
Apr 09 23:54:58 <philipp64|laptop> I think it would be pretty trivial.
Apr 09 23:56:30 <philipp64|laptop> say, since you wanted the rule to be as specific as possible...  how come we don't use the src/dst pairs in the rule?
Apr 09 23:56:46 <philipp64|laptop> the line:
Apr 09 23:56:53 <philipp64|laptop> iptables --table filter --insert zone_wan 1 --jump ACCEPT -m conntrack --ctstate DNAT -p tcp --dport 22
Apr 09 23:57:29 <philipp64|laptop> doesn't specifically reflect that this is for packets coming in on the interface associated with 'src' (wan) for instance... but perhaps that's reflected elsewhere.
Apr 09 23:59:13 <philipp64|laptop> ah, got it: ptables --table filter --append input --jump zone_wan -i nas0 ... nevermind.
Apr 10 00:02:53 <philipp64|laptop> all... a question... should the default for RootPasswordAuth in dropbear be '1'?  that seems a little questionable...
Apr 10 00:04:30 <xMff> erm yes?
Apr 10 00:04:45 <xMff> there is no other user that can login and no cert either
Apr 10 00:15:25 <KanjiMonster> ah, *finally* I get this bcm4321 to work with b43
Apr 10 00:17:23 <KanjiMonster> nice to see it working (more or less), but definitely not ready for general consumption (no actual 11n, and I could only get it to work with pio mode)
Apr 10 00:22:47 <KanjiMonster> would it make sense to have the b43 n-phy support selectable through menuconfig? (probably marked as broken or so) or would this just spread (for now) false hope?
Apr 10 00:25:43 <nbd> if it's useful for debugging, then why not
Apr 10 00:25:55 <KanjiMonster> okay
Apr 10 01:02:53 <philipp64|laptop> xMff: sorry, was getting lunch (late). how do the firewall and solos patches look, btw?
Apr 10 01:42:45 <dirtyfreebooter> was there just a commit to the build system to use "du -b" ?
Apr 10 01:43:00 <dirtyfreebooter> because du -b doesn't exist on darwin
Apr 10 01:43:26 <dirtyfreebooter> and i am seeing mutliple "du: illegal option -- b
Apr 10 01:43:27 <dirtyfreebooter> usage: du [-H | -L | -P] [-a | -s | -d depth] [-c] [-h | -k | -m | -g] [-x] [-I mask] [file ...]"
Apr 10 01:43:35 <dirtyfreebooter> in today's builds
Apr 10 01:57:59 <dirtyfreebooter> both tools/ipkg-utils/patches/180-add_installed_size.patch and tools/ipkg-utils/patches/190-preserve_permissions.patch use `du -b'
Apr 10 01:58:54 <dirtyfreebooter> sorry just 180-add_installed_size.patch
Apr 10 01:59:28 <dirtyfreebooter> instead of installed_size=`du -b $tmp_dir/data.tar.gz | cut -f1`, could do something like installed_size=`ls -l $tmp_dir/data.tar.gz | awk '{print $5}'`
Apr 10 02:47:41 <cshore> how well is ar71xx (ar9130 specifiically) supported this days?  (ar9102 2x2 MIMO)  ?  if, when I visit my mom for her birthday I give here one of these http://wiki.openwrt.org/toh/start#trendnet with OpenWRT will she be complaining of network issues with her laptop?
Apr 10 02:49:07 <cshore> I ask because it's the least expensive OpenWRT-known-compatible routers I can find right now
Apr 10 02:49:25 <cshore> (about $30 CAD)
Apr 10 02:51:11 <cshore> I want to use openwrt so that I can do remote administration of her router and computer by using OpenVPN and SSH (keys of course).
Apr 10 02:56:36 <thepeople> cshore: I would go this route http://wiki.openwrt.org/toh/netgear/wndr3700
Apr 10 02:56:52 <cshore> thepeople: that's $70 more
Apr 10 02:57:00 <cshore> sorry $90
Apr 10 02:57:02 <thepeople> it has been working quite well for me
Apr 10 02:57:16 <cshore> thepeople: not in the budget
Apr 10 02:58:00 <cshore> thepeople: and I really don't need the extra RAM and flash, since 4/32 is pleny for what I need for my mom
Apr 10 02:58:05 <thepeople> well if you can find the trendnet with the correct chipset in it, it should work fine
Apr 10 02:58:28 <thepeople> they changed arches awhile back
Apr 10 02:58:36 <cshore> hmmmm....oh, I didn't know that
Apr 10 02:58:47 <cshore> So there are different versions?
Apr 10 02:59:01 <thepeople> yea, you would need to find a v1
Apr 10 02:59:27 <cshore> damn....the only sources I have are online
Apr 10 02:59:31 <cshore> and they don't tell you that
Apr 10 02:59:37 <thepeople> I was burnt by that about 3 months ago
**** ENDING LOGGING AT Sun Apr 10 02:59:57 2011