[00:05] <groz> mbm, building for wrt, so far, peerguardian and some sound stuff puked
[00:05] <[mbm]> figured
[00:05] <groz> haven't looked yet at wh, just take them out of menuconfig, let it go again
[00:05] <groz> see what else
[00:05] <[mbm]> added a -k to my make and let it see what bombed
[00:06] <groz> i've been letting it run while i deal with phone calls, been on phone most of the time, just letting it build
[00:06] <[mbm]> ditto
[00:41] <CIA-17> mbm * r4724 /packages/net/maradns/Makefile: prevent parse error on V=
[04:26] <db90h> asus added a save and restore (to/from a file) to the broadcom nvram utility.. of course it's not but a little code, but maybe worth slapping into OpenWrt (or recoding). Of course, such functionality is easily duplicated other ways, but this is intuitive.
[04:27] <db90h> I am going to make the patch, up to you if you want to use it
[04:28] <db90h> storage is of course in standard HDR1 format
[04:36] <[mbm]> I really doubt they handle issues like the unique nature of the sdram configuration or mac addresses
[04:37] <db90h> it's just the user mode nvram utility
[04:37] <db90h> the sdram variables (stored in the header as well as in variables) aren't dealt with at this level, they are handled (if appropriate) by the kernel mode code
[04:38] <db90h> all this is an addition to the nvram tool you're already using
[04:38] <[mbm]> what I mean is there's a good chance someone might take the nvram config from one router and attempt to load it on another router
[04:38] <db90h> sure, it doesn't try to protect an idiot from themselves
[04:38] <[mbm]> and if I attempted to take an nvram config from a gs with 32M and load it on a g with only 16M, it's going to be a mess
[04:40] <db90h> one could add such protections easily
[04:40] <db90h> maybe i will.. if restored sdram parameters != existing then don't restore
[04:41] <db90h> as far as the MAC addresses.. same could be done, but at least changing them wouldn't brick the router
[04:41] <[mbm]> no, but having 6 aps all claiming to have the same mac address might break any concept of networking
[04:42] <db90h> sure
[04:42] <db90h> of course
[04:44] <Bartman007> [mbm]: yeah, it's called idiot-proof networking.
[04:44] <[mbm]> hmm gotta love frys .. half of the boxes for network cards were opened; specifically asked for one that hadn't been opened and got one still in the shrink wrap, opened it up and all the seals inside are broken
[04:44] <[mbm]> in other words this is a returned item that they re-wrapped
[04:45] <Bartman007> yeah, was the shrinkwrap still warm? :-)
[04:45] <[mbm]> well, at least this time I didn't fall for the "give me that box and I'll see if we have any wrapped ones like it in the back" trick
[04:45] <[mbm]> this one actually was on the shelf wrapped
[04:46] Action: [mbm] goes to swap the lousy bcm43xx with an atheros
[04:49] <[mbm]> .. much better ..
[04:49] <Bartman007> swapped it without dropping the connection, impressive.
[06:45] <Bartman007> Kaloz: the package was shipped, hopefully the routers will arrive soon, then I can let you know what's inside the 6000
[08:14] <Kaloz> Bartman007: okay, thanks
[08:14] <Kaloz> florian_: http://akusho.chuui.jp/time/Inventel%20DV3210-WS%20-%20JTAG.jpg
[15:00] <florian_> Kaloz: hey nice shot
[15:00] <florian_> damn, how could we have figured this out by ourselves
[15:50] <florian_> {Nico}: are you available this week ? etienne told me he has just received the two airlink ar525 he ordered
[16:00] <florian_> happy hacking :)
[16:01] <nbd> airlink ar525 is that the one based on the x86 RDC core with ralink wifi?
[16:01] <florian_> precisely
[16:01] <nbd> great. i have a compatible one
[16:02] <florian_> ah
[16:02] <florian_> I just fear that we have to stick we a x86-2.4 kernel to have airlink master mode support
[16:02] <nbd> is the d80211 based driver only available for station mode?
[16:02] <florian_> I don't know yet
[16:03] <nbd> because there's clearly some work being done on it in wireless-dev
[16:03] <florian_> ah
[16:03] <florian_> this would be great
[16:03] <nbd> and i have already written some stuff to make the d80211 from wireless-dev compatible with 2.6.17 and put it in a package
[16:03] <florian_> I hope there is not too much x86 changes from the mainline branch
[16:04] <nbd> i've been able to compile bcm43xx-d80211 with it as well
[16:04] <nbd> but that one crashes
[16:04] <nbd> (probably not my fault either)
[16:04] <florian_> bcm43xx is quite unstable yet
[16:04] <florian_> it was better few months ago
[16:04] <nbd> let's see how this whole ssb stuff turns out
[16:05] <nbd> maybe with it we can make bcm43xx work with less hacks
[16:05] <florian_> sure
[16:05] <florian_> I think there is a lot of interest in such chips because they are usable now
[16:09] <dragorn> I think theres always been interest because they're cheap and if you go to a store, you'll end up with one 70% of the time
[16:09] <dragorn> and people don't like to pay real money for toys :P
[16:09] <dragorn> but then, I'm opinionated about people :P
[16:09] <nbd> just because you're opinionated doesn't mean you're wrong :)
[16:10] <dragorn> Just judging from the number of "can i get kismet working with ndiswrapprer" questions
[16:11] <dragorn> I think theres been a fairly high level of interest for a while
[16:11] <nbd> yeah
[16:12] <florian_> ndiswrapper is a real problem actually because it prevents people from making pressure to have native drivers
[16:12] <nbd> yep
[16:13] <florian_> and because ndiswrapper is really good now, it more and more prevent people from using native drivers
[16:13] <nbd> next thing we'll see is that manufacturers claim their stuff is 'linux compatible' because it works with crappy windows drivers and ndiswrapper
[16:13] <florian_> yes
[16:14] <dragorn> ndiswrapper achieves what people always complained about with wine
[16:14] <dragorn> unfortunately
[16:15] <dragorn> but now i have to go, 6 hours car ride + camping + wedding. Hope I don't get washed away in the monsoon thats forecast.
[16:15] <nbd> good luck
[16:23] <florian_> did you ever tried cross compiling isakmpd ?
[16:24] <nbd> no
[16:25] <florian_> looks like the most painful thing I ever attempted to cross compile
[16:25] <florian_> I was supposed to make racoon with ios work with x509 certs, but it looks like I have to install isakmpd instead
[16:26] <nbd> why?
[16:30] <florian_> because it does not work :)
[16:30] <florian_> and that isakmpd did not make choice in implementation, it implements the whole rfc
[19:06] <Bartman007> florian_: wine is the same way.
[19:07] <Bartman007> oh heh, I was scrolled up...
[23:45] <florian_> re
[00:00] --- Sat Sep 2 2006
[00:05] <[mbm]> figured
[00:05] <groz> haven't looked yet at wh, just take them out of menuconfig, let it go again
[00:05] <groz> see what else
[00:05] <[mbm]> added a -k to my make and let it see what bombed
[00:06] <groz> i've been letting it run while i deal with phone calls, been on phone most of the time, just letting it build
[00:06] <[mbm]> ditto
[00:41] <CIA-17> mbm * r4724 /packages/net/maradns/Makefile: prevent parse error on V=
[04:26] <db90h> asus added a save and restore (to/from a file) to the broadcom nvram utility.. of course it's not but a little code, but maybe worth slapping into OpenWrt (or recoding). Of course, such functionality is easily duplicated other ways, but this is intuitive.
[04:27] <db90h> I am going to make the patch, up to you if you want to use it
[04:28] <db90h> storage is of course in standard HDR1 format
[04:36] <[mbm]> I really doubt they handle issues like the unique nature of the sdram configuration or mac addresses
[04:37] <db90h> it's just the user mode nvram utility
[04:37] <db90h> the sdram variables (stored in the header as well as in variables) aren't dealt with at this level, they are handled (if appropriate) by the kernel mode code
[04:38] <db90h> all this is an addition to the nvram tool you're already using
[04:38] <[mbm]> what I mean is there's a good chance someone might take the nvram config from one router and attempt to load it on another router
[04:38] <db90h> sure, it doesn't try to protect an idiot from themselves
[04:38] <[mbm]> and if I attempted to take an nvram config from a gs with 32M and load it on a g with only 16M, it's going to be a mess
[04:40] <db90h> one could add such protections easily
[04:40] <db90h> maybe i will.. if restored sdram parameters != existing then don't restore
[04:41] <db90h> as far as the MAC addresses.. same could be done, but at least changing them wouldn't brick the router
[04:41] <[mbm]> no, but having 6 aps all claiming to have the same mac address might break any concept of networking
[04:42] <db90h> sure
[04:42] <db90h> of course
[04:44] <Bartman007> [mbm]: yeah, it's called idiot-proof networking.
[04:44] <[mbm]> hmm gotta love frys .. half of the boxes for network cards were opened; specifically asked for one that hadn't been opened and got one still in the shrink wrap, opened it up and all the seals inside are broken
[04:44] <[mbm]> in other words this is a returned item that they re-wrapped
[04:45] <Bartman007> yeah, was the shrinkwrap still warm? :-)
[04:45] <[mbm]> well, at least this time I didn't fall for the "give me that box and I'll see if we have any wrapped ones like it in the back" trick
[04:45] <[mbm]> this one actually was on the shelf wrapped
[04:46] Action: [mbm] goes to swap the lousy bcm43xx with an atheros
[04:49] <[mbm]> .. much better ..
[04:49] <Bartman007> swapped it without dropping the connection, impressive.
[06:45] <Bartman007> Kaloz: the package was shipped, hopefully the routers will arrive soon, then I can let you know what's inside the 6000
[08:14] <Kaloz> Bartman007: okay, thanks
[08:14] <Kaloz> florian_: http://akusho.chuui.jp/time/Inventel%20DV3210-WS%20-%20JTAG.jpg
[15:00] <florian_> Kaloz: hey nice shot
[15:00] <florian_> damn, how could we have figured this out by ourselves
[15:50] <florian_> {Nico}: are you available this week ? etienne told me he has just received the two airlink ar525 he ordered
[16:00] <florian_> happy hacking :)
[16:01] <nbd> airlink ar525 is that the one based on the x86 RDC core with ralink wifi?
[16:01] <florian_> precisely
[16:01] <nbd> great. i have a compatible one
[16:02] <florian_> ah
[16:02] <florian_> I just fear that we have to stick we a x86-2.4 kernel to have airlink master mode support
[16:02] <nbd> is the d80211 based driver only available for station mode?
[16:02] <florian_> I don't know yet
[16:03] <nbd> because there's clearly some work being done on it in wireless-dev
[16:03] <florian_> ah
[16:03] <florian_> this would be great
[16:03] <nbd> and i have already written some stuff to make the d80211 from wireless-dev compatible with 2.6.17 and put it in a package
[16:03] <florian_> I hope there is not too much x86 changes from the mainline branch
[16:04] <nbd> i've been able to compile bcm43xx-d80211 with it as well
[16:04] <nbd> but that one crashes
[16:04] <nbd> (probably not my fault either)
[16:04] <florian_> bcm43xx is quite unstable yet
[16:04] <florian_> it was better few months ago
[16:04] <nbd> let's see how this whole ssb stuff turns out
[16:05] <nbd> maybe with it we can make bcm43xx work with less hacks
[16:05] <florian_> sure
[16:05] <florian_> I think there is a lot of interest in such chips because they are usable now
[16:09] <dragorn> I think theres always been interest because they're cheap and if you go to a store, you'll end up with one 70% of the time
[16:09] <dragorn> and people don't like to pay real money for toys :P
[16:09] <dragorn> but then, I'm opinionated about people :P
[16:09] <nbd> just because you're opinionated doesn't mean you're wrong :)
[16:10] <dragorn> Just judging from the number of "can i get kismet working with ndiswrapprer" questions
[16:11] <dragorn> I think theres been a fairly high level of interest for a while
[16:11] <nbd> yeah
[16:12] <florian_> ndiswrapper is a real problem actually because it prevents people from making pressure to have native drivers
[16:12] <nbd> yep
[16:13] <florian_> and because ndiswrapper is really good now, it more and more prevent people from using native drivers
[16:13] <nbd> next thing we'll see is that manufacturers claim their stuff is 'linux compatible' because it works with crappy windows drivers and ndiswrapper
[16:13] <florian_> yes
[16:14] <dragorn> ndiswrapper achieves what people always complained about with wine
[16:14] <dragorn> unfortunately
[16:15] <dragorn> but now i have to go, 6 hours car ride + camping + wedding. Hope I don't get washed away in the monsoon thats forecast.
[16:15] <nbd> good luck
[16:23] <florian_> did you ever tried cross compiling isakmpd ?
[16:24] <nbd> no
[16:25] <florian_> looks like the most painful thing I ever attempted to cross compile
[16:25] <florian_> I was supposed to make racoon with ios work with x509 certs, but it looks like I have to install isakmpd instead
[16:26] <nbd> why?
[16:30] <florian_> because it does not work :)
[16:30] <florian_> and that isakmpd did not make choice in implementation, it implements the whole rfc
[19:06] <Bartman007> florian_: wine is the same way.
[19:07] <Bartman007> oh heh, I was scrolled up...
[23:45] <florian_> re
[00:00] --- Sat Sep 2 2006