27 Jan
2020
27 Jan
'20
4:24 a.m.
Mattis Lind wrote:
Ignore the bcb stuff - this is part of RJE/NJE protocol. (It is a bit strange
that it is included in the same file as the crc code despite belonging to a
quite different protocol layer.)
Absolutely right!
I'm a bit puzzled by the ACK0 appearing inside an (apparantly non-transparant)
text block and not having a DLE ahead of it but I am not really sure if this
would be a problem. Most of the rest of the data looks very plausable with
SYN, SOH, STX and ETX appearing in the expected places. However, if there
could be a subtle error in the hardware being used to read the data, getting
just one bit wrong would throw the crc right off. Maybe the terminal manual
contains enough information to confirm or deny whether the poll responses are
exactly as expected or not?
[snip]
Hello Peter!
Thanks for the effort to help!
I maybe should elaborate a bit on what I am doing and what equipment is
involved. The sending equipment is a Alfaskop CPR4101 communication
processor. Basically IBM 3274 model C BSC compatible. There is some
description on how it communicates using BSC from page 89 and onwards in
this pdf:
http://storage.datormuseum.se/u/96935524/Datormusuem/Alfaskop/Alfaskop_Syst…
Essentially what is written there is very similar to what IBM has written
in
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/3274/GA23-0061-1_3274_…
on
page 159 and onwards.
I was hoping it was an RJE or NJE implementation rather than a terminal
as I am more familiar with that side of things and I would have a good
chance of being able to recognise valid data from invalid data.
[snip]
In the file bcb_crc.c supplied with the funetnje and HUJI-NJE packages, it
says the following (which may or may not relate to CRCs in the BSC world):
Thanks! Interesting. Checked this CRC generator and it creates exactly the
same CRC bytes compared to the other CRC implementations I have found
around on the net. But not matching the bytes received.
| The generating polynomial is X^16+X^15+X^2+1
(CRC-16). When computing
the
| CRC, DLE's are not computed (except from a second DLE in a sequence of
| 2 DLE's). Furthermore, the first DLE+ETB which starts a text block is
| not computed also.
There is also some code for checking CRCs, however, it is not clear to me
if this code is for use with BSC lines or with DECnet lines.
Cannot really understand what bcb is and what has to do with it. Is the
protocol some kind of BSC derivative with extra features. Don't really
understand it when glancing quickly through the code.
I have two actual messages from equipment employing IBM BSC:
32016CD90240404070032688
and
32016CD90240C84050030D28
These appear to be something like:
SYN SOH '%' 'R' STX SP SP SP ACK0 ETX followed by CRC-16
and
SYN SOH '%' 'R' STX SP 'H' SP '&' ETX followed by
CRC-16
One of my concerns is my complete inability to get the same CRC digits from
crc reveng compared with the three C crc algorithms I found on the
internet. I just have to do something wrong when fiddling with the options.
But what? I think I have tried bit order, inverting the bits etc. But still
nothing.
Are there any crc reveng experts out there??
Hopefully someone else can help with this.
Regards,
Peter Coghlan.