IBM BSC CRC?

[Peter Coghlan]

Mattis Lind wrote:
>
> 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_System_41_Reference_Manual_IBM3270_Emulation.pdf
> 
> 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_Control_Unit_Description_and_Programmers_Guide_Jan84.pdf
> 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.
>

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.)

>
> > >
> > > 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
>
>
> 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]

>
> 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.