Well yes, but I’ll always consider all options and pursue the one that makes sense according to the data. And i’m a very small step kinda person.
First step to me is make it work (just one or two commands with feedback) while mixrack is talking to director (intercept the return packets on the same port).
Then make it work without director. ‘why develop something without testing it will work’
But I see the other POV as well; ‘why develop something that we don’t want’.
I figured you could, and over time you could use the send/receive commands to decipher the ‘starting config’ of the mixrack that is sent upon connection to the ‘fake director’
Anyways, the TCP stream is still being created, i don’t know why the tcp follow command takes forever in wireshark its only around 100mb worth of data. Hopefully done by morning and I’ll post a link.
It’s important to think about all uses when building something so you don’t accidentally limit the possibilities. However, anything that gets us going in the right direction is going to be helpful. We’re just doing detective work ATM.
Anyways, the TCP stream is still being created, i don’t know why the tcp follow command takes forever in wireshark its only around 100mb worth of data. Hopefully done by morning and I’ll post a link.
I’ll just keep working at the list of instruction code then when I get a minute or two.
Also when are you doing this packet collect? If I ever use wireshark on the dLive network I get like 5k bits of thing in less than a minute I think? Let me look at that I might get a min today