[05:12] <db90h> lo
[05:12] <db90h> i've explored jffs2
[05:12] <db90h> at least, as bit
[05:13] <db90h> first obvious thing is that u can remove DYNRUBIN decompression support, since compression support has already been removed
[05:13] <db90h> the decmopression code is still there for backwards compatibility
[05:14] <db90h> JFFS2 ends up using ZLIB most of the time, tho one can easily extend it to support whatever algorithms
[05:16] <db90h> also RTIME algorithm comp&decomp support may or may not be worth it.. (currently its included).. will have to evaluate that
[05:17] <db90h> I could tweak JFFS2 endlessly and improve compression ratio for specific platforms.. by how much, I dunno.. progressively and incrementally, I can make a decent difference tho I think
[05:17] <db90h> since this is my area of expertise and I am a linux idiot still, can I submit patches for JFFS2 for you guys? I will test them first here.. if I get this build system working again that is ;p
[05:18] <db90h> ndb: as far as moving ipkg to a busybox plug-in, I still haven't looked at the busybox source.. been mucking around with other stuff, but will sometime ;)
[05:19] <db90h> the removal of DYNRUBIN decompression support will save a decent amount of space I think... there's no reason it should be there
[05:20] <db90h> unless u've got some older JFFS2 filesystems u want to maintain compatibility for.. and even then its extremely unlikely that you'll find DYNRUBIN used I think
[05:23] <db90h> I could insert LZMA support into JFFS2 as well, that'd probably be the thing to do for the most instantaneous improvement in compression ratio.. it'd be so easy
[05:38] <db90h> has JFFS2 source changed since RC5? I think I'd rather avoid other messes and test my changes on a known to be stable build first
[05:48] <db90h> i'll assume it hasn't changed... something else to consider is whether other ppl have made improvements to JFFS2.. perhaps this work has already been done and just needs patched in, must search to make sure
[06:06] <[mbm]> we haven't really played with the jffs2 stuff lately .. at one point we were using a patched version of jffs2 called jffs2-bbc which allowed plugin compression .. that got merged into the kernel and we really haven't tried to tweak it since
[06:06] <db90h> is this patch present in whiterussian rc5?
[06:07] <[mbm]> ".. that got merged into the kernel .."
[06:11] <db90h> so jffs2-bbc is part of the linux kernel now? i guess i'm an idiot, or linux newb, or whatever..
[06:11] <db90h> i wouldn't imagine its part of the kernel, that doesn't make sense to me
[06:12] <[mbm]> :P bbc is what added the dynbin, rtime and rubin support
[06:12] <db90h> but i don't know shit about the linux kernel
[06:13] <db90h> ah, ok..
[06:14] <db90h> those algorithms were not selected specifically for ur needs I'm sure, just there as part of the new plugin compression algo support
[06:14] <db90h> ?
[06:14] <db90h> ur needs being embedded mips
[06:15] <[mbm]> when we were using bbc I actually went and did some testing
[06:15] <db90h> how did they do?
[06:15] <[mbm]> that's why the options were selected
[06:16] <db90h> wait
[06:16] <db90h> dynrubin and rubin compression is not compiled in
[06:16] <db90h> that's what I was saying.. u can kill the decoders of both
[06:17] <db90h> unless u want to maintain backwards compatibility
[06:17] <db90h> look at compr.com,, jffs_compress .. u'll see both dynrubin and rubin disable.. and i doubt rtime comes in handy much
[06:18] <[mbm]> I'm saying what happened today is what happens when you take an old config file that was written for jffs2-bbc and load it on a current kernel
[06:18] <db90h> anyway.. unless u want to support other JFFS2-BBC file systems, no reason to include decompressor for DYNRUBIN
[06:18] <db90h> RUBIN decompressor is already killed I see
[06:19] <db90h> I haven't event looked at the configuration file, but the things in question are "#if 0" and "#if 1", so not #def's set make a difference.. so I'll have to look at the config and see what you are talking about
[06:20] <db90h> I dunno what it is about u, but u make my head hurt ;p.. I give up.. I'm gonna hack on the source code and live in my own little world, that's probably best for everyone ;)
[06:22] <[mbm]> I think that typing "u" all the time has had a disabling effect on your cognitive abilities
[06:23] <db90h> if DYNRUBIN decoder is needed for backwards compatibility, then keep it around ..it likely is small anyway.. if u want to remove it, see line 139 of compre.c... meanwhile, I'm gonna add new algorithms or optimize ZLIB one
[06:23] <[mbm]> it isn't, but I was trying to explain how we came to the current situation
[06:25] <db90h> yes, I'm sure there are many little things here and there like that caused by all the patches to various sources
[06:25] <db90h> and from so many cooks in the pot
[06:25] <db90h> it's nit picky of me to even mention it to start with
[06:27] <db90h> i guess its a whole different world open source development.. i have too much to get up to speed on, obviously.. so, like I said, I'll just go do my own thing.. I'll let u know if I do anything useful
[06:29] <db90h> i'm all demotivated now, fuck it.. i've got other things to do anyway.. sorry
[06:31] <[mbm]> ...
[06:32] Action: [mbm] wonders wtf just happened
[20:11] <[mbm]> http://www.htelephones.co.uk/usd.htm#9.00ZK9K8G08OUM .. $9 for a 1g flash chip?
[20:14] <[mbm]> http://kerneltrap.org/node/6692
[20:56] <[mbm]> nbd: poke
[20:57] <nbd> sup?
[20:58] <[mbm]> keep thinking about a way to get the equivilant of a serial console by booting into failsafe
[20:59] <[mbm]> you'd telnet in and run some command to resume a normal bootup
[21:00] <nbd> didn't someone mention the setconsole utility?
[21:00] <nbd> what if we'd just make telnet use a pts device and use setconsole to redirect the console to that pts device?
[21:01] <[mbm]> actually my concern is mostly about how to boot up the device without dropping the network connection
[21:02] <nbd> isn't there also a kernel patch for console-over-network?
[21:02] <nbd> if it can't do it already, we could modify it so that it sends the console data as raw packets independent of the interface configuration
[21:02] <[mbm]> there is but that's a mess
[21:02] <nbd> hmm
[21:03] <[mbm]> I mean we already have the telnet server and we have an rcS that could probably be invoked manually
[21:03] <[mbm]> I'm just trying to figure out the final pieces of how to get it to work from failsafe
[21:03] <nbd> well, if we allow scripts to change firewall settings or the network interface configuration, it'll never be safe from broken scripts
[21:03] <[mbm]> all the other network console patches require a special listening daemon and spam the network even when not in failsafe
[21:04] <nbd> hmm
[21:05] <[mbm]> and yes, I know that scripts could easily break it
[21:05] <[mbm]> which is why you'd get the script name printed out
[21:05] <[mbm]> if you see S45firewall and then it hangs or drops your connection
[21:05] <[mbm]> well then it'spretty obvious what happened
[21:06] <[mbm]> ...
[21:06] <[mbm]> the intent is mostly just to make it easier for people to debug problems with bootup
[21:09] <nbd> yeah
[21:09] <nbd> makes sense
[21:10] <[mbm]> btw when is webif going to be fixed for the rc6 release?
[21:12] <nbd> what part specifically?
[21:13] <[mbm]> I'd have to go back and look, I just remember that there was a number of things I'd pointed out that needed to be fixed before an rc6 release
[21:13] <nbd> make tickets for them
[21:14] <[mbm]> done any work on the firewall page?
[21:14] <nbd> not yet
[21:14] Action: [mbm] goes to compile whiterussian
[21:14] <nbd> but i will
[22:16] <RoDent> nbd: you have a minute to chat about mssid ?
[22:19] <[mbm]> hmm this is annoying; if you tftp a firmware but get the 'code pattern incorrect' from cfe then it stops the tftp server
[22:19] <nbd> RoDent: sure
[22:20] <[mbm]> and without booting the old firmware .. so now it'll be stuck in cfe until I powercycle it
[22:20] <RoDent> nbd: Have you succesfully had the new wificonf broadcast multiple ssid's ?
[22:21] <RoDent> FYI: There seems to be a small bug in the setup_bcom_new -- it doesn't bring up the main (wl0) iface
[22:23] <nbd> wificonf is obsolete
[22:23] <RoDent> Oh?
[22:23] <nbd> i've written a wl replacement that can set all the important options in the driver
[22:23] <nbd> and i'll use it to set up the driver with some shell code
[22:23] <RoDent> Ah
[22:23] <RoDent> Could I beta it ? ;)
[22:24] <nbd> the shell code is not working yet
[22:24] <nbd> i didn't have time to finish it yet
[22:24] <RoDent> I'
[22:25] <RoDent> I'm currently pottering around with one of the tarballs' proprietary wl.
[22:26] <RoDent> Back to original question: Have you gotten the driver to do anything useful as far as multiple ssids are concerned?
[22:26] <RoDent> I can get wl to happily configure and bring up multiple configurations
[22:26] <RoDent> Scans just show a single ssid though.
[22:27] <[mbm]> send out a probe request for the other ssids and see if you get a response
[22:28] <RoDent> Will give that a shot. Thanks.
[22:29] <malbon> RoDent: I had problems like that. The ssid's share the same mac, and certain cards don't report the extra ssids available.
[22:29] <[mbm]> hrm .. can't get this damned thing out of cfe
[22:29] <[mbm]> pings but doesn't tftp
[22:31] <nbd> RoDent: the main problem is that the broadcast only happens on one bssid
[22:31] <nbd> RoDent: many drivers don't deal with that properly and only show one essid
[22:31] <malbon> RoDent: especially hermes based cards I found.
[22:32] <RoDent> Apparently the old broadcom drivers too. I've been scanning from an older WRT
[22:32] <[mbm]> well, it's a beacon .. it'll contain the beacon interval, channel, ssid and supported rates
[22:32] <[mbm]> even when you turn off 'broadcast ssid' all that happens is that it doesn't send the ssid in the beacons .. you still get beacons
[22:33] <[mbm]> so the only thing that's happening with the multi ssid is that it's using the first ssid for the beacons
[22:33] <[mbm]> which really isn't that surprising
[22:33] <RoDent> Alright, so it should respond to association requests from the other virtual IF's
[22:33] <[mbm]> would hope so
[22:34] <malbon> it flips between the ssid's in the beacon, using a acx111 card I could see 2 at a time.
[22:34] <[mbm]> malbon: oh, you've tested the broadcom multi ssid?
[22:34] <malbon> [mbm]: I wrote a wiki page on it.
[22:34] <[mbm]> ah
[22:35] <RoDent> This one ? http://wiki.openwrt.org/multi-ssid
[22:35] <malbon> yup
[22:35] <malbon> has it been useful?
[22:35] <RoDent> Yes. Very much
[22:36] <malbon> I abandoned it and moved to atheros because their multi-ssid uses different mac addresses fir each vif.
[22:38] <RoDent> Ugh.
[22:38] <RoDent> I can scan for one of the VIF's SSID's manually. But associating to it from another WRT is impossible it seems.
[22:39] <RoDent> The scanresult comes back with the SSID of one of the other iF's
[22:40] <RoDent> OK.
[22:40] <RoDent> I'm going to give up on this feature for now. Seems like it's a bit of a dark horse at this point. Thanks for the pointers malbon:
[22:40] <dragorn> try kismet or tcpdump
[22:41] <dragorn> see what it's actually beaconing
[22:41] <dragorn> gets firmware collisions out of the way
[22:41] <RoDent> Hmm. Wonder if that may make a difference. New driver to New Driver on different wrts
[22:42] Action: nbd slaps CIA-16
[22:42] <nbd> lazy bot
[22:42] <malbon> RoDent: how many vif's have you configured?
[22:43] <RoDent> three at the moment.
[22:43] <RoDent> But it has not made a difference with two either.
[22:43] <malbon> aha
[22:43] <malbon> try two, reset everything then do testing.
[22:43] <RoDent> Will do.
[22:44] <RoDent> Two wl0.x's ?
[22:44] <malbon> I had real problems with 3, 2 seems nearly stable.
[22:44] <RoDent> Or just wl0, and wl0.1 ?
[22:44] <malbon> no, wl0 and wl0.1
[22:44] <RoDent> K
[22:44] <nbd> 4 is the upper limit (wl0 .. wl0.3)
[23:40] <[mbm]> hmm .. why do we have ipw2100 support in the broadcom kernels?
[23:41] <crazy_imp> wtf?
[23:41] <crazy_imp> are the ipw2100/2200 sold on cards so you would be able to plug it in a pcmia slot?
[23:42] <[mbm]> probably.. I just don't remember any broadcom boards using them
[23:43] <crazy_imp> remove it, maybne someone is screaming if he miss it :D
[23:43] <[mbm]> https://dev.openwrt.org/browser/trunk/openwrt/target/linux/brcm-2.6/config#L942
[23:43] <[mbm]> nah, I'll track down exactly who added it and when
[23:44] <[mbm]> I hate people who just blindly nuke code, since it usually breaks stuff I'm working on
[23:45] <crazy_imp> hm, isn't the line 959 needed for kismet on wrt54g(s)?
[23:47] <crazy_imp> i'm too tired to read it right :D. good night all
[23:48] <[mbm]> hmm those lines seem to have come from one of kaloz's commits 6 months ago
[23:52] <Kaloz> crashev: minpci :p
[23:53] <Kaloz> minipci*
[00:00] --- Tue Jun 13 2006
[05:12] <db90h> i've explored jffs2
[05:12] <db90h> at least, as bit
[05:13] <db90h> first obvious thing is that u can remove DYNRUBIN decompression support, since compression support has already been removed
[05:13] <db90h> the decmopression code is still there for backwards compatibility
[05:14] <db90h> JFFS2 ends up using ZLIB most of the time, tho one can easily extend it to support whatever algorithms
[05:16] <db90h> also RTIME algorithm comp&decomp support may or may not be worth it.. (currently its included).. will have to evaluate that
[05:17] <db90h> I could tweak JFFS2 endlessly and improve compression ratio for specific platforms.. by how much, I dunno.. progressively and incrementally, I can make a decent difference tho I think
[05:17] <db90h> since this is my area of expertise and I am a linux idiot still, can I submit patches for JFFS2 for you guys? I will test them first here.. if I get this build system working again that is ;p
[05:18] <db90h> ndb: as far as moving ipkg to a busybox plug-in, I still haven't looked at the busybox source.. been mucking around with other stuff, but will sometime ;)
[05:19] <db90h> the removal of DYNRUBIN decompression support will save a decent amount of space I think... there's no reason it should be there
[05:20] <db90h> unless u've got some older JFFS2 filesystems u want to maintain compatibility for.. and even then its extremely unlikely that you'll find DYNRUBIN used I think
[05:23] <db90h> I could insert LZMA support into JFFS2 as well, that'd probably be the thing to do for the most instantaneous improvement in compression ratio.. it'd be so easy
[05:38] <db90h> has JFFS2 source changed since RC5? I think I'd rather avoid other messes and test my changes on a known to be stable build first
[05:48] <db90h> i'll assume it hasn't changed... something else to consider is whether other ppl have made improvements to JFFS2.. perhaps this work has already been done and just needs patched in, must search to make sure
[06:06] <[mbm]> we haven't really played with the jffs2 stuff lately .. at one point we were using a patched version of jffs2 called jffs2-bbc which allowed plugin compression .. that got merged into the kernel and we really haven't tried to tweak it since
[06:06] <db90h> is this patch present in whiterussian rc5?
[06:07] <[mbm]> ".. that got merged into the kernel .."
[06:11] <db90h> so jffs2-bbc is part of the linux kernel now? i guess i'm an idiot, or linux newb, or whatever..
[06:11] <db90h> i wouldn't imagine its part of the kernel, that doesn't make sense to me
[06:12] <[mbm]> :P bbc is what added the dynbin, rtime and rubin support
[06:12] <db90h> but i don't know shit about the linux kernel
[06:13] <db90h> ah, ok..
[06:14] <db90h> those algorithms were not selected specifically for ur needs I'm sure, just there as part of the new plugin compression algo support
[06:14] <db90h> ?
[06:14] <db90h> ur needs being embedded mips
[06:15] <[mbm]> when we were using bbc I actually went and did some testing
[06:15] <db90h> how did they do?
[06:15] <[mbm]> that's why the options were selected
[06:16] <db90h> wait
[06:16] <db90h> dynrubin and rubin compression is not compiled in
[06:16] <db90h> that's what I was saying.. u can kill the decoders of both
[06:17] <db90h> unless u want to maintain backwards compatibility
[06:17] <db90h> look at compr.com,, jffs_compress .. u'll see both dynrubin and rubin disable.. and i doubt rtime comes in handy much
[06:18] <[mbm]> I'm saying what happened today is what happens when you take an old config file that was written for jffs2-bbc and load it on a current kernel
[06:18] <db90h> anyway.. unless u want to support other JFFS2-BBC file systems, no reason to include decompressor for DYNRUBIN
[06:18] <db90h> RUBIN decompressor is already killed I see
[06:19] <db90h> I haven't event looked at the configuration file, but the things in question are "#if 0" and "#if 1", so not #def's set make a difference.. so I'll have to look at the config and see what you are talking about
[06:20] <db90h> I dunno what it is about u, but u make my head hurt ;p.. I give up.. I'm gonna hack on the source code and live in my own little world, that's probably best for everyone ;)
[06:22] <[mbm]> I think that typing "u" all the time has had a disabling effect on your cognitive abilities
[06:23] <db90h> if DYNRUBIN decoder is needed for backwards compatibility, then keep it around ..it likely is small anyway.. if u want to remove it, see line 139 of compre.c... meanwhile, I'm gonna add new algorithms or optimize ZLIB one
[06:23] <[mbm]> it isn't, but I was trying to explain how we came to the current situation
[06:25] <db90h> yes, I'm sure there are many little things here and there like that caused by all the patches to various sources
[06:25] <db90h> and from so many cooks in the pot
[06:25] <db90h> it's nit picky of me to even mention it to start with
[06:27] <db90h> i guess its a whole different world open source development.. i have too much to get up to speed on, obviously.. so, like I said, I'll just go do my own thing.. I'll let u know if I do anything useful
[06:29] <db90h> i'm all demotivated now, fuck it.. i've got other things to do anyway.. sorry
[06:31] <[mbm]> ...
[06:32] Action: [mbm] wonders wtf just happened
[20:11] <[mbm]> http://www.htelephones.co.uk/usd.htm#9.00ZK9K8G08OUM .. $9 for a 1g flash chip?
[20:14] <[mbm]> http://kerneltrap.org/node/6692
[20:56] <[mbm]> nbd: poke
[20:57] <nbd> sup?
[20:58] <[mbm]> keep thinking about a way to get the equivilant of a serial console by booting into failsafe
[20:59] <[mbm]> you'd telnet in and run some command to resume a normal bootup
[21:00] <nbd> didn't someone mention the setconsole utility?
[21:00] <nbd> what if we'd just make telnet use a pts device and use setconsole to redirect the console to that pts device?
[21:01] <[mbm]> actually my concern is mostly about how to boot up the device without dropping the network connection
[21:02] <nbd> isn't there also a kernel patch for console-over-network?
[21:02] <nbd> if it can't do it already, we could modify it so that it sends the console data as raw packets independent of the interface configuration
[21:02] <[mbm]> there is but that's a mess
[21:02] <nbd> hmm
[21:03] <[mbm]> I mean we already have the telnet server and we have an rcS that could probably be invoked manually
[21:03] <[mbm]> I'm just trying to figure out the final pieces of how to get it to work from failsafe
[21:03] <nbd> well, if we allow scripts to change firewall settings or the network interface configuration, it'll never be safe from broken scripts
[21:03] <[mbm]> all the other network console patches require a special listening daemon and spam the network even when not in failsafe
[21:04] <nbd> hmm
[21:05] <[mbm]> and yes, I know that scripts could easily break it
[21:05] <[mbm]> which is why you'd get the script name printed out
[21:05] <[mbm]> if you see S45firewall and then it hangs or drops your connection
[21:05] <[mbm]> well then it'spretty obvious what happened
[21:06] <[mbm]> ...
[21:06] <[mbm]> the intent is mostly just to make it easier for people to debug problems with bootup
[21:09] <nbd> yeah
[21:09] <nbd> makes sense
[21:10] <[mbm]> btw when is webif going to be fixed for the rc6 release?
[21:12] <nbd> what part specifically?
[21:13] <[mbm]> I'd have to go back and look, I just remember that there was a number of things I'd pointed out that needed to be fixed before an rc6 release
[21:13] <nbd> make tickets for them
[21:14] <[mbm]> done any work on the firewall page?
[21:14] <nbd> not yet
[21:14] Action: [mbm] goes to compile whiterussian
[21:14] <nbd> but i will
[22:16] <RoDent> nbd: you have a minute to chat about mssid ?
[22:19] <[mbm]> hmm this is annoying; if you tftp a firmware but get the 'code pattern incorrect' from cfe then it stops the tftp server
[22:19] <nbd> RoDent: sure
[22:20] <[mbm]> and without booting the old firmware .. so now it'll be stuck in cfe until I powercycle it
[22:20] <RoDent> nbd: Have you succesfully had the new wificonf broadcast multiple ssid's ?
[22:21] <RoDent> FYI: There seems to be a small bug in the setup_bcom_new -- it doesn't bring up the main (wl0) iface
[22:23] <nbd> wificonf is obsolete
[22:23] <RoDent> Oh?
[22:23] <nbd> i've written a wl replacement that can set all the important options in the driver
[22:23] <nbd> and i'll use it to set up the driver with some shell code
[22:23] <RoDent> Ah
[22:23] <RoDent> Could I beta it ? ;)
[22:24] <nbd> the shell code is not working yet
[22:24] <nbd> i didn't have time to finish it yet
[22:24] <RoDent> I'
[22:25] <RoDent> I'm currently pottering around with one of the tarballs' proprietary wl.
[22:26] <RoDent> Back to original question: Have you gotten the driver to do anything useful as far as multiple ssids are concerned?
[22:26] <RoDent> I can get wl to happily configure and bring up multiple configurations
[22:26] <RoDent> Scans just show a single ssid though.
[22:27] <[mbm]> send out a probe request for the other ssids and see if you get a response
[22:28] <RoDent> Will give that a shot. Thanks.
[22:29] <malbon> RoDent: I had problems like that. The ssid's share the same mac, and certain cards don't report the extra ssids available.
[22:29] <[mbm]> hrm .. can't get this damned thing out of cfe
[22:29] <[mbm]> pings but doesn't tftp
[22:31] <nbd> RoDent: the main problem is that the broadcast only happens on one bssid
[22:31] <nbd> RoDent: many drivers don't deal with that properly and only show one essid
[22:31] <malbon> RoDent: especially hermes based cards I found.
[22:32] <RoDent> Apparently the old broadcom drivers too. I've been scanning from an older WRT
[22:32] <[mbm]> well, it's a beacon .. it'll contain the beacon interval, channel, ssid and supported rates
[22:32] <[mbm]> even when you turn off 'broadcast ssid' all that happens is that it doesn't send the ssid in the beacons .. you still get beacons
[22:33] <[mbm]> so the only thing that's happening with the multi ssid is that it's using the first ssid for the beacons
[22:33] <[mbm]> which really isn't that surprising
[22:33] <RoDent> Alright, so it should respond to association requests from the other virtual IF's
[22:33] <[mbm]> would hope so
[22:34] <malbon> it flips between the ssid's in the beacon, using a acx111 card I could see 2 at a time.
[22:34] <[mbm]> malbon: oh, you've tested the broadcom multi ssid?
[22:34] <malbon> [mbm]: I wrote a wiki page on it.
[22:34] <[mbm]> ah
[22:35] <RoDent> This one ? http://wiki.openwrt.org/multi-ssid
[22:35] <malbon> yup
[22:35] <malbon> has it been useful?
[22:35] <RoDent> Yes. Very much
[22:36] <malbon> I abandoned it and moved to atheros because their multi-ssid uses different mac addresses fir each vif.
[22:38] <RoDent> Ugh.
[22:38] <RoDent> I can scan for one of the VIF's SSID's manually. But associating to it from another WRT is impossible it seems.
[22:39] <RoDent> The scanresult comes back with the SSID of one of the other iF's
[22:40] <RoDent> OK.
[22:40] <RoDent> I'm going to give up on this feature for now. Seems like it's a bit of a dark horse at this point. Thanks for the pointers malbon:
[22:40] <dragorn> try kismet or tcpdump
[22:41] <dragorn> see what it's actually beaconing
[22:41] <dragorn> gets firmware collisions out of the way
[22:41] <RoDent> Hmm. Wonder if that may make a difference. New driver to New Driver on different wrts
[22:42] Action: nbd slaps CIA-16
[22:42] <nbd> lazy bot
[22:42] <malbon> RoDent: how many vif's have you configured?
[22:43] <RoDent> three at the moment.
[22:43] <RoDent> But it has not made a difference with two either.
[22:43] <malbon> aha
[22:43] <malbon> try two, reset everything then do testing.
[22:43] <RoDent> Will do.
[22:44] <RoDent> Two wl0.x's ?
[22:44] <malbon> I had real problems with 3, 2 seems nearly stable.
[22:44] <RoDent> Or just wl0, and wl0.1 ?
[22:44] <malbon> no, wl0 and wl0.1
[22:44] <RoDent> K
[22:44] <nbd> 4 is the upper limit (wl0 .. wl0.3)
[23:40] <[mbm]> hmm .. why do we have ipw2100 support in the broadcom kernels?
[23:41] <crazy_imp> wtf?
[23:41] <crazy_imp> are the ipw2100/2200 sold on cards so you would be able to plug it in a pcmia slot?
[23:42] <[mbm]> probably.. I just don't remember any broadcom boards using them
[23:43] <crazy_imp> remove it, maybne someone is screaming if he miss it :D
[23:43] <[mbm]> https://dev.openwrt.org/browser/trunk/openwrt/target/linux/brcm-2.6/config#L942
[23:43] <[mbm]> nah, I'll track down exactly who added it and when
[23:44] <[mbm]> I hate people who just blindly nuke code, since it usually breaks stuff I'm working on
[23:45] <crazy_imp> hm, isn't the line 959 needed for kismet on wrt54g(s)?
[23:47] <crazy_imp> i'm too tired to read it right :D. good night all
[23:48] <[mbm]> hmm those lines seem to have come from one of kaloz's commits 6 months ago
[23:52] <Kaloz> crashev: minpci :p
[23:53] <Kaloz> minipci*
[00:00] --- Tue Jun 13 2006