<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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:</p>
<p><tt><b><font color="green">22:04:30</font></b>.749823
aa:00:04:00:ff:0b > ab:00:00:03:00:00, ethertype DN (0x6003),
length <font color="purple"><b>1478</b></font>: lev-1-routing
src 2.1023 {ids 0-726 cost 0 hops 0</tt><br>
</p>
<div class="moz-cite-prefix">This is two (2) bytes over the maximum
that Tops-20 can accept.<br>
</div>
<blockquote>
<div class="moz-cite-prefix">NCP><b>SHOW LINE NI-0
CHARACTERISTICS </b><br>
NCP><br>
22:16:04 NCP<br>
<br>
Request # 23; Show Line Characteristics Completed<br>
<br>
Line = NI-0<br>
<br>
Receive Buffers = 6<br>
Controller = Normal<br>
Protocol = Ethernet<br>
Hardware Address = 00 1F 16 EC CE 47<br>
Receive buffer size = <font size="+1" color="purple"><b>1476</b></font><br>
</div>
</blockquote>
<p>It would appear that the 20's are advertising this length in
their layer 1 hello messages:</p>
<p><tt>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 <font color="purple"><b>1476</b></font>
pri 5 hello 15</tt><tt><br>
</tt><tt>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 </tt><tt><tt><font color="purple"><b>1476</b></font></tt>
pri 5 hello 15</tt><br>
</p>
<p>About two seconds after the message comes in from A2RTR, the
following appears in the error log:</p>
<blockquote>
<p><font size="+1"><tt>***********************************************</tt><tt><br>
</tt><tt>DECNET ENTRY</tt><tt><br>
</tt><tt> LOGGED ON 17-Jan-2021 <font color="green"><b>22:04:32</b></font>-EST
MONITOR UPTIME WAS 1 day(s) 1:17:54</tt><tt><br>
</tt><tt> DETECTED ON SYSTEM # 3691.</tt><tt><br>
</tt><tt> RECORD SEQUENCE NUMBER: 70952.</tt><tt><br>
</tt><tt>***********************************************</tt><tt><br>
</tt><tt>DECNET Event type 5.15, Receive failed</tt><tt><br>
</tt><tt>From node 2.520 (TOMMYT), occurred 17-JAN-2021
22:04:08</tt><tt><br>
</tt><tt><br>
</tt><tt> Line NI-0-0</tt><tt><br>
</tt><tt><br>
</tt><tt> Failure reason = Frame too long</tt><tt><br>
</tt><tt> Ethernet header = AB 00 00 03 00 00 / AA 00 04 00
0A 0A</tt></font><br>
</p>
</blockquote>
<div class="moz-cite-prefix">So... no way I can get around this
without some <i>serious</i> 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...</div>
<div class="moz-cite-prefix">
<p>Paul, what does this suggest to you?<br>
</p>
</div>
<blockquote type="cite"
cite="mid:8ae1f204-05db-b19b-36e1-ef7469cfc54c@softjar.se">
<hr width="100%" size="2">On 1/17/21 7:39 PM, Johnny Billquist
wrote:<br>
<blockquote type="cite">
<hr width="100%" size="2">On 2021-01-18 00:17, Thomas DeBellis
wrote:
<br>
<br>
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.
<br>
</blockquote>
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.
<br>
Depends on the hardware I guess. I have no idea what the NIA-20
expose.
<br>
</blockquote>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:8ae1f204-05db-b19b-36e1-ef7469cfc54c@softjar.se">
<blockquote type="cite">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.
<br>
</blockquote>
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.
<br>
<br>
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.
<br>
</blockquote>
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.<br>
</body>
</html>