I've encountered a problem with a hardware vendor that has created their
own "transmission control protocol".
During a hardware test on 3 June 2003 they were using standard TCP
packets and I was able to capture and analyze them using ethereal. In a
subsequent test on 11 July 2003 ethereal was unable to capture any TCP
frames containing data. Ethereal was working for UDP, ARP, etc frames
which were also being transmitted. The TCP frames containing critical
data had disappeared. An oscilloscope connected to the network showed
that transmissions were still present that ethereal was not capturing.
Also, the data from the remote instruments was being transmitted to the
host computer.
I found out that the hardware/software vendor had "upgraded" the host
computer software and remote controller firmware the week of 30 June
2003.
Since I was able to capture and analyze the data previously, but am
unable to do so after the "upgrade" I have concluded that the vendor has
decided to quit using TCP or any other known protocol at that level and
has, instead, substituted their own "proprietary" protocol. This is a
cheap sales tactic that prevents competitors from supplying
interoperable hardware or software.
I'm now stuck with trying to analyze what they changed. The data link
layer is still Ethernet (IEEE 802.3). Can ethereal be used to capture
and display the Ethernet frames as is or will it require modification?
If modification is required is there any documentation overview
available or will I need to reverse engineer the entire source code?
I'd appreciate any assistance I can get with this problem.
--
Mike Stickney <mstickney@xxxxxxxxxxxxxx>