<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 17, 2021, at 10:45 PM, Thomas DeBellis <<a href="mailto:tommytimesharing@gmail.com" class="">tommytimesharing@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">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 class=""><tt class=""><b class=""><font color="green" class="">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" class=""><b class="">1478</b></font>: lev-1-routing
src 2.1023 {ids 0-726 cost 0 hops 0</tt><br class="">
</p>
<div class="moz-cite-prefix">This is two (2) bytes over the maximum
that Tops-20 can accept.<br class="">
</div>
<blockquote class="">
<div class="moz-cite-prefix">NCP><b class="">SHOW LINE NI-0
CHARACTERISTICS </b><br class="">
NCP><br class="">
22:16:04 NCP<br class="">
<br class="">
Request # 23; Show Line Characteristics Completed<br class="">
<br class="">
Line = NI-0<br class="">
<br class="">
Receive Buffers = 6<br class="">
Controller = Normal<br class="">
Protocol = Ethernet<br class="">
Hardware Address = 00 1F 16 EC CE 47<br class="">
Receive buffer size = <font size="+1" color="purple" class=""><b class="">1476</b></font><br class="">
</div>
</blockquote><p class="">It would appear that the 20's are advertising this length in
their layer 1 hello messages:</p><p class=""><tt class="">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" class=""><b class="">1476</b></font>
pri 5 hello 15</tt><tt class=""><br class="">
</tt><tt class="">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 class=""><tt class=""><font color="purple" class=""><b class="">1476</b></font></tt>
pri 5 hello 15 </tt><br class="">
</p></div></div></blockquote></div><div class="">The buffer size in the routing message and in the NCP characteristics (1476) is defined as the size of the routing layer message; it does NOT include the data link layer overhead. So the 14 byte Ethernet header is not part of that count; neither is the 2 byte DEC Ethernet length field -- which DNA considers a data link field.</div><div class=""><br class=""></div><div class="">I assume the tcpdump report includes everything after the Ethernet header in the reported length, so 1478 is correct, given that it includes the Ethernet length field. If TOPS is not expecting that, this would be a bug on its part.</div><div class=""><br class=""></div><div class="">That said, I didn't really intend to send packets that big. The code was supposed to use the minimum of the neighbor buffer sizes or my own, but in one of the two places where the calculation was done the part "my own" was missing. Fixed in rev 577, so with that you should be seeing 590 byte messages.</div><div class=""><br class=""></div><div class="">You should still look at why TOPS-20 is apparently getting the buffer length rules wrong.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>paul</div></body></html>