Messages in this thread | | | Date | Fri, 12 Nov 1999 18:33:10 +0000 (GMT) | From | Riley Williams <> | Subject | [OT] Reverse Engineering |
| |
Hi there.
Probably at least partly off topic here, but...
A friend of mine will shortly be working on a driver for Linux for some rather specialised hardware that connects via the serial port. He doesn't have any technical specs for it, nor does there appear to be any chance of him getting any. What he does have is one sample of the said hardware, together with the official cable to connect it to a standard serial port, and the Windows 95 driver for it.
The driver apparently takes over control of the relevant serial port, and then produces a virtual serial port that a normal terminal program can connect to and use to control the hardware. However, the actual handshake over the serial line is a complete mystery, and attempts to monitor it via various freely available RS232 snooper programs that run under Win95 have so far only succeeded in causing Win95 to BSOD a few times more than it would otherwise have done.
Michael does have a second computer running Linux, as well as the primary one that dual-boots Linux and Win95, and the suggestion has been made that some sort of snooping by having the second machine monitor the actual serial link would be the next stage.
The basic options I can see are as follows:
1. Have a serial lead from the Win95 machine to the Linux machine, with the modem plugged into a second serial port on the Linux machine, and a program thereon that literally copies everything between the two ports, but saving copies in files as well.
The basic problem I can see with this approach is that if there are any timing dependancies in the handshake, they could easily be violated as a result of the latency involved.
2. Have a special lead made up, consisting basically of a serial extension lead with an additional lead wired in parallel and connecting to the PARALLEL port on the Linux machine, wired such that Gnd on the serial connects to Gnd on the parallel, and the other 8 wires on the serial each connect to one of the eight data wires on the parallel. The Linux machine would then run a program which just took a snapshot of the parallel port every X microseconds and filed this on the hard drive somewhere, repeating this for as long as necessary.
This approach has the following obvious advantages:
1. As long as the sample rate exceeds twice the baud rate of the serial link, it is guaranteed to capture the entire handshake and all data transferred.
2. If there are nay timing constraints in the handshake, they will not be violated as the handshake between the Win95 box and the hardware is not being changed.
The following obvious disadvantages are also apparent:
1. The interval timing on the Linux box will need to be very accurate. As the maximum Baud rate of a standard serial port is 115,200 Baud, a frequency of 333k samples every second, giving an inter-sample period of 3 microseconds, is to be recommended. This also allows leeway for the interval to drift slightly and still obtain sufficient readings to positively identify the transitions.
The basic question is whether such is realisable on the Linux box in question, which is based on a 486dx4/75 processor.
2. To avoid problems connected with hard drive latency in write operations, the system will probably need to buffer the handshake session to RAM, with as large a buffer as possible. The available system only has 32M of RAM, so the maximum buffer size is likely to be around 20M, or around a minute's worth of handshake. Is this enough?
Since I have probably omitted some really obvious means of doing this, can anybody with any experience in this field please advise on their recommendations?
I will note in advance that the available finance will NOT run to the purchase of anything beyond basic test gear, so suggestions relating to obtaining a digital signal analyser can be left unsaid...
Finally, Michael isn't currently on L-K so if any replies can be cc'd to him, it would be appreciated. I don't mind whether the replies are on L-K or private to Michael and me as I am on L-K.
Best wishes from Riley.
PS: The kernel versions page is now back online at the URL below, and includes separate sublists both for each kernel series, and for each year of development.
+----------------------------------------------------------------------+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this XXXX feature, but I bet someone | | else has already done so and is just about to release their patch. | +----------------------------------------------------------------------+ * http://www.memalpha.cx/Linux/Kernel/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |