Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
jekhor has quit [Ping timeout: 255 seconds]
wej has quit [Ping timeout: 260 seconds]
wej has joined #qi-hardware
jurting has quit [Ping timeout: 260 seconds]
jurting has joined #qi-hardware
xiangfu has joined #qi-hardware
jurting has quit [Ping timeout: 264 seconds]
jurting has joined #qi-hardware
panda|x201 has quit [Ping timeout: 245 seconds]
jurting has quit [Ping timeout: 246 seconds]
urandom__ has quit [Quit: Konversation terminated!]
hack has joined #qi-hardware
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
emeb has joined #qi-hardware
hack is now known as megha
emeb has quit [Quit: Leaving.]
megha has quit [Ping timeout: 264 seconds]
megha has joined #qi-hardware
megha has quit [Read error: Operation timed out]
rz2k has quit []
megha has joined #qi-hardware
jayar has joined #qi-hardware
<jayar> is this the right place to ask a harddrive question?
* jayar taps the mic
<jayar> is this thing on?
<jayar> testing testing... civilance... civilance...
<jayar> well dangsauce
<jayar> carry on, idlers
jayar has left #qi-hardware [#qi-hardware]
jekhor has joined #qi-hardware
<C-Keen> wtf
wej has quit [Ping timeout: 264 seconds]
megha has quit [Ping timeout: 252 seconds]
megha has joined #qi-hardware
<wpwrak> nowadays they have really earth-shattering insults. "idlers". boah.
Hoolxi has joined #qi-hardware
<kyak> !top10 idle
<qi-bot> Top10(idle-factor): 1. woakas(262588.66) 2. paroneayea(195220.00) 3. jluis(165642.67) 4. Openfree`(82697.50) 5. emeb(73045.20) 6. freakazoid0223(62197.67) 7. zumbi(61670.25) 8. zedstar_(56398.00) 9. wej(54859.40) 10. newcup(44201.75)
wej has joined #qi-hardware
<qi-bot> [commit] kyak: ben-cyrillic: use phonetic keymap by default (master) http://qi-hw.com/p/openwrt-packages/fa463c3
wej has quit [Ping timeout: 264 seconds]
wej has joined #qi-hardware
liuqi has quit [Ping timeout: 264 seconds]
<whitequark> wpwrak: you know what makes me sad?
<whitequark> all these new high-speed interfaces. they're completely impenetrable for DIY
<whitequark> DVI, HDMI, USB>2 (or >= maybe), DisplayPort, SATA
<whitequark> !top10
<qi-bot> Top10(words): 1. wpwrak(363814) 2. wolfsprau(156714) 3. wolfspraul(103224) 4. kristianpaul(97052) 5. whitequark(95257) 6. DocScrutinizer(85365) 7. kyak(71580) 8. roh(56080) 9. viric(48162) 10. xiangfu(36599)
<DocScrutinizer05> meh
<whitequark> hehehe
<DocScrutinizer05> and WTF?
<DocScrutinizer05> friggin bot's statistics are useless
<larsc> wpwrak talks as much as everybody else combined
<larsc> kind of
<whitequark> well not everyone, sum(2..5) = 1
<DocScrutinizer05> nfc what those statistics mean at all
wej has quit [Ping timeout: 260 seconds]
<wpwrak> damn. my absolute majority is being threatened !
<wpwrak> need to talk more then :)
<wpwrak> whitequark: (fancy new interfaces) yeah, they're tricky. not completely impenetrable but considerably more difficult to play with
<whitequark> fortunately USB is as backwards-compatible as it is realistically possible
<wpwrak> yeah, a pain at any speed, but at least manageable while slow
<whitequark> why? USB is pretty nice
<whitequark> when you are programming a device at least :)
<whitequark> (well, theoretically it is fully backwards compatible, but I've seen more than once noncompliant device working on 2.0 and failing on 3.0.)
<whitequark> s/once/one/
<qi-bot> whitequark meant: "(well, theoretically it is fully backwards compatible, but I've seen more than one noncompliant device working on 2.0 and failing on 3.0.)"
<whitequark> in fact let me check if v-usb-based USBASP still works...
<whitequark> if only I had a clue where the board is.
<whitequark> yeah works perfectly
<whitequark> [1183600.307007] usb 3-3: new low-speed USB device number 32 using xhci_hcd
<whitequark> well, kudos to USB Consortium then.
<whitequark> STM32VLDISCOVERY: fail
<whitequark> they abused USB Mass Storage on their programmer to display a 64k "block device" with a pseudo-FAT where four .url file is stored with links to the ST website
<larsc> well they have to make sure it works
<larsc> the USB consortium
<whitequark> larsc: there is more than one example when something ought to work, a consortium existed to ensure that, and it actually doesn't
<whitequark> for example, I dunno, Bluetooth
<whitequark> the fucking thing never works for me. every single time I need to use BT I spend hours trying to make it work and then usually give up.
<whitequark> bluez in Debian is completely unable to talk with bluez in Android. perfect.
<larsc> yea, it is always sad when that happens
<wpwrak> whitequark: USB mass storage for a virtual FAT is a very good idea. i'm actually surprised it seems to have taken so long to be implemented (NXP have it too)
<whitequark> wpwrak: I'm not if this was intentional or not on their side, but this device violates sheer amount of requirements in the spec
<wpwrak> whitequark: what sucks is that you can't have USB mass storage on a USB low-speed device
<whitequark> it's a high-speed device btw
mth has quit []
<wpwrak> ah, like what ?
<whitequark> it hardly works even on 2.0, requiring a kernel patch and a quirk enable
<wpwrak> ;-))
<whitequark> just to enumerate
<whitequark> (the patch is in mainline for a long time, but still)
<whitequark> then, the mass-storage port doesn't work in linux anyway
<wpwrak> perhaps they had deadlines to meet, leaving no time to read those boring specs ;-)
<whitequark> but you can abuse SCSI vendor-specific commands to actually program the target
<wpwrak> blargh
<whitequark> and in 3.0, it is just stuck in an endless reset loop
<whitequark> wpwrak: oh, it's a high-speed device btw
<whitequark> [1183860.020531] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010cd80780
<whitequark> [1183860.020549] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010cd807c0
<whitequark> [1183860.179003] usb 3-3: reset full-speed USB device number 34 using xhci_hcd
<whitequark> [1183860.190426] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010cd80780
<whitequark> [1183860.190436] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88010cd807c0
<whitequark> [1183860.349773] usb 3-3: reset full-speed USB device number 34 using xhci_hcd
<whitequark> I've seen similar behavior with Samsung's bootloader in their phones
<larsc> but is that a bug in the device or in the kernel?
<wpwrak> heh. perhaps they should have been less ambitious ;-)
<wpwrak> (vendor-specific commands) the beauty of using USB storage is that this is about the only way to get data to a USB device that's OS-agnostic.
<wpwrak> for anything else you need some sort of driver
<whitequark> wpwrak: but they screwed them up too
<whitequark> something with error codes, I don't remember, it was two years ago
<wpwrak> well, one you decide to foul it up, you may as well go all the way ;-)
<whitequark> so you need even more quirks, or libusb
<larsc> wpwrak: usb keyboard works as well ;)
<whitequark> oh yes, HID requests.
<whitequark> you can even send them from an unprivileged account in Windows
<wpwrak> larsc: how do you send a file over HID, in an OS-neutral way ? :)
<larsc> tell people to open up a texteditor, then send the characters ;)
<wpwrak> huh ?
<viric> with a proper keyboard layout chosen.
mth has joined #qi-hardware
<wpwrak> does HID have a snoop option ? e.g., for law enforcement :)
<wpwrak> viric: the problem is that you're the device. so how do you see what other HID devices are doing ?
<larsc> well you can of course only send one file
<viric> no idea.
<whitequark> larsc: what?
<wpwrak> larsc: and then it self-destructs ?
<viric> in ps2 times, barcode readers were put between the keyboard and the computer :)
<whitequark> viric: you can do this with HID too
<whitequark> there are examples for atmel chips on the net
<larsc> wpwrak: well you can send the same file multiple times
<wpwrak> bar code is easy. pretent you're a keyboard and just send the numbers.
<larsc> you need a push button on the device to start the transaction
<wpwrak> larsc: wait ... how does the data get sent to the device ? i mean, what does it pretend to be and by what mechanism does it receive the data ?
<larsc> wpwrak: the device only sends data out
<larsc> no backchannel
<wpwrak> ah, okay. that's trivial
<wpwrak> no firmware updates then
<whitequark> larsc: wpwrak implemented a firmware update via mass storage
<wpwrak> back to USB storage and its full-speed requirement :-(
<larsc> except maybe using morse code on the capslock key
<wpwrak> whitequark: no, i haven't yet. but i'd want to. without paying the premium for full-speed.
<wpwrak> larsc: yes, the LEDs are a backchannel :)
<whitequark> wpwrak: linux has a quirk which modifies bulk endpoints to be interrupt for low-speed devices
<wpwrak> whitequark: that one no longer exists (tried it)
<whitequark> but you probably have no luck with windows and even more os x
<whitequark> oh, that sucks
<whitequark> it was a nice quirk.
<larsc> I think we even looked up the commit that removed it some time ago
<wpwrak> yeah
<larsc> so it is still there
<wpwrak> the internet never forgets :)
<larsc> I mean the quirk
<larsc> it's still in the kernel
<wpwrak> ah .. no, i don't think the quirk is still there
<wpwrak> or at least it doesn't work
<wpwrak> anyway, given that the objective is compatibility, relying on linux-specific quirks wouldn't be such a great idea
<wpwrak> after all, if we just care about linux, making a little libusb-based utility is trivial
<larsc> libusb works also on windows and macos
<whitequark> larsc: but not when code signing is enabled
<whitequark> i.e. >= Vista
<whitequark> and/or 64-bit kernel, which forces code signing to be enabled
<larsc> ah, didn't knew that
<whitequark> oh wait, they fixed it
<larsc> is this because of the libusb kernel module?
<whitequark> For 64bit Windows Vista/7/2008/2008R2, the version should be 1.2.0.0 or later.
<wpwrak> windows - designed to suck and delivering on its premises since day one :)
<wpwrak> s/prem/prom/
<qi-bot> wpwrak meant: "windows - designed to suck and delivering on its promises since day one :)"
<whitequark> that's very neat
<whitequark> As of version V1.2.0.0, a valid digital signature is embedded inside libusb0.sys for AMD/Intel x86_64 version of Windows so that the users can install the driver as well under 64bit x86_64 version of Windows Vista/7/2008/2008R2.
<wpwrak> ah, nice
<whitequark> wpwrak: code signing in windows is awesome
<whitequark> that should've been there from day one
<whitequark> you can override it with a boot.ini switch even for 64-bit kernels btw
<whitequark> it does make sense in fact that it is intentionally hard for users, because malware.
<larsc> I must say I like the new Linux kernel module signing
* whitequark doesn't like mindless bashing of windows
<whitequark> larsc: the EFI Secure Boot one?
<larsc> create a new public-private key pair, build your kernel, sign your modules and delete the private key
<larsc> makes it much harder for rootkits
<whitequark> linux doesn't have a shortage of kernel holes
<whitequark> just look at all the android phones, which are trivially routed, often without physical access
<whitequark> half of them is due to vendor stupidity. the other half is in linux.
<larsc> it's for the case where the attacker is already root
<larsc> and tries to hide himself
<whitequark> but if you're root, isn't it trivial to patch kernel memory?
<whitequark> unless you have selinux or something like that
<whitequark> where root isn't an actual root
<larsc> still makes it harder
<whitequark> marginally IMO
<larsc> yea, I didn't really though about that you can still patch the kernel easily
<qi-bot> [commit] Werner Almesberger: README: add ubbctl and ubb-jtag (master) http://qi-hw.com/p/ben-blinkenlights/85ed493
<qi-bot> [commit] Werner Almesberger: ubbctl/ubbctl.c: add copyright header (master) http://qi-hw.com/p/ben-blinkenlights/fe96b3b
<qi-bot> [commit] Werner Almesberger: ubbctl/ubbctl.c (main): move pin status display to separate function (master) http://qi-hw.com/p/ben-blinkenlights/e6a0e42
<qi-bot> [commit] Werner Almesberger: ubbctl/ubbctl.c (main): add command line processing and usage display (master) http://qi-hw.com/p/ben-blinkenlights/33085ce
<qi-bot> [commit] Werner Almesberger: ubbctl/ubbctl.c (show_pins): also show level seen at pin (master) http://qi-hw.com/p/ben-blinkenlights/77fd696
<qi-bot> [commit] Werner Almesberger: ubbctl/ubbctl.c (show_pins): indicate function pins with "F" instead of "FN" (master) http://qi-hw.com/p/ben-blinkenlights/5297de4
<qi-bot> [commit] Werner Almesberger: ubbctl/ubbctl.c: add setting of UBB signals (DAT0=1, etc.) (master) http://qi-hw.com/p/ben-blinkenlights/246a8a0
<qi-bot> [commit] Werner Almesberger: ubbctl/ubbctl.c: add actions "on" and "off" to control nPWR (master) http://qi-hw.com/p/ben-blinkenlights/fd5707e
jekhor has quit [Read error: Operation timed out]
jekhor has joined #qi-hardware
<wpwrak> whitequark: (mindless bashing) bash, beat your windows every day, it will know why :)
<wpwrak> of course, in my case "my" windows would be a diffuse ambient condition
xiangfu has quit [Ping timeout: 276 seconds]
Hoolxi has quit [Remote host closed the connection]
jurting has joined #qi-hardware
LunaVorax has joined #qi-hardware
<LunaVorax> Hi!
wolfspra1l has joined #qi-hardware
wolfspraul has quit [Read error: Operation timed out]
liuqi has joined #qi-hardware
megha has quit [Quit: WeeChat 0.3.9.2]
hack has joined #qi-hardware
hack is now known as Guest17317
Guest17317 is now known as hack
hack has quit [Changing host]
hack has joined #qi-hardware
hack has quit [Quit: WeeChat 0.3.9.2]
hack has joined #qi-hardware
wolfspra1l has quit [Quit: leaving]
wolfspraul has joined #qi-hardware
<qi-bot> [commit] Werner Almesberger: ubbctl/ubbctl.c: new option -c for continuous display (master) http://qi-hw.com/p/ben-blinkenlights/5fadbce
<qi-bot> [commit] Werner Almesberger: ubbctl/README: short documentation (master) http://qi-hw.com/p/ben-blinkenlights/ed19239
emeb has joined #qi-hardware
FrankBlues has joined #qi-hardware
urandom__ has joined #qi-hardware
hack is now known as megha
LunaVorax has quit [Ping timeout: 260 seconds]
megha has quit [Ping timeout: 272 seconds]
megha has joined #qi-hardware
porchaso0 has joined #qi-hardware
porchao has quit [Ping timeout: 264 seconds]
porchao has joined #qi-hardware
porchaso0 has quit [Ping timeout: 255 seconds]
rz2k has joined #qi-hardware
LunaVorax has joined #qi-hardware
<wpwrak> DocScrutinizer05: that's bee on heise news a few days ago. certificate-based "trust" must die :)
whitequark has quit [Read error: Operation timed out]
bartbes has quit [Read error: Operation timed out]
whitequark has joined #qi-hardware
<DocScrutinizer05> wpwrak: I didn't say I invented it today
<DocScrutinizer05> better late than never, eh?
<wpwrak> ;-)
<DocScrutinizer05> well, TURKTRUST
<DocScrutinizer05> :-x
<DocScrutinizer05> "ooops we handed out a master cert by accident" - LOL
<DocScrutinizer05> "ooops again, even two"
<DocScrutinizer05> "but thanks for letting us know, we wouldn't have noticed otherwise"
<wpwrak> ah, you hadn't read it before ;-)
<DocScrutinizer05> I've read it 2h ago
LunaVorax has quit [Read error: No route to host]
<DocScrutinizer05> when somebody informed me about the issue, since it is relevant for maemo-CSSU
<wpwrak> it potentially affects everyone using SSL
LunaVorax has joined #qi-hardware
<kyak> wpwrak: can i use one instance of ubbctl to set ping status, and another instance of ubbctl to get pin status?
<wpwrak> kyak: yes, you can run as many ubbctls in parallel as you like. they don't conflict with each other. that it, unless they try to perform contradictory changes on the same pins
<kyak> nice :)
<wpwrak> but even then it's not certain you would get an invalid result
<wpwrak> (at least the static result should be identical, no matter how many concurrent setters you have. there may be transient states that differ between concurrent runs of ubbctl and unordered sequential runs, though)
<DocScrutinizer05> wpwrak: sure it affects everyone, but not everyone is responsible to fix the issue for ~60k other users
<DocScrutinizer05> that's the kind of relevance it has for maemo-CSSU
<wpwrak> heh :)
<DocScrutinizer05> and actually I had no time to read any Heise news lately, since my plate is already more than filled with migrating a complete infra (*.maemo.org) to a yet-to-be-defined new hoster and financial basis
<DocScrutinizer05> which gives me a headache every now and then, when I have to explain difference between a vhost and a RX300 rack
porchao has quit [Ping timeout: 246 seconds]
porchao has joined #qi-hardware
wej has joined #qi-hardware
<kyak> wpwrak: i'm packaging libubb and ubbctl. However, i noticed that you only provide libubb.a and you link ubbctl statically
<kyak> how about providing an libubb.so and linking ubbctl against it? I will then package both and ubbctl with depend on libubb
<wpwrak> yeah, i should probably do that. though i hate the version number management :)
<kyak> btw, it's working great
<wpwrak> but that'll have to wait until tomorrow. got a barbecue to go to now.
<wpwrak> kewl :-) and thanks for packaging !
<kyak> np, have fun!
<wpwrak> thanks ! :)
Jurting_pc2 has quit [Read error: Connection reset by peer]
FrankBlues has quit [Quit: Leaving]
Jurting_pc2 has joined #qi-hardware
megha has quit [Read error: Operation timed out]
jekhor has quit [Ping timeout: 276 seconds]
megha has joined #qi-hardware
Jurting_pc2_ has joined #qi-hardware
Jurting_pc2_ has quit [Remote host closed the connection]
wej has quit [Ping timeout: 248 seconds]