[01:26] <nbd> Kaloz: syn
[01:33] <Keloz> nbd: ack
[01:35] <nbd> frop: RST
[01:37] <frop> :)
[02:03] <db90h> is there any tasks I can help with in my spare time, tho I'm still a linux noob, am getting acclimated quickly and am a C/C++ coder. I've got everything set up to do package and openwrt development, so if there's some task that needs doing, please let me know... like I said, I am no linux guru, so cut me a break.. just offering help where I can help, if anywhere.. maybe that's nowhere
[02:04] <frop> db90h begin porting packages to buildroot-ng :)
[02:05] <nbd> db90h: what kind of wifi hardware do you have?
[02:05] <db90h> wrt54g v4 and a wrt54g v5
[02:05] <db90h> (nothing useful<g>)
[02:07] <db90h> what needs to be doen /w the porting packages to buildroot-ng?
[02:08] <nbd> that should wait until we have a separate repository for packages set up
[02:09] <nbd> i'm thinking about what coding task would be the most useful right now...
[02:09] <db90h> preferrably something fun ;p
[02:10] <[mbm]> well, there's always fixing up the website
[02:13] <db90h> web stuff isn't my cup of tea, but I've been working on some of the wiki pages here and there lately.. just let me know, and as I continue to get into linux, if I see something myself that I want to do, I'll do it .. and u can decide to toss it or use it
[02:15] <nbd> [mbm]: you could make a svn directory for packages and give db90h commit access to it
[02:15] <nbd> if he wants to work on something like that
[02:20] <db90h> that'd be great, tho no rush.. if there's some package that needs writing from scratch, I'd love to jump on it... I've been struggling to think of something useful to code
[02:21] <nbd> if you had access to atheros wifi stuff, i'd say that porting hostapd to axTLS would be useful
[02:21] <nbd> that would involve c coding
[02:22] <db90h> i wish I had more money right now, I could buy an atheros based platform
[02:22] <db90h> maybe if I get some big sales soon I can buy something..
[02:26] <db90h> well, I'll be mucking around openwrt for some time.. so just let me know.. in the meantime, I'm gonna figure out some useless packages to code up
[02:27] <h3sp4wn> Florian has ported most of the even semi useful ones from mipsel sid
[02:28] <h3sp4wn> (or which are in mipsel sid)
[02:28] <h3sp4wn> and all the useful ones that I have managed to fine
[02:29] <nbd> the thing is: all the package stuff in trunk is obsolete
[02:29] <nbd> tyhe packages have to be ported over to buildroot-ng
[02:29] <nbd> which doesn't have many packages yet
[02:29] <db90h> oh.. and I've lots of experience in lossless data compression, so just to throw that out.. mostly LZ77 and LZ78 derivatives is my speciality, for example LZSS based algorithms (and LZ77 derivative).. if there are pre-processors I can code to optimize compression in any place, or tweaks on the compression algorithm(s) used by JFFS2, let me know
[02:30] <nbd> i think the lacking jffs2 compression is mostly a problem with the small block size
[02:31] <h3sp4wn> nbd: Is the idea with build root ng to have all the config files in /etc/config (in an openwrt specific format) and then use a parser to generate the ones that are used by the actual programs so as to be able to be able to keep /etc/config between upgrades ?
[02:33] <db90h> I'll take a look into the inards of JFFS2 and see what's up.. there are pre-processors that can be written to optimize particular data sets for better compression
[02:33] <crazy_imp> how big are these config files? i saw a firmware which stored the complete firewallscript in the nvram, so it's maybe possible to drop the files in the nvram?
[02:33] <nbd> h3sp4wn: the config file stuff is also planned
[02:33] <nbd> h3sp4wn: but with 'buildroot-ng' i'm referring to the build system rewrite
[02:34] <nbd> crazy_imp: nvram is crap and not portable
[02:34] <nbd> crazy_imp: we don't want to use it
[02:34] <crazy_imp> (it was a crank branch from the original linksys firmware from an isp)
[02:34] <db90h> as u know, known data types can be optimized to compress better.. for instsance, x86 code can be pre-processed with BCJ and that substantially improves compression. That algorithm adjusts the JMPs/CALLs addresses so they aren't relative, but static.. so CALLs to the same address all end up being identical, regardless of their placement..
[02:34] <crazy_imp> nbd: ack, was just an idea
[02:34] <nbd> db90h: sounds interesting. i think on linux 2.6, jffs2 has model based compressors
[02:34] <nbd> db90h: at least for arm
[02:35] <db90h> MIPS code, I'm sure, can be pre-processeed so that general purpose algorithms compress it better.. I'd just need to get acquainted with the instruction formats to know for sure
[02:35] <nbd> db90h: i believe some of the code from linux 2.6 should be backported for that purpose
[02:36] <db90h> i'll take a look into eveyrthing.. currently I know jack about JFFS2, so better shut-up before I say anything stupid ;).. gotta go eat, bbl
[02:37] <h3sp4wn> nbd: But there is provision for the config files to be preserved between upgrades in the new image ?
[02:37] <h3sp4wn> nbd: Or will be ?
[02:37] <nbd> we will add something like that, yes
[02:37] <nbd> still thinking about the best way to implement it
[04:05] <db90h> what's up with this: http://openbsd-geek.de/archives/224-An-open-letter-to-the-OpenWrt-community.html ... we have an openwrt fork going on?
[05:46] <[mbm]> db90h: it already happened
[11:19] <RoDent> nbd: Which tarball did the latest kamikaze driver come from? I checked the revision logs and you mention USR, but the two tarballs I downloaded's wl_apsta.o doens't match the one I see in kernel-binary-wl-0.7.tar.gz
[11:20] <RoDent> I'm really after the "wl" util that matches that driver, because all the wl's I've tried so for whine about bss_info_version mismatch.
[12:15] <florian__> wrt: shut up
[12:17] <common> source based routing kicks ass
[12:18] <common> i hooked my neighbours wlan, setup a bridge, and sourcebase route my torrent traffic via his line
[12:19] <common> everything but torrent uses my line, torrent his line
[12:19] <common> i love it
[12:19] <florian__> lol
[12:20] <florian__> interesting way of doing QoS ;)
[12:20] <common> best way
[12:20] <common> i hope i can find a neighbour with adsl2+
[12:30] <florian__> where are you living common ?
[12:31] <common> germany
[12:31] <florian__> ok
[12:32] <florian__> I am wondering how efficient is this http-replicator stuff for gentoo
[12:34] <common> for debian there is apt-proxy
[12:35] <florian__> yep, that's the same idea
[12:35] <florian__> except that you have to cache both portage tree, so set up a rsync module, and the "distfiles" you download
[12:40] <Kaloz> nbd: syn/ack
[13:08] <nbd> Kaloz: have you had a look at http://busybox.net/bugs/view.php?id=370 for the ppc stuff?
[13:08] <nbd> RoDent: it's from the wrt300n gpl tarball
[13:09] <Kaloz> nbd: yeah, but the proper fixes in their svn are totally different :p
[13:10] <Kaloz> nbd: and my biggest concern is the armeabi stuff :p
[14:31] <RoDent> nbd: Thanks
[17:06] <pjf> guys - here is improved netmsg which can also receive meesages: http://projects.asn.pl/pointwrt/browser/branches/nutrius/package/busybox/patches/300-netmsg.patch
[17:07] <pjf> and in case someone was interested, there is a tool called setconsole backported from busybox' svn to 1.0 (eg. in whiterussian)
[17:08] <pjf> in the same dir, also
[17:08] <nbd> what does setconsole do?
[17:20] <pjf> it redirects what normally goes to /dev/console to tty of your choice
[17:20] <pjf> eg. /dev/tty
[17:21] <pjf> in other words it changes console= boot parameter
[17:26] <nbd> interesting
[17:29] <pjf> do you have idea how to fetch channel number of wds peer without scanning?
[17:29] <pjf> I mean -- I just realized that if I change channel number on one of two peers of a wds link, eg. one channel down, the link still em... "works"
[17:30] <pjf> ...but poorly, of course - I would like to detect such situation and sync the other peer to new channel
[17:31] <pjf> my first idea is to try libpcap it on monitor interface, but it'll take some time to implement
[17:34] <dragorn> well yeah, you're still hitting channel overlap there, you need to get 3+ channels away to avoid that
[17:34] <pjf> dragorn: that's not the problem I described
[17:35] <dragorn> iwconfig ought to show the current channel of the radio
[17:35] <pjf> I do know what I'm doing :P
[17:35] <pjf> I want to know it on the box which is syncing to the other
[17:35] <pjf> I can't fetch iwconfig from the other box
[17:36] <dragorn> if it doesn't implement syncing to the channel over tagparms announcing it, you're pretty stuck.
[17:36] <nbd> proprietary drivers suck
[17:37] <pjf> nbd: you're right :)
[17:37] Action: nbd will give bcm43xx another try very soon
[17:37] <pjf> cool! :)
[17:38] <pjf> well... I think for now I'll just write a proper libpcap filter and attach it to looong chain of tcpdump options :)
[17:38] <pjf> finally channel number in beacons will be useful :P
[17:45] <nbd> hmm... i just noticed that with buildroot-ng, i can finally make use of the image builder package lists in menuconfig
[00:00] --- Sun Jun 11 2006
[01:33] <Keloz> nbd: ack
[01:35] <nbd> frop: RST
[01:37] <frop> :)
[02:03] <db90h> is there any tasks I can help with in my spare time, tho I'm still a linux noob, am getting acclimated quickly and am a C/C++ coder. I've got everything set up to do package and openwrt development, so if there's some task that needs doing, please let me know... like I said, I am no linux guru, so cut me a break.. just offering help where I can help, if anywhere.. maybe that's nowhere
[02:04] <frop> db90h begin porting packages to buildroot-ng :)
[02:05] <nbd> db90h: what kind of wifi hardware do you have?
[02:05] <db90h> wrt54g v4 and a wrt54g v5
[02:05] <db90h> (nothing useful<g>)
[02:07] <db90h> what needs to be doen /w the porting packages to buildroot-ng?
[02:08] <nbd> that should wait until we have a separate repository for packages set up
[02:09] <nbd> i'm thinking about what coding task would be the most useful right now...
[02:09] <db90h> preferrably something fun ;p
[02:10] <[mbm]> well, there's always fixing up the website
[02:13] <db90h> web stuff isn't my cup of tea, but I've been working on some of the wiki pages here and there lately.. just let me know, and as I continue to get into linux, if I see something myself that I want to do, I'll do it .. and u can decide to toss it or use it
[02:15] <nbd> [mbm]: you could make a svn directory for packages and give db90h commit access to it
[02:15] <nbd> if he wants to work on something like that
[02:20] <db90h> that'd be great, tho no rush.. if there's some package that needs writing from scratch, I'd love to jump on it... I've been struggling to think of something useful to code
[02:21] <nbd> if you had access to atheros wifi stuff, i'd say that porting hostapd to axTLS would be useful
[02:21] <nbd> that would involve c coding
[02:22] <db90h> i wish I had more money right now, I could buy an atheros based platform
[02:22] <db90h> maybe if I get some big sales soon I can buy something..
[02:26] <db90h> well, I'll be mucking around openwrt for some time.. so just let me know.. in the meantime, I'm gonna figure out some useless packages to code up
[02:27] <h3sp4wn> Florian has ported most of the even semi useful ones from mipsel sid
[02:28] <h3sp4wn> (or which are in mipsel sid)
[02:28] <h3sp4wn> and all the useful ones that I have managed to fine
[02:29] <nbd> the thing is: all the package stuff in trunk is obsolete
[02:29] <nbd> tyhe packages have to be ported over to buildroot-ng
[02:29] <nbd> which doesn't have many packages yet
[02:29] <db90h> oh.. and I've lots of experience in lossless data compression, so just to throw that out.. mostly LZ77 and LZ78 derivatives is my speciality, for example LZSS based algorithms (and LZ77 derivative).. if there are pre-processors I can code to optimize compression in any place, or tweaks on the compression algorithm(s) used by JFFS2, let me know
[02:30] <nbd> i think the lacking jffs2 compression is mostly a problem with the small block size
[02:31] <h3sp4wn> nbd: Is the idea with build root ng to have all the config files in /etc/config (in an openwrt specific format) and then use a parser to generate the ones that are used by the actual programs so as to be able to be able to keep /etc/config between upgrades ?
[02:33] <db90h> I'll take a look into the inards of JFFS2 and see what's up.. there are pre-processors that can be written to optimize particular data sets for better compression
[02:33] <crazy_imp> how big are these config files? i saw a firmware which stored the complete firewallscript in the nvram, so it's maybe possible to drop the files in the nvram?
[02:33] <nbd> h3sp4wn: the config file stuff is also planned
[02:33] <nbd> h3sp4wn: but with 'buildroot-ng' i'm referring to the build system rewrite
[02:34] <nbd> crazy_imp: nvram is crap and not portable
[02:34] <nbd> crazy_imp: we don't want to use it
[02:34] <crazy_imp> (it was a crank branch from the original linksys firmware from an isp)
[02:34] <db90h> as u know, known data types can be optimized to compress better.. for instsance, x86 code can be pre-processed with BCJ and that substantially improves compression. That algorithm adjusts the JMPs/CALLs addresses so they aren't relative, but static.. so CALLs to the same address all end up being identical, regardless of their placement..
[02:34] <crazy_imp> nbd: ack, was just an idea
[02:34] <nbd> db90h: sounds interesting. i think on linux 2.6, jffs2 has model based compressors
[02:34] <nbd> db90h: at least for arm
[02:35] <db90h> MIPS code, I'm sure, can be pre-processeed so that general purpose algorithms compress it better.. I'd just need to get acquainted with the instruction formats to know for sure
[02:35] <nbd> db90h: i believe some of the code from linux 2.6 should be backported for that purpose
[02:36] <db90h> i'll take a look into eveyrthing.. currently I know jack about JFFS2, so better shut-up before I say anything stupid ;).. gotta go eat, bbl
[02:37] <h3sp4wn> nbd: But there is provision for the config files to be preserved between upgrades in the new image ?
[02:37] <h3sp4wn> nbd: Or will be ?
[02:37] <nbd> we will add something like that, yes
[02:37] <nbd> still thinking about the best way to implement it
[04:05] <db90h> what's up with this: http://openbsd-geek.de/archives/224-An-open-letter-to-the-OpenWrt-community.html ... we have an openwrt fork going on?
[05:46] <[mbm]> db90h: it already happened
[11:19] <RoDent> nbd: Which tarball did the latest kamikaze driver come from? I checked the revision logs and you mention USR, but the two tarballs I downloaded's wl_apsta.o doens't match the one I see in kernel-binary-wl-0.7.tar.gz
[11:20] <RoDent> I'm really after the "wl" util that matches that driver, because all the wl's I've tried so for whine about bss_info_version mismatch.
[12:15] <florian__> wrt: shut up
[12:17] <common> source based routing kicks ass
[12:18] <common> i hooked my neighbours wlan, setup a bridge, and sourcebase route my torrent traffic via his line
[12:19] <common> everything but torrent uses my line, torrent his line
[12:19] <common> i love it
[12:19] <florian__> lol
[12:20] <florian__> interesting way of doing QoS ;)
[12:20] <common> best way
[12:20] <common> i hope i can find a neighbour with adsl2+
[12:30] <florian__> where are you living common ?
[12:31] <common> germany
[12:31] <florian__> ok
[12:32] <florian__> I am wondering how efficient is this http-replicator stuff for gentoo
[12:34] <common> for debian there is apt-proxy
[12:35] <florian__> yep, that's the same idea
[12:35] <florian__> except that you have to cache both portage tree, so set up a rsync module, and the "distfiles" you download
[12:40] <Kaloz> nbd: syn/ack
[13:08] <nbd> Kaloz: have you had a look at http://busybox.net/bugs/view.php?id=370 for the ppc stuff?
[13:08] <nbd> RoDent: it's from the wrt300n gpl tarball
[13:09] <Kaloz> nbd: yeah, but the proper fixes in their svn are totally different :p
[13:10] <Kaloz> nbd: and my biggest concern is the armeabi stuff :p
[14:31] <RoDent> nbd: Thanks
[17:06] <pjf> guys - here is improved netmsg which can also receive meesages: http://projects.asn.pl/pointwrt/browser/branches/nutrius/package/busybox/patches/300-netmsg.patch
[17:07] <pjf> and in case someone was interested, there is a tool called setconsole backported from busybox' svn to 1.0 (eg. in whiterussian)
[17:08] <pjf> in the same dir, also
[17:08] <nbd> what does setconsole do?
[17:20] <pjf> it redirects what normally goes to /dev/console to tty of your choice
[17:20] <pjf> eg. /dev/tty
[17:21] <pjf> in other words it changes console= boot parameter
[17:26] <nbd> interesting
[17:29] <pjf> do you have idea how to fetch channel number of wds peer without scanning?
[17:29] <pjf> I mean -- I just realized that if I change channel number on one of two peers of a wds link, eg. one channel down, the link still em... "works"
[17:30] <pjf> ...but poorly, of course - I would like to detect such situation and sync the other peer to new channel
[17:31] <pjf> my first idea is to try libpcap it on monitor interface, but it'll take some time to implement
[17:34] <dragorn> well yeah, you're still hitting channel overlap there, you need to get 3+ channels away to avoid that
[17:34] <pjf> dragorn: that's not the problem I described
[17:35] <dragorn> iwconfig ought to show the current channel of the radio
[17:35] <pjf> I do know what I'm doing :P
[17:35] <pjf> I want to know it on the box which is syncing to the other
[17:35] <pjf> I can't fetch iwconfig from the other box
[17:36] <dragorn> if it doesn't implement syncing to the channel over tagparms announcing it, you're pretty stuck.
[17:36] <nbd> proprietary drivers suck
[17:37] <pjf> nbd: you're right :)
[17:37] Action: nbd will give bcm43xx another try very soon
[17:37] <pjf> cool! :)
[17:38] <pjf> well... I think for now I'll just write a proper libpcap filter and attach it to looong chain of tcpdump options :)
[17:38] <pjf> finally channel number in beacons will be useful :P
[17:45] <nbd> hmm... i just noticed that with buildroot-ng, i can finally make use of the image builder package lists in menuconfig
[00:00] --- Sun Jun 11 2006