dLive TCP capture data (companion module build)

[lightingman117]

@Andy

Like I say, there’s no “wrong answers”.

Let’s just agree on what to tackle first. My focus was on sending commands to the MixRack, specifically commands that the MIDI implementation was missing.
If everyone feels the better direction would be Director/Surface control, then let’s move in that direction instead.

It’s important, though, that everyone understand that there are 2 separate sets of commands. There are MixRack commands that affect the audio, and there are Surface/Director commands that ONLY affect that device.

e.g. A channel mute is a MixRack command. If this happens, the surfaces reflect this change through a message sent from the MixRack to the Surface.
A channel select command is a Surface command. When this happens, no other surface reflects this change and the MixRack doesn’t even care. It just changes what information the Surface displays.
Other “surface only” commands are things like:

[ul]
[li]Channel Layout[/li]nr[li]Scene storage[/li]nr[li]Sends on Fader mode[/li]nr[li]Soft Keys[/li][/ul]
There’s a few more, but think of things that do not directly affect the audio, and you’ll get the picture.

With the “surface only” commands, I’m not even sure that it even sends that information out over the network. I’m not sure that it would need to, as it’s not something that affects other devices.

So, with that in mind, can you even make “surface only” changes, like Channel Select or Soft Keys? That’s the big question.

If you’d like to see the SD work as an extension for Director or a surface, we’ll have to determine if that’s even possible.

We already know that the idea I was running with (MixRack control) is possible and workable, but if that’s not the goal, then let’s see if the Surface control is even possible. Show me a message that affects the “Surface only”.

BTW, the above “conclusions” are only my opinion from watching how the dLive system works. I may be completely off-base, so correct me if you’ve discovered that it works a different way to the way I’ve described.

I spent considerable time with wireshark and the system figuring out how each part of the dLive system communicates with each other part in my earlier posts when I was posting the TCP data captures.

In general UDP is for meters only, StuartW, use the “not udp & not arp & not DNS” command in the filters in wireshark. I have not investigated this thoroughly, but I am 95% sure that is all UDP is for.
Director sends TCP heartbeat, status updates, and nearly every command to mixrack and mixrack returns confirms to the specific Director instance in communication. This includes the commands you might think are ‘Director only’ such as ‘Sel’ or ‘SoF’.

I am not 100% certain of how this handshaking occurs, but I have a general gist. Mixrack can accept control from 4 directors at once.
Setup: 2x Directors (or surfaces, i’ll use it interchangeably) & mixrack.

Here’s an example:
Director1 CH1 sel > tcp command to mixrack “select channel 1”
mixrack > tcp command to director “selected CH1”

Current State: Director1 shows CH1 selected, Director2 does not show CH1 selected, Mixrack internally knows Director1 is selecting Ch1

Director1 change EQ4 +3dB > tcp command to mixrack “change EQ4 +3dB” [not 100% certain whether it includes info about which channel or because CH1 is the currently selected channel mixrack changes the specific setting]
mixrack > tcp command to director “okay did that to Ch1”
mixrack > tcp commands to other director “hey I changed EQ4 +3dB on CH1”

Current state: D1 shows Ch1 selected & sends EQ changes to mixrack.
Mixrack sends D1 EQ changes to D2 for CH1
D2 shows CH1 not selected but reflects D1 EQ changes on CH1

---

The reason why I say controlling Director is more useful is two-fold.

1. Controlling director allows offline non-mixrack emulation & control/setup. One can completely create a dLive ecosystem without the mixrack and controlling Director from SD would allow testing & implementation.
2. I find that controlling Director is much more useful (command-wise) than controlling the mixrack.

To the surface only/mixrack, I think you’ll see from the above investigations that there aren’t many ‘surface only’ commands.
And I get that you’ve already done work controlling the mixrack directly and I’m sure there is more that could be expanded upon the current commands allowed via MIDI, but I’m not sure what else you’d want to do.
Give me a specific list of things you want to control on the mixrack and I’ll give you the data, sure, no prob. But if it is “everything one can do” that’s a huge amount of commands I’m not really interested in sniffing.
My priorities when developing is make it useful first to most people, then add moar cow-bell

---

So getting to the meat of things…
I can sniff packets all day long, but without getting it to work by sending the same message I can’t really test anything.
To be more useful to this project, I need is a program that sends proper HEX strings via TCP messages to an IP & socket from a source socket.
I started trying to find a program but it doesn’t exist, I know vb.net better than c# but there’s only c# programs so I guess I need to make a program that can do this.
I am REALLY close to doing what I want with director from a sniffing POV, but not from a ‘test this command’ POV.

