11 Jan
2021
11 Jan
'21
10:41 p.m.
On Jan 11, 2021, at 4:22 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
OK, I guess that's probably a level 2 router broadcast coming over the bridge. There
is no way Tops-10 or Tops-20 could currently be generating that because there is no code
to do so; they're level 1, only
Yes, unfortunately originally both multicasts used the same address. That was changed in
Phase IV Plus, but that still sends to the old address for backwards compatibility and it
isn't universally implemented.
I started looking at the error; it starts out in
DNADLL when it is detected on a frame that has come back from NISRV (the Ethernet
Interface driver). The error is then handed off to NTMAN where the actual logging is
done. So, there are two quick hacks to stop all the errors:
? I could stub out the length error entry (XWD UNLER%,^D5) in the NIEVTB: table in
DNADLL.MAC.
? I could put in a filter ($NOFIL) for event class 5 in the NMXFIL: table in NTMAN.MAC.
That will stop the deluge for the moment. Meanwhile, I have to understand what's
actually being detected; even the full SPEAR entry is short on details (like how long the
frame was).
The thing to look for is the buffer size (frame size) setting of the stations on the
Ethernet. It should match; if not someone may send a frame small enough by its settings
but too large for someone else who has a smaller value. Routing messages tend to cause
that problem because they are variable length; the Phase IV rules have the routers send
them (the periodic ones) as large as the line buffer size permits.
Note that DECnet by convention doesn't use the full max Ethernet frame size in DECnet,
because DECnet has no fragmentation so the normal settings are chosen to make for
consistent NSP packet sizes throughout the network. The router sending the problematic
messages is 2.1023 (not 63.whatever, Rob, remember that addresses are little endian) which
has its Ethernet buffer size set to 591. That matches the VMS conventional default of 576
when accounting for the "long header" used on Ethernet vs. the "short
header" on point to point (DDCMP etc.) links). But VENTI2 has its block size set to
576. If you change it to 591 it should start working.
Perhaps I should change PyDECnet to have a way to send shorter than max routing messages.
paul