<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 3/3/20 4:45 PM, Paul Koning wrote:<br>
<blockquote type="cite"
cite="mid:13BE0FB8-C5A0-48BA-AD31-26F7BF7F9485@comcast.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I'm puzzled by the bit about MacOS PATHworks detecting duplicate
address. How would it do that? As an end node, it doesn't see
routing messages at all. It could see a duplicate address on its
own Ethernet, by detecting the receipt of a message from its
Ethernet address that it didn't send. But I can see no way it
could know about an off-LAN duplicate.</blockquote>
<p>My bad. MACOS9 sits in a little Ethernet network with other
nodes, the Ethernet extended virtually over VDE2. PYDNET then does
not really do anything much in this case, nor is it going be able
to do much.</p>
<p>The good thing is I now realize the "rogue" node must be on the
same Ethernet segment. Which narrows the possibilities down.</p>
<p>Thanks.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:13BE0FB8-C5A0-48BA-AD31-26F7BF7F9485@comcast.net">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>paul</div>
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 3, 2020, at 3:33 PM, Supratim Sanyal
<<a href="mailto:supratim@riseup.net" class=""
moz-do-not-send="true">supratim@riseup.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8" class="">
<div dir="auto" class="">Thinking more ... it is difficult
to run Wireshark 24/7 trying to trap the rogue node's
source. But PYDNET - a DECnet/python rev 486 node - does
L1 routing for area 31. Wouldn't PYDNET know that the
address for MACOS9 is taken and that node is up, and
therefore another node with the same address trying to
come up is likely a situation to be at the least logged
? Knowing Paul, it probably already does, it has not
struck me to look at PYDNET logs before.<br class="">
<br class="">
<div dir="ltr" class="">
<div class="">
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class=""><br class="">
</span></div>
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class="">---</span></div>
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class="">Supratim
Sanyal, W1XMT</span></div>
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class="">39.19151 N,
77.23432 W</span></div>
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class="">QCOCAL::SANYAL
via <a
href="http://www.update.uu.se/~bqt/hecnet.html"
class="" moz-do-not-send="true">HECnet</a></span></div>
</div>
<div class=""><br class="">
</div>
</div>
<div dir="ltr" class=""><br class="">
On Mar 3, 2020, at 3:13 PM, Supratim Sanyal <<a
href="mailto:supratim@riseup.net" class=""
moz-do-not-send="true">supratim@riseup.net</a>>
wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8" class="">
I have had someone on area 31 bring up a node that
conflicts with my MACOS9 node running Pathworks for
Macintosh. The Mac handles it by turning it's
executor off and throwing a error popup saying
"someone grabbed my address".
<div class=""><br class="">
</div>
<div class="">Since I am not sitting there staring
at the Mac screen all the time, the situation
always has gone away by the time I get to
investigating why MACOS9 dropped off.</div>
<div class=""><br class="">
</div>
<div class="">This makes me wonder if whoever has
that other node gets a similar message and
disconnects. But that still leaves MACOS9 in
limbo.</div>
<div class=""><br class="">
<div dir="ltr" class="">
<div class="">
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class=""><br
class="">
</span></div>
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class="">---</span></div>
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class="">Supratim
Sanyal, W1XMT</span></div>
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class="">39.19151
N, 77.23432 W</span></div>
<div class=""><span style="background-color:
rgba(255, 255, 255, 0);" class="">QCOCAL::SANYAL
via <a
href="http://www.update.uu.se/~bqt/hecnet.html"
class="" moz-do-not-send="true">HECnet</a></span></div>
</div>
<div class=""><br class="">
</div>
</div>
<div dir="ltr" class=""><br class="">
On Mar 3, 2020, at 2:16 PM, Paul Koning <<a
href="mailto:paulkoning@comcast.net" class=""
moz-do-not-send="true">paulkoning@comcast.net</a>>
wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class=""><span class=""></span><br
class="">
<span class=""></span><br class="">
<blockquote type="cite" class=""><span
class="">On Mar 3, 2020, at 1:13 PM,
Thomas DeBellis <<a
href="mailto:tommytimesharing@gmail.com"
class="" moz-do-not-send="true">tommytimesharing@gmail.com</a>>
wrote:</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span
class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span
class="">You may be talking about a number
of things here. DECnet node numbers are
something (very) vaguely like IP tuples,
except with half the bits and fixed
fields. The upper 6 bits constitute the
area, the lower 10 bits constitute the
number within area. This is what I
recall:</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span
class=""></span><br class="">
</blockquote>
<blockquote type="cite" class=""><span
class=""> • If the node number's name
is not defined to other systems, then many
user level programs will not be able to
see if. Tops-20 won't able to build a
connection.</span><br class="">
</blockquote>
<span class=""></span><br class="">
<span class="">Interesting. It depends on the
application API. For example, in RSTS the
"node name" argument can contain a number in
string form, which lets you connect by
address. But in some places in NCP things
don't work if there isn't a name for the
node. I would call that a bug.</span><br
class="">
<span class=""></span><br class="">
<blockquote type="cite" class=""><span
class=""> • Phase II DECnet used
node names directly, I think.</span><br
class="">
</blockquote>
<span class=""></span><br class="">
<span class="">Yes, though it also mentions
node addresses. The spec requires a value
between 2 and 240, with no explanation why.
The address appears in the Node Init
message, but nowhere else that I can see.</span><br
class="">
<span class=""></span><br class="">
<blockquote type="cite" class=""><span
class=""> • If the number is the same
as another system in different area, then
everything is fine except for 1.</span><br
class="">
</blockquote>
<span class=""></span><br class="">
<span class="">That isn't a duplicate address.
The address is a 16 bit value, not a 6 or
10 bit value. If some of the bits are the
same but others aren't, you have two
different addresses.</span><br class="">
<span class=""></span><br class="">
<blockquote type="cite" class=""><span
class=""> • If the number is the same
as another system in the same area, then
somebody will become 'unhappy'.</span><br
class="">
</blockquote>
<blockquote type="cite" class=""><span
class=""> • I don't remember how
the adjacency is reported for
point-to-point.</span><br class="">
</blockquote>
<blockquote type="cite" class=""><span
class=""> • If you think of MAC address
clash on the same Ethernet segment as
opposed to different segments, you may
appreciate a similarity.</span><br
class="">
</blockquote>
<span class=""></span><br class="">
<span class="">Two nodes on the same Ethernet
(not just segment but bridged also) will
result in a duplicate Ethernet address.
DECnet doesn't define anything that checks
for this. Depending on the implementation,
you might see it as an "adjacency" to your
own node address on a circuit. The same
issue appears if you have a router with
multiple Ethernet interfaces and you attach
those to the same Ethernet. Phase V of
course fixes this by not using a MAC address
derived from the node address. So does
Phase IV Prime, but implementations of that
are rare at best.</span><br class="">
<span class=""></span><br class="">
<span class="">If the multiple nodes are
connected to point to point links, or to
disjoint Ethernets, then as far as DECnet is
concerned that's just one node reachable via
several paths. That ability is of course
intentional -- a router can be reached on
any of its interfaces. A duplicate address
essentially looks like a partitioned node.
Other nodes would see one or the other of
the two, depending on which is closer (by
path cost).</span><br class="">
<span class=""></span><br class="">
<blockquote type="cite" class=""><span
class=""> • I don't remember the finer
details of the differences between a level
1 and 2 router.</span><br class="">
</blockquote>
<span class=""></span><br class="">
<span class="">If one of the duplicate-address
nodes is a level 2 router but the other
isn't, then the one that is will show in
entry 0 of the routing tables as a possible
"nearest L2 router". That will work just
fine.</span><br class="">
<span class=""></span><br class="">
<span class="">If both are level 2 routers,
then for the out of area routing they just
act as redundant L2 routers offering out of
area service. The usual rule that an area
must not be partitioned applies, of course.</span><br
class="">
<span class=""></span><br class="">
<span class="">That brings up a particularly
nasty case. Suppose you have an L2 router
that duplicates someone else's address, and
in fact it isn't connected into the area its
address says it belongs in. The scenario of
"I accidentally booted up an old node" could
do this. If the rogue node isn't connected
to other L2 nodes, that's benign because its
L2 services will be turned off -- an L2
router only offers out of area service if it
has out of area circuits that are up. But
if the rogue happens to be connected to some
other L2 router, then it would claim
connectivity to its area in its L2 routing
messages. That would make the entire area
(except the rogue node itself) effectively
unreachable to anyone who has a lower cost
L2 path to the rogue than to the real area.</span><br
class="">
<span class=""></span><br class="">
<span class=""> paul</span><br class="">
<span class=""></span><br class="">
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet</pre>
</body>
</html>