**** BEGIN LOGGING AT Fri Nov 30 02:59:58 2012
Nov 30 03:05:52 <swalker> RealOpty: rrdtool1's description clearly states the reasoning
Nov 30 09:09:00 <OpenWrt-Commits> florian r34428 branches/attitude_adjustment/target/linux/ar7/config-3.3 * AA: [ar7] use a default kernel command-line to mount squashfs and jffs2
Nov 30 09:10:49 <OpenWrt-Commits> florian r34429 branches/attitude_adjustment/target/linux/ar7/config-3.3 * AA: [ar7] add back symbols accidentally removed in r34428
Nov 30 10:54:24 <OpenWrt-Commits> florian r34430 trunk/target/linux/ubicom32 * [ubicom32] remove target
Nov 30 10:54:27 <OpenWrt-Commits> florian r34431 trunk/ package/kernel/modules/netdevices.mk package/kernel/modules/block.mk target/Config.in package/kernel/modules/crypto.mk * [package] kernel: remove references to TARGET_ubicom32
Nov 30 10:54:32 <OpenWrt-Commits> florian r34432 trunk/ (18 files in 14 dirs) * [toolchain] remove support for ubicom32
Nov 30 12:30:31 <karlp> I wrote up what I learnt yesterday about perf/oprofile on openwrt, fwiw: http://false.ekta.is/2012/11/cpu-profiling-applications-on-openwrt-with-perf-or-oprofile/
Nov 30 13:26:05 <[florian]> karlp: thanks, care to put that on the wiki?
Nov 30 13:26:11 <[florian]> karlp: and it's OpenWrt not OpenWRT /)
Nov 30 13:37:40 <roh> hm.. are there plans/concepts for 'physical portnumber labeled on device' to 'logic port numbers inside devices (interfaces, ports on switches) mappings?
Nov 30 13:38:13 <roh> especially since these seem not only model but subversion dependant (v2 of a tplink 741 seems different to a v4 board)
Nov 30 13:43:53 <jow_laptop> roh: not before device trees
Nov 30 13:44:23 <karlp> [florian]: doh, tried to be consistent, mixed it up.  where on the wiki would be relevant?
Nov 30 13:46:19 <roh> jow_laptop: well.. i fear i will just print model-version specific stickers and simply relabel the device to 'real chip internal order' ;)
Nov 30 13:46:34 <jow_laptop> thats the most pragamtic solution
Nov 30 13:46:47 <roh> another detail would be.. finding out the revision from software...
Nov 30 13:46:52 <jow_laptop> impossible
Nov 30 13:47:08 <roh> well.. its different images being built and flashed. whats impossible?
Nov 30 13:47:09 <jow_laptop> also implies carrying huge databases with label<>chip mappings in the firmware
Nov 30 13:47:36 <roh> then one would only need to check the back of the device once for a revision and not every time
Nov 30 13:47:46 <jow_laptop> not every paltform with alternating switch layouts has a specific image per model
Nov 30 13:47:49 <roh> jow_laptop: i know. its messy.
Nov 30 13:48:08 <jow_laptop> right, and I prefer to simply expose chip order to complicated and messy solutions
Nov 30 13:48:11 <roh> thats why i am asking how one _could_ do it.. if wanted
Nov 30 13:48:36 <roh> maybe its only a 'documentation' issue and the order should be in the wiki for all versions and models supported
Nov 30 13:48:42 <jow_laptop> yes
Nov 30 13:48:55 <roh> what about noting the version of image inside the image somehow?
Nov 30 13:49:12 <roh> so i could check that its a V4 remotely before updating
Nov 30 13:49:25 <roh> and not a v2 which means get the device and reflash from the start
Nov 30 13:50:20 <jow_laptop> cat /proc/cmdline
Nov 30 13:50:47 <roh> jow_laptop: says only " board=TL-WR741ND console=ttyS0,115200 rootfstype=squashfs,jffs2 noinitrd
Nov 30 13:50:56 <roh> no v2 or v4 .. sadly
Nov 30 13:51:06 <jow_laptop> because they're probably identical from a software pov
Nov 30 13:51:18 <roh> why are there different images for them then?
Nov 30 13:52:24 <jow_laptop> different flash chips/layouts afair
Nov 30 13:52:45 <roh> v4 has SOC_AR933X, v2 has SOC_AR724X
Nov 30 13:53:05 <jow_laptop> they get the same kernel and rootfs nonetheless
Nov 30 13:53:20 <jow_laptop> just different oem image headers
Nov 30 13:53:50 <roh> ah.. sorry.. the board= has em.
Nov 30 13:53:57 <roh> i just checked the wrong device ...
Nov 30 13:54:03 <[florian]> and so should /proc/cpuinfo no?
Nov 30 13:54:07 <roh> got 2 v2 by accident
Nov 30 13:54:23 <jow_laptop> anyhow, putting such info into the image is also no reliable solution
Nov 30 13:54:31 <roh> ah. yes.
Nov 30 13:54:43 <jow_laptop> if you put a v4 image on a v2 device it will work perfectly and the device will think its a v4 while its a v2
Nov 30 13:54:48 <roh> jow_laptop: as long as i now know where to find that detail remote i am happy
Nov 30 13:54:50 <jow_laptop> and vice versa
Nov 30 13:55:33 <jow_laptop> maybe one could use the eeprom7art partition to find more unique identifiers but idk
Nov 30 18:30:31 <Wipster> what options do I need to set in menuconfig to use gdb on a kernel module?
Nov 30 20:50:24 <Wipster> when trying to connect gdb to the outer is this the right one? ./staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/bin/mipsel-openwrt-linux-uclibc-gdb ?
Nov 30 21:13:04 <cshore> hey looks like kmod-l2tp has a bad header
Nov 30 22:04:24 <dwmw2_gone> hm, my geos image doesn't seem to have grub installed
Nov 30 22:08:20 <tonikasch> bye
Nov 30 22:08:38 <swalker> dwmw2_gone: old config, missing a make defconfig after the grub->grub2 change?
Nov 30 22:20:06 <dwmw2_gone> no, don't think so
Nov 30 22:20:17 <dwmw2_gone> tried switching back to grub1 too and still the same
Nov 30 22:22:51 <russell--> grub1 was yanked from trunk, wasn't it?
Nov 30 22:23:07 <dwmw2_gone> this is AA
Nov 30 22:23:23 <dwmw2_gone> although my trunk image also looks the same
Nov 30 22:23:54 <russell--> there was a bug in grub2 for x86 builds that i tracked down, having to do with probing for at_keyboard which isn't present on the alix2 (for example)
Nov 30 22:24:11 <dwmw2_gone> unzip the openwrt-x86-geos-combined-ext4.img.gz and mount its first partition, and it only contains a /boot/vmlinuz-3.3.8 and /boot/grub/grub.cfg
Nov 30 22:24:14 <dwmw2_gone> no actual copy of grub
Nov 30 22:26:38 * russell-- tries to remember if that's normal
Nov 30 22:27:52 <dwmw2_gone> aha, the first partition of openwrt-x86-geos-combined-squashfs.img *does* have stuff in /boot/grub/ other than the config
Nov 30 22:27:58 <russell--> yeah, mine is like that too, i think the grub2 core.img gets baked in to the boot land
Nov 30 22:28:20 <dwmw2_gone> but not the combined-ext4 image
Nov 30 22:28:58 <russell--> my squashfs image only has:
Nov 30 22:29:00 <russell--> ./vmlinuz
Nov 30 22:29:01 <russell--> ./grub
Nov 30 22:29:01 <russell--> ./grub/grub.cfg
Nov 30 22:29:06 <russell--> in the first partition
Nov 30 22:29:14 <russell--> (and it works)
Nov 30 22:29:26 <dwmw2_gone> um... how? :)
Nov 30 22:29:32 <russell--> lol
Nov 30 22:29:42 <russell--> all the modules get baked in
Nov 30 22:29:47 <russell--> afaict
Nov 30 22:30:17 <russell--> i assume in the space between the partition table and the first partition
Nov 30 22:30:36 <russell--> grub-mkimage
Nov 30 22:31:40 <russell--> target/linux/x86/image/Makefile
Nov 30 22:34:53 <dwmw2_gone> qemu can boot my squashfs image, but not the ext4 one
Nov 30 22:35:05 <dwmw2_gone> fsvo 'boot' which includes bitchign about qemu having no 3dnow
Nov 30 22:35:07 <dwmw2_gone> but grub works :)
Nov 30 22:36:47 <russell--> *magic*
Nov 30 22:36:59 <dwmw2_gone> that's the one with the files
Nov 30 22:37:04 <dwmw2_gone> the one without the files does *not* work by magic
Nov 30 22:37:14 <russell--> bad magic--
Nov 30 22:47:54 <russell--> grub-bios-setup is doing the magic afaict
Nov 30 22:48:16 <dwmw2_gone> hm, now I have grub1 files in /boot/grub of the image. And it boots grub2
Nov 30 22:48:23 <dwmw2_gone> that's even more impressive. I've turned off grub1 in config
Nov 30 22:58:24 * russell-- sticks to theory that grub-bios-setup in plunking everything grub2 needs into some blocklist in the space between the partition table and the first partition
Nov 30 22:59:06 <dwmw2_gone> yeah, or in the space at the beginning of the partition
Nov 30 22:59:10 <dwmw2_gone> ext2 leaves some space there.
Nov 30 22:59:40 <dwmw2_gone> hm, now I get grub2 with no config
Nov 30 23:04:17 <dwmw2_gone> how do I make it rebuild the grub config? I think it thinks it's done it
Nov 30 23:08:49 <DonkeyHotei> dwmw2_gone: since you mentioned that a sane mac addr would indeed be needed for rfc2684 IPoA, can you think of any better ideas to put it in than that horrendous hack in my patch?
Nov 30 23:11:58 <dwmw2_gone> I can't think of one.
Nov 30 23:12:23 <dwmw2_gone> not if we can't put it in the general luci config
Nov 30 23:13:52 <DonkeyHotei> well, luci would mean it needs to be user-entered
Nov 30 23:14:05 <DonkeyHotei> that's just not right
Nov 30 23:14:35 <DonkeyHotei> the sane mac should be the sane default like pretty much every similar device
Nov 30 23:14:44 <dwmw2_gone> yeah
Nov 30 23:15:21 <DonkeyHotei> but the only other way i could think of doing it would be even worse
Nov 30 23:16:09 <DonkeyHotei> the sysfs thing i mentioned on the ml
Nov 30 23:16:42 <dwmw2_gone> you *could* do it in userspace if it's just for br2684, and don't need to hack the kernel too much
Nov 30 23:17:28 <DonkeyHotei> yes, but the kernel driver would still need code to receive the addr from userspace
Nov 30 23:19:41 <DonkeyHotei> the mac has to be set before the vc is created, and only the kernel can do that, even if it gets the addr from userspace
Nov 30 23:21:51 <DonkeyHotei> IMHO, best compromise would be some far less ugly kernel hack
Nov 30 23:22:07 <DonkeyHotei> but idk what
Nov 30 23:22:53 <DonkeyHotei> dwmw2_gone: am i wrong?
Nov 30 23:24:01 <dwmw2_gone> not at all
Nov 30 23:24:08 <dwmw2_gone> but there *isn't* a cleaner kernel hack :)
Nov 30 23:24:20 <dwmw2_gone> it should have been in an eeprom or device-tree somewhere.
Nov 30 23:24:31 <dwmw2_gone> where does it actually come from, for the Ethernet?
Nov 30 23:24:50 <DonkeyHotei> uboot env, at least on the netgear
Nov 30 23:25:58 <dwmw2_gone> and uboot puts it on the command line for us?
Nov 30 23:26:04 <DonkeyHotei> yep
Nov 30 23:26:09 <dwmw2_gone> why not just have userspace get it from /proc/cmdline and set it on the nas0 device?
Nov 30 23:26:42 <DonkeyHotei> because the nas0 device does not exist until br2684 is running
Nov 30 23:26:51 <dwmw2_gone> so?
Nov 30 23:27:06 <dwmw2_gone> set it before you send anything
Nov 30 23:27:12 <dwmw2_gone> before you bring the device up
Nov 30 23:27:21 <DonkeyHotei> and the way owrt handles that is manually putting it in /etc/config/network
Nov 30 23:28:00 <DonkeyHotei> afaict, the device does not exist at the userspace level until it's brought up
Nov 30 23:28:07 <dwmw2_gone> brb, testing grub2 on router
Nov 30 23:30:55 <dwmw2_gone> root (hd0,3)
Nov 30 23:30:55 <dwmw2_gone>  Filesystem type is ext2fs, partition type 0x83
Nov 30 23:30:55 <dwmw2_gone> chainloader +1
Nov 30 23:30:55 <dwmw2_gone> Error 13: Invalid or unsupported executable format
Nov 30 23:32:51 <DonkeyHotei> those are grub1 commands
Nov 30 23:33:16 <dwmw2_gone> I have grub1 working on the CF card which is inside my router, which is in the cupboard under the stairs
Nov 30 23:33:23 <dwmw2_gone> I have no spare CF card
Nov 30 23:33:37 <dwmw2_gone> so I'm trying to build some confidence in a new AA installation, before I take the plunge
Nov 30 23:33:52 <dwmw2_gone> I installed an AA rootfs onto a spare partition on the CF card, and it works OK
Nov 30 23:34:21 <dwmw2_gone> now I'm trying grub2, by copying the boot partition into my spare space, and using chainloader to try to boot it
Nov 30 23:35:19 <DonkeyHotei> the chainloader command in grub1 leaves the bios device numbers in a state grub2 might not like
Nov 30 23:35:46 <dwmw2_gone> I don't understand the error message
Nov 30 23:35:59 <DonkeyHotei> also, grub2 really wants to be in the mbr
Nov 30 23:36:05 <dwmw2_gone> if it's just supposed to load a sector and jump to it, like the INT 19h handler does, why on earth would it complain about executable format
Nov 30 23:36:22 <dwmw2_gone> perhaps grub2 *is* in the mbr, which I didn't copy over
Nov 30 23:36:25 <russell--> dwmw2_gone: /me sees core.img starting at 0x00000200 in the combined-squashfs img
Nov 30 23:36:33 <dwmw2_gone> I may just have to be brave :)
Nov 30 23:37:08 <dwmw2_gone> for the combined-ext4 image is there actually any point in having separate partitions for boot and rootfs?
Nov 30 23:37:11 <DonkeyHotei> if you didn't copy the mbr from where you have grub2, you didn't copy grub2
Nov 30 23:37:47 <DonkeyHotei> grub2 handles ext4 just fine
Nov 30 23:38:19 <russell--> dwmw2_gone should mug a photographer and swipe their CF card
Nov 30 23:38:23 <dwmw2_gone> so did grub1, for the last few years
Nov 30 23:38:29 <dwmw2_gone> I have a CF card out of a camera.
Nov 30 23:38:33 <dwmw2_gone> but being a CF card, it's shagged
Nov 30 23:38:37 <russell--> lol
Nov 30 23:38:48 * russell-- has a stack
Nov 30 23:38:52 <DonkeyHotei> grub1 tended to choke on jfs, though
Nov 30 23:39:26 <russell--> awesomely openwrt only uses the first 48meg of my 1G cards ... and only uses about 9meg of the 48
Nov 30 23:39:42 <dwmw2_gone> a bunch of the space it does 'use' is wasted
Nov 30 23:40:08 * russell-- doesn't need to use it for anything, so i don't mind
Nov 30 23:40:10 <dwmw2_gone> see the TARGET_ROOTFS_RESERVED_PCT config option
Nov 30 23:40:46 <DonkeyHotei> considering it was designed to fit in 4meg flash, that's not a huge surprise
Nov 30 23:41:21 <DonkeyHotei> russell--: did you ever get that jtag flash dump from that orion-based router a few years back?
Nov 30 23:41:41 <russell--> i still have the router, but no flash dump
Nov 30 23:42:05 <DonkeyHotei> if you can jtag anything, you can jtag that too
Nov 30 23:42:26 <DonkeyHotei> problem is, _i'd_ now have to look for where mine is
Nov 30 23:42:37 * russell-- doesn't have a jtag rigged up
Nov 30 23:42:52 <DonkeyHotei> yeah, that was the issue back then too
Nov 30 23:43:44 <russell--> what software do you use? /me has an ARM olimex jtag adapter, but wouldn't know off hand how to drive it.
Nov 30 23:43:54 <DonkeyHotei> openocd
Nov 30 23:44:13 <DonkeyHotei> it supports the olimex directly, iirc
Nov 30 23:44:17 <russell--> is there a board config for the router?
Nov 30 23:44:30 <DonkeyHotei> i had one somewhere
Nov 30 23:45:03 <DonkeyHotei> i might need to dig through three or four old hard disks to find it
Nov 30 23:45:43 <russell--> my one excursion into jtag was with openocd and the olimex, but on an arm board that i managed to figure out semi-randomly
Nov 30 23:45:47 <DonkeyHotei> also, its jtag pinout is pretty nonstandard
Nov 30 23:46:38 <DonkeyHotei> back then i knew all the info you'd need off the top of my head, but you had no jtag adapter
Nov 30 23:46:55 <russell--> continuity tester + exacto knife to cut through solder mask into vias, ftw!
Nov 30 23:47:08 <DonkeyHotei> gawd no
Nov 30 23:47:22 <DonkeyHotei> i tried that on a different device
Nov 30 23:47:42 <DonkeyHotei> i still need that fixed
Nov 30 23:47:55 <russell--> it worked well, not scraping, just poking to make contact
Nov 30 23:48:26 <DonkeyHotei> well, jtag needs like 5 lines, and i don't have that many hands
Nov 30 23:48:52 <russell--> yeah, in my case there were pinheaders, but i had to trace them out to figure which pins were which
Nov 30 23:49:03 <russell--> had the data sheet for the cpu
Nov 30 23:49:19 <DonkeyHotei> no, i mean on a device that had no exposed jtag connector at all
Nov 30 23:49:26 <russell--> yeah
Nov 30 23:49:51 <DonkeyHotei> as for the thing you and i have, i could get you the pinout
Nov 30 23:50:27 * russell-- still needs to figure out how to build a uboot for my board (a peplink winti)
Nov 30 23:50:45 * russell-- has a crapton of the boards now, but needs a bootloader to be useful
Nov 30 23:51:05 <DonkeyHotei> they have blank flash?
Nov 30 23:51:18 <russell--> they have two 8 meg chips
Nov 30 23:51:28 <russell--> they have a weird-assed bootloader
Nov 30 23:51:32 <DonkeyHotei> that's a lot. ram?
Nov 30 23:51:43 <russell--> no, that's flash
Nov 30 23:51:47 <russell--> 32 meg of ram
Nov 30 23:51:54 <russell--> (iirc)
Nov 30 23:51:59 <DonkeyHotei> a weird-assed bootloader is better than blank flash
Nov 30 23:52:33 <russell--> the bootloader transfers an image using icmp type 15 packets (or something)
Nov 30 23:52:58 <DonkeyHotei> if you can boot a custom kernel from the weird-assed bootloader, you can use that to flash uboot on
Nov 30 23:53:57 <DonkeyHotei> dwmw2_gone: you still poking grub2?
Nov 30 23:54:10 <dwmw2_gone> not right now
Nov 30 23:54:29 <dwmw2_gone> I'll have to get another CF card and play.
Nov 30 23:54:30 <DonkeyHotei> so, it worked?
Nov 30 23:54:34 <DonkeyHotei> oh.
Nov 30 23:56:36 <DonkeyHotei> dwmw2_gone: no, about this br2684 mess...
Nov 30 23:56:49 <DonkeyHotei> s/no,/now,/
Nov 30 23:56:51 <russell--> DonkeyHotei: yeah, can't flash my own kernel, bootloader complains, which i've been assuming is because it's looking for a signature, which is why i wanted to put my own bootloader on.
Nov 30 23:57:21 <DonkeyHotei> russell--: grr.
Nov 30 23:57:46 <DonkeyHotei> how does the stock firmware handle it?
Nov 30 23:58:25 <russell--> yeah, but i had jtag working on it for reading, anyway, and was working my courage up to start hacking on uboot before i lost steam
Nov 30 23:58:39 <DonkeyHotei> happens
Nov 30 23:59:07 <DonkeyHotei> sometimes i let things sit for years, even decades
Nov 30 23:59:17 <russell--> the stock firmware was a 2.4.x linux kernel and i could log in and look at the built-in scripts for flashing
Nov 30 23:59:20 <DonkeyHotei> i'm so disorganized
Nov 30 23:59:30 <DonkeyHotei> yes
Dec 01 00:00:13 <russell--> the stock firmware was a two-image thing, where you'd flash a new one, but somehow could fall back to the old one, thus the 2 8meg flash chips
Dec 01 00:00:28 <DonkeyHotei> ugh, i hate those
Dec 01 00:00:57 <russell--> it used a different method than openwrt though, i think it loaded everything into a ramfs and ran out of that.
Dec 01 00:01:09 <DonkeyHotei> waste of ram
Dec 01 00:01:26 <russell--> although, it was a couple years ago and my memory is fuzzy now
Dec 01 00:02:41 <russell--> we were considering offering a bounty for building a uboot for it at one point
Dec 01 00:03:07 <russell--> for someone who understood uboot, it probably wouldnt take long
Dec 01 00:03:22 <russell--> if i had to learn uboot from scratch, it would take longer
Dec 01 00:04:20 <russell--> another board that uses the same cpu was already supported in uboot at the time
Dec 01 00:05:47 <DonkeyHotei> iirc, nbd wanted to make uboot owrt's official replacement bootloader
Dec 01 00:07:59 <russell--> at the time, i'd never seen a working uboot
Dec 01 00:08:04 <russell--> just cfe and redboot
Dec 01 00:08:18 <russell--> which also slowed me down a little
Dec 01 00:16:39 <russell--> https://personaltelco.net/~russell/peplink-sbc-winti.bootlog
Dec 01 00:23:42 <dwmw2_gone> wow, 2.4.24-rmk2
Dec 01 00:28:48 <DonkeyHotei> dwmw2_gone: now, about this br2684 mess...
Dec 01 00:31:50 <russell--> dwmw2_gone: yeah, it's ancient.  these devices were manufactured circa 2005-6.
Dec 01 00:34:15 <DonkeyHotei> what will you do with them?
Dec 01 00:36:18 <russell--> finally found my notes: https://groups.google.com/forum/?fromgroups=#!topic/ptp-skypilot/srFF8YH1u6A
Dec 01 00:36:21 <dwmw2_gone> DonkeyHotei: hm, brain no work any more
Dec 01 00:36:37 <dwmw2_gone> tomorrow? Seriously though, let's look at doing it in userspace.
Dec 01 00:36:49 <russell--> not sure, they are generic SBC with an 10/100 ethernet port and mini-PCI
Dec 01 00:37:20 <DonkeyHotei> dwmw2_gone: timezone differences are a bitch. ping me
Dec 01 00:37:36 <DonkeyHotei> i'm 8 hours behind you
Dec 01 00:37:42 <dwmw2_gone> timezone differences between me and the rest of the household are a bitch :)
Dec 01 00:37:53 <dwmw2_gone> they're going to be up early... :)
Dec 01 00:38:15 <dwmw2_gone> if you set the mac address before bringing nas0 up, in userspace, that should be perfectly sufficient
Dec 01 00:38:19 <dwmw2_gone> you can do it in a hotplug script
Dec 01 00:38:24 <dwmw2_gone> in /etc/hotplug.d/iface
Dec 01 00:39:35 <russell--> timezone difference with family provide quiet time for getting stuff done
Dec 01 00:40:01 <dwmw2_gone> at this end of the day, yes.
Dec 01 00:40:03 <DonkeyHotei> dwmw2_gone: there is no iface before br2684 is running
Dec 01 00:40:16 <dwmw2_gone> but then it provides noisy time for jumping on daddy and trying to prise his eyes open with sharp baby-claws
Dec 01 00:40:20 <dwmw2_gone> yes, that's fine
Dec 01 00:40:23 <russell--> lol
Dec 01 00:40:27 <dwmw2_gone> after br2684ctl is running is run
Dec 01 00:40:32 <dwmw2_gone> after br2684ctl is running is fine
Dec 01 00:40:36 <dwmw2_gone> brain going; I told you
Dec 01 00:40:43 <dwmw2_gone> change the MAC address before the device is brought up
Dec 01 00:40:53 <dwmw2_gone> but after it exists.
Dec 01 00:41:12 <DonkeyHotei> ping me when you're ready tomorrow
Dec 01 00:41:32 <dwmw2_gone> ok.
Dec 01 00:43:01 <DonkeyHotei> russell--: if they have empty minipci, you can get really creative. you have no idea what kinds of things have been put on such cards
Dec 01 00:48:21 * russell-- has the ubiquiti sr2 cards that came in the minipci slots as well as a bunch of abg cards
Dec 01 00:48:42 <russell--> so it seems a waste not to use them for something
Dec 01 00:49:20 <russell--> 400 mW b/g radio
Dec 01 00:53:36 <DonkeyHotei> how trite
Dec 01 00:53:49 <DonkeyHotei> what about video capture cards?
Dec 01 01:01:47 <russell--> we have the radios for free
**** ENDING LOGGING AT Sat Dec 01 02:59:58 2012