[HECnet] Some SIMH weirdness on Raspbian

[Keith Halewood]

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