[HECnet] Thousands of DECnet errors on Tops-20

[Johnny Billquist]

On 2021-01-21 02:37, Paul Koning wrote:
> 
> 
>> On Jan 20, 2021, at 5:54 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> Hey, speaking of this...
>>
>> I decided to go and check how RSX actually works. And that have led to some interesting observations on my side.
>>
>> 1. RSX actually do respect the maximum data layer block size the other end sends in its init message. So even if I have a large size defined in RSX, it should be working correct against another end with a smaller block size.
> 
> Yes, and that behavior is exactly what the spec intended.

Right. All good. I previously was wondering if RSX might just use the 
own buffer size, which would then be the reason it fails to talk to that 
VMS V5.4 node, but this is not the case...

>> 2. With a block size of 576 (either local or remote), the actual packets being sent are 578 bytes. Seems there is a 2 byte checksum that is in addition to the actual payload. I found this a bit surprising, but it seems this might be very intentional. So I'm trying to see if this also is true for other systems. If someone else can do some checking that would also be interesting.
> 
> You mean the routing messages?  Yes, they end in a 2 byte checksum, but that is part of the message and is required to be included in the size limit.  If an implementation is told block size 576 and it sends 578 byte routing messages, that's a bug.  Apparently one it gets away with, but it's not supposed to do that.

Yeah. Got it sorted now. I misunderstood the code the first time.

> Is this on Multinet?  I would expect this sort of thing to be caught on DDCMP.  For example, DECnet/E allocates DMC buffers of the precise size you ask for, so if you were to send it a routing message 2 bytes longer than expected, DDCMP would reject it as an oversized packet and the link would go down due to excessive retransmits.

Well, now we need to clarify what we mean by 576 or 578 byte messages.
The 576 is what is reported in the init message, and is what the each 
node knows the other accept. 578 is the number of bytes in the payload 
on the wire.
And in this case, the wire is ethernet. So essentially what tcpdump reports.
So, in the DECnet sense, it's still 576 bytes. But then you have those 
two extra bytes at the start, making it 578.
And of course, any ethernet driver actually need to read 578 bytes, in 
order to get the 576 bytes at the DECnet link layer.

>> 3. VMS V5.4 seem to not be happy at all if the other end declares a largee maximum data layer block size that the local one. This is the problem I had when talking to a VAX at Peter, which is running V5.4. I have no idea if that problems is still there in V7...
> 
> That's ugly and a definite bug.

I agree. I would really like to investigate things more here.
I struggled a lot with this, and only when I put RSX to use 576 byte 
buffer size did I finally manage to establish a link up.
But looking at the packets, everything seems to be just as expected even 
when I set RSX to use 1500 bytes, but VMS just refuse to accept the link 
then. And the only difference is just that one field in the init message 
that declares the buffer size of the node.
I tried a lot of different values between 576 and 1500. Nothing above 
576 works.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol