Discussion:
SSH/SCP sessions hanging for 7 minutes while reading from "/dev/random"
(too old to reply)
sphowes
2021-09-29 22:31:05 UTC
Permalink
I am hoping someone may be able to help resolve an issue while opening an SSH or SCP session on an OpenVMS 7.3-2 cluster.

When a session is initiated to or from the server, the connection will hang for ~7 minutes before finally opening the connection and asking for a password.

While running an 'ssh -D 99' I can see that all of the delay time is being spent while trying to read from "/dev/random". Each iteration of "Starting read from /dev/random" is taking a minute to timeout and then returning with "Opening /dev/random failed" and then it tries again for a total of 7 total tries.

At the end of this section the SSH/SCP connection opens fine.

Does anyone know what it is actually trying to open when it references "/dev/random"? Is there any way to make a configuration change to work around this? Or limit the number of times it loops the read or reduce the 60 sec read timeout?

This is the SSH debug output that took ~7 minutes to complete:
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.

Thank you in advance for any insight you can provide.

-Seth
Stephen Hoffman
2021-09-30 00:44:45 UTC
Permalink
Post by sphowes
I am hoping someone may be able to help resolve an issue while opening
an SSH or SCP session on an OpenVMS 7.3-2 cluster.
...
Thank you in advance for any insight you can provide.
I'm mildly surprised that this ssh client even connects to anything,
without also having the other end de-tuned.

What to do here? Use telnet. It's not like security is a central
consideration here, to be blunt. Get it working, move on to the next
issue.

Or petition local management to fund an upgrade to V8.4-2L1 or maybe
V8.4-2L2, which'll bring this configuration forward twenty years, of
course.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2021-09-30 00:31:41 UTC
Permalink
Post by sphowes
I am hoping someone may be able to help resolve an issue while
opening an SSH or SCP session on an OpenVMS 7.3-2 cluster.
When a session is initiated to or from the server, the connection
will hang for ~7 minutes before finally opening the connection and
asking for a password.
While running an 'ssh -D 99' I can see that all of the delay time is
being spent while trying to read from "/dev/random". Each iteration
of "Starting read from /dev/random" is taking a minute to timeout and
then returning with "Opening /dev/random failed" and then it tries
again for a total of 7 total tries.
At the end of this section the SSH/SCP connection opens fine.
Does anyone know what it is actually trying to open when it
references "/dev/random"? Is there any way to make a configuration
change to work around this? Or limit the number of times it loops
the read or reduce the 60 sec read timeout?
If you define a logical DEV to point to a directory
and you place a file RANDOM. in that directory, then
I expect it to read from that file.

But that would not be good for the randomness so I will
not recommend that.

I am puzzled about why it tries to read from /dev/random
on VMS - it should try and get some random bytes via
SYS$GETJPIW, SYS$GETSYI and SUS$GETDVIW - or something
like that.

Arne
Scott Dorsey
2021-09-30 22:41:33 UTC
Permalink
Post by Arne Vajhøj
I am puzzled about why it tries to read from /dev/random
on VMS - it should try and get some random bytes via
SYS$GETJPIW, SYS$GETSYI and SUS$GETDVIW - or something
like that.
What he is seeing is the result of a printf statement that is activated
only when the debug flag is set.

So it is likely doing exactly what you describe, but nobody has changed
the printf statement in the source accordingly. Exactly what it's doing
you'd have to look in the source for, but a grep on "/dev/random" ought
to get you to the right place.

