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