Due to personal prioritie(s) I’ll have less responsibilities starting Monday so I can help more on this project.

[lightingman117]

@StuartW

Hey all,

I had a crack at trying to see Mixrack -> Surface and other way unsure. Im going to try put a gigabit switch between the two and then wireshark that see how I go.
I think that may hold answer to what you are wanting.

What do you need exactly?
I know there are LOTS of UDP messages that get sent around in the system. So a way to minimize information so its more direct would be helpful.
To be honest I am in no way a coder or computer expert.

I have by accident made a surface do a channel PFL… however i do not remember how I did it.
From memory it was an incorrect code from the mute function we have.

Also apologies being behind on the thread! I never got an email notifcation… I shall check those settings

No worries brotha!

In wireshark you can filter messages.
I would use a separate (offline) NIC & switch on the computer & mixrack that you wish to sniff.
Anytime you connect Director & mixrack there is a ton of extra messages that you’ll have to filter.
It’s much easier to see messages with only two devices talking (director > IP8) (Director > mixrack) etc. or Director by itself.
Use the ‘not’ command in the filter bar in wireshark to remove stuff you don’t want to see.
“not udp & not dns & not arp”

How are you sending messages to the mixrack and/or director?

[Andy]

Hey Nathan;

Do you have time for a phone call one of these days? I think we can clear up my confusion rather quickly with a conversation. I also have software to send/receive TCP that might be useful to you.

[StuartW]

Just had a catch-up read. Some heavy stuff in there that’s beyond my computing knowledge.
Ultimately my vision for this module was to make ‘macros’ like a Digico hence expanding the dLives useability and versatility to new heights!

Ultimately I think it it will beeed to be a mix of mixrack commands and surface/director commands.
ie I cannot find a string of data for ‘GEQ’ when pressed on either surface or director

Does that make sense?
It would be amazing to have endless options of steps chained together.

One mega one would be changing layouts! If that’s possible it would mean in theory you could turn a C1500 into a bigger surface.

I currently tour a CDM48 & C1500 (when they get hired)
So I’m looking for that upper edge above what it already has

I was going to spend sometime sitting with digico offline to see what macro options you have to see what is possible to do.

[Andy]

Thanks, Stuart.

In speaking to Nathan, there’s 2 different issues. 1 is feedback, 2 is communication with Director or a Surface for the non-audio commands.

I think we should start with is finishing the current module (direct MixRack control) and just try to figure out how to get messages BACK from the MixRack for feedback purposes. We can’t go much further without getting the feedback working.
In the end this module will just be a possible improvement on the MIDI module because it adds commands that aren’t possible by simple A&H MIDI, if we can’t figure out how to control a Surface or Director.

The next step would be to try and figure out if Director or a Surface can be controlled. That would be the golden apple as it would allow changing layouts, selecting mixes, channels, etc.

[StuartW]

Alright well hopefully I get a day this week to sus that failing that it will be next week.
What is the purpose of getting the feedback? And what exactly is that?
Is that not what is the wire shark I uploaded?

[Andy]

@StuartW

Alright well hopefully I get a day this week to sus that failing that it will be next week.

Great!

What is the purpose of getting the feedback? And what exactly is that?

Feedback are messages back from the MixRack. E.g. If we sent a “Mute Ch 1” message to the MixRack, it responds “Ch 1 Muted”. The command to the MixRack could come from the SD or a surface or controller.
Feedback is critical so that on the SD you see what state a setting is in. If you mute a channel, you want to see that it’s muted by a color change on the SD button.
We also need it to try and determine the MixRack layout so buses are labelled accordingly.

Is that not what is the wire shark I uploaded?
AFAIK, you were sending commands that the MixRack can accept and act on. I didn’t see any response messages back from the MixRack to SD.

[StuartW]

By mixrack layout so mean the console ‘structure’? ie how many of each type of buss?
If so I don’t think they are fixed. The possible changing 162 busses all have the same code type just a matter of order as I suggested in the capture doc
Or did you mean something else?

As for the feedback you want great. I can get you a capture of what happens when press a button in director is pressed.
From memory it looks very similar. Only 4 lines of TCP happen

[Andy]

@StuartW

By mixrack layout so mean the console ‘structure’? ie how many of each type of buss?
If so I don’t think they are fixed. The possible changing 162 busses all have the same code type just a matter of order as I suggested in the capture doc