Note that this is a very ancient, perhaps historical version of ssh and
it doesn't support any modern encryption.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2021-10-01 00:38:57 UTC
Permalink
Post by Scott Dorsey
Post by Arne Vajhøj
I am puzzled about why it tries to read from /dev/random
on VMS - it should try and get some random bytes via
SYS$GETJPIW, SYS$GETSYI and SUS$GETDVIW - or something
like that.
What he is seeing is the result of a printf statement that is activated
only when the debug flag is set.
So it is likely doing exactly what you describe, but nobody has changed
the printf statement in the source accordingly.
That is possible.
Post by Scott Dorsey
Exactly what it's doing
you'd have to look in the source for, but a grep on "/dev/random" ought
to get you to the right place.
Arne
Dave Froble
2021-09-30 02:36:58 UTC
Permalink
Post by sphowes
I am hoping someone may be able to help resolve an issue while opening an SSH or SCP session on an OpenVMS 7.3-2 cluster.
When a session is initiated to or from the server, the connection will hang for ~7 minutes before finally opening the connection and asking for a password.
While running an 'ssh -D 99' I can see that all of the delay time is being spent while trying to read from "/dev/random". Each iteration of "Starting read from /dev/random" is taking a minute to timeout and then returning with "Opening /dev/random failed" and then it tries again for a total of 7 total tries.
At the end of this section the SSH/SCP connection opens fine.
Does anyone know what it is actually trying to open when it references "/dev/random"? Is there any way to make a configuration change to work around this? Or limit the number of times it loops the read or reduce the 60 sec read timeout?
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
debug: GenRand/GENRAND.C:429: Starting to collect noise.
debug: GenRand/GENRAND.C:270: Starting read from /dev/random.
debug: GenRand/GENRAND.C:292: Opening /dev/random failed.
debug: GenRand/GENRAND.C:424: Already acquiring noise.
Thank you in advance for any insight you can provide.
-Seth
Just guessing. Perhaps the connection attempts the highest level of
encryption first, then times out, then tries the next, until some level
works.

Or something similar.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Lawrence D’Oliveiro
2021-09-30 05:39:35 UTC
Permalink
Post by sphowes
While running an 'ssh -D 99' I can see that all of the delay time is being spent
while trying to read from "/dev/random". Each iteration of "Starting read from
/dev/random" is taking a minute to timeout and then returning with
"Opening /dev/random failed" and then it tries again for a total of 7 total tries.
Lack of system entropy to keep /dev/random fed? This is why we have /dev/urandom, for all but the most critical uses.
Arne Vajhøj
2021-09-30 12:19:19 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by sphowes
While running an 'ssh -D 99' I can see that all of the delay time is being spent
while trying to read from "/dev/random". Each iteration of "Starting read from
/dev/random" is taking a minute to timeout and then returning with
"Opening /dev/random failed" and then it tries again for a total of 7 total tries.
Lack of system entropy to keep /dev/random fed?
More like lack of /dev/random completely.

Arne
Stephen Hoffman
2021-09-30 16:26:02 UTC
Permalink
Post by Lawrence D’Oliveiro
Lack of system entropy to keep /dev/random fed? This is why we have
/dev/urandom, for all but the most critical uses.
Within OpenVMS, there is no pseudo-device that provides either
pseudo-random number generation or cryptographic pseudo-random number
generation.

That driver (which would be unusual on OpenVMS), and system service
APIs (which are common) have been proposed. Kernel TLS has been
proposed, too.

OpenVMS itself hasn't more generally adopted CPRNG support at its
existing APIs, with the common APIs producing PRNGs.

Reasons not to update have been found, as per usual with OpenVMS upward
compatibility.

For one of the previous discussions of OpenVMS and CPRNGs and of
seeding an entropy pool:
https://groups.google.com/g/comp.os.vms/c/BmIXV0gN3n8/m/mETohq6qAgAJ

Within recent Linux kernel versions, /dev/random and /dev/urandom are
the same underneath, neither will block post-initialization, and both
will produce the same CPRNG values.
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2021-09-30 16:32:47 UTC
Permalink
Post by Stephen Hoffman
Post by Lawrence D’Oliveiro
Lack of system entropy to keep /dev/random fed? This is why we have
/dev/urandom, for all but the most critical uses.
Within OpenVMS, there is no pseudo-device that provides either
pseudo-random number generation or cryptographic pseudo-random number
generation.
That driver (which would be unusual on OpenVMS), and system service APIs
(which are common) have been proposed.
The "Entropy Engine," which I assume is what's under discussion here, is
on the roadmap for April 2022. Almost certainly x86-only and thus of no
help to the OP on OpenVMS Alpha 7.3-2.
Simon Clubley
2021-09-30 18:11:18 UTC
Permalink
Post by Stephen Hoffman
Within recent Linux kernel versions, /dev/random and /dev/urandom are
the same underneath, neither will block post-initialization, and both
will produce the same CPRNG values.
On the face of it, that change would seem to be a bad idea.

