[HECnet] Thousands of DECnet errors on Tops-20

[Thomas DeBellis]

I think I may have finally gotten to the bottom of this.  It's a level 1 
routing message that I'm getting from 2.1023 (A2RTR) that does not 
appear to be respecting lengths, viz:

*22:04:30*.749823 aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN 
(0x6003), length *1478*: lev-1-routing src 2.1023 {ids 0-726 cost 0 hops 0

This is two (2) bytes over the maximum that Tops-20 can accept.

    NCP>*SHOW LINE NI-0 CHARACTERISTICS *
    NCP>
    22:16:04     NCP

    Request # 23; Show Line Characteristics Completed

    Line = NI-0

       Receive Buffers = 6
       Controller = Normal
       Protocol = Ethernet
       Hardware Address = 00 1F 16 EC CE 47
       Receive buffer size = *1476*

It would appear that the 20's are advertising this length in their layer 
1 hello messages:

22:04:21.018507 aa:00:04:00:0a:0a > ab:00:00:03:00:00, ethertype DN 
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.522 
blksize *1476* pri 5 hello 15
22:04:21.082680 aa:00:04:00:08:0a > ab:00:00:03:00:00, ethertype DN 
(0x6003), length 60: router-hello l1rout vers 2 eco 0 ueco 0 src 2.520 
blksize *1476* pri 5 hello 15

About two seconds after the message comes in from A2RTR, the following 
appears in the error log:

    ***********************************************
    DECNET ENTRY
      LOGGED ON 17-Jan-2021 *22:04:32*-EST MONITOR UPTIME WAS 1 day(s)
    1:17:54
             DETECTED ON SYSTEM # 3691.
             RECORD SEQUENCE NUMBER: 70952.
    ***********************************************
    DECNET Event type 5.15, Receive failed
     From node 2.520 (TOMMYT), occurred 17-JAN-2021 22:04:08

       Line NI-0-0

       Failure reason = Frame too long
       Ethernet header = AB 00 00 03 00 00 / AA 00 04 00 0A 0A

So... no way I can get around this without some /serious/ hacking of 
DNADLL and ROUTER (see below), which would probably take me a few months 
to learn and debug.  Of course, then maybe I could put level 2 routing 
into Tops-20, which I been daydreaming about...

Paul, what does this suggest to you?

> ------------------------------------------------------------------------
> On 1/17/21 7:39 PM, Johnny Billquist wrote:
>> ------------------------------------------------------------------------
>> On 2021-01-18 00:17, Thomas DeBellis wrote:
>>
>> Well, the frames certainly won't be larger than 1,500 bytes, right?  
>> So I'm guessing they'll be the maximum.  Problem is, all of that 
>> stuff is hidden under several layers of drivers, so I'm not sure how 
>> I'm going to get the overage passed back.  And I also need to put in 
>> some BUGINF logic to alert if I get more of these than whatever I 
>> decide the interval to be.
> That depends on what they count. Like I said - ethernet payload is 
> 1500. Then you have the ethernet headers which is 14 bytes, plus the 
> crc trailer, which is 4 bytes. If you count them, you end up at 1518 
> bytes.
> Depends on the hardware I guess.   I have no idea what the NIA-20 expose.

I meant the maximum frame size; I suspect this is 1500 for the NI, but I 
don't actually know.  My speculation is that DECnet is using part of the 
buffer to piggy back node and and other information into it instead of 
holding this meta-data, separately.  I don't know what Multinet does, 
but there you can configure the NI to have a packet size of 1500.

>> If you are a DDP (LD.DDP), then you are not CPU dependent and you go 
>> ahead always, otherwise, you have to be on the CPU that owns the 
>> device (.CPCPN) So I'm not sure if it makes any difference, but DDP 
>> is not CPU dependent; not sure if that is a synonym for 'shared'.  If 
>> I stumble over something more, I'll report it.
> It's actually the same in RSX. The DDCMP layer is sort of between the 
> hardware driver and the higher level protocols, and it's not tied to 
> any specific CPU.
>
> But that code would suggest that LD.DDP is just an indication of 
> whether something is CPU dependent or not, and would have anything to 
> do with DDCMP.
 From looking at the routing code, seems LD.DDP is used when something 
is getting handed to the NSP to play with, I guess that would be goig 
through some kind of layering.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20210117/1ca312fd/attachment.htm>