dtserver needed for speakerpoints?

[willosof]

I'm doing some hacking here. I'm trying to emulate a speakerpoint with some of my other i386 hardware i have around in my house, and have the audioserver and the netusb services running, but do I need the dtserver as well for stuff to communicate properly?

when i'm stracing dtserver, it's ofcourse trying to find devices it doesnt find in my /dev, etc. So, not working. Just wanted to know if there is any cool workarounds

Feel free to contact me privately on msn williamv@opera.com ..

PS:

~# df -h

Filesystem Size Used Available Use% Mounted on

/dev/mtdblock3 21.8M 21.8M 0 100% /

/dev/ram0 23.2M 353.0k 22.9M 1% /mnt/ram

/dev/mtdblock4 20.3M 12.8M 7.5M 63% /mnt/jffs2

/dev/sda1 3.7G 25.2M 3.5G 1% /mnt/internal

256mb aint enough! ;D

[henniae]

You are Da Bomb dude.

What are your thoughts on running the C4 software that is used on the HC-1000 on a i386 box? The HC-1000 is after all just a standard Intel motherboard with all the ports except the USB and Ethernet disabled.

[willosof]

Hehe

That's my plan. But I dont have a HC-1000 nor a Media Controller in my posession. :/ I only have a ARM-style Home Theater Controller, and that doesn't help me much packages are available through the update-server, but it doesn't contain everything i need for making "my own i386 controller"

MEH! I want money for more c4 products! hehe, so that I can hack them apart to make cool inexpencive stuff

[slemay]

HC-1000 is hardware locked - so it can't be ported over to another x86 platform and ran. However - I don't believe any of the other C4 equipment is locked like that, and thus I'm sure you can port it over to whatever platform you'd like.

[willosof]

Uh. hardware locked? What do you mean? Like, physicly? Then we use a chainsaw or whatever.

If it runs, it can be reverse engineered.. And I don't think the security measures is too serious after looking at my own controller at home. I have full access to the "hidden" jffs2/cramfs filesystem in my htcbox (telnet access, etc) and, i'm running my own apps on it as well. And that i managed to in.. 20 minutes after opening it up. Including upgrading the 256mb stick to 4gb and resizing the filesystem

[c44me]

very cool

[henniae]

Uh. hardware locked? What do you mean? Like, physicly? Then we use a chainsaw or whatever.

If it runs, it can be reverse engineered.. And I don't think the security measures is too serious after looking at my own controller at home. I have full access to the "hidden" jffs2/cramfs filesystem in my htcbox (telnet access, etc) and, i'm running my own apps on it as well. And that i managed to in.. 20 minutes after opening it up. Including upgrading the 256mb stick to 4gb and resizing the filesystem

Would you care to post some detailed instructions on how you have done some of these hacks? I am a bit of a Linux hacker but not at the level you have described here.

[slemay]

Willosof - there was no worries about you hacking the HTC - thus why it was pretty wide open (as most people do NOT own the chipset that it was running on, thus it could NOT be ported over to an x86 computer). However - with the HC-1000 running on an x86 platform - security was quite high on it not being pirated / copied. So it is hardware mirrored os to the physical hardware it's in. What does that mean exactly? I don't know - but I would speculate you're not hacking it, unless you know how to put capturing devices inbetween the software and the hardware and can break encryptions... but then again - if you were doing that, you WOULD be breaking the law (at least US law as it stands today).

Not that I'm knocking you at all willosof - but hacking the HTC and hacking the HC-1000 are two different leagues... like comparing the local youth hockey team to the NHL.

[willosof]

Thanks for your reply Well, ARM can easily be emulated on x86 systems, but I see your point in any case. I would never want my own hardware to run my director etc. But the thing I'd want instead is for my non-c4 x86 devices i have placed in different rooms, i want them to act as speakerpoints. Generally like, the main component in a product should ofcourse be bought. They deserve money for making such a cool system. But all the extras? Not so much.

I borrowed a speakerpoint yesterday, and like you say, captured the traffic between the speakerpoint and my director. Analyzed the traffic (which is pretty much plaintext and no encryption what so ever), and tonight I'm going to make my own speakerpoint. My own software - only that it's compatible with the one control4 use =)

And that I did without any cracking of encryption, and not even opening up anything. I see why c4 as a company wanting to sell as much as possible wouldn't like it, but I see how the poor users would benefit from it. I also think providing a more open interface to this, would contribute to more attention around the c4 products.

The people that can afford automation systems usually buy "the whole thing" anyways, so. Why not.

Open Source.

I've created a project named control4toolkit which i'm going to upload my speakerpoint emulation software (and everything else) to when i'm done with it: http://code.google.com/p/control4toolkit/

[slemay]

willosof - it's built on Linux, so my understanding is that it has to be open (according to the license) - so you can reverse engineer a lot of it and get it working - I'm sure.

