[00:30] ali1234: so, I've got this fan controller all up and running in a VM, care to give me a bit of guidance? :) [07:45] dir [07:45] list [08:14] raspberry jam \o/ http://www.eventbrite.com/event/3878091476 === Lcawte|Away is now known as Lcawte [08:43] aloha [09:40] good morning everyone. [09:41] now do I have enough bits on my desk to build a new computer [09:44] AlanBell, what are the parts ? [09:45] several incomplete units [09:45] bits \o/ [09:45] I think I have one together, found some ram that fits, have loads of HDDs kicking about [09:46] yup, that boots [09:47] as long as it does not burn ;-) === Lcawte is now known as Lcawte|Away [10:01] dual core atom with 1GB ram and a 320GB disk now [10:01] just installing Precise [10:04] bother, the wireless card won't fit [10:36] AlanBell, ethernet otherwise ? === Lcawte|Away is now known as Lcawte === Lcawte is now known as Lcawte|Away === Lcawte|Away is now known as Lcawte [12:44] ali1234: you about to give me some help with this bitfenix fan controller? :) [13:11] Azelphur: ok [13:11] ali1234: so I got it up in virtualbox, and I've been hacking away in python trying to get it to talk to me, no luck :( [13:11] got dumps? [13:11] it should be broadcasting pings to tell me fan speeds and stuff, not sure if I have to request those pings [13:11] yea [13:12] you do [13:12] USB is entirely host controlled [13:12] device cannot initiate comms [13:12] ali1234: https://dl.dropbox.com/u/3832397/misc/2012/July/recon it's a wireshark dump [13:12] what about a lsusb -vvv [13:13] http://pastebin.com/0WSTQ2W6 [13:13] it's a mouse! :D [13:14] hid mouse wat [13:14] that makes no sense at all [13:14] apparently it's a dirty hack to stop windows searching for drivers for it [13:14] if you plug it in inux does the pointer mose right when the temperature goes up? [13:14] well, anyway [13:15] haha [13:15] you only have 1 endpoint there [13:15] and it's interrupt [13:15] so that's where the temperatre data will come from [13:15] there's no EP OUT [13:15] so most likely everything else is done using the setup EP [13:15] which means making a driver is really simple [13:16] you'll have to read the dump to find out the commands though [13:16] that's cool, my python code gets the right address then [13:16] my code tries to read from endpoint 0x81, but I just get operation timed out. [13:16] dunno about that [13:16] ah [13:16] so interrupt end point is funny [13:16] you read and it blocks until the the interrupt happens [13:16] if you don't tell libusb it's an interrupt it will time out [13:17] you might also increase the timeout [13:17] http://pastebin.com/iagv2d7R is what I have atm [13:17] i've never used that stuff [13:18] libusb looks a bit different to that [13:18] apparently it's more or less the same as the C libusb stuff just in a different syntax [13:18] oh [13:18] let me show you a program that uses libusb to do setup requests [13:18] ok :) [13:18] you want to figure that stuff out first [13:19] so this is C http://al.robotfuzz.com/~al/s1mp3/unstable/hostapp/hostapp.c [13:19] usb_control_msg [13:19] timeout 5000 [13:20] and so on [13:20] what you want to do is look in the dump for setup/control messages [13:20] then try to replicate those [13:21] I see, still don't fully understand the dumps [13:22] looks like pyUSB has a controlMsg :) [13:22] yeah it should [13:22] ok let me install wireshark [13:22] :D [13:23] hmm that dump is not helpful [13:23] :( [13:23] ah [13:24] you see where it says USB_CONTROL out [13:24] URB_INTERRUPT in [13:24] oh yea :) [13:24] well, source host means computer wrote to device [13:25] yea I gathered that [13:25] the data doesn't make much sense though [13:25] it's hex [13:26] it is going to be one of: char, short, int, long, possibly signed or unsigned [13:26] 0010 83 93 f7 4f 00 00 00 00 2c 0c 02 00 8d ff ff ff ...O.... ,....... [13:26] I see [13:27] that's a dead giveaway for little endian signed [13:27] 32 bit ints [13:27] 32 bit because of 00 00 00 00 = 0 [13:27] little endian because you have a 00 in 4th position [13:27] and smaller numbers more likely than big [13:28] not sure about signed/unsigned [13:28] so, 2c 0c 02 00 -> 0x00020c2c [13:29] open a python shell and type 0x00020c2c and hit enter [13:29] 134188 [13:29] does not mean much to me [13:29] me either xD [13:29] there could be floats in there too [13:30] so, what actual data does this thing send to PC? [13:30] you have to think like the programmer. "if i wanted to send this data to PC, how would i do it?" [13:30] that's one I can answer, the stock driver shows debug output [13:30] meaning? [13:31] meaning I can show you example decoded fan controller output :P [13:32] great, let's see it? [13:33] btw what controller chip does it use? [13:33] i bet it's an AVR or a PIC [13:33] no idea [13:34] ali1234: http://pastebin.com/Hq1wxYHt [13:34] SONiX USB Device [13:34] i think you dumped the wrong device [13:35] no, virtualbox identifies it as a SONiX USB Device too [13:35] that's the device I passthrough to make it work [13:35] then the Microdia thing is wrong? [13:36] ah maybe not [13:36] I think it's more that the pci db is wrong or that they are misusing a pci id [13:36] no, that data all comes from the device [13:36] because I used the vendor and product id from virtualbox to find it in lsusb [13:36] so it's definitely the right thing :) [13:36] actually vendor id string doesn't come from device [13:37] ok from the dump [13:37] the dump, I have one fan plugged in it's running at 1300 RPM on channel 0 and it's maximum RPM is 2800 [13:38] so that's what that data is about :p [13:38] so 5 channels? [13:38] yup [13:38] the packet length is 72 [13:38] the response is 64 [13:39] 64/5 = 12.8 [13:39] so 4 byte header, and then 12 bytes per channel [13:39] so in python shell do hex(1300), gives 0x514 [13:39] fun, patched my code to match that :) [13:40] in little endian thats 14 05 [13:41] but there's temperature sensors too [13:41] and something that looks like a bitfield [13:42] I don't think it's actually reporting temperature, just the alarm temperature for that sensor (sadface) [13:42] in dumps there is a field that = 200 [13:43] yea, there's lots of 200's in the debug output too [13:43] that's the maximum RPM of a not connected fan \o/ [13:44] hang on, the dump is showing the whole packet [13:45] o.O [13:46] so there USB packet headers are shown there [13:46] the actual data starts at 0x28 [13:48] I see [13:48] hmm, I think controlMsg() got removed in pyUSB 1.0 [13:48] and now there's just write. [13:50] ah found it [13:50] so the sequence goes like this [13:50] host sends setup->device [13:50] device acks setup [13:51] device sends interrupt to host [13:51] host acks interrupt [13:51] so on the interrupt packets sent from device to host [13:51] if you go to packet 31 [13:52] 0x44 = 00 c8 [13:52] 0x45 = 0xc8 = 200 [13:53] there isn't much data here [13:53] fun [13:53] yea, I figured it'd be pretty simple [13:54] you should write a python script to dump it rather than using wireshark [13:54] I can't even get my python script to talk to it at all right now :( [13:54] you don't use usblib for that [13:54] you just read from debug device [13:55] I see [13:55] re controlMsg, I found device.ctrl_transfer in the docs, does that sound like what I want? [13:55] ctrl_transfer(0x40, CTRL_LOOPBACK_WRITE, 0, 0, msg) is an example call [13:55] don't worry about that yet [13:55] oh ok [13:57] ali1234: but surely if I just get the control message working, my code should just start working [13:57] no [13:57] all my read stuff is good, it's just there's nothing for it to read yet since the device isn't pinging [13:57] not by a long way [13:57] :( [13:57] what should I be doing then? [13:57] the control message is arbitrary data [13:58] you need to determine what the different values do [13:58] the different values in the control message you mean? [13:58] yes [13:59] I'd imagine for ping requests they are static [13:59] so, if you do lsusb -d 0c45:7100 [13:59] you see it is on bus 5 [13:59] yup [13:59] go to /sys/kernel/debug/usbmon [13:59] cat 5u [13:59] watch usb packets in real time [13:59] ooh [13:59] can wireshark handle those? [14:00] apparently it can [14:00] yes it can [14:00] however it isn't very helpful when looking for something [14:00] righto, I'm doing that [14:00] so on lsusb again [14:00] and i see lots of pretty packets. [14:00] you see it is device 2 [14:01] ffff880419515f00 143202048 C Ii:3:002:1 0:8 4 = 00fdff00 [14:01] Ii:3:002:1 [14:01] the 002 is the device [14:01] ali1234: Hmm.. that would work with USB ports passed into VMs? Probably? [14:01] ok [14:01] so first thing you want to do is filter out the lines that aren't 002 [14:01] MartijnVdS: yea it does [14:01] MartijnVdS: that's exactly what we are doing right now [14:02] "how to reverse engineer USB device with windows drivers in virtualbox" [14:02] that was easy, they are all 002 [14:02] :D [14:02] ali1234: ah, didn't read enough scrollback :) [14:02] Azelphur: if it is the only device on that bus they will be [14:02] 002? [14:02] yea, the fan controller connects directly to 2 motherboard headers. [14:03] it only appears as one device thugh right? [14:03] not sure, I think so [14:03] so t just takes power from the others [14:03] I guess so [14:03] that whole setup is a bit weird though, because it takes power from a molex as well [14:03] does it have a pass through usb port on the front or something? [14:03] nope [14:03] well, that is odd [14:04] indeed [14:04] maybe one of the connectors is optional [14:04] my best guess is that it's doing something like powering the LCD screen off USB [14:04] and the fans off the molex [14:04] couldbe [14:04] fans need 12V [14:04] :) [14:04] anyway, please show me some raw dump from usbmon [14:05] ffff8802a81649c0 309250180 S Ci:5:002:0 s 80 06 0301 0409 0102 258 < [14:05] ffff8802a81649c0 309252462 C Ci:5:002:0 0 12 = 0c035300 4f004e00 69005800 [14:05] ffff8802a81649c0 309253959 S Ci:5:002:0 s 80 06 0302 0409 0102 258 < [14:05] ffff8802a81649c0 309255386 C Ci:5:002:0 0 22 = 16035500 53004200 20004400 65007600 69006300 6500 [14:05] ffff8802a81649c0 309256422 S Ci:5:002:0 s 80 06 0300 0409 0082 130 < [14:05] smooth [14:06] oops, accidentally pasted the dump instead of the pastebin link \o/ [14:06] http://pastebin.com/CEZcqqqC [14:07] ok, see that column that is 0 or s [14:07] that means endpoint number or setup endpoint [14:08] I see [14:09] the parts after the = are the actual non-protocol data [14:09] Ii and Co - the lower case i or o means in or out [14:09] in or out to or from the host that is [14:10] I and C are "interrupt" and "Control" [14:10] or isochronous? [14:10] and then there's "bulk" [14:11] not sure, but it doesn't really matter [14:11] cool [14:11] they are all pretty much the same at a high level [14:11] ah, now I'm starting to understand why I need to understand what the numbers are \o/ [14:11] now, when it says 8 > [14:11] that means "i am going to send 8 bytes" [14:11] and when it says 8 < it means "please send me 8 bytes" [14:12] cool [14:12] only the host can send such messages [14:13] fun [14:13] so really the only interesting part right now is the lines with an = on [14:14] so first figure out what the device is saying [14:15] so filter out everything except lines with lower case i and = [14:15] should leave just these lines: ffff8802c3e23200 315391401 C Ii:5:002:1 0:1 8 = 05839e00 00da0000 [14:15] i can already see some data [14:15] looks like it is big endian [14:15] hmm [14:16] well the first few lines are no doubt it sending the config (auto/manual, F/C) back [14:16] and then the rest of those lines follow a format so those are gonna be the fan speed replies [14:16] so 5 consecutive packets contain 0x5c4, 0xc8, 0xc8, 0xc8, 0xc8 [14:16] indeed [14:16] so that field is fan speed for one channel [14:17] ah there is our 6 bits bitfield and channel number [14:18] you should be able to write a python program which reads lines from usbmon, and prints out exactly what you see in the debug log [14:18] when you've done that you have deciphered the device->host protocol [14:19] next step is to figure out the outgoing packets [14:19] that is harder as you will need to mess with the UI while watching the dump [14:19] I see [14:19] righto then, I shall try and write that :) [14:20] so yeah the process here is first to document the protocol, then you start writing usb code [14:21] 05819e00 00dc0000 -> 058 is the ==M=== bitfield, 1 is the channel, dunno next 4 bytes, 00dc is a fanspeed, dunno next 4 bytes [14:21] if you sit and watch the dump long enough you should figure out what all the bytes mean [14:23] hehe [14:26] there's just enough space in there for 12 bits, 4 bit channel number, and 3 shorts [14:26] can you do a long capture (couple of megs) and put it on dropbox? [14:27] sure [14:27] ali1234: shall I fuck with the fan speed too? [14:29] ok, but note the changes [14:29] ok [14:36] ali1234: https://dl.dropbox.com/u/3832397/misc/2012/July/recon.txt [14:37] ali1234: I notice in the fan controller it shows voltage too, so one of the numbers it throws out will be voltage (5 or 5.6V) [14:37] ok [14:37] so i do: cat recon.txt | grep i | grep = [14:38] ah [14:38] :) [14:39] this gives the host->device msgs cat recon.txt | grep o | grep = [14:39] doing that we see only a couple packets that aren't 00000000 at the end [14:39] cat recon.txt | grep o | grep = | grep -v 00000000 [14:39] I guess those are the "me messing with it" ones :) [14:40] 0xae3 = 2787 [14:40] although, there are only 5 events there, I made 7 adjustments [14:41] C/F is a UI thing [14:41] it will always report same format [14:41] the PC sends a signal to the fan controller changing the readout on the LCD display [14:41] perhaps [14:42] well, it does, I watched it do it :P [14:42] that could be in the other part of the message though [14:42] ah [14:42] like it updates the display continuously [14:43] anyway it's safe to assume that 0x5c6 = 69 somehow [14:43] and 0x5c4 = 70 somehow [14:43] :P [14:43] what is the maximum range? [14:44] on what? [14:44] the temp? [14:44] the temperature [14:44] * Azelphur finds out [14:44] 90 [14:44] actually [14:44] 90C, 194F [14:45] oO, I haxed it [14:45] cat 2u | grep o | grep = | grep -v 00000000 [14:45] turn it up to 194F, switch to C, C drops to 124 :P [14:45] you mean 5u right? [14:45] you should only see packets when changing stuff [14:45] yeah [14:46] so now now try all temps and figure out the relatin [14:46] i'm going to look at the output fields [14:47] don't get anything out of it really when things are changed [14:47] I got a couple of lines out of it at the beginning, and a couple random lines, apart from that nothing [14:51] I have to go to some meeting thing, when I come back I'll work on parsing the debug output :) [14:51] ty for your help, will be back around 9ish [15:29] Getting frustrated here. Trying out Linux Mint Xchat for a someone [hoping to convert her across from "the dark side"]. Trying to use two servers so I can actually log into #ubuntu-uk via freenode [as well as Mint channels via mint server] to show a community comparison. Using same nick for both or different nicks - I still get "This nickname is registered" on freenode [both nicks fully registered ok, same pwd for each]. [15:29] Were am I going wrong? [15:29] *Where [15:36] you're using xchat [16:20] oh so nice to be back - first full weekend off off in 3 weeks - get out of the way, I'm heading for the bottle opener ;) [16:21] [& no, I don't know what an "off off" is] [16:36] * AlanBell takes a broken ironing board to the dump [16:38] oh i've just been to the dump! [16:38] speaking of dumps.. [16:39] the recycling centre in reading is always so busy on weekends [16:39] mattt: because normal people have jobs on other days :P [16:39] kinda scary to see how much crap doesn't get recycled and goes to the dump :( [16:39] MartijnVdS: they stay open late during the week tho, i think they close at 8 :P but on weekends it takes like an hour just to get in [16:40] mattt: Recycling and dump are the same place here.. just different bins ;) [16:40] * bigcalm awakens [16:41] afternoon [16:45] Any trading bankers here? I'd hate to think the channel had been polluterd with evil while I've been away [16:45] Would they confess? [16:45] ;) [16:46] I've been called a banker before now [16:46] bigcalm: ditto [16:46] but never a trading bnanker - I'm too honest [16:48] hmm - what's a bnanker I asume u ask? It's 'polite' word for trading banker methinks [16:51] Is it impolite to ask why a man just won the ladies tennis singles? [16:51] * SuperEngineer slaps own wrist [16:55] Some headlines make me sad - e.g. Parachutist found dead in field [ http://tinyurl.com/6s9rtsv ] [16:56] SuperEngineer: Well he was the best parachutist in his field [16:56] SuperEngineer: Maybe he needed a field engineer [16:57] MartijnVdS: ooo - naughty [16:57] SuperEngineer: [too soon?] [17:14] Is it just me or has anyone else found recent updates slow grub to desktop startup times? [17:16] ...& no - I have not any package called "please slow down my startup times" [17:17] http://taylorworld.me.uk/wiki/doku.php/taylorworld_wiki now there a theme. :) [17:21] Once at password dialogue screen it used to be a few seconds to be at desktop... now I tap fingers waiting [17:22] SuperEngineer: that happened to me too [17:22] SuperEngineer: bootchart is supposed to help find that out a bit - it can be quite difficult to track that type of thing down, but stuff is getting slow [17:23] ali1234: hmmm... at least I'm not alone in this [17:23] tried bootchart as well - still hunting!" [17:24] bug 1001138 [17:24] Launchpad bug 1001138 in gnome-session (Ubuntu) "logging in to gnome-classic session takes over 45 seconds" [Low,New] https://launchpad.net/bugs/1001138 [17:24] read all the comments [17:25] ali1234: priority "low" ??? wtf? [17:25] it onyl happens if you log in to gnome classic [17:25] SuperEngineer: There are a set of rules for priorities - it's probably technically right [17:25] once you have logged into gnome classic it affects all compiz based desktops though [17:25] SuperEngineer: I mean it's lower than a crash or it turning your computer into smoke [17:25] it doesn't cause a crash or data loss so yeah [17:26] ali1234: ...but I'm on standard unity here [17:26] * penguin42 looks at his bootchart for the 1st time in ages and wonder what colord is doing taking a few seconds of cpu [17:26] like i said [17:26] ..and thanks for ythe priority listing;) [17:26] if you ever log into gnome classic, it affects all desktops from that point on [17:27] SuperEngineer: https://wiki.ubuntu.com/Bugs/Importance is the real list [17:28] oh buhga! [17:28] :) [17:30] shouldn't there be an update then to simply "refresh".... or os that too simple a solotionn? [17:31] I'll rephrase that.. [17:31] shouldn't there be an update then to simply "refresh".... or is that too simple a solotion? doh! [17:32] *soloution [17:32] Weird [17:33] Thunderstorms approaching and signal strength gets _better_ [17:34] arsen: electrons travel better in wet atmospshere? [17:35] they tend not to [17:35] Maybe thunderstorms calm the ionosphere or something [17:35] * penguin42 would have thought they would be below the ionosphere [17:35] MartijnVdS: Reception on what? [17:36] MartijnVdS: known fact: radio reception poorer on sunny days than rainy days [17:36] penguin42: satellite TV [17:36] MartijnVdS: OK, so in that case you want you're ionosphere to be more transparent; is it you're signal strength that's got better or your error rate that's dropped? [17:37] penguin42: status 1f | signal 014f | snr 0077 | ber 00000000 | unc fffffffe | FE_HAS_LOCK [17:37] penguin42: "signal" is usually around 130ish [17:37] BER is always 0 [17:37] ok, so it's actual signal increased [17:38] yeah [17:39] hmmm.. atmospheric electronic interference with signal clarity apoplies - global warming, stop it or I'll kick your teeth in! [17:40] * SuperEngineer curses human race [excvept for U-UK'er's] [17:42] where do all these extra letters come from? I'm not typing them! [17:42] wanted - new keyboard! [17:46] Fentiman's Cherrytree Cola - much better than their regular cola [18:09] * SuperEngineer watrches mysterious Dr. Who [18:10] SuperEngineer: a random episode? [18:10] Beeb 3 - old episode - but good one [18:11] the movie! starring the 8th doctor! [18:11] no, there was no movie [18:11] ...and only a mere 50 mins [18:13] Demons Run [18:14] a.k.a A Good Man Goes Goes To War [18:14] ah yes, a child is born etc. [18:14] I never quite understood the point of all that warring in that episode, supposedly it was a circular argument [18:15]