They’re not fixed, they are determined by the MixRack configuration. If we’re going to have SD buttons that affect sends it would be good to know which bus is which, ideally with names.

As for the feedback you want great. I can get you a capture of what happens when press a button in director is pressed.
From memory it looks very similar. Only 4 lines of TCP happen

The mixrack will not transmit to the Companion module. It will only transmit to “known” devices that have completed the correct handshaking. It’s the handshaking I need to figure out.

[StuartW]

@Andy

They’re not fixed, they are determined by the MixRack configuration. If we’re going to have SD buttons that affect sends it would be good to know which bus is which, ideally with names.

The mixrack will not transmit to the Companion module. It will only transmit to “known” devices that have completed the correct handshaking. It’s the handshaking I need to figure out.

Yeap ok so as per document I made so far. I think it needs to be in the settings for the module and then module can label. If possible.
No need for the mixrack to tell companion what it’s doing as it’s right there Easily accessible to the user
At least that’s how I think…

Ok cool well I’ll find the director to mixrack wireshark that shows the only interaction that happens when a command is sent

[Andy]

@StuartW

Yeap ok so as per document I made so far. I think it needs to be in the settings for the module and then module can label. If possible.
No need for the mixrack to tell companion what it’s doing as it’s right there Easily accessible to the user
At least that’s how I think…

That’s ok as a workaround for now, but I prefer software to be smarter than that, ideally!
Did I read your document correctly, that the L/R mute is dependent on the MixRack config? If so, then that’s a problem if I create a button to mute L/R and then use it on a MR with a different config, then it’ll be muting the wrong bus.

But that’s only 1 of the reasons that feedback is essential.

Ok cool well I’ll find the director to mixrack wireshark that shows the only interaction that happens when a command is sent

Not sure I understand what u mean?

[StuartW]

@Andy

That’s ok as a workaround for now, but I prefer software to be smarter than that, ideally!
Did I read your document correctly, that the L/R mute is dependent on the MixRack config? If so, then that’s a problem if I create a button to mute L/R and then use it on a MR with a different config, then it’ll be muting the wrong bus.

But that’s only 1 of the reasons that feedback is essential.

Not sure I understand what u mean?

All busses are one type of code that is based off the console structure
And the console doesn’t tell you what it is just that you are muting buss 10 for eg.
So it has to be a setting put in by the user
Group, Aux, Main & Matrix all use the same code
ie if my structure was 2 group, 2 aux, main LR, 0 matrix
Buss 1 code (as per doc) would mute the group
Buss 3 code (as per doc) would mute aux
Buss 5 code (as per doc) would mute main
Or
Structure 0 group, 2 aux, main LR, 2 matrix
Buss 1 code would mute aux 1
Buss 3 code would mute Main
Buss 5 code would mute Matrix

I hope that makes sense?

You are wanting feedback or the handshake that happens with a command.
So that is just a matter of wireshark director sending a command to mixrack.
Which from memory looks the same as though sending the code string from packet sender or something I’ll have another look though. I’ll send you the capture

[Andy]

@StuartW

All busses are one type of code that is based off the console structure
And the console doesn’t tell you what it is just that you are muting buss 10 for eg.
So it has to be a setting put in by the user
Group, Aux, Main & Matrix all use the same code
ie if my structure was 2 group, 2 aux, main LR, 0 matrix
Buss 1 code (as per doc) would mute the group
Buss 3 code (as per doc) would mute aux
Buss 5 code (as per doc) would mute main
Or
Structure 0 group, 2 aux, main LR, 2 matrix
Buss 1 code would mute aux 1
Buss 3 code would mute Main
Buss 5 code would mute Matrix

I hope that makes sense?

Got it. Definitely will want to see if there’s a way to capture the MixRack’s config then.

You are wanting feedback or the handshake that happens with a command.
So that is just a matter of wireshark director sending a command to mixrack.
Which from memory looks the same as though sending the code string from packet sender or something I’ll have another look though. I’ll send you the capture

Great! I haven’t figured that part out yet. I thought it was UDP handshaking but I don’t really know.

[StuartW]

@Andy

Got it. Definitely will want to see if there’s a way to capture the MixRack’s config then.

I’ll try to see if there is a way to capture that but I don’t think so. It’s entirely changeable as you go.
Easy to see what you have going on with structure using director or an actual surface. Which you kind of need to make the most of dLive.
I wouldn’t even know where to start to look for that capture. Hence why I’m thinking that one might be best as a user input setting when they add the module to companion.

