[Simh] vax750 and simulated hard-wired serial connections and Raspbian

[Mark Pizzolato]

On Tuesday, May 9, 2017 at 11:16 AM, Alan Perry wrote:
> -----Original Message-----
> From: Simh [mailto:simh-bounces at trailing-edge.com] On Behalf Of Alan
> Perry
> Sent: Tuesday, May 9, 2017 11:16 AM
> To: Mark Pizzolato <Mark at infocomm.com>; simh at trailing-edge.com
> Subject: Re: [Simh] vax750 and simulated hard-wired serial connections and
> Raspbian
> > On 5/9/17 10:42 AM, Mark Pizzolato wrote:
> > On Tuesday, May 9, 2017 at 10:15 AM, Alan Perry wrote:
> >> I am participating in the UUCP project and have set up a SIMH vax750
> >> on a Raspberry Pi. I am using the 4.3BSD bits that the UUCP project
> >> lead
> >> (Warren) provides to install the system and followed his instructions
> >> for configuring it.
> >>
> >> It uses a simulated hard-wired serial connection to communicate with
> >> a remote simulated host over TCP/IP. However, I have not been able to
> >> make this connection work. Everything seems good on the simulated
> >> VAX. But when I initiate connections to the remote host, I see no
> >> corresponding activity on my network.
> >>
> >> Any suggestions of specific things to check to figure out why nothing
> >> is going out to the network?
> > To start understanding what is going on, please provide:
> > 1) the output of SHOW VERSION executed at the sim> prompt of your
> simulator.
> > 2) the same for the remote simulator.
> > 3) The configuration that is being used on BOTH simulators
> >
> > - Mark
> Other that the IP address and port, I don't have info on the other remote
> simulator.

The first Info you'll need is confirmation that others are, in fact, able 
to successfully connect to the particular remote system you're trying to 
reach. 

> My SHOW VERSION output is:
> VAX 11/750 simulator V4.0-0 Beta
>      Simulator Framework Capabilities:
>          64b data
>          64b addresses
>          Threaded Ethernet Packet transports:PCAP:TAP:VBE:NAT:UDP
>          Idle/Throttling support is available
>          Virtual Hard Disk (VHD) support
>          RAW disk and CD/DVD ROM support
>          Asynchronous I/O support (Lock free asynchronous event queue)
>          Asynchronous Clock support
>          FrontPanel API Version 4
>      Host Platform:
>          Compiler: GCC 4.9.2
>          Simulator Compiled as C arch: ARM (Release Build) on Apr 29 2017 at 01:13:50
>          Memory Access: Little Endian
>          Memory Pointer Size: 32 bits
>          Large File (>2GB) support
>          SDL Video support: No Video Support
>          PCRE RegEx support for EXPECT commands
>          OS clock resolution: 1ms
>          Time taken by msleep(1): 1ms
>          OS: Linux nmtvax 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux
>          git commit id: 7a46fcf1
> 
> My simulator's .ini file:
>      set dz lines=0
        ^^^^^^^^^^^^
This line MUST produce an error message.

>      set dz 8b

This line doesn't change anything since 8b is the default

>      # Connect some lines to remote servers
>      # Connect the remaining lines to listen on port 5000
>      attach dz -m -a line=0,Connect=<ip address of remote
> simulator>:<port num for remote service>
>      att dz -m -a 5000
>      set xu enable
>      att xu nat:
>      set rq0 ra81
>      att rq0 nmtvax.dsk
>      att ts nmtvax.tap
>      ...
> 
> Do you need more of it than this?
> 
> The boot disk image, .tap image, and .ini file are generated by a script that is
> part of the UUCP project.
> 
> Again, I am not asking anyone to fix this for me. Just asking for suggestions on
> where to look for what could be going wrong.

There are many potential points of failure when you're trying to reach directly between what I'm guessing here are two independent consumer class networks, probably with various firewall pieces at several steps along the way.  Addressing all of these issues is completely your problem.

Since you're using system configurations provided by the UUCP project, it would seem most useful to ask them for help troubleshooting problems with their stuff.

Knowing nothing else, all I can offer is that you can play with simh debugging, by adding different forms of these line to the beginning of your configuration file:
	sim> set debug -t debug.file
or for ALL available debug output:
	sim> set DZ debug
or specific debug details try:
	sim> help dz set
and then pick the different debug details you may want to have reported.

Good Luck.

- Mark