For some applications, it might be more important for them to actually
block until sufficient high-quality values are available.

Do you know the reason for the change ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2021-09-30 19:06:25 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
Within recent Linux kernel versions, /dev/random and /dev/urandom are
the same underneath, neither will block post-initialization, and both
will produce the same CPRNG values.
On the face of it, that change would seem to be a bad idea.
For some applications, it might be more important for them to actually
block until sufficient high-quality values are available.
Do you know the reason for the change ?
Once properly seeded, chacha20 or another recent stream cipher can
produce as much CPRNG data as might be needed.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2021-10-01 13:03:43 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
Post by Stephen Hoffman
Within recent Linux kernel versions, /dev/random and /dev/urandom are
the same underneath, neither will block post-initialization, and both
will produce the same CPRNG values.
On the face of it, that change would seem to be a bad idea.
For some applications, it might be more important for them to actually
block until sufficient high-quality values are available.
Do you know the reason for the change ?
Once properly seeded, chacha20 or another recent stream cipher can
produce as much CPRNG data as might be needed.
Hmmm, I see what they have done. Thanks Stephen.

I'm not convinced that it's actually a good idea.

Let's just hope someone doesn't come up with viable attacks against it.

I hope they at least do reseeding on a regular basis.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Lawrence D’Oliveiro
2021-10-01 00:53:39 UTC
Permalink
Post by Stephen Hoffman
Within recent Linux kernel versions, /dev/random and /dev/urandom are
the same underneath, neither will block post-initialization, and both
will produce the same CPRNG values.
Not a chance.

https://man7.org/linux/man-pages/man4/random.4.html
https://www.redhat.com/en/blog/understanding-random-number-generators-and-their-limitations-linux
https://unix.stackexchange.com/questions/324209/when-to-use-dev-random-vs-dev-urandom
Stephen Hoffman
2021-10-01 01:03:20 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by Stephen Hoffman
Within recent Linux kernel versions, /dev/random and /dev/urandom are
the same underneath, neither will block post-initialization, and both
will produce the same CPRNG values.
Not a chance.
https://lore.kernel.org/lkml/***@mit.edu/

"Change /dev/random so that it uses the CRNG and only blocking if the
CRNG hasn't initialized, instead of the old blocking pool. Also clean
up archrandom.h, and some other miscellaneous cleanups."
--
Pure Personal Opinion | HoffmanLabs LLC
Lawrence D’Oliveiro
2021-10-03 23:00:48 UTC
Permalink
Post by Stephen Hoffman
Post by Lawrence D’Oliveiro
Post by Stephen Hoffman
Within recent Linux kernel versions, /dev/random and /dev/urandom are
the same underneath, neither will block post-initialization, and both
will produce the same CPRNG values.
Not a chance.
"Change /dev/random so that it uses the CRNG and only blocking if the
CRNG hasn't initialized, instead of the old blocking pool. Also clean
up archrandom.h, and some other miscellaneous cleanups."
Just to be clear, the crucial difference between /dev/random and /dev/urandom is that the former will only ever return real entropy, and will block when it runs out, while the latter will start returning a merely pseudorandom number sequence. That is never going to change.

If you don’t believe me, check the source code for yourself <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c>. Note the difference between the “random_read” and “urandom_read” routines.
Arne Vajhøj
2021-10-01 01:07:03 UTC
Permalink
Post by Lawrence D’Oliveiro
Post by Stephen Hoffman
Within recent Linux kernel versions, /dev/random and /dev/urandom are
the same underneath, neither will block post-initialization, and both
will produce the same CPRNG values.
Not a chance.
https://man7.org/linux/man-pages/man4/random.4.html
https://www.redhat.com/en/blog/understanding-random-number-generators-and-their-limitations-linux
https://unix.stackexchange.com/questions/324209/when-to-use-dev-random-vs-dev-urandom
I believe Hoff is referring to the changes in Linux kernel 5.6
made in January that made the two more similar (even though I
believe there still is some difference).

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Random-Rework