Great! I haven’t figured that part out yet. I thought it was UDP handshaking but I don’t really know.

I’ll check but it seemed to be a TCP data packet with instruction then a few back and forths with TCP but no data

[Andy]

@StuartW

I’ll try to see if there is a way to capture that but I don’t think so. It’s entirely changeable as you go.
Easy to see what you have going on with structure using director or an actual surface. Which you kind of need to make the most of dLive.
I wouldn’t even know where to start to look for that capture. Hence why I’m thinking that one might be best as a user input setting when they add the module to companion.

Like I say, I can do that for now, but I probably won’t be able to sleep until it’s automated! :sad11:

I’ll check but it seemed to be a TCP data packet with instruction then a few back and forths with TCP but no data

A&H didn’t make this easy, unfortunately!
I’m not really jazzed on creating a module that doesn’t have feedback.

[lightingman117]

I’ve been playing with this since you gave me the TCP Communicator, thanks Andy!
I haven’t been able to get TCP Communicator to receive reply’s back from the mixrack on the same open socket/connection besides ‘ACK’ (required for TCP).

Mixrack always updates all instances of surfaces/directors/IP8’s connected to it though.

I’m not sure if a socket can be listened to on two different programs. It seems the same process UID is necessary (to protect open sockets), but that can never happen as director & companion/TCP listener are separate programs.
https://stackoverflow.com/questions/45952956/tcp-open-socket-from-port-thats-already-used-for-listening
I am currently trying to test this, haven’t found a program that can open the already open socket from director (randomized on connection).

I think the only remaining option is to emulate a ‘director connection’ to mixrack so that mixrack always sends feedback commands to the ‘fake director’ (companion).
The way I see that happening is to get whatever TCP commands director sends to mixrack on first connection via wireshark.
Mixrack will then send a complete ‘current state’ to Director which will then update itself accordingly to match the mixrack config.
This is where you could get the initial current state in companion; parsing all that data will be a ton of monkey work though.

Once connected to eachother mixrack Director sends a pretty simple 1second heartbeat to the mixrack via UDP on port 51320 sourced in the 40k range with data: e0 00 01 03 e7
all other udp data is multicast discovery & mixrack sending non-critical (meters) updates to director via UDP

I think the next step is capturing the director > mixrack handshake and see if we can emulate that in a program to see if mixrack will send updates to our ‘listening program’ when another director (or a TCP command) communicates with mixrack.

Andy I can work on this program, but it’ll take me a few days as i’m slow. You’re probably super fast to do it.
Is there anything that I can get you that will help with this endeavor (provided you think it is an appropriate path forward).

[Andy]

@lightingman117

I’ve been playing with this since you gave me the TCP Communicator, thanks Andy!
I haven’t been able to get TCP Communicator to receive reply’s back from the mixrack on the same open socket/connection besides ‘ACK’ (required for TCP).

Mixrack always updates all instances of surfaces/directors/IP8’s connected to it though.

Thats as far as I got as well.

I’m not sure if a socket can be listened to on two different programs. It seems the same process UID is necessary (to protect open sockets), but that can never happen as director & companion/TCP listener are separate programs.
networking - TCP open socket from port that's already used for listening - Stack Overflow
I am currently trying to test this, haven’t found a program that can open the already open socket from director (randomized on connection).

Isn’t that what wire shark does?

I think the only remaining option is to emulate a ‘director connection’ to mixrack so that mixrack always sends feedback commands to the ‘fake director’ (companion).
The way I see that happening is to get whatever TCP commands director sends to mixrack on first connection via wireshark.
Mixrack will then send a complete ‘current state’ to Director which will then update itself accordingly to match the mixrack config.
This is where you could get the initial current state in companion; parsing all that data will be a ton of monkey work though.

Not a problem, just need to know how to get the communication started. I can take it from there.

Once connected to eachother mixrack Director sends a pretty simple 1second heartbeat to the mixrack via UDP on port 51320 sourced in the 40k range with data: e0 00 01 03 e7
all other udp data is multicast discovery & mixrack sending non-critical (meters) updates to director via UDP

I saw that, thank you for confirming.

I think the next step is capturing the director > mixrack handshake and see if we can emulate that in a program to see if mixrack will send updates to our ‘listening program’ when another director (or a TCP command) communicates with mixrack.

Word.

Andy I can work on this program, but it’ll take me a few days as i’m slow. You’re probably super fast to do it.
Is there anything that I can get you that will help with this endeavor (provided you think it is an appropriate path forward).

What program?

[lightingman117]

