[Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Tim Stark]

Folks,



I tried to configure DHCLIENT for DHCP access from my FIOS gateway router
but DHCLIENT crashed during boot time and complaint undefined symbol in API
libraries.



Also I am figuring out how to set SSH2 terminal server. I successfully
generated SSH2 keys on emulated SIMH VAX system.



Does anyone know good DHCLIENT and SSH2 configuration instructions for
OpenVMS 7.3 and Multinet 5.5?



I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
Armbian OS for 7/24 operation.



Tim

[Hunter Goatley]

Post by Tim Stark
Folks,
I tried to configure DHCLIENT for DHCP access from my FIOS gateway
router but DHCLIENT crashed during boot time and complaint undefined
symbol in API libraries.
Also I am figuring out how to set SSH2 terminal server. I successfully
generated SSH2 keys on emulated SIMH VAX system.
Does anyone know good DHCLIENT and SSH2 configuration instructions for
OpenVMS 7.3 and Multinet 5.5?

SSH2 is covered in the /MultiNet Installation and Administration Guide/:

http://www.process.com/docs/multinet5_5/install_admin/chapter_28.htm

There's also an FAQ here:

http://www.process.com/support/multinet/faq/ssh.html

The DHCP client is documented here:

http://www.process.com/docs/multinet5_5/install_admin/chapter_16.htm

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
***@goatley.com

[Tim Stark]

Folks,



Thanks for info. I figured out and have to put 'define/system/exec
multinet_dhcp_client "1"' before start_multinet script.

It now worked fine but interfaces are still not updated (no effect).
Installation guide did not mention that.



I now have another problem.



I have some problem with @configure setup. When I put 0.0.0.0 as default IP
address and execute dhclient.

I think that @configure is for manual settings with static IP address only
but I want automated settings with DHCP client.



After dhclient was executed, it successfully got correct settings (according
to log files) from my fios router but it still display 0.0.0.0 on SHOW NET
and MULTINET CONFIGURE /INTERFACE (show command).



I tried to execute @dhclient-script.com and it verbosely did set settings
properly but SHOW NETWORKS still display 0.0.0.0.



Does anyone know any solution?



Thanks,

Tim



From: Hunter Goatley [mailto:***@goatley.com]
Sent: Sunday, January 28, 2018 1:45 PM
To: Tim Stark <***@gmail.com>; ***@trailing-edge.com
Subject: Re: [Simh] VMS multinet DHCLIENT/SSH2 configuration problem



On 1/28/2018 12:08 PM, Tim Stark wrote:

Folks,



I tried to configure DHCLIENT for DHCP access from my FIOS gateway router
but DHCLIENT crashed during boot time and complaint undefined symbol in API
libraries.



Also I am figuring out how to set SSH2 terminal server. I successfully
generated SSH2 keys on emulated SIMH VAX system.



Does anyone know good DHCLIENT and SSH2 configuration instructions for
OpenVMS 7.3 and Multinet 5.5?


SSH2 is covered in the MultiNet Installation and Administration Guide:

http://www.process.com/docs/multinet5_5/install_admin/chapter_28.htm

There's also an FAQ here:

http://www.process.com/support/multinet/faq/ssh.html

The DHCP client is documented here:

http://www.process.com/docs/multinet5_5/install_admin/chapter_16.htm

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
***@goatley.com <mailto:***@goatley.com>

[Jeremy Begg]

Hi TIm,

Post by Tim Stark
...
Also I am figuring out how to set SSH2 terminal server. I successfully
generated SSH2 keys on emulated SIMH VAX system.
...
I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
Armbian OS for 7/24 operation.

Once you get SSH working you may find it's unusable. On my RPi 3 it
takes the VMS MultiNet SSH server several *minutes* to negotiate the
SSL handshake. I suspect (without having attempted any diagnosis!)
that this is due to SIMH having to emulate a huge number of VAX floating
point instructions.

(Even on my real VAXstation 4000/96 the MultiNet SSH server took up to a
minute to negotiate the SSL handshake, and of course the system would
"pause" every now and again while the session keys were renogotiated.
I had hoped that in moving from a 100MHz VAX to a 1.2GHz SIMH VAX things
might improve, but they went dramatically backwards.)

Regards

Jeremy Begg

+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| P.O.Box 402, Walkerville, | E-Mail: ***@vsm.com.au |
| South Australia 5081 | Phone: [phone] |
|---------------------------| Mobile: [phone] |
| A.C.N. 068 409 156 | FAX: [phone] |
+---------------------------------------------------------+

[Timothe Litt]

Post by Jeremy Begg
Hi TIm,

Post by Tim Stark
...
Also I am figuring out how to set SSH2 terminal server. I successfully
generated SSH2 keys on emulated SIMH VAX system.
...
I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
Armbian OS for 7/24 operation.

Once you get SSH working you may find it's unusable. On my RPi 3 it
takes the VMS MultiNet SSH server several *minutes* to negotiate the
SSL handshake. I suspect (without having attempted any diagnosis!)
that this is due to SIMH having to emulate a huge number of VAX floating
point instructions.

I suggest running PCA to determine if this is in fact the cause.  Or
stop the emulation a few times while "hung" and look at the history buffer.

If I had to guess, I'd start by looking at where the required randomness
(for key generation) is coming from.  In most implementations, that's
the cause of typical hangs like these.  I don't know what Multinet is
using for a source of randomness - perhaps Hunter can shed light on that.

FP in SimH isn't that slow - the VAX format is unpacked, then integer
(hardware) operations are performed on the "mantissa" and exponent, then
the result repacked.  These are all integer operations, and should be
reasonably fast on any processor, even a Pi.  The FP code would benefit
from a high level of compiler optimization, as there are lots of
opportunities for inlining.