Personally - I'd love to see someone come out with a full NAVIGATOR emulator. So we can run the full C4 interface from our computer and act as if we're talking to the system directly (there is something internally that C4 made - but because of licensing issues... it'll never be released publically).

[willosof]

Hehe, yep. I'll probably not have the spare time to make a navigator, but it shouldn't be that difficult with some SDL and Just use the skins and everything available for the original system

Aaanyhow. As soon as I find out what type of packets the audio-stream is, I have a perfectly working emulated audiopoint \o/ wuuu! hehe. Got it aaaalmost working

[willosof]

Would you care to post some detailed instructions on how you have done some of these hacks? I am a bit of a Linux hacker but not at the level you have described here.

Check out my subversion repository at

http://control4toolkit.googlecode.com/svn/trunk/

And http://control4toolkit.googlecode.com/svn/trunk/drafts <- some quick debugging notes on the fly. Trying to get it down in order in the wiki at:

http://code.google.com/p/control4toolkit/w/list

..stuff like that takes time to document with little or no spare time, but in the meanwhile you can look at my allmost finished complete speakerpoint (only missing to output the audio now ..it does ofcourse not work from end to end with all controls, etc, but it's a start..

http://control4toolkit.googlecode.com/svn/trunk/bin/speakerpoint/

[RyanE]

willosof,

I don't know why you say upthread that the jffs partition on the HTC / MC is 'hidden'. Not too hard to find and use.

Nothing on the HTC has been attempted to be hidden in any way, shape, or form.

I mean, when we give dealers (and indeed even on external forums) the root password, security isn't the top concern.

RyanE

[willosof]

Hehe, okay

Anyhow! Due to my lack of access to documentation, I have now done some bruteforce engineering(!) haha, well, I've finally realized that it's RTP MPEG TS-ish stuff. And with some mpg123, Net::RTP::Packet, Audio::Mixer and IO::Socket, we have a working speakerpoint ;P super-beta though.

Syncs perfectly with the htc output and other streaming rooms. I Love it!

[willosof]

And i must say.

Control 4 developers cannot have coding standards and communication between projects AT ALL I mean. TCP, UDP, UDP, different ports, and all of the services are doing things differently. Even with the serials!

00i00 req

00r00 resp

versus

the rtp-sequencing

versus

the

0 something

0 OK something

..blah It's not easy to GUESS atleast Any answers to why this is so messy/different from eachother, RyanE?

[RyanE]

The system certainly was developed very quickly by different teams of developers. You have to remember, all of the devices that are currently out (or their immediate predecessor) were created in an extremely short time frame to get shipping product.

Parts of it show that legacy, and parts of it have been more standardized.

It continues to mature and grow, and I'm sure it will continue to be standardized as it has been.

All in all, the codebase (which obviously I have access to) is clear and standard. There definitely is a set of published coding standards (for both software and firmware) at Control4, although as you've pointed out some of the communication between devices is not completely standardized.

RyanE

[willosof]

Cool.

So, when can the end user (or just: me) expect a public available documentation to how stuff works ? Hehe The SDK-price is a bit.. Well, what can I say. Expencive. And I doubt that it even contain the slightest bit of information on stuff like that, other than how to make new stuff

[str1der]

Willosof what we really need is a hack for internet control.

[willosof]

Willosof what we really need is a hack for internet control.

Internet control? What do you mean? On what device?

[str1der]

Willosof what we really need is a hack for internet control.

Internet control? What do you mean? On what device?

The whole system

[slemay]

Why? You can tap into it with the SDK... you can build stuff on top of it (as it is Linux... so you can setup additional processes and have them do additional stuff too... so what other control do you want?

[henniae]

Why? You can tap into it with the SDK... you can build stuff on top of it (as it is Linux... so you can setup additional processes and have them do additional stuff too... so what other control do you want?

SDK? Do you mean the current SDK? The one that limits you to building serial drivers only? Is there another SDK that you can direct me to that documents this additional control and feature set you speak of?

If one wanted to they could use a sniffer to decode the communication between a TS and a controller. Once you had this protocol you could probably build software that opens a TCP connection to the controller to send commands. Again, too bad this is not documented somewhere. I can see why C4 would keep these protocols a secret, others would build the software C4 chooses not to build. If there were open source software to interface with C4 such software would probably cut deep into profit. Why would I buy a 10.5 inch TS if I could use free/open source software to control my system.

[slemay]

Again - and I could be wrong - but being that it is built on Linux, and is an open standard, there is nothing being hidden here. C4 DOES encourage other companies to build product for it (Card Access is a great example). Yes - I'm sure they're concerned about people opening it up and giving it away for free, but I'm sure they encourage and would LOVE to work with people who are looking to improve the product and market it. I would suggest contacting them directly to discuss this.

[willosof]

Well, "everything is open" sure. if you reverse engineer it first. Like I had to do now without documentation. My point was only that this was pretty idiotic, because, like henniae say, one could just do like i did, and guess the protocol by using a sniffer and some common sense, but things will never be any good that way, as you don't have errorcodes and different sceniaros that could come up along the way, only the "perfect working system".

I can mail them asking about their opinion on this, and my best guess is that I'll get a no. Like, no documentation, source code examples, etc.

Btw, it would be great to use c4 together with mythtv *thinks*

[RyanE]

Yes, the current SDK only has documentation for the *Driver SDK*, not the *Director SDK*.

That's not currently available outside of Control4, although I don't know that will always be the case.

RyanE