@Andy

Isn’t that what wire shark does?

My understanding is that wireshark installs a npcap driver to the network device and thus the kernel writes to that both the interface driver and the wireshark npcap driver at the same time for any network traffic it needs to send/receive. Thus no it isn’t the same and I doubt you want people to be installing npcap drivers on computers to run companion.

@Andy

Not a problem, just need to know how to get the communication started. I can take it from there.

I saw that, thank you for confirming.

Word.

What program?

A program that is just a fake shell of director.

just enough so we can listen on a port for any commands mixrack wants to update everyone else with and we can send commands to mixrack via that socket connection.

shell - tcp > mixrack - “hi i’m here” (random port) (51321)
mixrack - “great, show me yours i’ll show you mine”
shell - “i’m director v1.85, my ID is 0f 95 xyz”
mixrack - “awesome, we’re compatible, i’ma send you a ton of stuff”
mixrack - “data, data, data dump”
shell - udp > mixrack - “hi i’m still here” (1s intervals 51320)
mixrack - “I done sending you stuff”
shell - “yep, i’ll be quiet unless i want to do stuff”
mixrack - “sure, thing; i’ll keep you updated”
shell - “i’ll listen on our connection for any updates” (random port)

Here’s the main packets that start everything off

director > mixrack - conversation start
0000 f0 00 01 00 00 5c 31 00 04 00 16 44 52 20 42 6f …\1…DR Bo
0010 78 20 49 64 65 6e 74 69 66 69 63 61 74 69 6f 6e x Identification
0020 00 f7 e0 00 04 01 03 d3 95 e7 …

mixrack > director - conversation reply
0000 f0 00 01 5c 31 00 06 00 02 00 24 54 4c 44 44 4d …\1…$TLDDM
0010 43 33 32 53 74 61 67 65 62 6f 78 20 56 31 2e 38 C32Stagebox V1.8
0020 35 20 2d 20 52 65 76 2e 20 35 36 34 38 31 00 f7 5 - Rev. 56481…

---

this whole conversation takes place over 30s or so
I wouldn’t be surprised if we could do it with just the starting bit of info that director sends to mixrack and then the udp heartbeat.
i’m following the tcp stream and will make the file downloadable once it complies (taking forever).

[StuartW]

Looks like y’all have the capture under control! And don’t need me for that now which is great as I don’t really know what I’m doingbthere.
I can get the instructional data but that’s my knowledge.

If you can work out how to automate console structure then amazing!! Unsure if possible but y’all are the wizards!
My thought process was that it isn’t necessary as the people who will use this are going to have show files made before they go and add extra functions

[Andy]

@lightingman117

My understanding is that wireshark installs a npcap driver to the network device and thus the kernel writes to that both the interface driver and the wireshark npcap driver at the same time for any network traffic it needs to send/receive. Thus no it isn’t the same and I doubt you want people to be installing npcap drivers on computers to run companion.

Ah, you’re still thinking of the scenario where the SD is used in conjunction with Director. I would rather not limit it to just that if at all possible. I would prefer to have it work as a separate “director lite” so Director is not needed.

A program that is just a fake shell of director.

just enough so we can listen on a port for any commands mixrack wants to update everyone else with and we can send commands to mixrack via that socket connection.

Ah, I can automate that with my TCP Communicator program for testing, but then once communication is confirmed, it’ll be done within the module.

Here’s the main packets that start everything off

director > mixrack - conversation start
0000 f0 00 01 00 00 5c 31 00 04 00 16 44 52 20 42 6f …\1…DR Bo
0010 78 20 49 64 65 6e 74 69 66 69 63 61 74 69 6f 6e x Identification
0020 00 f7 e0 00 04 01 03 d3 95 e7 …

mixrack > director - conversation reply
0000 f0 00 01 5c 31 00 06 00 02 00 24 54 4c 44 44 4d …\1…$TLDDM
0010 43 33 32 53 74 61 67 65 62 6f 78 20 56 31 2e 38 C32Stagebox V1.8
0020 35 20 2d 20 52 65 76 2e 20 35 36 34 38 31 00 f7 5 - Rev. 56481…

---

this whole conversation takes place over 30s or so
I wouldn’t be surprised if we could do it with just the starting bit of info that director sends to mixrack and then the udp heartbeat.
i’m following the tcp stream and will make the file downloadable once it complies (taking forever).

I feel pretty confident that not everything will be necessary, so it doesn’t matter if there’s a bunch of irrelevant info, I can just filter out what’s needed.