Note that the PI, and many modern CPUs provide a hardware source of
randomness (which can be behind /dev/{u,}random).  It may be off by
default, depending on your distribution.  I don't think that SimH VAX
uses it, but it might be something to export.  Most older OS would try
to gather randomness from device timing (interrupt jitter), something
that SimH alters...  It can take quite a bit of data to get enough bits
to satisfy randomness (or primality) tests used in key generation.

Anyhow, FP would not be the first place I'd look.

Post by Jeremy Begg
(Even on my real VAXstation 4000/96 the MultiNet SSH server took up to a
minute to negotiate the SSL handshake, and of course the system would
"pause" every now and again while the session keys were renogotiated.
I had hoped that in moving from a 100MHz VAX to a 1.2GHz SIMH VAX things
might improve, but they went dramatically backwards.)
Regards
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| South Australia 5081 | Phone: [phone] |
|---------------------------| Mobile: [phone] |
| A.C.N. 068 409 156 | FAX: [phone] |
+---------------------------------------------------------+
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Timothe Litt]

Post by Timothe Litt

Post by Jeremy Begg
Hi TIm,

Post by Tim Stark
...
Also I am figuring out how to set SSH2 terminal server. I successfully
generated SSH2 keys on emulated SIMH VAX system.
...
I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
Armbian OS for 7/24 operation.

Once you get SSH working you may find it's unusable. On my RPi 3 it
takes the VMS MultiNet SSH server several *minutes* to negotiate the
SSL handshake. I suspect (without having attempted any diagnosis!)
that this is due to SIMH having to emulate a huge number of VAX floating
point instructions.

I suggest running PCA to determine if this is in fact the cause.  Or
stop the emulation a few times while "hung" and look at the history buffer.
If I had to guess, I'd start by looking at where the required
randomness (for key generation) is coming from.  In most
implementations, that's the cause of typical hangs like these.  I
don't know what Multinet is using for a source of randomness - perhaps
Hunter can shed light on that.
FP in SimH isn't that slow - the VAX format is unpacked, then integer
(hardware) operations are performed on the "mantissa" and exponent,
then the result repacked.  These are all integer operations, and
should be reasonably fast on any processor, even a Pi.  The FP code
would benefit from a high level of compiler optimization, as there are
lots of opportunities for inlining.
Note that the PI, and many modern CPUs provide a hardware source of
randomness (which can be behind /dev/{u,}random).  It may be off by
default, depending on your distribution.  I don't think that SimH VAX
uses it, but it might be something to export.  Most older OS would try
to gather randomness from device timing (interrupt jitter), something
that SimH alters...  It can take quite a bit of data to get enough
bits to satisfy randomness (or primality) tests used in key generation.
Anyhow, FP would not be the first place I'd look.

Post by Jeremy Begg
(Even on my real VAXstation 4000/96 the MultiNet SSH server took up to a
minute to negotiate the SSL handshake, and of course the system would
"pause" every now and again while the session keys were renogotiated.

This supports the guess that the issue is more likely to be generating
random bits than the speed of FP emulation.

When I stopped paying attention to VMS, there was no hardware RNG
support.  The usual advice - MTH$RANDOM is a uniform software pseudo-RNG
that produces an F-float between 0.0 & 1.0.  It is fine for simulations
(as in statistics, not what SimH does), but not suitable for most
crypto.  Given the seed, the next number is predictable as it's a simple
congruential algorithm.  And there's no good way to initialize the seed
(for crypto).  Time, process ID, etc are guessable.  And these days, the
limited range of an F-Floating mantissa is susceptible to a dictionary. 

Things are actually more complicated than this summary, but the bottom
line is that if it is slow on hardware, it will be slow on SimH.  And
I'd look at what is happening during the hangs.  The root cause is
likely getting enough randomness...

Post by Timothe Litt

Post by Jeremy Begg
I had hoped that in moving from a 100MHz VAX to a 1.2GHz SIMH VAX things
might improve, but they went dramatically backwards.)
Regards
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| South Australia 5081 | Phone: [phone] |
|---------------------------| Mobile: [phone] |
| A.C.N. 068 409 156 | FAX: [phone] |
+---------------------------------------------------------+

[Jeremy Begg]

Hi Timothe,

Post by Jeremy Begg
Once you get SSH working you may find it's unusable. On my RPi 3 it
takes the VMS MultiNet SSH server several *minutes* to negotiate the
SSL handshake. I suspect (without having attempted any diagnosis!)
that this is due to SIMH having to emulate a huge number of VAX floating
point instructions.

I suggest running PCA to determine if this is in fact the cause.  Or
stop the emulation a few times while "hung" and look at the history buffer.

Can you just clarify, what is "PCA"? DEC Performance & Coverage Analyzer
springs to mind but I'm not sure that's what you're referring to.

Thanks,

Jeremy Begg

[Timothe Litt]

Post by Jeremy Begg
Hi Timothe,

Post by Jeremy Begg
Once you get SSH working you may find it's unusable. On my RPi 3 it
takes the VMS MultiNet SSH server several *minutes* to negotiate the
SSL handshake. I suspect (without having attempted any diagnosis!)
that this is due to SIMH having to emulate a huge number of VAX floating
point instructions.

I suggest running PCA to determine if this is in fact the cause.ￜ Or
stop the emulation a few times while "hung" and look at the history buffer.

Can you just clarify, what is "PCA"? DEC Performance & Coverage Analyzer
springs to mind but I'm not sure that's what you're referring to.

Yes.  A DECset tool.

Post by Jeremy Begg
Thanks,
Jeremy Begg