<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000066" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Gregg,<br>
<br>
Adding on to Keith, I have been using Paul's DECnet/Python (aka
pydecnet) for perhaps a year now; it serves both as the primary
area-31 router using MULTINET and Ethernet, and uplinks to the GRE
mesh using GRE and Ethernet (it supports all of these protocols +
Johnny's Bridge + SIMH internal protocol in a single user-mode
solution). It includes a http control and status server; two
examples of my DECnet/Python nodes are at the following URL's,
just to give you an idea of its capabilities.<br>
<br>
<a
href="http://impvax.duckdns.org/pyrtr/routing/internals%3Fsystem=PYRTR.html">http://impvax.duckdns.org/pyrtr/routing/internals%3Fsystem=PYRTR.html</a><br>
<br>
<a
href="http://sanyalnet-cloud-vps3.freeddns.org/routing/internals%3Fsystem=IMPRTR.html">http://sanyalnet-cloud-vps3.freeddns.org/routing/internals%3Fsystem=IMPRTR.html</a><br>
<br>
The web contents are CSS based, and you can also change the look,
as in<br>
<br>
<a class="moz-txt-link-freetext" href="http://sanyal.duckdns.org:8000">http://sanyal.duckdns.org:8000</a><br>
<br>
Regards,<br>
Supratim<br>
<br>
On 12/08/2019 12:09 PM, Keith Halewood wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1629905f521c4ac8b1741e570e3de299@MERLIN.pitbulluk.local">
<pre wrap="">Hi Gregg,
PyDecnet is Paul Koning's (he's on this list) DECnet router written entirely in Python. Here's his response he posted to this last a while back when I expressed curiosity:
</pre>
<blockquote type="cite">
<pre wrap="">There are some, yes. You can find the code and documentation -- admittedly somewhat brief -- on my Subversion server at svn://akdesign.dyndns.org/pydecnet/trunk/pydecnet .
</pre>
<blockquote type="cite">
<pre wrap="">Very briefly, it's a DECnet implementation implemented entirely in Python 3, the full stack (including some applications). Phase IV, but unlike others it will talk to Phase II nodes. For that matter, it can be run as a Phase >> III or Phase II node if you like.
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">There currently isn't a formal kit; you can install it from the Subversion working directory, or run it directly in there if you like. See doc/*.txt for details.
</pre>
</blockquote>
<pre wrap="">
Feel free to email me with questions, and of course any bug reports.
</pre>
</blockquote>
<pre wrap="">
I made a small modification to make it work better with the Ethernet TAP devices debian Linux offers.
Keith
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-hecnet@Update.UU.SE">owner-hecnet@Update.UU.SE</a> [<a class="moz-txt-link-freetext" href="mailto:owner-hecnet@Update.UU.SE">mailto:owner-hecnet@Update.UU.SE</a>] On Behalf Of Gregg Levine
Sent: 08 December 2019 01:56
To: Hecnet <a class="moz-txt-link-rfc2396E" href="mailto:hecnet@update.uu.se"><hecnet@update.uu.se></a>
Subject: Re: [HECnet] Some SIMH weirdness on Raspbian
Hello!
Keith can you elaborate on what "pydecnet" is? Google searching for me is not working because the search engine keeps trying to change my spelling to what it thinks it is. Johnny as it happens I am no expert on the way Dec hardware even simulated can communicate, but I am almost one on how Linux does do that. And you are indeed right.
-----
Gregg C Levine <a class="moz-txt-link-abbreviated" href="mailto:gregg.drwho8@gmail.com">gregg.drwho8@gmail.com</a>
"This signature fought the Time Wars, time and again."
On Sat, Dec 7, 2019 at 7:37 AM Keith Halewood <a class="moz-txt-link-rfc2396E" href="mailto:Keith.Halewood@pitbulluk.org"><Keith.Halewood@pitbulluk.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hi,
Perhaps this isn’t strictly HECnet related but as HECnet traffic is traversing some part of this weird arrangement via pydecnet, I’m taking a chance:
I run SIMH on Raspberry PIs under Raspbian Buster.
I have both IPv4 and IPv6 networking switched on and a router/DHCP(v6)/DNS infrastructure to cope successfully with it.
(Nothing is wireless for what I’m about to describe, not that it would
make much difference) SIMH’s simulated Ethernet devices on the PIs are TAP connections to a bridge device connection to a real eth0 – no problem here.
SIMH instances’ consoles and terminal MUX devices are listening on individual ports and I telnet into these usually from my PC via Putty.
The DNS servers do not have AAAA for the PIs, just A, so the PC connects to the PIs via IPv4 – no problem here.
The PIs show the SIMH instances listening on the right TCP ports but when I filter with -4, ie:
netstat –a -4
I don’t see SIMH listening. When I filter with -6, ie:
netstat –a -6
I do see a listen on those ports.
I notice that, for example, ssh listens on 0.0.0.0:ssh AND [::]:ssh
but SIMH listens only on *:8601 (for example) The * seems to show up only when I restrict the search to the ipv6 family.
The * seems to indicate a listen with no ‘family’ preference.
An established connection to *:8601 seems even stranger.
It only shows up when netstat is run with -6 but it shows the correct IPv4 addresses for each endpoint. It is an IPv4 connection anyway.
The ‘ss -6’ command shows up something even weirder for the established (IPv4) connections:
The local address port is: [::ffff:192.168.2.42]:8601 and the remote
address port is: [::ffff:192.168.2.12]:61152 The IPv4 part of these ports is correct. Why are they ‘encapsulated’ in some IPv6 syntax and listed as IPv6 connections?
Can anybody point me in the right direction for some explanation please? My google keyword searching skills seem a little off today.
Regards,
Keith
</pre>
</blockquote>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Sent via Thunderbird/MX-Linux on an overheated Compaq Presario CQ61</pre>
</body>
</html>