Tunneled Network data and 237 byte frames

[Selemba1000]

I have recently acquired a ILive System and have also captured some of the traffic between the devices.
As a result of that I was able to figure out the format of the tunneled network data.

During that i also found a new phenomenon not documented here before:
My system usually sends packets of 237 bytes, with two bytes of FCS appended. I'm still unsure why exactly this happens. Interestingly both the surface and the mixrack omit those two bytes on every fourth packet they send for some amount of time. Only one of the devices will display this behavior at any given time, and the periodically switch wich one does it.
If anyone has ideas as to why or what that is, might be interesting to figure out.

In any case the updated documentation for tunneled network data, for anyone still interested in these systems, can be found here: Selemba1000@b6d4699

[PatrLind]

Nice, if you want to make a pull request, go ahead and I can merge the updated documentation

[Selemba1000]

Just added the PR #4 . It's still not done and i will probably try to uncover some more. But strictly considering ace, as far as i understand only the details of how the devices sync up are still unknown.

Also something interesting i uncovered is that the dSnake protocol is mostly compatible to ace, and therefore modern SLink devices can exchange audio with the iLive. Only sync and of course control doesn't work.

Maybe I will also take a closer look at AHnet to understand the controlling, we will see what comes of it.

[Selemba1000]

And as a side note the iLive consoles usually only use the lower 32 channels to communicate data between surface and mixrack, with only PAFL related stuff on channels 63-64. On the iLive T112 specifically the lower 12 channels of audio are just the back IO ports in order. And main seems to start at channel 25.