SDLC - How to write a C program to communicate on SDLC
Reuben Pilli
kind soul. Can anyone help please.
Calling all experts:
I have a unique problem on hand. I need to write a C application on Unix box
to talk to a Security Cryptographic Device (Atalla 6000) attached to a Unix
Box. This Device is made by a Tandem Company and talks on SDLC protocol.
This device comes with a Low-Level Protocol Handler (which handles SDLC) and
an Application Interface Module (which interfaces with the application on
one side and the Protocol Handler on the other) for only Tandem machines but
not for Unix boxes.Odd, but that's how Tandem company works.
My problem is how can I write a C program to connect to this device and send
a command to it. Because my system is a Unix system, I do not have the
benefit of any of these software interfaces. What is the approach I have to
take. Do I have to write a Protocol Handler/ Device Driver to do this? Do I
need to learn SDLC protocol first? I just need to open the device, send a
command and receive the response. How do I do this? The Device Programming
Manual states that much only. To be more specific, it states: "Your
application issues a WRITEREAD to the security processor by means of host
computer's I/O process". I don't know where to start or where to look for
help.
Can any one throw some pointers to me please. Any help in any form will be
highly appreciated.
Thanks in advance
Reuben
Tauno Voipio
"Reuben Pilli" <reuben...@ncr.com> wrote in message
news:3aafd070$1...@rpc1284.daytonoh.ncr.com...
SDLC is IBM's version of the ISO standard HDLC bit-oriented protocol. There
is an ISO standard called 'High-Level Data Link Control' explaining the
protocol.
The main problem is that the protocol works by inserting extra bits in the
message transferred. It also has no start or stop bits required by the
standard serial interfaces on PC: the COM ports cannot talk SDLC/HDLC. The
transmission is packet-oriented, the packets are called frames. The packets
contain CRC checksums at the end. The CRC calculation is done after the
bit-stuffing. All this means in practice that you need a special interface
card for SDLC / HDLC.
Yes, all protocol handling from the special card device driver up has to be
provided somehow.
The manual's information is insufficient to write the application, if it
does not state the bit layout of the necessary message packets.
Tauno Voipio
tauno voipio @ iki fi
David Empson
> I have a unique problem on hand. I need to write a C application on Unix box
> to talk to a Security Cryptographic Device (Atalla 6000) attached to a Unix
> Box. This Device is made by a Tandem Company and talks on SDLC protocol.
This is sounding a bit tricky.
The big problem: SDLC is a bit-synchronous protocol. If your host
computer's serial hardware only supports asynchronous communication,
then you cannot connect directly to a device which expects SDLC.
What type of Unix box are you using?
(I may not be able to help much with the Unix specifics, but this may
assist others in providing more detailed help.)
For example, the standard serial ports on the IBM PC and all derived
machines do not support SDLC, so if you are running some flavour of
PC-based Unix (including Linux), you will need some special serial
hardware and a driver which supports it.
> This device comes with a Low-Level Protocol Handler (which handles SDLC) and
> an Application Interface Module (which interfaces with the application on
> one side and the Protocol Handler on the other) for only Tandem machines but
> not for Unix boxes.Odd, but that's how Tandem company works.
If the "Low level protocol handler" is a hardware device which connects
to the Atalla 6000 on one side and the Tandem machine on the other side,
then it is quite possible that its only purpose is to convert between
SDLC and asynchronous data, and it could be used with a different host
machine, as long as you can find out the necessary protocol details.
On the other hand, if the "Low level protocol handler" is a piece of
software, then the Tandem machine must have special serial hardware with
direct support for SDLC. You would need corresponding serial hardware
in your machine (or an external converter) before you could connect to
the Atalla 6000 at all.
> My problem is how can I write a C program to connect to this device and send
> a command to it. Because my system is a Unix system, I do not have the
> benefit of any of these software interfaces. What is the approach I have to
> take. Do I have to write a Protocol Handler/ Device Driver to do this? Do I
> need to learn SDLC protocol first?
The extent to which the device complies with SDLC is an issue.
There are two main parts to SDLC: the framing structure (including the
error detection mechanism, though some derived protocols change this),
and the content of the frame (address, control, and information fields).
If a reasonably full subset of SDLC is used, then the address and
control fields can be used to allow communication between a primary
station and one or more secondary stations, with reliable and ordered
delivery of data (retrying lost messages, etc.) The information content
of the frame is not defined by SDLC: it is the responsibility of a
higher level protocol.
On the other hand, they might have just used the framing structure of
SDLC, in which case the frame content is entirely defined by the higher
level protocol.
If you need to access the device at this level, you will definitely need
more information about exactly what parts of SDLC apply.
> I just need to open the device, send a command and receive the response.
> How do I do this? The Device Programming Manual states that much only.
> To be more specific, it states: "Your application issues a WRITEREAD to
> the security processor by means of host computer's I/O process". I don't
> know where to start or where to look for help.
Assuming the hardware compatibility issue can be solved, you should be
able to write a C application on a Unix system which opens the device
driver for the serial port, uses some ioctl() calls to configure it as
appropriate, and then uses read() and write() calls to transfer data.
(I've never done any low-level serial port access on a Unix system, so
I'm not entirely clear on what facilities are available.) You might
need special privileges to be able to open the serial driver.
The data transferred would be the content of the SDLC frame, but some
mechanism would be needed to define frame boundaries. Depending on the
capabilities of your hardware, you might also need to implement the
error detection protocol (a 16-bit CRC calculation) in your application.
You would need to consult the protocol documentation for this device in
order to determine the data which needs to go in the frames.
Simon Bowring
>You would need to consult the protocol documentation for this device in
>order to determine the data which needs to go in the frames.
David's answer is very full and accurate IMHO!
The only thing missing is where to get the SDLC spec from (not easy!)
It's too old to be available in electronic formats, but can be bought
(for under UKP 2) from IBM. The IBM document number is "GA27-3093-04"
and is entitled "IBM Synchronous Data Link Concepts Specification"
Search for it and order from:
http://www.elink.ibmlink.ibm.com/public/applications/pbl/cgibin/pbl.cgi
IBM *may* also still make (PCI?) SDLC h/w for some Unix boxes (possibly
AIX only)
Simon Bowring
Simon Bowring
>SDLC is IBM's version of the ISO standard HDLC bit-oriented protocol. There
>is an ISO standard called 'High-Level Data Link Control' explaining the
>protocol.
I thought SDLC was a different (though similar) beast to HDLC, can you
support your claim that HDLC == SDLC?
Regards
Simon Bowring
Blakely LaCroix
<sbowrin...@mpc-data.co.uk> writes:
>>SDLC is IBM's version of the ISO standard HDLC bit-oriented protocol. There
>>is an ISO standard called 'High-Level Data Link Control' explaining the
>>protocol.
SDLC was IBM's creation. Years later, part of SDLC became the basis for the
ISO standard HDLC. At the 8 bit framing level, they are nearly the same. HDLC
added a mechanism for address extensions and dropped SDLC's "Loop" mode.
IMHO, I regard SDLC as one of the better ideas of the last century.
Blakely LaCroix
Minneapolis, Minnesota, USA.
RBP Clique member # 86.
The best adventure is yet to come.
Anton Erasmus
Hi,
Get a serial card that uses the Z85230. This is quite an old device
that supports HDLC/SDLC. You still need to do quite a few things in
software though. If you can get a card with the Zilog Z16C30 then it
will be very easy to write the software. This device does almost all
of the HDLC/SDLC protocol in hardware. It keeps track of the frame
length etc. in hardware.
Regards
Anton
K Simons
blackbox makes converters and other interface devices.
Reuben Pilli <reuben...@ncr.com> wrote in message
news:3aafd070$1...@rpc1284.daytonoh.ncr.com...
DUBOSSE Thierry
K Simons a écrit :
>
> check is blackbox has a protocol converter, that may solve you problem.
> blackbox makes converters and other interface devices.
They don't make, they just sold. ;-)
Thierry.
--
Regards.
Equip'Trans
http://www.equiptrans.com/
Reuben Pilli
I have additional information on this. I managed to get a Digi Sync/570i
expansion board installed and the Security device is now connected to it.
The software that came with it is a HDLC protocol driver (data link service
provider that supports SDLC, LAPB and HDLC ). This driver is dependent on
another software, Sync/570i Device Driver which is a physical level service
provider which also came with the hardware. That much I could glean from the
few pages (they call it Users Manual!) that came with the card. Both drivers
are installed on the system.
Can anyone throw any light on how I can communicate using these drivers. I
need to open the device and "WRITEREAD". Yes, the security device manual
says that the device does not support a WRITE followed by a READ as separate
commands; only the WRITEREAD.
I will be much obliged if anyone can point me in the right direction.
Thanks in advance
Reuben
"Anton Erasmus" <ant...@intekom.co.za> wrote in message
news:3ab7a542...@news.saix.net...