[02:29] <CIA-16> nbd * r3916 / (3 files in 3 dirs): add dropbear pubkey auth patch from #582
[02:32] <CIA-16> nbd * r3917 /branches/whiterussian/openwrt/package/wificonf/wificonf.c: allow 63 chars in the wpa psk in wet mode (#556)
[02:39] <CIA-16> nbd * r3918 /branches/whiterussian/openwrt/package/webif/files/usr/lib/webif/webif.sh: add webif workaround for ie (#564)
[02:41] <[mbm]> nbd: you might want to take a look at the firewall page in webif; several complaints about that over the last week
[02:41] <[mbm]> maybe we should write that iptables plugin to match the ip address of an interface
[02:46] <nbd> yeah
[02:46] <[mbm]> the other thing that I was thinking of is a way of booting the system from failsafe
[02:46] <CIA-16> nbd * r3919 / (4 files in 4 dirs): upgrade maradns to the latest version (#511)
[02:47] <[mbm]> so you could start a normal bootup and what would otherwise only be visible on serial
[02:58] <[mbm]> .. as for the firewall, the other option is to start putting pieces of the firewall in hotplug
[02:58] <[mbm]> which would require us to restructure the firewall
[03:04] <nbd> i don't like that
[03:04] <nbd> the matching module is a better solution
[03:04] <[mbm]> trying to get a response from #netfilter to see if there's anything similar
[03:05] Action: nbd is currently fixing the applet name display of busybox for the process list
[03:05] <nbd> it's a bug in my ash performance hack
[03:05] <[mbm]> if we decided to do it the hotplug way we'd have custom tables like wan_input wan_output ...
[03:06] <[mbm]> which would replace the input_rule, output_rule and so on in firewall.user
[03:19] <nbd> [mbm]: is there a safe way to replace a short argv with a longer one?
[03:26] <[mbm]> hmm .. after argv is the environment
[03:26] <[mbm]> so you'd be clobbering that
[03:30] <CIA-16> nbd * r3920 / (2 files in 2 dirs): fix cflags, fix adjtimex patch (#587)
[03:35] <CIA-16> nbd * r3921 / (3 files in 3 dirs): ppp: try to reconnect indefinitely (#551)
[03:35] <[mbm]> nbd: btw what do you think of setting up /etc/resolv.conf to point at dnsmasq and having dnsmasq use /tmp/resolv.conf?
[03:38] <nbd> good idea
[03:39] <[mbm]> there's a thread on the forum from back in january where the idea was discussed
[03:39] <[mbm]> we just never got around to it
[03:55] <CIA-16> nbd * r3922 / (6 files in 6 dirs): update ebtables to 2.0.8-rc2 (#558)
[04:05] <CIA-16> nbd * r3923 / (3 files in 3 dirs): install missing ebtables files
[04:21] <CIA-16> nbd * r3924 /branches/whiterussian/openwrt/package/base-files/default/sbin/ifup: don't try to change interface settings if <group>_proto is unset or 'none' (#504)
[04:21] <[mbm]> the only way that would ever do something is if the interface was a bridge
[04:23] <nbd> the problem is, without that change it does an ifconfig down
[04:25] <[mbm]> ouch
[04:25] <nbd> and the WE800G has wan_ifname=eth1, which incidentally is the lan port
[04:25] <nbd> that's why setting wan_proto=none would result in a brick
[04:25] Action: [mbm] tries to remember why there's a down in there
[04:25] <nbd> to set the mac
[04:25] <[mbm]> but er don't set the mac anymore
[04:25] <[mbm]> s/er/we/
[04:25] <nbd> hmm
[04:43] <nbd> [mbm]: is it ok if i replace slob with slab on all targets?
[04:43] <nbd> [mbm]: even with different kernel versions it does seem to have performance problems
[04:46] <[mbm]> yeah, I think we need to
[04:46] <CIA-16> nbd * r3925 / (10 files in 10 dirs): enable slab, disable slob - for better performance (#583)
[04:59] <CIA-16> nbd * r3926 /branches/whiterussian/openwrt/target/linux/image/brcm/Makefile: build jffs2 images with both erase block sizes for wr850g (#576)
[05:05] <CIA-16> nbd * r3927 / (2 files in 2 dirs): add adjtimex to ntpclient (#450)
[06:23] <[mbm]> .
[07:11] <malbon> in 3
[09:53] <nbd> hey xrg_
[09:54] <florian__> nbd: you have been on a comitting spree !
[10:00] <florian__> nbd: did you find the source of your presentation .
[10:00] <florian__> ?
[10:05] <Kaloz> .
[10:05] <Kaloz> yo xrg_ :)
[10:07] <[mbm]> presentation?
[10:17] <florian__> I think I mentionned that I would like to make a presentation during french RMLL 2006
[10:17] <florian__> and I asked if anyone was opposed, enjoyed ...
[10:17] <[mbm]> oh, missed it
[10:18] <florian__> no pb
[10:18] <[mbm]> anyways, it just so happens that I'm writing up a piece about openwrt
[10:18] <florian__> it was yesterday I think
[10:18] <florian__> great !
[10:20] <[mbm]> florian__: well, it's not a technical piece, just covers some of how openwrt started
[10:20] <florian__> yep, I could need it as well
[10:20] <florian__> no one yet answered if he/she/it was interested in helping me writing documentation
[10:21] <[mbm]> if I had more free time I'd have already done it
[10:21] <florian__> I would have time in almost 1 week
[10:21] Action: [mbm] actually enjoys writing long, long articles
[10:42] <xrg_> hi, Kaloz..
[10:43] <xrg_> brb
[11:03] <nbd> xrg_: i got an updated rb532 patch. it's become even smaller and it now uses the platform_device for korina and cf
[11:37] <nbd> yay... i have serial on the wl-700gE
[11:55] <xrg_> nbd, nice.
[11:56] <xrg_> Sadly, I have no free time. I am now drawing a Gantt chart for another project, and that looks awful and still involves me 100%.
[11:56] <xrg_> I'm in deep trouble here..
[12:24] <common> Kaloz i found a bug in the openixp code
[12:24] <common> for some reason the load is stable on 1
[12:34] <nbd> damn... seems like we have to reverse engineer broadcom's cryptoloop-clone
[12:35] <Kaloz> nbd: or simpy don't use it :p
[12:35] <Kaloz> simply*
[12:35] <nbd> the asus firmware uses it to store the data on the hard drive
[12:35] <Kaloz> and?
[12:35] <Kaloz> you don't have to use it imho
[12:35] <nbd> i'd like to have something that can use the old data
[12:37] <Kaloz> well, imho who wants to openwrt on it won't have data on the hdd :)
[12:37] <nbd> just thought it would be nice to have
[12:39] <wigyori> nbd: as i recall, wl566gm has some kind of bcmcrypto header files
[12:39] <wigyori> should we try to get the .c's aswell? :)
[12:39] <nbd> nah, bcmcrypto is not interesting
[12:39] <nbd> it's just a reimplementation of the crypto algorithms
[12:39] <wigyori> i see
[12:39] <nbd> what i'm talking about is a kernel module
[12:39] <nbd> called 'se'
[12:40] <wigyori> i thought it's the layer to the 5365's hwcrypto
[12:40] <nbd> no, hwcrypto can only be accessed from kernel space
[12:40] <nbd> iirc
[12:40] <wigyori> i see
[12:41] <wigyori> btw, asus didn't answer my mail yet :)
[13:38] <common> Kaloz: from what i've read the bug is a uninterutptable sleep (d-state) somewhere in the driver
[19:01] <[mbm]> wow, nbd's really gone crazy with tickets and svn updates over the last 24h
[19:04] <nbd> :)
[19:04] <[mbm]> btw did the bug with ppp mtu ever get fixed?
[19:05] <nbd> i don't think so
[19:05] <[mbm]> I just remember seeing it in someone's pastebin the other day
[19:07] Action: [mbm] tries to remember what the major showstoppers were for the rc6 release .. wondering if we'll be able to release a new version this weekend
[19:20] <[mbm]> aww.. iptables prevents you from setting up feedback loops
[19:20] <[mbm]> iptables -N test; iptables -A test -j test
[19:36] <nbd> [mbm]: i think we should tag rc6 a day before we release it or so
[19:36] <nbd> [mbm]: to give all the devs a chance of testing it properly
[19:36] <[mbm]> yeah
[19:40] <alxhh> and organise partys
[19:40] <[mbm]> doing a few builds here to see what state things are in
[19:41] <[mbm]> honestly it's been months since I've looked at the whiterussian branch
[19:43] <nbd> yeah, i also haven't spent much time on it lately
[19:44] <nbd> let's make a final effort to get it as close to release quality as possible, then make 0.9 after rc6, and then focus on the new stuff entirely to get it ready for 1.0
[19:49] <[mbm]> hmm that's odd .. compile crashed durring diag.o
[19:49] <nbd> weird
[19:50] Action: [mbm] tries it again, logging the output to a file
[19:54] <CIA-16> nbd * r3928 /branches/whiterussian/openwrt/target/linux/ (5 files in 2 dirs): enabled mini_fo by default
[19:56] <[mbm]> ok, same error .. let's look at the logs
[19:59] <[mbm]> ah. my fault.
[19:59] <[mbm]> my branch had some grsec patches which were conflicting with some other kernel patches
[19:59] <nbd> ah
[22:26] <[mbm]> nbd: have a look at the benchmarking page now
[22:27] <nbd> much better
[22:28] <[mbm]> feel free to add to it
[22:30] <nbd> looks pretty complete to me
[22:30] <[mbm]> I probably should have pointed out that it wasn't even a standard benchmark tool
[22:30] <nbd> hmmm... right... and the fact that they're using several different versions
[22:31] <[mbm]> how about the fact there's nothing saying to kill off other processes which may interfere with the benchmark ?
[22:31] <nbd> yeah
[22:34] Action: [mbm] looks suspciously at the 48s for OpenDebianSlug to compute Pi on a 266, or the 30 seconds for the wl500g to calculate e
[22:34] <h3sp4wn> Can pi or e ever be calculated ? I thought they were irrational ?
[22:35] <h3sp4wn> You can calculate either of them for however long you like
[22:35] <nbd> this whole benchmark is irrational :)
[22:36] <[mbm]> it's a pissing contest
[22:37] <[mbm]> it's like the gentoo people that do an emerge system every time a new gcc patch comes out, hoping to gain another 0.0001% of speed
[22:37] <frop> gentoo sUx
[22:37] <[mbm]> frop: I've got nothing against the distro, just the users
[22:38] <frop> [mbm] the distro too
[22:38] <frop> ...is the distro that forge users
[22:39] <frop> ...and every time you launch emerge, you are afraid that something could go wrong...
[22:40] <h3sp4wn> I applied the realtime-prempt patch to my kernel (So I can record low latency sound) but it definately helps keep the system responsive whilst compiling (Probably not relevent to most people if you compile on a seperate box)
[22:40] <[mbm]> well, I used to complain that installing the distribution took at least 3 straight days of compiling, but they've since fixed that with their binaries
[22:41] <frop> h3sp4wn are you a gentoo user?
[22:41] <h3sp4wn> No
[22:41] <frop> ...ooh better...
[22:41] <[mbm]> h3sp4wn: makes the system more responsive but also slows down your compile
[22:42] Action: [mbm] has a machine set up strictly as a server .. low timer resolution, no preempt
[22:42] <[mbm]> and yes, I use it for remote compiles
[22:47] <h3sp4wn> mbm: Would you think it would slow the compile vastly ?
[22:48] <h3sp4wn> suppose I could time it but that would be a pretty pointless benchmark also
[22:48] <[mbm]> would slow down compiling by a certain percentage; context switching is overhead
[22:48] <h3sp4wn> not by 100% or anything like that though ?
[22:48] <h3sp4wn> I wouldn't have thought it would
[22:48] <[mbm]> and actually it would be an interesting benchmark to see the same system compile with an without preempt
[22:49] <[mbm]> if I had to guess I'd say around 10% but there's absolutely no basis for that claim
[22:50] <h3sp4wn> http://people.redhat.com/~mingo/realtime-preempt/ (thats the one I am talking about, I expect you know)
[22:52] <[mbm]> nbd: we might have to look into that madwifi ticket you closed earlier .. tristan reported similar errors while using 802.11a
[22:52] <[mbm]> h3sp4wn: yeah, I know about it
[22:53] <[mbm]> I'm just curious how efficient it is
[22:53] <nbd> [mbm]: which one specifically?
[22:54] <[mbm]> well, tristan's report just said that the ap locks up and eventually reboots after being flooded with 802.11a traffic
[22:55] <[mbm]> which makes it sound like there's an oops condition in madwifi
[00:00] --- Sat Jun 10 2006
[02:32] <CIA-16> nbd * r3917 /branches/whiterussian/openwrt/package/wificonf/wificonf.c: allow 63 chars in the wpa psk in wet mode (#556)
[02:39] <CIA-16> nbd * r3918 /branches/whiterussian/openwrt/package/webif/files/usr/lib/webif/webif.sh: add webif workaround for ie (#564)
[02:41] <[mbm]> nbd: you might want to take a look at the firewall page in webif; several complaints about that over the last week
[02:41] <[mbm]> maybe we should write that iptables plugin to match the ip address of an interface
[02:46] <nbd> yeah
[02:46] <[mbm]> the other thing that I was thinking of is a way of booting the system from failsafe
[02:46] <CIA-16> nbd * r3919 / (4 files in 4 dirs): upgrade maradns to the latest version (#511)
[02:47] <[mbm]> so you could start a normal bootup and what would otherwise only be visible on serial
[02:58] <[mbm]> .. as for the firewall, the other option is to start putting pieces of the firewall in hotplug
[02:58] <[mbm]> which would require us to restructure the firewall
[03:04] <nbd> i don't like that
[03:04] <nbd> the matching module is a better solution
[03:04] <[mbm]> trying to get a response from #netfilter to see if there's anything similar
[03:05] Action: nbd is currently fixing the applet name display of busybox for the process list
[03:05] <nbd> it's a bug in my ash performance hack
[03:05] <[mbm]> if we decided to do it the hotplug way we'd have custom tables like wan_input wan_output ...
[03:06] <[mbm]> which would replace the input_rule, output_rule and so on in firewall.user
[03:19] <nbd> [mbm]: is there a safe way to replace a short argv with a longer one?
[03:26] <[mbm]> hmm .. after argv is the environment
[03:26] <[mbm]> so you'd be clobbering that
[03:30] <CIA-16> nbd * r3920 / (2 files in 2 dirs): fix cflags, fix adjtimex patch (#587)
[03:35] <CIA-16> nbd * r3921 / (3 files in 3 dirs): ppp: try to reconnect indefinitely (#551)
[03:35] <[mbm]> nbd: btw what do you think of setting up /etc/resolv.conf to point at dnsmasq and having dnsmasq use /tmp/resolv.conf?
[03:38] <nbd> good idea
[03:39] <[mbm]> there's a thread on the forum from back in january where the idea was discussed
[03:39] <[mbm]> we just never got around to it
[03:55] <CIA-16> nbd * r3922 / (6 files in 6 dirs): update ebtables to 2.0.8-rc2 (#558)
[04:05] <CIA-16> nbd * r3923 / (3 files in 3 dirs): install missing ebtables files
[04:21] <CIA-16> nbd * r3924 /branches/whiterussian/openwrt/package/base-files/default/sbin/ifup: don't try to change interface settings if <group>_proto is unset or 'none' (#504)
[04:21] <[mbm]> the only way that would ever do something is if the interface was a bridge
[04:23] <nbd> the problem is, without that change it does an ifconfig down
[04:25] <[mbm]> ouch
[04:25] <nbd> and the WE800G has wan_ifname=eth1, which incidentally is the lan port
[04:25] <nbd> that's why setting wan_proto=none would result in a brick
[04:25] Action: [mbm] tries to remember why there's a down in there
[04:25] <nbd> to set the mac
[04:25] <[mbm]> but er don't set the mac anymore
[04:25] <[mbm]> s/er/we/
[04:25] <nbd> hmm
[04:43] <nbd> [mbm]: is it ok if i replace slob with slab on all targets?
[04:43] <nbd> [mbm]: even with different kernel versions it does seem to have performance problems
[04:46] <[mbm]> yeah, I think we need to
[04:46] <CIA-16> nbd * r3925 / (10 files in 10 dirs): enable slab, disable slob - for better performance (#583)
[04:59] <CIA-16> nbd * r3926 /branches/whiterussian/openwrt/target/linux/image/brcm/Makefile: build jffs2 images with both erase block sizes for wr850g (#576)
[05:05] <CIA-16> nbd * r3927 / (2 files in 2 dirs): add adjtimex to ntpclient (#450)
[06:23] <[mbm]> .
[07:11] <malbon> in 3
[09:53] <nbd> hey xrg_
[09:54] <florian__> nbd: you have been on a comitting spree !
[10:00] <florian__> nbd: did you find the source of your presentation .
[10:00] <florian__> ?
[10:05] <Kaloz> .
[10:05] <Kaloz> yo xrg_ :)
[10:07] <[mbm]> presentation?
[10:17] <florian__> I think I mentionned that I would like to make a presentation during french RMLL 2006
[10:17] <florian__> and I asked if anyone was opposed, enjoyed ...
[10:17] <[mbm]> oh, missed it
[10:18] <florian__> no pb
[10:18] <[mbm]> anyways, it just so happens that I'm writing up a piece about openwrt
[10:18] <florian__> it was yesterday I think
[10:18] <florian__> great !
[10:20] <[mbm]> florian__: well, it's not a technical piece, just covers some of how openwrt started
[10:20] <florian__> yep, I could need it as well
[10:20] <florian__> no one yet answered if he/she/it was interested in helping me writing documentation
[10:21] <[mbm]> if I had more free time I'd have already done it
[10:21] <florian__> I would have time in almost 1 week
[10:21] Action: [mbm] actually enjoys writing long, long articles
[10:42] <xrg_> hi, Kaloz..
[10:43] <xrg_> brb
[11:03] <nbd> xrg_: i got an updated rb532 patch. it's become even smaller and it now uses the platform_device for korina and cf
[11:37] <nbd> yay... i have serial on the wl-700gE
[11:55] <xrg_> nbd, nice.
[11:56] <xrg_> Sadly, I have no free time. I am now drawing a Gantt chart for another project, and that looks awful and still involves me 100%.
[11:56] <xrg_> I'm in deep trouble here..
[12:24] <common> Kaloz i found a bug in the openixp code
[12:24] <common> for some reason the load is stable on 1
[12:34] <nbd> damn... seems like we have to reverse engineer broadcom's cryptoloop-clone
[12:35] <Kaloz> nbd: or simpy don't use it :p
[12:35] <Kaloz> simply*
[12:35] <nbd> the asus firmware uses it to store the data on the hard drive
[12:35] <Kaloz> and?
[12:35] <Kaloz> you don't have to use it imho
[12:35] <nbd> i'd like to have something that can use the old data
[12:37] <Kaloz> well, imho who wants to openwrt on it won't have data on the hdd :)
[12:37] <nbd> just thought it would be nice to have
[12:39] <wigyori> nbd: as i recall, wl566gm has some kind of bcmcrypto header files
[12:39] <wigyori> should we try to get the .c's aswell? :)
[12:39] <nbd> nah, bcmcrypto is not interesting
[12:39] <nbd> it's just a reimplementation of the crypto algorithms
[12:39] <wigyori> i see
[12:39] <nbd> what i'm talking about is a kernel module
[12:39] <nbd> called 'se'
[12:40] <wigyori> i thought it's the layer to the 5365's hwcrypto
[12:40] <nbd> no, hwcrypto can only be accessed from kernel space
[12:40] <nbd> iirc
[12:40] <wigyori> i see
[12:41] <wigyori> btw, asus didn't answer my mail yet :)
[13:38] <common> Kaloz: from what i've read the bug is a uninterutptable sleep (d-state) somewhere in the driver
[19:01] <[mbm]> wow, nbd's really gone crazy with tickets and svn updates over the last 24h
[19:04] <nbd> :)
[19:04] <[mbm]> btw did the bug with ppp mtu ever get fixed?
[19:05] <nbd> i don't think so
[19:05] <[mbm]> I just remember seeing it in someone's pastebin the other day
[19:07] Action: [mbm] tries to remember what the major showstoppers were for the rc6 release .. wondering if we'll be able to release a new version this weekend
[19:20] <[mbm]> aww.. iptables prevents you from setting up feedback loops
[19:20] <[mbm]> iptables -N test; iptables -A test -j test
[19:36] <nbd> [mbm]: i think we should tag rc6 a day before we release it or so
[19:36] <nbd> [mbm]: to give all the devs a chance of testing it properly
[19:36] <[mbm]> yeah
[19:40] <alxhh> and organise partys
[19:40] <[mbm]> doing a few builds here to see what state things are in
[19:41] <[mbm]> honestly it's been months since I've looked at the whiterussian branch
[19:43] <nbd> yeah, i also haven't spent much time on it lately
[19:44] <nbd> let's make a final effort to get it as close to release quality as possible, then make 0.9 after rc6, and then focus on the new stuff entirely to get it ready for 1.0
[19:49] <[mbm]> hmm that's odd .. compile crashed durring diag.o
[19:49] <nbd> weird
[19:50] Action: [mbm] tries it again, logging the output to a file
[19:54] <CIA-16> nbd * r3928 /branches/whiterussian/openwrt/target/linux/ (5 files in 2 dirs): enabled mini_fo by default
[19:56] <[mbm]> ok, same error .. let's look at the logs
[19:59] <[mbm]> ah. my fault.
[19:59] <[mbm]> my branch had some grsec patches which were conflicting with some other kernel patches
[19:59] <nbd> ah
[22:26] <[mbm]> nbd: have a look at the benchmarking page now
[22:27] <nbd> much better
[22:28] <[mbm]> feel free to add to it
[22:30] <nbd> looks pretty complete to me
[22:30] <[mbm]> I probably should have pointed out that it wasn't even a standard benchmark tool
[22:30] <nbd> hmmm... right... and the fact that they're using several different versions
[22:31] <[mbm]> how about the fact there's nothing saying to kill off other processes which may interfere with the benchmark ?
[22:31] <nbd> yeah
[22:34] Action: [mbm] looks suspciously at the 48s for OpenDebianSlug to compute Pi on a 266, or the 30 seconds for the wl500g to calculate e
[22:34] <h3sp4wn> Can pi or e ever be calculated ? I thought they were irrational ?
[22:35] <h3sp4wn> You can calculate either of them for however long you like
[22:35] <nbd> this whole benchmark is irrational :)
[22:36] <[mbm]> it's a pissing contest
[22:37] <[mbm]> it's like the gentoo people that do an emerge system every time a new gcc patch comes out, hoping to gain another 0.0001% of speed
[22:37] <frop> gentoo sUx
[22:37] <[mbm]> frop: I've got nothing against the distro, just the users
[22:38] <frop> [mbm] the distro too
[22:38] <frop> ...is the distro that forge users
[22:39] <frop> ...and every time you launch emerge, you are afraid that something could go wrong...
[22:40] <h3sp4wn> I applied the realtime-prempt patch to my kernel (So I can record low latency sound) but it definately helps keep the system responsive whilst compiling (Probably not relevent to most people if you compile on a seperate box)
[22:40] <[mbm]> well, I used to complain that installing the distribution took at least 3 straight days of compiling, but they've since fixed that with their binaries
[22:41] <frop> h3sp4wn are you a gentoo user?
[22:41] <h3sp4wn> No
[22:41] <frop> ...ooh better...
[22:41] <[mbm]> h3sp4wn: makes the system more responsive but also slows down your compile
[22:42] Action: [mbm] has a machine set up strictly as a server .. low timer resolution, no preempt
[22:42] <[mbm]> and yes, I use it for remote compiles
[22:47] <h3sp4wn> mbm: Would you think it would slow the compile vastly ?
[22:48] <h3sp4wn> suppose I could time it but that would be a pretty pointless benchmark also
[22:48] <[mbm]> would slow down compiling by a certain percentage; context switching is overhead
[22:48] <h3sp4wn> not by 100% or anything like that though ?
[22:48] <h3sp4wn> I wouldn't have thought it would
[22:48] <[mbm]> and actually it would be an interesting benchmark to see the same system compile with an without preempt
[22:49] <[mbm]> if I had to guess I'd say around 10% but there's absolutely no basis for that claim
[22:50] <h3sp4wn> http://people.redhat.com/~mingo/realtime-preempt/ (thats the one I am talking about, I expect you know)
[22:52] <[mbm]> nbd: we might have to look into that madwifi ticket you closed earlier .. tristan reported similar errors while using 802.11a
[22:52] <[mbm]> h3sp4wn: yeah, I know about it
[22:53] <[mbm]> I'm just curious how efficient it is
[22:53] <nbd> [mbm]: which one specifically?
[22:54] <[mbm]> well, tristan's report just said that the ap locks up and eventually reboots after being flooded with 802.11a traffic
[22:55] <[mbm]> which makes it sound like there's an oops condition in madwifi
[00:00] --- Sat Jun 10 2006