7 Dec
2019
7 Dec
'19
1:37 p.m.
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
7 Dec
7 Dec
2:39 p.m.
That looks just like the IPv4 over IPv6 thingy...
Johnny
On 2019-12-07 13:37, Keith Halewood wrote:
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:08 p.m.
And I appear to have 'fixed' it by explicit reference to an interface, ie:
Set console telnet=0.0.0.0:xxxx
Similarly for the DZ attachment.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Johnny Billquist
Sent: 07 December 2019 13:40
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Some SIMH weirdness on Raspbian
That looks just like the IPv4 over IPv6 thingy...
Johnny
On 2019-12-07 13:37, Keith Halewood wrote:
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
7:45 p.m.
Hi Keith,
I'm glad you're exploring all the various combination of port specifications and
the fact that each combination actually works. That was my goal when I added the IPv6
support.
The point of the effort was to allow the user to achieve maximum flexibility while at the
same time managing a single listening socket that could be used for either IPv4 and/or
IPv6 connectivity. The encapsulation model allows for support for both protocol types
with a single listening socket that passes the problem of the protocol details to the host
system network stack where it belongs.
- Mark
On Saturday, December 7, 2019 at 8:09 AM, Keith Halewood wrote:
And I appear to have 'fixed' it by explicit
reference to an interface, ie:
Set console telnet=0.0.0.0:xxxx
Similarly for the DZ attachment.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Johnny Billquist
Sent: 07 December 2019 13:40
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Some SIMH weirdness on Raspbian
That looks just like the IPv4 over IPv6 thingy...
Johnny
On 2019-12-07 13:37, Keith Halewood wrote:
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10:23 p.m.
Hi Mark,
Encapsulation... that was the word I was looking for. I was slightly worried that
something might be wrong with the Buster network stack even though it all worked perfectly
well. I suppose I'm a bit nervous having fully enabled IPv6 to the outside world,
effectively leaving NAT behind in the IPv4 side of things. The firewall rules seem ok
though.
Thanks for making SIMH so flexible.
I can go back to my VAX/VMS troubles now, particularly wondering why there's an ASCII
string to F_FLOAT conversion routine (OTS$CVT_T_F) but no apparent equivalent of
OTS$CNVOUT to convert from F_FLOAT to ASCII text. D, G and H seem well catered for.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark
Pizzolato
Sent: 07 December 2019 18:46
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Some SIMH weirdness on Raspbian
Hi Keith,
I'm glad you're exploring all the various combination of port specifications and
the fact that each combination actually works. That was my goal when I added the IPv6
support.
The point of the effort was to allow the user to achieve maximum flexibility while at the
same time managing a single listening socket that could be used for either IPv4 and/or
IPv6 connectivity. The encapsulation model allows for support for both protocol types
with a single listening socket that passes the problem of the protocol details to the host
system network stack where it belongs.
- Mark
On Saturday, December 7, 2019 at 8:09 AM, Keith Halewood wrote:
And I appear to have 'fixed' it by explicit
reference to an interface, ie:
Set console telnet=0.0.0.0:xxxx
Similarly for the DZ attachment.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Johnny Billquist
Sent: 07 December 2019 13:40
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Some SIMH weirdness on Raspbian
That looks just like the IPv4 over IPv6 thingy...
Johnny
On 2019-12-07 13:37, Keith Halewood wrote:
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol 
8 Dec
8 Dec
2:56 a.m.
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 gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Sat, Dec 7, 2019 at 7:37 AM Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
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
6:09 p.m.
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:
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 .
I made a small modification to make it work better with the Ethernet TAP devices debian
Linux offers.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Gregg Levine
Sent: 08 December 2019 01:56
To: Hecnet <hecnet at update.uu.se>
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 gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Sat, Dec 7, 2019 at 7:37 AM Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
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.
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.
Feel free to email me with questions, and of course any bug reports.
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
7:44 p.m.
FWIW: since the topic right now is IPv6, or at least related to it... currently pydecnet
does not handle ipv6 yet. I'm thinking about adding that.
paul
On Dec 8, 2019, at 12:09 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
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:
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 .
I made a small modification to make it work better with the Ethernet TAP devices debian
Linux offers.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Gregg Levine
Sent: 08 December 2019 01:56
To: Hecnet <hecnet at update.uu.se>
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 gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again." 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.
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.
Feel free to email me with questions, and of course any bug reports.
8:30 p.m.
Nor does RSX. And yes, I have been pondering that as well. It might
happen some day, but it's not that trivial... :-)
Johnny
On 2019-12-08 19:44, Paul Koning wrote:
FWIW: since the topic right now is IPv6, or at least
related to it... currently pydecnet does not handle ipv6 yet. I'm thinking about
adding that.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Dec 8, 2019, at 12:09 PM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
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:
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 .
I made a small modification to make it work better with the Ethernet TAP devices debian
Linux offers.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Gregg Levine
Sent: 08 December 2019 01:56
To: Hecnet <hecnet at update.uu.se>
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 gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again." 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.
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.
Feel free to email me with questions, and of course any bug reports. 
8:35 p.m.
It?s easy - the underlying OS does all the hard work for you.
Oh wait...
;)
Ian
Sent from my iPhone
On Dec 8, 2019, at 11:30 AM, Johnny Billquist <bqt
at softjar.se> wrote:
?Nor does RSX. And yes, I have been pondering that as well. It might happen some day, but
it's not that trivial... :-)
Johnny
On 2019-12-08 19:44, Paul Koning wrote:
FWIW: since the topic right now is IPv6, or at least related to it... currently pydecnet
does not handle ipv6 yet. I'm thinking about adding that.
paul
>> On Dec 8, 2019, at 12:09 PM, Keith Halewood <Keith.Halewood at
pitbulluk.org> wrote:
>
> 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:
>
>> 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 .
>>
>>> 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.
>>
>>> 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.
>>
>> Feel free to email me with questions, and of course any bug reports.
>
> I made a small modification to make it work better with the Ethernet TAP devices
debian Linux offers.
>
> Keith
>
> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Gregg Levine
> Sent: 08 December 2019 01:56
> To: Hecnet <hecnet at update.uu.se>
> 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 gregg.drwho8 at gmail.com
> "This signature fought the Time Wars, time and again."
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
9 Dec
9 Dec
2:03 a.m.
Nor is it true in Unix, since it has that ugly mess of "address family". DECnet
got this right...
paul
On Dec 8, 2019, at 2:35 PM, Ian McLaughlin <ian at
platinum.net> wrote:
It?s easy - the underlying OS does all the hard work for you.
Oh wait...
;)
Ian
Sent from my iPhone
On Dec 8, 2019, at 11:30 AM, Johnny Billquist
<bqt at softjar.se> wrote:
?Nor does RSX. And yes, I have been pondering that as well. It might happen some day, but
it's not that trivial... :-)
Johnny
On 2019-12-08 19:44, Paul Koning wrote:
FWIW: since the topic right now is IPv6, or at least related to it... currently pydecnet
does not handle ipv6 yet. I'm thinking about adding that.
paul
>> On Dec 8, 2019, at 12:09 PM, Keith Halewood <Keith.Halewood at
pitbulluk.org> wrote:
>
> 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:
>
>> 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 .
>>
>>> 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.
>>
>>> 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.
>>
>> Feel free to email me with questions, and of course any bug reports.
>
> I made a small modification to make it work better with the Ethernet TAP devices
debian Linux offers.
>
> Keith
>
> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Gregg Levine
> Sent: 08 December 2019 01:56
> To: Hecnet <hecnet at update.uu.se>
> 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 gregg.drwho8 at gmail.com
> "This signature fought the Time Wars, time and again."
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol 
10 Dec
10 Dec
7:46 p.m.
Hi Gregg,
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.
http://impvax.duckdns.org/pyrtr/routing/internals%3Fsystem=PYRTR.html
http://sanyalnet-cloud-vps3.freeddns.org/routing/internals%3Fsystem=IMPRTR.…
The web contents are CSS based, and you can also change the look, as in
http://sanyal.duckdns.org:8000
Regards,
Supratim
On 12/08/2019 12:09 PM, Keith Halewood wrote:
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:
--
Sent via Thunderbird/MX-Linux on an overheated Compaq Presario CQ61
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 .
I made a small
modification to make it work better with the Ethernet TAP devices debian Linux offers.
Keith
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of
Gregg Levine
Sent: 08 December 2019 01:56
To: Hecnet <hecnet at update.uu.se>
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 gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Sat, Dec 7, 2019 at 7:37 AM Keith Halewood <Keith.Halewood at pitbulluk.org>
wrote:
> 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 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.
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.
Feel free to email me with questions, and of course any bug reports.
1606
days inactive
1609
days old
11 comments
7 participants
participants (7)
-
bqt＠softjar.se -
gregg.drwho8＠gmail.com -
ian＠platinum.net -
Keith.Halewood＠pitbulluk.org -
Mark＠infocomm.com -
paulkoning＠comcast.net -
supratim＠riseup.net