search

OpenLightingProject / ola

The Open Lighting Architecture - The Travel Adaptor for the Lighting Industry
https://www.openlighting.org/ola/
Other
647 stars 205 forks source link

Support e:cue / e*net #1153

Open FloEdelmann opened 8 years ago

FloEdelmann commented 8 years ago

It'd be nice if we could figure out the e*net protocol used by the e:cue hardware and software. The software is free but limited until you purchase a premium unlock key.

I've found one other project supporting e:cue, namely vvvv. Maybe that can help us in some way.

e*net is a proprietary protocol on top of UDP. By using Wireshark, I could only recognize the butler search, but not the DMX data, so I guess it will be really difficult to reverse-engineer.

I attached a K12 txt file recorded while searching for a butler while none was connected, which you can open in Wireshark. There you can recognize the Windows account name (Florian) and the hostname of the computer (IO).

The other file is more interesting: I connected a butler, started the Wireshark recording and then opened the e:cue Programmer. You can see the butler search again (from source 192.168.123.10 = my computer) and the butler (192.168.123.1) answering. It is in standalone mode first, then after I added it in the software's device wizard, the butler switched to link mode. The first DMX data are sent in package no. 159. There, all channels should be zero. After that I more or less smoothly pulled up ch2 and ch5 to 255, which certainly has to be transmitted in the last packages. The data packages were sent at a very high rate no matter if I changed channels or not.

In the transmitted UDP data (read backwards), you can see 512 ascending bytes starting at 0x01. But after some random number of bytes, it switches back to 0x01. I think this is the point we need to start investigating.

peternewman commented 7 years ago

If you've got a Windows machine, why not try driving it from vvvv and see if you get any useful captures.

s-light commented 7 years ago

i have a butler here for testing. and there is some information about the e:net package available in the Advanced System Manual - 20 The e:net protocol (page111) and additionally there is some discussion about the 'key message' at Butler XT2 - UDP Triggering and Control Butler XT2 via TCP/UDP instead of RS232

the forum topics are all not on topic for dmx - but they are all on topic for general e:net messages..

as fare as i know the dmx data is encrypted so that only e:cue hardware can be used with the software. (that makes sens as you need a 'dongle'[=usb-license-stick] to send artnet..) the vvvv things also seams to only allow to send a stream. (better only sending than nothing :-) ) i think it could be possible that the butler devices are understanding encrypted and unencrypted dmx data - so eventually vvvv is sending unencrypted data... i have a virtual Win7 - i can install vvvv tomorrow and try to get a wireshark dump from this dmx node (if i get the node to work ;-) )

s-light commented 7 years ago

Looked at vvvv today. during the installaiton i noticed a information: https://vvvv.org/documentation/missing-in-64bit-builds

unlikely candidates all DMX nodes versioned 'ecue' rely on a proprietary .dll

so that is 'bad news' vvvv is using the official ecue device drivers. this dll is named 'EcueDeviceDriverDLL.dll'

FloEdelmann commented 7 years ago

@s-light Thanks for trying that out. What a pity!

I suppose we should nevertheless not include proprietary plugins. That would violate the openness of the project. Maybe we can work the protocol out in some other way...

s-light commented 7 years ago

@FloEdelmann some other way would mean breaking the dmx-data encryption - that is as -fare as i know- illegal - and the ecue brand is owned by Osram - so a big company with lots of laywers. so i think that is not a good idea for a open and friendly project like ola to do. If ecue wants to have there hardware used more easily they could drop the encryption. (but i think this will not happen..)

FloEdelmann commented 7 years ago

@s-light Yeah, that is also true. Unfortunatly, we have to let this alone then, I guess.

@peternewman If I figured the protocol out and we choose not to risk anything by including the encryption in our code, do you think it would be worth having a stub plugin for which one has to provide the encryption part oneself? So we would just include the barebone plugin without the encryption? If not, we can close this issue :/

FloEdelmann commented 4 years ago

I'm tidying up a bit and close this now. As we have sold our e:cue Butler, I also don't have any chance of giving it a shot anymore.

peternewman commented 4 years ago 
* with the right license from ecue it would be possible to write a closed source output-only plugin that works on windows with this dll.. (same as vvvv has done)

