[HECnet] Some SIMH weirdness on Raspbian

[Mark Pizzolato]

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