OpenVMS x86 Field Test questions, reports, and feedback.
-
Topic author
cct
- Valued Contributor
- Posts: 95
- Joined: Sat Aug 15, 2020 9:00 am
- Reputation: 0
- Location: Cambridge, UK
-
Status:
Offline
Post
by cct » Sun Apr 23, 2023 10:45 am
Having got 9.2-1 working nicely under KVM/QEMU on an Intel NUC12 with an i5 running Ubuntu 22.04 LTS I am seeing an odd one with DHCP
Decnet plus and TCP/IP services installed and working fine, but:
Code: Select all
$ show net
Product: DECNET Node: VMS2 Address(es): 1.10
Product: TCP/IP Node: <TCP/IP host/node name not yet available> Address(es): 0.0.0.0
$ show net "TCP/IP" /full
Product: TCP/IP Manufacturer: VMS Software, Inc.
Node: [b]<TCP/IP host/node name not yet available> Address(es): 0.0.0.0[/b]
Network Type: TCP/IP Interface(s):
VSI TCP/IP Services for OpenVMS x86_64 Version X6.0
on a QEMU Standard PC (Q35 + ICH9, 2009) running OpenVMS E9.2-1
Port Remote
Device_socket Type Local Remote Service Host
bg26 STREAM 49152 0 *
bg27 STREAM 49153 49152 127.0.0.1
bg28 STREAM 49152 49153 127.0.0.1
bg35 DGRAM 68 0 *
bg37 RAW_IP 0 0 *
bg43 STREAM 21 0 FTP *
bg54 STREAM 22 0 SSHD22 *
bg1081 STREAM 22 55301 SSHD22 192.168.1.158
bg1092 STREAM 49196 49195 127.0.0.1
bg1093 STREAM 49195 49196 127.0.0.1
Communication Parameters
Local host: VMS2 Domain: fritz.box
Maximum Current Peak
Proxies 20
Remote Terminal
Large buffers: 0
UCBs: 0
Virtual term: disabled
This is with a bridged network
I can happily ssh into the VM from my network, and as above the interface is mapped and working#
So why is it showing
<TCP/IP host/node name not yet available> Address(es): 0.0.0.0
Also it is showing an ip address that is not being used - it has correctly been given 192.168.1.137
Any ideas?
Chris
--
Chris
-
martinv
- Master
- Posts: 102
- Joined: Fri Jun 14, 2019 11:05 pm
- Reputation: 0
- Location: Goslar, Germany
-
Status:
Offline
-
Contact:
Post
by martinv » Mon Apr 24, 2023 1:54 am
Hi!
It seems that SYS$MANAGER:SYS$NET_SERVICES_TCPIP.COM doesn't get executed after the system gets configured via DHCP. Once you execute it manually, SHOW NET does show the hostname and IP.
DHCP does seem to be a litte shaky. My hostname does not get propagated to our DNS server. But then, I've seen oddities with those DHCP/DNS server and other clients, too, so perhaps it's not VMS fault.
HTH,
Martin
Last edited by
martinv on Mon Apr 24, 2023 3:12 am, edited 1 time in total.
Working hard for something we don't care about is called stress;
working hard for something we love is called passion.
(Simon Sinek)
-
nix23
- Member
- Posts: 9
- Joined: Fri Apr 14, 2023 9:53 am
- Reputation: 0
-
Status:
Offline
Post
by nix23 » Mon Apr 24, 2023 2:59 am
DHCP is definitely funny, i have a Wireless-Bridge (OpenWRT) and my workstation (and with it the virtualized OpenVMS) is connected to it. The OpenVMS-DHCP-Client took the IP of that Bridge, i have never seen that with any other OS, but it created kind of a "funny" fight between OpenVMS and the Bridge
-
Topic author
cct
- Valued Contributor
- Posts: 95
- Joined: Sat Aug 15, 2020 9:00 am
- Reputation: 0
- Location: Cambridge, UK
-
Status:
Offline
Post
by cct » Mon Apr 24, 2023 6:55 am
martinv wrote: ↑Mon Apr 24, 2023 1:54 am
Hi!
It seems that SYS$MANAGER:SYS$NET_SERVICES_TCPIP.COM doesn't get executed after the system gets configured via DHCP. Once you execute it manually, SHOW NET does show the hostname and IP.
DHCP does seem to be a litte shaky. My hostname does not get propagated to our DNS server. But then, I've seen oddities with those DHCP/DNS server and other clients, too, so perhaps it's not VMS fault.
HTH,
Martin
Thanks, running that seems to work. The address show before is of course my remote address of my workstation. I now get:
Code: Select all
$ show net /full "TCP/IP"
Product: TCP/IP Manufacturer: VMS Software, Inc.
Node: VMS2.fritz.box Address(es): 192.168.1.151
Network Type: TCP/IP Interface(s):
VSI TCP/IP Services for OpenVMS x86_64 Version X6.0
on a QEMU Standard PC (Q35 + ICH9, 2009) running OpenVMS E9.2-1
Port Remote
Device_socket Type Local Remote Service Host
bg26 STREAM 49152 0 *
bg27 STREAM 49153 49152 127.0.0.1
bg28 STREAM 49152 49153 127.0.0.1
bg35 DGRAM 68 0 *
bg37 RAW_IP 0 0 *
bg43 STREAM 21 0 FTP *
bg54 STREAM 22 0 SSHD22 *
bg1563 STREAM 22 55417 SSHD22 192.168.1.158
bg1574 STREAM 49205 49204 127.0.0.1
bg1575 STREAM 49204 49205 127.0.0.1
Communication Parameters
Local host: VMS2 Domain: fritz.box
Maximum Current Peak
Proxies 20
Remote Terminal
Large buffers: 0
UCBs: 0
Virtual term: disabled
However the IP address it shows is now being used, but is another node on the network. Again weird.
Should I add the SYS$NET_SERVICES_TCPIP call to SYSTARTUP_VMS? or is there a better way?
Chris
--
Chris
-
imiller
- Master
- Posts: 136
- Joined: Fri Jun 28, 2019 8:45 am
- Reputation: 0
- Location: South Tyneside, UK
-
Status:
Offline
-
Contact:
Post
by imiller » Mon Apr 24, 2023 10:27 am
Have a look in SYS$SYSDEVICE:[TCPIP$DHCP] at the log files to see what the DHCP is asking for and what it is getting.
You can edit DHCLIENT.CONF to add some information for the client.
What have you set up in the core menu of TCPIP$CONFIG ?
Ian Miller
[ personal opinion only. usual disclaimers apply. Do not taunt happy fun ball ].
-
debbee.west
- VSI Expert
-
Contributor
- Posts: 12
- Joined: Mon Oct 07, 2019 11:10 am
- Reputation: 0
-
Status:
Offline
Post
by debbee.west » Mon Apr 24, 2023 11:20 am
I do not see this issue on my VM.
Code: Select all
$ prod show prod tcpip
prod show prod tcpip
------------------------------------ ----------- ---------
PRODUCT KIT TYPE STATE
------------------------------------ ----------- ---------
VSI X86VMS TCPIP X6.0-20 Full LP Installed
------------------------------------ ----------- ---------
I enabled dhcp on a freshly built system. I rebooted (for several reasons). Here is what I got:
$ sho net
sho net
Product: DECNET Node: SUP861 Address(es): 1.501
Product: TCP/IP Node: SUP861 Address(es): 10.10.113.241
If you want to update this output manually, you should be able to do so by running the command procedure
Code: Select all
$ dir sys$manager:*net*serv*.com
dir sys$manager:*net*serv*.com
Directory SYS$COMMON:[SYSMGR]
SYS$NET_SERVICES_TCPIP.COM;1
Total of 1 file.
Hope that helps.
Last edited by
marty.stu on Thu Apr 27, 2023 4:59 pm, edited 1 time in total.
-
Topic author
cct
- Valued Contributor
- Posts: 95
- Joined: Sat Aug 15, 2020 9:00 am
- Reputation: 0
- Location: Cambridge, UK
-
Status:
Offline
Post
by cct » Tue Apr 25, 2023 6:32 am
imiller wrote: ↑Mon Apr 24, 2023 10:27 am
Have a look in SYS$SYSDEVICE:[TCPIP$DHCP] at the log files to see what the DHCP is asking for and what it is getting.
You can edit DHCLIENT.CONF to add some information for the client.
What have you set up in the core menu of TCPIP$CONFIG ?
The logs look OK, showing the correct IP address
Usual stuff set up from TCPIP$CONFIG
Just about to reboot to see how it comes up
Chris
Added in 14 minutes :
debbee.west wrote: ↑Mon Apr 24, 2023 11:20 am
I do not see this issue on my VM.
$ prod show prod tcpip
prod show prod tcpip
------------------------------------ ----------- ---------
PRODUCT KIT TYPE STATE
------------------------------------ ----------- ---------
VSI X86VMS TCPIP X6.0-20 Full LP Installed
------------------------------------ ----------- ---------
I enabled dhcp on a freshly built system. I rebooted (for several reasons). Here is what I got:
$ sho net
sho net
Product: DECNET Node: SUP861 Address(es): 1.501
Product: TCP/IP Node: SUP861 Address(es): 10.10.113.241
If you want to update this output manually, you should be able to do so by running the command procedure
$ dir sys$manager:*net*serv*.com
dir sys$manager:*net*serv*.com
Directory SYS$COMMON:[SYSMGR]
SYS$NET_SERVICES_TCPIP.COM;1
Total of 1 file.
Hope that helps.
Thanks for that.
I have just rebooted again, and this time it comes up with a random new IP address. I still needed to manually run SYS$NET_SERVICES_TCPIP.COM
I gave this up on 8.4-2L1 and moved to TCPware
I think I will cut my losses, and just give it the same IP address that I allocate on the router. Shame as I much prefer to manage all addresses with DHCP
It is a shame that DHCP cannot be sorted to manage DHCP correctly - these days I don't have any issues with other O/Ss
Chris
Chris
--
Chris