Arne
Arne Vajhøj
2021-10-01 01:31:37 UTC
Permalink
Post by Stephen Hoffman
Post by Lawrence D’Oliveiro
Lack of system entropy to keep /dev/random fed? This is why we have
/dev/urandom, for all but the most critical uses.
Within OpenVMS, there is no pseudo-device that provides either
pseudo-random number generation or cryptographic pseudo-random number
generation.
That driver (which would be unusual on OpenVMS), and system service APIs
(which are common) have been proposed.  Kernel TLS has been proposed, too.
OpenVMS itself hasn't more generally adopted CPRNG support at its
existing APIs, with the common APIs producing PRNGs.
For one of the previous discussions of OpenVMS and CPRNGs and of seeding
https://groups.google.com/g/comp.os.vms/c/BmIXV0gN3n8/m/mETohq6qAgAJ
I have long time wanted to actually implement that thing.

This thread was a good excuse.

So I did.

https://www.vajhoej.dk/arne/opensource/extran/extran-v0_1.zip

Brief documentation:

/*
* get_extran_data
*
* arguments:
* buf - pointer to char array that will receive 32 random bytes
with SHA-256 of source data
* flags - mask of sources to use
* EXTRAN_TIM 8 bytes from SYS$GETTIM (not unpredictable)
* EXTRAN_SYI 112 bytes from SYS$GETSYIW
* EXTRAN_DVI_SYS 64 bytes from SYS$GETDVIW on
SYS$SYSDEVIVE
* EXTRAN_DVI_USR 64 bytes from SYS$GETDVIW on SYS$DISK
* EXTRAN_JPI 520 bytes from SYS$GETJPIW
* EXTRAN_CNT 40 bytes from an array of counters (not
unpredictable but ensures change with multiple calls)
* EXTRAN_HSH 32 bytes of SHA-256 of all other data
(not unpredictable but may make reversing more difficult)
*
* return value:
* SS$_NORMAL - 32 random bytes generated
* SS$_BADPARAM - non valid flags resulting in no random bytes
generated
*
*/
long int get_extran_data(char *buf, long int flag);

How to:

download
unzip
@build
use

Example:

#include <stdio.h>

#include "extran.h"

int main(int argc,char *argv[])
{
char buf[32];
int i;
get_extran_data(buf, EXTRAN_TIM + EXTRAN_SYI + EXTRAN_DVI_SYS +
EXTRAN_DVI_USR + EXTRAN_JPI + EXTRAN_CNT);
for(i = 0; i < 32; i++)
{
printf("%02X", (unsigned char)buf[i]);
}
printf("\n");
return 0;
}

Have fun.

(I will probably clean it up a bit and release an update later)

Arne
Arne Vajhøj
2021-10-02 23:59:42 UTC
Permalink
Post by Arne Vajhøj
I have long time wanted to actually implement that thing.
This thread was a good excuse.
So I did.
https://www.vajhoej.dk/arne/opensource/extran/extran-v0_1.zip
Have fun.
(I will probably clean it up a bit and release an update later)
Cleaned up and added an option to grab the top (actually bottom)
page of the stack and append that before hashing.

https://www.vajhoej.dk/arne/opensource/extran/extran-v0_2.zip

Arne
Simon Clubley
2021-09-30 12:17:16 UTC
Permalink
Post by sphowes
I am hoping someone may be able to help resolve an issue while opening an SSH or SCP session on an OpenVMS 7.3-2 cluster.
When a session is initiated to or from the server, the connection will hang for ~7 minutes before finally opening the connection and asking for a password.
It is not clear to me what is on the other end of the connection in
both these cases. Is it also a VMS system or is it something else ?

Can you confirm that the output you are seeing about /dev/random is
coming from a SSH client that is running on a VMS system ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-09-30 12:56:43 UTC
Permalink
Post by Simon Clubley
Post by sphowes
I am hoping someone may be able to help resolve an issue while opening an SSH or SCP session on an OpenVMS 7.3-2 cluster.
When a session is initiated to or from the server, the connection will hang for ~7 minutes before finally opening the connection and asking for a password.
It is not clear to me what is on the other end of the connection in
both these cases. Is it also a VMS system or is it something else ?
Can you confirm that the output you are seeing about /dev/random is
coming from a SSH client that is running on a VMS system ?
For the VMS systems, you also need to state which TCP/IP stack and
version you are using and if you are using the SSH client supplied
with that stack.