I was looking at a similar idea for some of the newer StageProfi stuff.

@peternewman If I figured the protocol out and we choose not to risk anything by including the encryption in our code, do you think it would be worth having a stub plugin for which one has to provide the encryption part oneself? So we would just include the barebone plugin without the encryption?

I think the first thing that would do would generate an issue asking for the encryption code, that feels like possibly a worse worm hole.

I suppose we should nevertheless not include proprietary plugins. That would violate the openness of the project. Maybe we can work the protocol out in some other way...

Others may feel differently, but as long as our code is open source, I'd say it ticks the boxes, after all we support e.g. the Enttec Pro by using their serial protocol as a type of API, the behaviour of the dongle and translation of this onto the wire is still a black box. A plugin like this would still for example allow someone to replace an e:cue install with some other source of generation without replacing all the hardware, which is potentially of use.

I'd argue the OLE is the closest thing available to an open source dongle we support (apart from perhaps some of the old Linux hardware we support): https://www.openlighting.org/ole/

I'm tidying up a bit and close this now. As we have sold our e:cue Butler, I also don't have any chance of giving it a shot anymore.

I'm re-opening this @FloEdelmann , because it's still an interface and protocol that people may want supported, so the info is still relevant (although a lot of the links frustratingly appear to be dead now, and not on web archive).

vinhtranq commented 4 years ago

Hi @FloEdelmann , @peternewman ,

I'm in need of e*net/e:net specification support. Do you have any updates on this topic? Thanks.

Many of the reference links were obsolete.

It seems that the spec of e:net is no longer open now.

FloEdelmann commented 4 years ago

@vinhtranq I don't own the e:cue Butler anymore; and before I sold it, I haven't invested any time in reverse-engineering the protocol. So no updates from my side.

The spec of e*net was never open; it is/was a proprietary protocol.

vinhtranq commented 4 years ago

Dear @FloEdelmann , Thank you very much for your response. I will continue to try the reverse engineering or other possible methods, we are trying to display things on e:cue devices not from e:cue server. Once again, thank you!

s-light commented 4 years ago

if someone develops anything - i have a e:cue butler (first generation) i can test with.. let me know. (i have no time & interest to do any reverse engineering or development at this topic myself..)

peternewman commented 4 years ago

Thank you very much for your response. I will continue to try the reverse engineering or other possible methods, we are trying to display things on e:cue devices not from e:cue server.

If you're going down this route @vinhtranq , from experience with other devices, the first step is probably to try and find the DMX packets, so send e.g. a frame of 255's, then a frame of 0's and try and locate them in Wireshark. Then do a frame where channel 1 is at 1, 2 is at 2 etc, after that you've probably pretty much cracked it.

dsoft-vinhqt commented 4 years ago

if someone develops anything - i have a e:cue butler (first generation) i can test with.. let me know. (i have no time & interest to do any reverse engineering or development at this topic myself..)

Thank you very much for your support! Will let you know if we need to test something. Furthermore, we can not get the spec of e:net anymore, do you still have anything from it?

If you're going down this route @vinhtranq , from experience with other devices, the first step is probably to try and find the DMX packets, so send e.g. a frame of 255's, then a frame of 0's and try and locate them in Wireshark. Then do a frame where channel 1 is at 1, 2 is at 2 etc, after that you've probably pretty much cracked it.

Thank you very much, we will try that out, now we are investigating the wireshark captures to understand it.

dsoft-vinhqt commented 4 years ago

@peternewman, @s-light if we want to test with vvvv, can you share any experiences generating e:net package from DMX raw data using vvvv toolkit? Does it like executing a command in CLI of Windows with some parameters?

s-light commented 4 years ago

sorry - i just saw it one time running... i have no experience doing this - or details what is needed...

vinhtranq commented 4 years ago

thank you, so we should try reverse engineering from e:net data following this thread.

On Fri, Aug 7, 2020, 19:23 Stefan Krüger notifications@github.com wrote:

sorry - i just saw it one time running... i have no experience doing this - or details what is needed...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenLightingProject/ola/issues/1153#issuecomment-670490463, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEUFXIMI54WIGYOBFLBMJWTR7PW5HANCNFSM4CXOPZNA .