x86 OpenVMS 9.2-2 DHCP client issue in virtualbox

[alexwong]

DHCP client startup fails with the message in tcpip$dhcp_client_run.log,
Error getting hardware address for: "IE0"

Tried Bridged/NAT/Host-only networks, all had the same issue. No ip address is assigned to the lan interface BUT if I restart the DHCP client after a login, it works. Turns out it's a timing issue with EIA0: link state still down when TCPIP$STARTUP.COM in SYSTARTUP_VMS.COM starts. I made a helper procedure to check the link state before starting TCPIP and found a 6 sec delay was needed. Searching thru the SP issues database and forums, I found nothing related which is odd as I assume most would use TCPIP to connect. Just wondering if someone else has come across this and got a better idea. Does this warrant raising an issue with VSI?

Virtualbox Version 7.0.14 r161095 (Qt5.15.2)
Windows 11
x86 OpenVMS 9.2-2 VMDK

[sms]

Code: Select all

   I've never tried a VMS DHCP client, so I know nothing, but is there
any chance of blaming DECnet for fiddling with the MAC address?

> [...] Does this warrant raising an issue with VSI?

   I'd say so, if you have a way to do that other than this posting.

[cct]

I've never tried a VMS DHCP client, so I know nothing, but is there
any chance of blaming DECnet for fiddling with the MAC address?

> [...] Does this warrant raising an issue with VSI?

I'd say so, if you have a way to do that other than this posting.

At various times it has worked.
I think it is correct to raise this, as most sysadmins want to control their network using DHCP, rather than have random 'fixed' addresses cropping up

On recent Alphas, I used TCPWare where it does work. No reason for it not to work on X86

[alexwong]

Thanks for advice, I shall raise an issue in Service Platform.

[roberbrooks]

This will be an interesting problem.

We've seen a similar problem where MSCP-served disks from Alpha/IA64 systems to virtual machines take longer than expected to be visible and mountable. Even after f$getdvi( "<devnam>", "EXISTS" ) returns TRUE, it does *not* mean that the disk will actually mount -- a delay loop is still needed.

As the author of the $GETDVI LAN_* item codes, I'm glad to see at least one of them being put to good use.


-- Rob

[imiller]

@Alex,
are you running DECnet?

[alexwong]

DECnet-Plus is installed by default in the VMDK but I have not run NET$CONFIGURE at all. Was planning to setup a TCPIP-only network.

[alexwong]

VSI has provided a workaround for this issue, see below. I have tested it and DHCP client startup completes with no error so my CHECK_LINK_STATE procedure in SYSTARTUP_VMS.COM is no longer necessary. Thanks, VSI.

"A fix is being implemented for this situation for V9.2-3. In the meantime,
you can address the situation with the following workaround:

$ MC SYSGEN
SYSGEN> USE CURRENT
SYSGEN>SET LAN_FLAGS %X00004000
SYSGEN>WRITE CURRENT
SYSGEN>EXIT

Reboot

This changes how the LAN driver accomodates the “Link Up” condition,
be actually waiting for it, rather than assuming a second’s delay
between initialization and actual link up state."