If you are, then make sure you have run the required startup command
procedure(s) for that stack at startup.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
sphowes
2021-09-30 16:44:36 UTC
Permalink
Post by Simon Clubley
Post by Simon Clubley
Post by sphowes
I am hoping someone may be able to help resolve an issue while opening an SSH or SCP session on an OpenVMS 7.3-2 cluster.
When a session is initiated to or from the server, the connection will hang for ~7 minutes before finally opening the connection and asking for a password.
It is not clear to me what is on the other end of the connection in
both these cases. Is it also a VMS system or is it something else ?
Can you confirm that the output you are seeing about /dev/random is
coming from a SSH client that is running on a VMS system ?
For the VMS systems, you also need to state which TCP/IP stack and
version you are using and if you are using the SSH client supplied
with that stack.
If you are, then make sure you have run the required startup command
procedure(s) for that stack at startup.
Simon.
--
Walking destinations on a map are further away than they appear.
Yes, we are using the SSH supplied version:

debug: Ssh2/SSH2.C:1847: CRTL version (SYS$SHARE:DECC$SHR.EXE ident) is V7.3-2-03

We are running the TCP startup command procedure at system boot time:
@SYS$STARTUP:TcpIp$STARTUP.COM
Stephen Hoffman
2021-09-30 17:05:56 UTC
Permalink
Post by sphowes
On 2021-09-30, Simon Clubley
If you are, then make sure you have run the required startup command
procedure(s) for that stack at startup.
debug: Ssh2/SSH2.C:1847: CRTL version (SYS$SHARE:DECC$SHR.EXE ident) is V7.3-2-03
@SYS$STARTUP:TcpIp$STARTUP.COM
Make sure SSH is started; ensure ssh has been configured within the
TCPIP$CONFIG tool.

Make sure your DNS configuration is correct and valid and one or more
DNS servers are not tossing timeouts.

And get off of twenty-year-old V7.3-2.
--
Pure Personal Opinion | HoffmanLabs LLC
sphowes
2021-09-30 16:37:37 UTC
Permalink
Post by Simon Clubley
Post by sphowes
I am hoping someone may be able to help resolve an issue while opening an SSH or SCP session on an OpenVMS 7.3-2 cluster.
When a session is initiated to or from the server, the connection will hang for ~7 minutes before finally opening the connection and asking for a password.
It is not clear to me what is on the other end of the connection in
both these cases. Is it also a VMS system or is it something else ?
Can you confirm that the output you are seeing about /dev/random is
coming from a SSH client that is running on a VMS system ?
Simon.
--
Walking destinations on a map are further away than they appear.
It doesn't matter if the connection is coming to/from another OpenVMS server or a Linux server, there is still the 7 minute wait. We have tried to/from multiple servers with the same delay. The "/dev/random" delay is definitely occurring on the OpenVMS server.
Stephen Hoffman
2021-09-30 16:54:35 UTC
Permalink
Post by sphowes
It doesn't matter if the connection is coming to/from another OpenVMS
server or a Linux server, there is still the 7 minute wait. We have
tried to/from multiple servers with the same delay. The "/dev/random"
delay is definitely occurring on the OpenVMS server.
Bad DNS is another option.

Wouldn't be the first configuration with sketchy DNS causing long delays.

Really needs an upgrade to V8.4-2L1 or V8.4-2L2, too.

Twenty-year-old software... has issues.
--
Pure Personal Opinion | HoffmanLabs LLC
sphowes
2021-09-30 17:04:19 UTC
Permalink
Post by Stephen Hoffman
Post by sphowes
It doesn't matter if the connection is coming to/from another OpenVMS
server or a Linux server, there is still the 7 minute wait. We have
tried to/from multiple servers with the same delay. The "/dev/random"
delay is definitely occurring on the OpenVMS server.
Bad DNS is another option.
Wouldn't be the first configuration with sketchy DNS causing long delays.
Really needs an upgrade to V8.4-2L1 or V8.4-2L2, too.
Twenty-year-old software... has issues.
--
Pure Personal Opinion | HoffmanLabs LLC
BIND is disabled on the cluster so it is not doing any DNS lookups.

