**** BEGIN LOGGING AT Tue Sep 28 02:59:57 2010
Sep 28 10:43:28 <CIA-14> jow * r23141 /trunk/package/firewall/ (5 files in 2 dirs):
Sep 28 10:43:28 <CIA-14> [package] fireall:
Sep 28 10:43:28 <CIA-14> - support negations for src_ip, dest_ip, src_dip options in rules and redirects
Sep 28 10:43:28 <CIA-14> - add NOTRACK target to rule sections, allows to define fine grained notrack rules
Sep 28 10:59:57 <Alicemirror> Hi! i'm doing some experiments on a new board to study how I can create a specific target in OWRT10. I see that the architecture and toolchaing structure of owrt is very similar to ltib and ledk. What is the real difference between owrt and the others? Consider that at least 90% of the work is already on ltib targets. I need to have clear in mind the differences before I start.
Sep 28 11:02:09 <nbd> haven't looked into ltib yet
Sep 28 11:02:12 <nbd> what's ledk?
Sep 28 11:04:49 <nbd> from what i can see, ltib seems to be a rather minimal build environment that does just enough to get a kernel and a very basic userland running
Sep 28 11:05:14 <nbd> no proper integration or even tools to keep targets in sync with each other
Sep 28 11:05:58 <nbd> openwrt has a large set of common patches and tools to make sure that devs only need to focus on the platform specific bits and let the generic code do its work
Sep 28 11:06:15 <nbd> it also has infrastructure to keep kernel configs across targets in sync with each other
Sep 28 11:06:30 <nbd> and openwrt is probably easier to use for porting new targets
Sep 28 11:06:56 <RealOpty> xMff, can you merge 23141 into backfire :D ?
Sep 28 11:07:06 <xMff> RealOpty: working on it
Sep 28 11:07:14 <RealOpty> xMff, your awesome
Sep 28 11:11:01 <RealOpty> whats the notrack chain?
Sep 28 11:11:44 <CIA-14> jow * r23142 /trunk/package/firewall/files/reflection.hotplug: [package] firewall: don't setup nat reflection if negations are used
Sep 28 11:11:47 <nbd> forcibly disables connection tracking
Sep 28 11:12:00 <nbd> which improves performance
Sep 28 11:12:18 <xMff> we use openwrt on ha systems and need it :)
Sep 28 11:12:35 <nbd> :)
Sep 28 11:13:12 <nbd> btw. started to add some config integration for netifd
Sep 28 11:14:08 <nbd> after that, i only need to add some proto handler abstraction, then i can begin to add ubus, the shell callout, and then fill in the low level stubs
Sep 28 11:14:17 <RealOpty> ah nice, i should use that option when redirecting http trafic to my squid proxy yeah?
Sep 28 11:14:38 <nbd> that's one place where you should absolutely not use it ;)
Sep 28 11:15:18 <RealOpty> lol kk :)
Sep 28 11:16:01 <RealOpty> nbd, example of a time to use it?
Sep 28 11:16:31 <nbd> if you're routing packets between two interfaces and use no NAT or connection based filtering
Sep 28 11:17:23 <RealOpty> ah
Sep 28 11:39:04 <CIA-14> jow * r23143 /trunk/package/firewall/files/lib/core_rule.sh: [package] firewall: fix chain selection logic, option dest must be ignored for notrack targets
Sep 28 11:50:49 <CIA-14> jow * r23144 /branches/backfire/package/firewall/ (Makefile files/reflection.hotplug files/uci_firewall.sh): [backfire] firewall: backport r23141, r23142 and r23143
Sep 28 11:55:26 <Alicemirror> ndb: very clear and stisfying.
Sep 28 14:02:40 <Memphiz> mhh has someone an idea why the mv_cesa module (marvell hardware encryption) doesn't get build. i've tried the package and menuconfig and the modul in kernel_menuconfig aswell ... it doesn't get build :(
Sep 28 14:13:06 <blogic> Memphiz: no, but i noticed yesterday aswell
Sep 28 14:13:15 <blogic> have not had time to look in detail though
Sep 28 14:14:31 <Memphiz> blogic: this module should work on kirkwood/dockstar shouldn't it?
Sep 28 14:14:44 <Memphiz> want some hardware aes encryption for speeding up the dm-crypt :)
Sep 28 14:19:55 <KanjiMonster> perhaps wrong kernel symbol?
Sep 28 14:20:55 <Memphiz> KanjiMonster: what do you mean?
Sep 28 14:21:01 <blogic> Memphiz: indeed
Sep 28 14:21:18 <blogic> Memphiz: i just made a nas6210 work and want dmcrypt for my sata drive
Sep 28 14:21:19 <blogic> :)
Sep 28 14:21:36 <KanjiMonster> Memphiz: I meant kernel config value
Sep 28 14:21:39 <blogic> but i ran out of time on the weekend
Sep 28 14:21:59 <blogic> Memphiz: i think the default kernel config is not correct as KanjiMonster just suggested
Sep 28 14:22:23 <Memphiz> i changed the kernel config by make kernel_menuconfig ... activated hw encryption modules and mv_cesa ...
Sep 28 14:22:35 <Memphiz> don't know what to do more to tell him to build this module *G*
Sep 28 14:22:36 <xMff> but mv_cesa is not part of ocf?
Sep 28 14:22:54 <Memphiz> xMff: it is under the ocf directory in kernelsrc/crypto
Sep 28 14:22:57 <xMff> ok
Sep 28 14:23:07 <xMff> so its ocf
Sep 28 14:23:36 <Memphiz> ohh
Sep 28 14:23:37 <Memphiz> shit
Sep 28 14:23:43 <Memphiz> then it is somehow twice there in kernel config
Sep 28 14:24:00 <Memphiz> once under cryptographic api ...
Sep 28 14:24:16 <Memphiz> and once under ocf configuration (which i didn't see until now ...)
Sep 28 14:24:18 <xMff> there are actually two stacks
Sep 28 14:24:21 <Memphiz> mhh
Sep 28 14:24:22 <KanjiMonster> also, the module definition needs to depend on TARGET_kirkwood; being under target/kirkwood doesn't prevent it from being selectable for other targets ;)
Sep 28 14:24:34 <xMff> some linux native modules and then the ocf framework
Sep 28 14:25:08 <Memphiz> so i'll try the ocf thing ... has it disadvantages?
Sep 28 14:25:29 <xMff> when I played with hw crypto the last time ocf was the only thing that worked
Sep 28 14:25:32 <xMff> even on 2.4
Sep 28 14:26:07 <xMff> but this was for a vpn1411 crypto accel card, never tried the soc drivers
Sep 28 14:26:43 <Memphiz> i'll give it a shot ... but the module isn't called mv_cesa.ko then ... so it seems to be a different approach (have read in other forums they used mv_cesa.ko on there sheevaplugs)
Sep 28 14:35:13 <Memphiz> crypto/ocf/kirkwood/mvHal/mvSysHwConfig.h:34:48: error: ../../../../include/linux/autoconf.h: No such file or directory
Sep 28 14:35:14 <Memphiz> wtf
Sep 28 14:36:04 <builder> build #112 of octeon is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/112
Sep 28 14:37:30 <Memphiz> mhh found that header unter include/generated/autoconf.h ... will try if that works
Sep 28 14:37:46 <xMff> ah now I remember
Sep 28 14:37:59 <xMff> the sources had some blurbs about SDKs
Sep 28 14:39:47 <Memphiz> mhh
Sep 28 14:40:02 <Memphiz> but i still wonder why the other stack doesn't build the module at all ...
Sep 28 14:40:50 <Memphiz> mhh when changing it to use the generated/autoconf.h header it still burps and fails
Sep 28 14:41:07 <xMff> *frickel* *frickel*  :)
Sep 28 14:41:11 <Memphiz> harr
Sep 28 14:41:45 <blogic> grfnuckel
Sep 28 14:42:01 <blogic> it would not be fun if it worked ootb
Sep 28 14:42:09 <Memphiz> sure it would be fun :)
Sep 28 14:42:31 <Memphiz> but then we would loose our geek status
Sep 28 14:42:37 <xMff> true, one could accidentially become productive... far too dangerous
Sep 28 14:42:42 <Memphiz> lol
Sep 28 14:43:22 <Memphiz> 6mb/s with software dm-crypt ... well ... i could stick with it ... but i can't sleep if there is hardware in it which could speed things up ... and i can't use it ... so ... frickel again *G*
Sep 28 14:43:55 <Memphiz> btw the seagate freagent usb hard drives damn look like apple stuff *G*
Sep 28 14:44:06 <Memphiz> really sweet design
Sep 28 14:44:13 <Memphiz> with blinking and glowing leds and stuff ...
Sep 28 14:44:21 <Memphiz> women would love that hrhrhr
Sep 28 14:44:51 <xMff> they wouldn't worry about dm-crypt either :P
Sep 28 14:45:26 <Memphiz> #include "mvAesBoxes.dat"  <- is that correct c syntax?
Sep 28 14:45:56 <xMff> sure
Sep 28 14:45:58 <Memphiz> mhh well ... guess the compile doesn't care about file extensions to include ... but looks strange though (that file doesn't even exist)
Sep 28 14:46:27 <xMff> the marvell tech guy hacked it together on windows xp probably ;)
Sep 28 14:47:09 <xMff> seriously, when I last skimmed through the sources it looked like they're incomplete and rely on some kind of vendor sdk
Sep 28 14:47:18 <xMff> never bothered to find out where to get it from
Sep 28 14:47:46 <xMff> the marvell parts I mean
Sep 28 14:49:21 <Memphiz> mhh
Sep 28 14:50:43 <Memphiz> mhh hopefully it is plattform independend ... got one through google ;)
Sep 28 14:51:11 <xMff> its probably just licensing foo
Sep 28 14:52:14 <Memphiz> mhh but there seems more missing :(
Sep 28 14:52:25 <Memphiz> crypto/ocf/kirkwood/cesa_ocf_drv.c:501: error: implicit declaration of function 'crypto_copy_bits_back'
Sep 28 14:52:32 <Memphiz> think that was the frickel ...
Sep 28 14:52:35 <Memphiz> *g*
Sep 28 14:52:44 <Memphiz> mhh
Sep 28 14:53:12 <KanjiMonster> blogic: btw, why the 6210 and not the 6220; didn't you want one for two discs? ;)
Sep 28 14:58:50 <Memphiz> so i better get the buildsystem to even try to build the other driver ...
Sep 28 14:59:03 <KanjiMonster> ah, I just saw, the 6220 isn't out
Sep 28 15:00:50 <Memphiz> xMff: any hints how to track back this issue? in .config "CONFIG_PACKAGE_kmod-crypto-mv_cesa" gets set to y  ... where does this variable gets evaluated?
Sep 28 15:11:48 <blogic> kristianpaul: 6220 is not on sale yet
Sep 28 15:11:53 <blogic> oops
Sep 28 15:12:01 <blogic> KanjiMonster: 6220 is not on sale yet
Sep 28 15:12:06 <blogic> once it is i will get a 6220
Sep 28 15:12:56 <blogic> for now i am using the esata for the 2nd disc
Sep 28 15:17:39 <kristianpaul> ah
Sep 28 15:17:42 <kristianpaul> :)
Sep 28 15:34:55 <Memphiz> xMff: cp: cannot stat `/home/christian/src/backfire/trunk-dockstar.sog/build_dir/linux-kirkwood/linux-2.6.35.4/crypto/mv_cesa.ko': No such file or directory
Sep 28 15:35:15 <Memphiz> the mv_cesa.ko gets build in build_dir/linux-kirkwood/linux-2.6.35.4/drivers/crypto/mv_cesa.ko ...
Sep 28 15:35:28 <Memphiz> or it doesn't get moved in the first directory ... any idea?
Sep 28 15:41:27 <Memphiz> yeah ... nearly doubled the throughput via ftp to 9mb/s ^^ ...
Sep 28 15:41:57 <Memphiz> mhh but ... it have to rethink if this is worse ... without encryption i get around 30mb/s
Sep 28 15:53:27 <KanjiMonster> ftp doesn't use encryption, unless you are talking about tfps or sftp
Sep 28 15:53:36 <KanjiMonster> *ftps
Sep 28 15:54:03 <KanjiMonster> ah, encrypted ds
Sep 28 15:54:05 <KanjiMonster> *fs
Sep 28 15:54:10 <KanjiMonster> gah, can't type today
Sep 28 15:54:35 <Memphiz> KanjiMonster: encrypted partition
Sep 28 15:54:39 <Memphiz> via dm-crypt ^^
Sep 28 15:55:41 <Memphiz> xMff: i've a patch for the kirkwood/modules.mk ... which accessed the mv_cesa.ko in the wrong place ... would you commit it?
Sep 28 15:56:22 <Memphiz> KanjiMonster: did i mention that the dockstar is a rocker? *hehe*
Sep 28 15:58:28 <KanjiMonster> Memphiz: while you are at it, add a dependency to @TARGET_kirkwood
Sep 28 15:58:57 <Memphiz> right
Sep 28 15:59:14 <KanjiMonster> Memphiz: haven't had time to do anything with my new dockstar (this time I wont do a "nand erase"! ;)
Sep 28 15:59:30 <Memphiz> ahh ... it isn't enough that the modules.mk is in the kirkwood subdir right?
Sep 28 15:59:40 <KanjiMonster> no it isn't
Sep 28 15:59:43 <blogic> KanjiMonster: you have a bricked dockstar ?
Sep 28 16:11:41 <larsc> Memphiz: where is the patch?
Sep 28 16:16:51 <Memphiz> larsc: one moment
Sep 28 16:18:37 <Memphiz> larsc: http://pastebin.com/4hk2xn7s
Sep 28 16:19:22 <larsc> do we really need the @TARGET_kirkwood?
Sep 28 16:20:01 <Memphiz> KanjiMonster: ping your question :)
Sep 28 16:24:29 <KanjiMonster> larsc: I selected ar71xx and I could still select the module. It didn't do anything (doesn't break the build), but I would expect it to be only visible if the kirkwood target is selected
Sep 28 16:32:42 <CIA-14> lars * r23145 /trunk/target/linux/kirkwood/modules.mk:
Sep 28 16:32:43 <CIA-14> [kirkwood] Fix mv_cesa module dependencies and .ko file location
Sep 28 16:32:43 <CIA-14> Thanks KanjiMonster & Memphiz
Sep 28 16:33:03 <Memphiz> thx lars
Sep 28 16:40:57 <builder> build #115 of sibyte is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/115
Sep 28 17:35:36 <loswillios> nice
Sep 28 17:36:50 <loswillios> Memphiz: 9mb/s via ftp is nice. which cipher do you use?
Sep 28 17:37:28 <Memphiz> aes
Sep 28 17:37:36 <Memphiz> 256bit key
Sep 28 17:37:39 <Memphiz> sha1 hashing
Sep 28 17:37:50 <Memphiz> http://smorgasbord.gavagai.nl/2010/02/sheevaplug-hardware-crypto/ <- this one ...
Sep 28 17:39:54 <Memphiz> and ext4 as fs
Sep 28 17:40:47 <loswillios> interesting, thanks
Sep 28 19:51:27 <builder_> build #0 of avr32 is complete: Exception [exception failed slave lost shell_10 compile_12]  Build details are at http://tksite.gotdns.org:8010/builders/avr32/builds/0
Sep 28 19:51:28 <builder_> build #0 of brcm63xx is complete: Exception [exception failed slave lost shell_10 compile_12]  Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/0
Sep 28 19:51:30 <builder_> build #0 of brcm47xx is complete: Exception [exception failed slave lost shell_10 compile_12]  Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/0
Sep 28 19:51:32 <builder_> build #0 of sibyte is complete: Exception [exception failed slave lost shell_10 compile_12]  Build details are at http://tksite.gotdns.org:8010/builders/sibyte/builds/0
Sep 28 19:51:35 <builder_> build #0 of octeon is complete: Exception [exception failed slave lost shell_10 compile_12]  Build details are at http://tksite.gotdns.org:8010/builders/octeon/builds/0
Sep 28 20:21:49 <CIA-14> obsy * r23146 /packages/net/proftpd/Makefile: [packages] proftpd: update to 1.3.3b
Sep 28 22:55:50 <CIA-14> nbd * r23147 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/mach-ap96.c:
Sep 28 22:55:50 <CIA-14> AP96: Fix LAN/WAN setup
Sep 28 22:55:50 <CIA-14> LAN (eth0) is behind a switch and the fixed speed/duplex was
Sep 28 22:55:50 <CIA-14> supposed to be for it, not WAN (eth1).
Sep 28 22:55:50 <CIA-14> Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Sep 28 23:11:36 <KanjiMonster> nbd: now it looks better ;)
Sep 28 23:42:39 <nbd> KanjiMonster: yup :)
Sep 28 23:43:18 <KanjiMonster> nbd: do you now have your own ap96 running?
Sep 28 23:43:33 <nbd> not yet
Sep 28 23:43:45 <nbd> forwarded your comments to jouni and gave him some more hints
Sep 28 23:44:04 <nbd> with that he got lan and wan working properly
Sep 28 23:48:11 <KanjiMonster> I see
**** ENDING LOGGING AT Wed Sep 29 02:59:57 2010