**** BEGIN LOGGING AT Sat Feb 27 02:59:56 2010
Feb 27 07:24:45 <Acinonyx> hi
Feb 27 08:22:15 <CIA-39> spudz76 * r19881 /packages/ (5 files in 3 dirs): [patchteam] sysfsutils: separate libsysfs and sysfsutils and move to libs, add patch - thanks Raphaël
Feb 27 09:13:53 <_trine> cshore, I see your code is now in trunk
Feb 27 09:14:01 <cshore> yep
Feb 27 09:14:26 <_trine> is there anything specific I need to know to be able to use it
Feb 27 09:14:36 <_trine> I would like to try it
Feb 27 09:15:02 <_trine> I have just compiled trunk with your code in it
Feb 27 09:15:30 <cshore> I would look at http://wiki.openwrt.org/doc/howto/rootfsonexternalstorage for a step-by-step guide
Feb 27 09:16:12 <cshore> and ask here if you have any questions :)
Feb 27 09:16:18 <_trine> where in trunk is your code selected
Feb 27 09:17:39 <cshore> Well first you have make sure you have e.g. usb-storage select and your host controller, and the Base system block-mount package.  Once you've done that it will be in Utilities|disc|block-extroot
Feb 27 09:17:39 <_trine> ah just seen it
Feb 27 09:18:38 <_trine> I have a spare pendrive I could try this on later
Feb 27 09:18:49 <cshore> one thing you will want to do at the very end, is to modify /etc/opkg.conf so that root_overlay points to /overlay instead of /jffs (this will be changed soon).
Feb 27 09:19:06 <_trine> ok
Feb 27 09:36:01 <_trine> cshore, still around ?
Feb 27 10:12:19 <cshore> pong _tring
Feb 27 10:12:22 <cshore> _trine
Feb 27 10:23:47 <_trine> cshore, I pm ed you
Feb 27 10:57:35 <cshore> ok
Feb 27 11:11:55 <cshore> ping _trine
Feb 27 15:10:15 <builder> build #24 of ar71xx is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/ar71xx/builds/24
Feb 27 15:14:06 <builder> build #21 of brcm_2_4 is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/brcm_2_4/builds/21
Feb 27 15:18:52 <netprince_> ping cshore: looked over rootfsonexternalstorage, looks good so far
Feb 27 15:20:23 <netprince_> Is it necessary to unmount /jffs during the boot process on squashfs installs?  It could be handy to have that mounted so you could adjust the fstab config?
Feb 27 16:26:51 <CIA-39> juhosg * r19882 /trunk/target/linux/adm5120/patches-2.6.32/ (3 files): adm5120: fix build error in the USB driver on 2.6.32
Feb 27 16:27:05 <CIA-39> juhosg * r19883 /trunk/target/linux/generic-2.6/config-2.6.32: kernel: yet another missing symbol for 2.6.32
Feb 27 17:32:18 <builder> build #20 of ep93xx is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/20
Feb 27 17:32:28 <cshore> ping netprince_
Feb 27 17:46:24 <cshore> anyone know where DEADC0DE is erased and moved in the kernel code?
Feb 27 17:50:42 <builder> build #18 of ifxmips is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ifxmips/builds/18
Feb 27 17:51:49 <{Nico}> cshore: look at jffs2_eofdetect.patch
Feb 27 17:52:13 <cshore> {Nico} thanks
Feb 27 18:11:31 <cshore> {Nico}: do you know of a platform that has to deal with a changing CRC due to JFFS changes?
Feb 27 18:11:50 <cshore> {Nico}: I'd like to see how someone else dealt with it
Feb 27 18:13:30 <xMff> cshore: brcm-2.4
Feb 27 18:14:07 <xMff> cshore: ... but only once, at the next boot after the initial jffs2 was formatted
Feb 27 18:14:20 <cshore> xMff: same situation here
Feb 27 18:14:26 <CIA-39> nico * r19884 /trunk/rules.mk: use a DIR_SUFFIX variable to hold libc/version and use it in build/staging dir names
Feb 27 18:16:51 <{Nico}> xMff: do you have a wrt54g v1.x ?
Feb 27 18:18:43 <xMff> cshore: https://dev.openwrt.org/browser/trunk/target/linux/brcm-2.4/files/drivers/mtd/maps/bcm947xx-flash.c#L343
Feb 27 18:19:05 <cshore> xMff: sorry, yeah I found it once I started looking 2.4
Feb 27 18:19:24 <cshore> the magic function is find_root
Feb 27 18:20:27 <xMff> {Nico}: nope
Feb 27 18:22:19 <xMff> only GL
Feb 27 18:27:50 <CIA-39> nico * r19885 /trunk/rules.mk: use distinct build/staging dirs for EABI/OABI builds
Feb 27 18:30:34 <{Nico}> humm, brcm47xx does not work on my wrt54g v1.1, while it does on my wrt54gs
Feb 27 18:30:39 <{Nico}> http://openwrt.pastebin.com/fj8JxEvQ
Feb 27 18:45:47 <CIA-39> spudz76 * r19886 /packages/net/umurmur/ (Makefile patches/001-makefile.patch): [patchteam] Update umurmur package to version 0.2.1 (and split into openssl and polarssl versions) - closes #6745 - thanks Zuljin
Feb 27 19:33:20 <dogge10> cshore trying block-extroot on the wl-700ge now
Feb 27 19:39:36 <rtz2> cshore: ping
Feb 27 19:39:40 <rtz2> blogic: ping
Feb 27 19:48:44 <blogic> rtz2: pong
Feb 27 19:50:35 <rtz2> blogic: do you know of any problems with serial connections to the amazon cpu?
Feb 27 19:51:13 <rtz2> blogic: I have a pl2303 usb cable and it looks like I can't send chars to the router
Feb 27 19:51:39 <rtz2> it works only rarely
Feb 27 19:51:46 <blogic> 10k pull up
Feb 27 19:52:04 <rtz2> blogic: where exactly?
Feb 27 19:52:10 <rtz2> tx to 3.3v?
Feb 27 19:53:09 <blogic> i think so
Feb 27 19:53:26 <rtz2> blogic: is this documented somewhere?
Feb 27 20:01:13 <loswillios> rtz2: I had no problems with my pl2303 on the g3010
Feb 27 20:01:56 <cshore> rtz2: pong
Feb 27 20:19:36 <rtz2> blogic: semms to work now, thanks
Feb 27 20:19:47 <rtz2> cshore: I have to eat, will be back in 15min
Feb 27 20:20:06 <cshore> ok, I'm in and out today so I can't guarantee I'll be here
Feb 27 20:33:17 <rtz2> cshore: back
Feb 27 21:24:48 <rtz2> nbd: ping
Feb 27 21:46:45 <fofware> nbd: xMff: ping
Feb 27 21:48:05 <fofware> any one know how delete uci.list.register?
Feb 27 22:16:28 <fofware> any one can tellme how delete register in uci.list with lua uci?
Feb 27 22:23:00 <cshore> rtz2: back
Feb 27 22:23:55 <fofware> nbd: lua uci don't have add_list() or what I need use to do that
Feb 27 22:24:43 <rtz2> cshore: ok, regarding your config-extroot script
Feb 27 22:24:54 <cshore> rtz2: yes?
Feb 27 22:24:58 <rtz2> cshore: Please enter the number of the device you wish to use as your root
Feb 27 22:25:08 <rtz2> cshore: what exactly do you use this for?
Feb 27 22:25:09 <cshore> number for?
Feb 27 22:25:24 <cshore> to probe the device to find the uuid
Feb 27 22:25:36 <cshore> in order to configure /etc/config/fstab
Feb 27 22:26:17 <rtz2> cshore: are you more likely to now the number then say the volume lable or simply the device node?
Feb 27 22:26:38 <cshore> the device node is listed onscreen....the number is a menu choice
Feb 27 22:27:18 <cshore> like
Feb 27 22:27:18 <cshore> 1) /dev/sda
Feb 27 22:27:18 <cshore> 2) /dev/sda1
Feb 27 22:27:18 <cshore> 3) /dev/sda2
Feb 27 22:27:18 <rtz2> cshore: ohh, right
Feb 27 22:27:39 <rtz2> cshore: well, it may still be better to except it as a command line argument
Feb 27 22:28:25 <cshore> nbd asked for selection from the available block devices
Feb 27 22:28:37 <cshore> rtz2: that's why I did it that way
Feb 27 22:28:39 <rtz2> hmm
Feb 27 22:28:52 <rtz2> well, I guess it's a question of taste ...
Feb 27 22:30:10 <cshore> rtz: though if labels are available displaying them as well would be useful...or even the UUID and LABEL (if defined) and device node
Feb 27 22:30:23 <cshore> rtz: I think I'll do that
Feb 27 22:34:11 <rtz2> cshore: and secondly, can't you autodetect the fs type
Feb 27 22:34:12 <rtz2> ?
Feb 27 22:36:52 <cshore> not with busybox blkid
Feb 27 22:37:13 <cshore> with util-linux blkid you can
Feb 27 22:37:45 <rtz2> cshore: can't you mount simply mount it?
Feb 27 22:38:13 <xMff> fofware: list handling in libuci-lua is just passing a table to .set
Feb 27 22:38:16 <cshore> rtz2: hmmm.....I suppose I could do that.  I hadn't thought of it
Feb 27 22:38:23 <rtz2> and then do some grep/cut magic to parse the mount output
Feb 27 22:38:41 <fofware> Ok thanks xMff
Feb 27 22:38:43 <cshore> yeah, that should work
Feb 27 22:52:39 <netprince_> cshore: I'm fresh out of spare routers, I'm tempted to get one just to try out your new code.
Feb 27 22:53:07 <cshore> netprince: I appreciate the vote of confidence :)
Feb 27 23:01:52 <fofware> xMff: uci.set("conffile.section.option", table) that is write?  or uci.set("conffile", "section","option",table)
Feb 27 23:02:19 <xMff> uci.set(c, s, o, {1, 2, 3})
Feb 27 23:05:01 <fofware> xMff: yes, thanks now It's working
Feb 27 23:45:08 <rtz2> xMff: you did read the stuff about the wl160nl checksum problem?
Feb 27 23:49:39 <xMff> rtz2: I can't help with that
Feb 27 23:50:48 <rtz2> xMff: i'm not looking for hardware test, only for suggestions what could go wrong, because I have no f* clue :/
Feb 27 23:53:36 <xMff> rtz2: I'm not really into this, have almost zero knowledge about uboot and haven't worked with ar71xx at all yet
Feb 27 23:56:27 <rtz2> xMff: it's not even standard u-boot code
Feb 27 23:56:27 <rtz2> xMff: they have some trx support bolted on top of it
Feb 27 23:56:27 <rtz2> xMff: and some times, for some strange reason the crc is calculated wrong :/
Feb 27 23:57:50 <rtz2> but only for some images and I really don't understand this
Feb 28 00:21:25 <xMff> rtz2: have you looked at the brcm-2.4 fixups?
Feb 28 00:21:35 <xMff> rtz2: maybe they can inspire you somehow
Feb 28 00:21:46 <xMff> rtz2: https://dev.openwrt.org/browser/trunk/target/linux/brcm-2.4/files/drivers/mtd/maps/bcm947xx-flash.c#L343
Feb 28 00:22:34 <xMff> ah wait, the uboot itslef complain right after flashing?
Feb 28 00:25:49 <rtz2> xMff: it complains during boot
Feb 28 00:26:01 <rtz2> xMff: uboot
Feb 28 00:26:29 <xMff> wrt160nl?
Feb 28 00:26:33 <rtz2> xMff: yes
Feb 28 00:26:50 <xMff> wasn't that where newer linksys firmwares removed the art partition?
Feb 28 00:27:07 <rtz2> no idea, but I don't think that's the problem
Feb 28 00:27:27 <rtz2> I have the source for uboot, so I know pretty well, what's happening
Feb 28 00:27:32 <rtz2> or what should happen
Feb 28 00:28:00 <xMff> well then, find out how it calculates the crc
Feb 28 00:28:05 <cshore> is the offset for MTD_READ in relation to the memory start, or the start of flash?
Feb 28 00:28:12 <rtz2> xMff: but for some reason, on some images, the crc32 is calculated wrongly
Feb 28 00:28:18 <rtz2> I know how it does
Feb 28 00:28:36 <cshore> rtz2: I think it happens for brcm63xx sometimes too....
Feb 28 00:28:42 <cshore> rtz2: rarely though
Feb 28 00:28:50 <xMff> calculated wrongly by what? the image creator or uboot?
Feb 28 00:29:09 <rtz2> and it does calculate the correct checksum for some image but not for all of them
Feb 28 00:29:16 <rtz2> xMff: well, they disagree
Feb 28 00:29:39 <rtz2> xMff: not sure, how's wrong and how's right
Feb 28 00:29:46 <cshore> rtz2: maybe someone tweaked the table
Feb 28 00:30:30 <rtz2> I even copied the uboot crc32 algorithm into trx and it produces the same result as the original algorithm in trx
Feb 28 00:30:57 <xMff> and what does it checksum=
Feb 28 00:31:02 <cshore> rtz2: endianness?
Feb 28 00:31:05 <rtz2> so no tweak table
Feb 28 00:31:19 <rtz2> cshore: I thought so, but it does work sometimes
Feb 28 00:31:27 <cshore> rtz2: on rollover or something like that
Feb 28 00:31:40 <rtz2> hmm, maybe
Feb 28 00:31:51 <rtz2> xMff: what do you mean?
Feb 28 00:32:08 <rtz2> xMff: print out the calculated checksum?
Feb 28 00:32:09 <xMff> I want to know what stuff it uses to calculate the checksum
Feb 28 00:32:28 <xMff> or better what exactly is checksummed
Feb 28 00:34:18 <cshore> xMff: that's a good though...brcm63xx has three or four different calculations depending on vendor
Feb 28 00:34:23 <cshore> thought
Feb 28 00:35:06 <rtz2> xMff: http://openwrt.pastebin.com/SDV2MurK
Feb 28 00:35:49 <rtz2> xMff: it seems the standard trx checksum stuff from the version field to (length - version_offset)
Feb 28 00:37:00 <rtz2> but It still produces this error: #
Feb 28 00:37:01 <rtz2> Application code length 0x002b0000
Feb 28 00:37:01 <rtz2> #
Feb 28 00:37:01 <rtz2> Bad CRC: trx.crc32 0x708e9077 calculate 0x2685349e
Feb 28 00:38:48 <cshore> does that router do something different and calculate over the image instead of header? (for example), or just the kernel, or...?
Feb 28 00:39:31 <cshore> rtz2: on brcm63xx some vendors change the broadcom code
Feb 28 00:39:32 <xMff> where is "addr" defined?
Feb 28 00:41:17 <rtz2> xMff: it's an unsigned char *
Feb 28 00:41:38 <xMff> how is it initialized?
Feb 28 00:42:47 <rtz2> xMff: it's read from an argument to the bootm command entered on the u-boot prompt
Feb 28 00:42:57 <rtz2> xMff: but the value for it is correct, because the printed out length and crc values match with the stuff in the the .bin file
Feb 28 00:43:07 <rtz2> addr = (unsigned char *)simple_strtoul(argv[1], NULL, 16);
Feb 28 00:44:43 <cshore> rtz2: have you looked at vendor firmware image....does it used a standard trx or have different fields (again on brcm63xx, some vendors have a kernel, rootfs, and wholeimage crc, while other just use wholeimage)
Feb 28 00:46:09 <rtz2> cshore: it uses one crc for the whole image
Feb 28 00:46:46 <rtz2> cshore: if I cut off the trx header, I can recreate it with the openwrt .trx tool with the same checksum
Feb 28 00:47:14 <cshore> rtz2: just not always?
Feb 28 00:48:01 <rtz2> the openwrt image produces an error
Feb 28 00:48:22 <rtz2> #
Feb 28 00:48:22 <rtz2> Application code length 0x002b0000
Feb 28 00:48:22 <rtz2> #
Feb 28 00:48:22 <rtz2> Bad CRC: trx.crc32 0x708e9077 calculate 0x2685349e
Feb 28 00:48:43 <cshore> always? or just for some calculations?
Feb 28 00:48:57 <rtz2> if I copy the u-boot crc32 algorithm into trx it also gives the 0x7... checksum
Feb 28 00:49:40 <cshore> right....do you know what parts of the image would produce the 0x2... checksum?
Feb 28 00:49:49 <xMff> I don't get this peace of code: "((unsigned  long)(&(((struct  trx_header *) 0)->flag_version)))"
Feb 28 00:49:58 <xMff> doesn't this always evaluate as "0" ?
Feb 28 00:50:04 <xMff> *piece
Feb 28 00:50:40 <larsc> will give you the offset of the flag_version field in the trx_header struct
Feb 28 00:50:44 <cshore> wouldn't be the value of the thing at 0
Feb 28 00:50:50 <xMff> ah
Feb 28 00:50:54 <cshore> it be
Feb 28 00:51:15 <xMff> got it
Feb 28 00:52:41 <xMff> so it checksum everything beginning from/including the version field
Feb 28 00:53:18 <rtz2> right
Feb 28 00:53:18 <larsc> xMff: where did you found that code?
Feb 28 00:53:26 <xMff> rtz2: posted it
Feb 28 00:53:28 <xMff> http://openwrt.pastebin.com/SDV2MurK
Feb 28 00:54:21 <rtz2> xMff: and that's the version in trx: p->crc32 = crc32buf((char *) &p->flag_version,
Feb 28 00:54:21 <rtz2> 223	                                                cur_len - offsetof(struct trx_header, flag_version));
Feb 28 00:54:45 <rtz2> p->crc32 = STORE32_LE(p->crc32);
Feb 28 00:59:15 <cshore> rtz2: is that the version from the router you're working on, or the 'standard' version?
Feb 28 00:59:48 <rtz2> cshore: that's the standard trx version
Feb 28 00:59:55 <cshore> rtz2: because some vendors change things
Feb 28 01:00:15 <cshore> rtz2: trust me, I've reverse engineered a few
Feb 28 01:00:50 <rtz2> cshore: the pastebin is the u-boot version from the vendor
Feb 28 01:01:30 <rtz2> cshore: and I compared it with the vendor binary image and it seems to be correct
Feb 28 01:01:31 <cshore> rtz2: ok, that's good to know...then the problem isn't wonky changes
Feb 28 01:01:42 <rtz2> have to reboot my router, will be back in a second
Feb 28 01:01:50 <rtz2> or minut
Feb 28 01:01:50 <rtz2> e
Feb 28 01:18:21 <cshore> rtz: what generates the value of trx.crc32 (i.e. the image generator)
Feb 28 01:19:01 <rtz2> cshore: the code I posted directly into the channel
Feb 28 01:19:12 <rtz2> it's from trx.c in tools/firmware
Feb 28 01:21:47 <cshore> and the trx struct matches the trx in u-boot code?
Feb 28 01:22:27 <cshore> same fields and so on?
Feb 28 01:23:21 <cshore> no strange version code?
Feb 28 01:23:23 <rtz2> yes
Feb 28 01:25:27 <rtz2> they are the same
Feb 28 01:25:35 <rtz2> version is also the same
Feb 28 01:26:22 <cshore> ok, from the header it uses flag_version and offsets[3] and then the kernel and rootfs?
Feb 28 01:27:19 <rtz2> yes
Feb 28 01:27:52 <rtz2> well, I don't think it has any concept of the actual data
Feb 28 01:28:16 <cshore> and the kernel + rootfs + 16 byes is 2b0000 bytes in length?
Feb 28 01:28:35 <rtz2> yes
Feb 28 01:29:18 <cshore> I still think it must not be using the code you posted
Feb 28 01:30:21 <rtz2> well, it does an awful good imitation of it
Feb 28 01:30:54 <cshore> where is struct trx_header defined in the u-boot code?
Feb 28 01:31:24 <cshore> and you say it sometimes works?
Feb 28 01:31:34 <cshore> or usually?
Feb 28 01:33:14 <rtz2> cshore: http://openwrt.pastebin.com/jeCUFbqS
Feb 28 01:33:29 <rtz2> cshore: well, I don't have much of a baseline
Feb 28 01:33:55 <cshore> it work ? times out of ?
Feb 28 01:34:41 <rtz2> cshore: I have some 30 byte test images which create the correct checksum and I can create the correct checksum for the vendor image (but didn't try to flash it yet) but 4 different openwrt images failed
Feb 28 01:35:35 <cshore> ok, so no openwrt image worked?
Feb 28 01:36:00 <rtz2> right
Feb 28 01:36:33 <cshore> for the 30byte and vendor image I presume you used a hacked version of trx.c?
Feb 28 01:37:38 <rtz2> cshore: for the vendor image, I used the original trx
Feb 28 01:38:06 <rtz2> cshore: and for the 30 byte image, yes, I hacked something together
Feb 28 01:39:39 <cshore> I guessing the problem is in getting the image from a file into the trx image...possibly a padding issue or uninitialized values
Feb 28 01:39:56 <cshore> I don't think the problem is the crc calculation per se
Feb 28 01:41:45 <rtz2> right, but how can the padding be a problem?
Feb 28 01:42:02 <rtz2> it doesn't even operate on dword blocks, only bytes
Feb 28 01:42:09 <rtz2> what should I pad to?
Feb 28 01:42:19 <cshore> I'm reading the code
Feb 28 01:43:20 <cshore> I presume the device is little endian?
Feb 28 01:46:27 <rtz2> I think it's bit endian
Feb 28 01:46:36 <cshore> doesnt conver_len = ((trx.len & 0x000000FF) << 24) | ((trx.len & 0x0000FF00) << 8 ) | ((trx.len & 0x00FF0000) >> 8) | ((trx.len & 0xFF000000) >> 24)
Feb 28 01:46:36 <cshore> switch the endianness of the value?
Feb 28 01:46:53 <cshore> oh, it's big endian, that makes sense
Feb 28 01:48:04 <cshore> In the image is HRD0 D0HR or HDR0? (the vendor one?)
Feb 28 01:48:18 <rtz2> big
Feb 28 01:48:42 <cshore> HDR0 ?
Feb 28 01:50:38 <cshore> actually it should be 0RDH, right?
Feb 28 01:50:41 <CIA-39> jow * r19887 /packages/utils/collectd/files/collectd.init: [packages] collectd: use start-stop-daemon for service invokation
Feb 28 01:51:08 <cshore> it's stored little endian according to the trx.c
Feb 28 01:51:13 <rtz2> cshore: hdr0
Feb 28 01:52:29 <cshore> and on the openwrt image?
Feb 28 01:53:04 <cshore> nvm
Feb 28 01:53:14 <cshore> chasing ghosts
Feb 28 01:53:57 <rtz2> cshore: it's the same
Feb 28 01:54:14 <cshore> how is the trx called (e.g. trx -o blah, -b what-offset, -f what files?)
Feb 28 01:54:30 <rtz2> cshore: and it hdr0, because the string in trx.c is 0rdh
Feb 28 01:54:36 <rtz2> I didn't add any offset
Feb 28 01:54:45 <cshore> right, I figured that out.ok
Feb 28 01:54:52 <cshore> -f kernel and -f rootfs ?
Feb 28 01:55:16 <rtz2> and files, well I think the kernel and rootfs is simply lumped together
Feb 28 01:55:18 <rtz2> didn't check it closely, didn't seem to be a problem
Feb 28 01:55:46 <cshore> ok, so if you use trx on the vendor image less the trx header, do you get the same header?
Feb 28 01:56:08 <cshore> since the image less the header should be the same
Feb 28 01:56:48 <rtz2> cshore: yes
Feb 28 01:57:35 <cshore> ok, so the OpenWRT trx on the vendor image, produces the same image and the vendor trx?
Feb 28 01:57:38 <cshore> as the
Feb 28 01:58:02 <rtz2> right
Feb 28 01:58:13 <rtz2> with the same checksum
Feb 28 01:58:35 <cshore> and that matches the vendor image before stripping the header?
Feb 28 01:58:55 <cshore> i.e. have they given you the right trx?
Feb 28 01:59:39 <cshore> yes, I have  nasty suspicious mind
Feb 28 02:00:30 <rtz2> yes
Feb 28 02:00:56 <cshore> ok, it matches?
Feb 28 02:01:16 <rtz2> it does
Feb 28 02:01:21 <rtz2> gahhh, i'm off to bed
Feb 28 02:01:29 <cshore> what happens when you flash the vendor image?
Feb 28 02:01:41 <rtz2> cshore: thanks for your help, but i'm making too many mistakes
Feb 28 02:01:45 <cshore> ok
Feb 28 02:01:47 <rtz2> cshore: didn't try yet
Feb 28 02:01:56 <cshore> let me know
Feb 28 02:02:09 <cshore> it's got me wanting the hardware so I can hack at it
Feb 28 02:02:18 <rtz2> I don't have a device myself and my victims are all gone :/
Feb 28 02:02:26 <cshore> :(
Feb 28 02:02:46 <cshore> another day then
**** ENDING LOGGING AT Sun Feb 28 02:59:57 2010