x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
-
Topic author - Active Contributor
- Posts: 27
- Joined: Tue Apr 23, 2024 6:28 am
- Reputation: 0
- Status: Offline
x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
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
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
- Attachments
-
- CHECK_LINK_STATE.TXT
- (933 Bytes) Downloaded 365 times
Re: x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
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.
-
- Master
- Posts: 193
- Joined: Sat Aug 15, 2020 9:00 am
- Reputation: 0
- Location: Cambridge, UK
- Status: Offline
Re: x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
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
--
Chris
Chris
-
Topic author - Active Contributor
- Posts: 27
- Joined: Tue Apr 23, 2024 6:28 am
- Reputation: 0
- Status: Offline
Re: x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
Thanks for advice, I shall raise an issue in Service Platform.
-
- VSI Expert
- Valued Contributor
- Posts: 55
- Joined: Thu Jun 20, 2019 11:48 am
- Reputation: 0
- Status: Offline
Re: x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
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
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
--
-- Rob
-- Rob
-
- Master
- Posts: 166
- Joined: Fri Jun 28, 2019 8:45 am
- Reputation: 0
- Location: South Tyneside, UK
- Status: Offline
- Contact:
Re: x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
@Alex,
are you running DECnet?
are you running DECnet?
Ian Miller
[ personal opinion only. usual disclaimers apply. Do not taunt happy fun ball ].
[ personal opinion only. usual disclaimers apply. Do not taunt happy fun ball ].
-
Topic author - Active Contributor
- Posts: 27
- Joined: Tue Apr 23, 2024 6:28 am
- Reputation: 0
- Status: Offline
Re: x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
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.
- Attachments
-
- SHSYS.TXT
- (1.59 KiB) Downloaded 341 times
-
Topic author - Active Contributor
- Posts: 27
- Joined: Tue Apr 23, 2024 6:28 am
- Reputation: 0
- Status: Offline
Re: x86 OpenVMS 9.2-2 DHCP client issue in virtualbox
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."
"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."