I agree regarding upgrading the OS however the version of Oracle we are running is not supported past 7.3-2. Clusters are pretty much in "maintain" mode until a replacement option is built out, so this SSH/SCP issue is something that we would like to resolve, if possible, in the meantime.

I just wonder when it is trying to open "/dev/random" what is it actually trying to access? That must translate to something that is actually part of OpenVMS in the code.
Stephen Hoffman
2021-09-30 17:13:25 UTC
Permalink
Post by sphowes
BIND is disabled on the cluster so it is not doing any DNS lookups.
Whether or not you are running the BIND server locally, you can be
running the resolver, and that resolver can be slow.

Check your DNS translations for all of the hosts involved, forward and reverse.

Whether those translations are arising from the resolver, or from the
local hosts database.

And upgrade that twenty year old OpenVMS configuration soonest.
--
Pure Personal Opinion | HoffmanLabs LLC
sphowes
2021-09-30 17:18:25 UTC
Permalink
Post by Stephen Hoffman
Post by sphowes
BIND is disabled on the cluster so it is not doing any DNS lookups.
Whether or not you are running the BIND server locally, you can be
running the resolver, and that resolver can be slow.
Check your DNS translations for all of the hosts involved, forward and reverse.
Whether those translations are arising from the resolver, or from the
local hosts database.
And upgrade that twenty year old OpenVMS configuration soonest.
--
Pure Personal Opinion | HoffmanLabs LLC
Yes, I meant that the BIND resolver is not setup. This even happens when opening an SSH session to localhost, which is defined in the local host database.

I hear you on the upgrade, but it is not as simple as "just upgrade" the environment. Wish it was my call, wish it was that easy. LOL
abrsvc
2021-09-30 17:35:38 UTC
Permalink
Post by Stephen Hoffman
Post by sphowes
BIND is disabled on the cluster so it is not doing any DNS lookups.
Whether or not you are running the BIND server locally, you can be
running the resolver, and that resolver can be slow.
Check your DNS translations for all of the hosts involved, forward and reverse.
Whether those translations are arising from the resolver, or from the
local hosts database.
And upgrade that twenty year old OpenVMS configuration soonest.
--
Pure Personal Opinion | HoffmanLabs LLC
Yes, I meant that the BIND resolver is not setup. This even happens when opening an SSH session to localhost, which is defined in the local host database.
I hear you on the upgrade, but it is not as simple as "just upgrade" the environment. Wish it was my call, wish it was that easy. LOL
I have seen similar behavior with an invalid/obsolete gateway address too.

Dan
Stephen Hoffman
2021-09-30 18:48:53 UTC
Permalink
Post by sphowes
Yes, I meant that the BIND resolver is not setup. This even happens
when opening an SSH session to localhost, which is defined in the local
host database.
Set up the resolver off-hours then, and confirm that DNS translations
work. Each DNS timeout will usually add ~30 seconds. And I've seen
these configs go into the weeds with bad DNS.
Post by sphowes
I hear you on the upgrade, but it is not as simple as "just upgrade"
the environment. Wish it was my call, wish it was that easy. LOL
Yeah, it really is that easy.

That's having experience with more than a few of these "we can never
upgrade in [x] years" cases getting upgraded in surprisingly short
order.

Once management was forced to move and forced to spend, and could not
continue to defer maintenance for whatever reason. Outside audits, for
instance.
--
Pure Personal Opinion | HoffmanLabs LLC
Scott Dorsey
2021-09-30 22:44:36 UTC
Permalink
Post by sphowes
BIND is disabled on the cluster so it is not doing any DNS lookups.
Bingo! I bet a nickel that's your issue right there. I bet it is doing
multiple DNS lookups and that it can be disabled through the config file.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Loading...