[mdlug] Reverse-engineering data protocols

[David McMillan]

On 3/1/2011 1:07 PM, Jeff Hanson wrote:
> On Tue, Mar 1, 2011 at 12:51 PM, David McMillan<skyefire at skyefire.org>  wrote:
> What is the part number of the sensor and who made it?  Is it some
> custom design for your company?
     It's essentially custom.  It's actually a firmware-based system 
running on an industrial robot (running a version of VxWorks, in fact), 
but that end of the chain is inaccessible.  It's a giant black box, for 
one thing, and a collection of human safety-critical systems to boot, so 
hacking away at it is a no-go under the circumstances.
>     I'm *pretty* certain that this data isn't enciphered to prevent
>> third-party access, but it's not plaintext being pushed through a
>> Telnet-esque connection either.  So I'm a bit stuck.
>>
> It could be compressed, raw data, multiplexed from multiple sensors,
> or a serial or time stamped stream.
     Time stamped, definitely.  Just what data is sent is actually 
configurable from the source "client".  When I tell the "server" 
software to export-to-textfile, what I get is a tab-separated set of 
columns.  Every other column, starting with the first, is a timestamp in 
milliseconds, serving as a time index for the data in the same row in 
the next column to the right.  One of the things I don't know is whether 
all these time-stamp columns are sent from the source, or if only one 
timestamp is sent (all the data is 100% synchronous) and the server 
software's Export function generates the multiple timestamp columns.
>> logged data is to detect first the port opening, followed by a halt to
>> port activity.  Which I haven't been able to figure out a way to do
>> under WinXP.
>>
> You can poll with netstat but that may have too much latency to
> activate a script on time.
>
> I'm not a software engineer but I do work on automotive-related test systems.
     That was actually one of the first things I tried, but I didn't get 
anywhere.  I could detect the port's Open/Closed/Listening status using 
netstat, but a few weeks of googling and poking about in my spare time 
hasn't turned up a way to use netstat to detect the "busyness" of the port.
     Going by my wireshark captures, all activity on the port stops as 
soon as the "client" stops sending data, but the port remains open 
indefinitely.  The act of closing the port causes the server to clear 
its buffers.  That, and what looks like an initial startup handshake, is 
all the communication there is between the client and server, AFAICT -- 
it's very bare-bones.  This software was really intended as a 
troubleshooting and setup tool, not for R&D work with flots and flots of 
repetitive testing.