Ok, I got my main server rebuilt and so it's time to run some simh for testing (particularly the new user mode routing stuff).
However, I'm still fighting this:
wonko at zaphod$ BIN/vax
VAX simulator V3.9-0
sim> set cpu idle
Command not allowed
sim> set cpu idle=VAX
Invalid argument
sim>
I'd really like for IDLE to work so I can run several copies of simh without nuking my CPUs.
Thoughts?
wonko at zaphod$ uname -a
SunOS zaphod 5.11 oi_151a5 i86pc i386 i86pc Solaris
-brian
IIRC object-specific default accounts (for FAL, PHONE and so on) appeared in version 5.0. In previous versions the setup command procedure just asked for the DECNET account.
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 15/09/2012, a les 21:00, Peter Coghlan <HECNET at beyondthepale.ie> va escriure:
I don't have a good understanding of default accounts when using NETCONFIG.
I would like to allow people to list files in a specific directory (DIR
NODE::), PHONE me and MAIL me. Does this mean I need to specify default
accounts for FAL, MAIL and PHONE? If so, what is the purpose of the "Default
DECnet account", which is the first of the questions in the sequence below:
My understanding of it (which might not be correct) is that the default
FAL account is used if someone remote does not specify a username and password
when doing a file access on your machine, the default PHONE account is used
when someone remote PHONEs your machine without specifying a username and
password and the default MAIL account is used when someone remotely sends
MAIL-11 mail to your machine without specifying a username and password (Is
it even possible to specify a username and password with PHONE and MAIL?)
So for example, files which FAL$SERVER has rights to access will be made
available to anyone who remotely tries to access them without their having to
specify a valid username and password on your machine.
If no username and password is specified by someone attempting to access
anything remotely on your machine and no suitable default account is available
for the activity in question, the default DECnet account will then be used if
available.
Therefore (I think) the default DECnet account is a catchall and if you have
one, you are granting anyone remote from your machine, some level of access to
all DECnet services on your machine.
I can't see any real use for it except for people who are too lazy to set up
the other few default accounts that they really want which offer finer control
over what services are made available remotely. I seem to remember default
DECnet accounts going out of favour and being regarded as a security risk.
(In addition to default accounts, default proxies also come into play here but
I thought it better not to further complicate things by mentioning them...)
Regards,
Peter Coghlan.
I don't have a good understanding of default accounts when using NETCONFIG.
I would like to allow people to list files in a specific directory (DIR
NODE::), PHONE me and MAIL me. Does this mean I need to specify default
accounts for FAL, MAIL and PHONE? If so, what is the purpose of the "Default
DECnet account", which is the first of the questions in the sequence below:
My understanding of it (which might not be correct) is that the default
FAL account is used if someone remote does not specify a username and password
when doing a file access on your machine, the default PHONE account is used
when someone remote PHONEs your machine without specifying a username and
password and the default MAIL account is used when someone remotely sends
MAIL-11 mail to your machine without specifying a username and password (Is
it even possible to specify a username and password with PHONE and MAIL?)
So for example, files which FAL$SERVER has rights to access will be made
available to anyone who remotely tries to access them without their having to
specify a valid username and password on your machine.
If no username and password is specified by someone attempting to access
anything remotely on your machine and no suitable default account is available
for the activity in question, the default DECnet account will then be used if
available.
Therefore (I think) the default DECnet account is a catchall and if you have
one, you are granting anyone remote from your machine, some level of access to
all DECnet services on your machine.
I can't see any real use for it except for people who are too lazy to set up
the other few default accounts that they really want which offer finer control
over what services are made available remotely. I seem to remember default
DECnet accounts going out of favour and being regarded as a security risk.
(In addition to default accounts, default proxies also come into play here but
I thought it better not to further complicate things by mentioning them...)
Regards,
Peter Coghlan.
I don t have a good understanding of default accounts when using NETCONFIG. I would like to allow people to list files in a specific directory (DIR NODE::), PHONE me and MAIL me. Does this mean I need to specify default accounts for FAL, MAIL and PHONE? If so, what is the purpose of the Default DECnet account , which is the first of the questions in the sequence below:
Do you want a default DECnet account? [NO]: yes
Do you want default access to the TASK object disabled? [YES]:
Do you want a default account for the MAIL object? [YES]:
Do you want a default account for the FAL object? [NO]: yes
Do you want a default account for the PHONE object? [YES]:
Do you want a default account for the NML object? [YES]:
Regards
Rob
And the link is https://route20.codeplex.com/
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rob Jarratt Sent: 15 September 2012 08:11 To: hecnet at update.uu.se Subject: [HECnet] Second Alpha Release of User Mode DECnet Router
This second alpha release fixes some bugs and limitations. It has been tested in two DECnet areas and seems to be stable enough for more extensive testing.
Interested in any and all feedback.
Regards
Rob
This second alpha release fixes some bugs and limitations. It has been tested in two DECnet areas and seems to be stable enough for more extensive testing.
Interested in any and all feedback.
Regards
Rob
On 14/09/12 21:29, John H. Reinhardt wrote:
On 9/14/12 3:51 PM, Mark Wickens wrote:
On 14/09/12 20:37, Dennis Boone wrote:
> so I updated the MODPARAMS.DAT, rebooted and ran NETCONFIG.COM, but I'm
> getting errors when attempting to reach out over the ethernet. I know
> the physical network connection is OK because tcpip is working fine.
Wasn't there something about starting DECnet first? Try rebooting again
now that the reconfig is done.
De
Well, I never thought this would fix a VMS issue, but rebooting it solved the problem.
Sorry for wasting your bandwidth ;)
Thanks for the help!!!
Mark.
As Dave says, DECnet needs to change the MAC address on the network interface. If you booted and TCP/IP came up and then you fiddled with and started DECnet, the MAC address was already locked in by TCP And DECnet wasn't able to change it. The rebooting allowed things to happen in the proper order. Technically, you could have stopped TCP and then started DECnet and then re-started TCP and it probably would have worked - unless the sysgen parameters were needed and then only the reboot would have done it.
John H. Reinhardt
Yes, of course that makes total sense. It's been a while since I did anything with DECnet, as I say, all this stuff slowly dribbles out of my brain...
Cheers, Mark.
On Sep 14, 2012, at 4:19 PM, Dave McGuire wrote:
On 09/14/2012 03:37 PM, Dennis Boone wrote:
so I updated the MODPARAMS.DAT, rebooted and ran NETCONFIG.COM, but I'm
getting errors when attempting to reach out over the ethernet. I know
the physical network connection is OK because tcpip is working fine.
Wasn't there something about starting DECnet first? Try rebooting again
now that the reconfig is done.
Starting DECnet changes the MAC address of the interface...could it
have been an ordering dependency there?
-Dave
That's definitely a dependency, unless you have a type of interface that supports multiple MAC addresses. The early ones (UNA and Lance) do not. QNA does, LQA emulates that but doesn't really want to. Tulip and later DEC-designed Ethernet adapters (and the FDDI adapters, for those of you that have one) all support multiple MAC addresses, because it was written into the DEC Ethernet architecture specification as a requirement.
paul
On 9/14/12 3:51 PM, Mark Wickens wrote:
On 14/09/12 20:37, Dennis Boone wrote:
> so I updated the MODPARAMS.DAT, rebooted and ran NETCONFIG.COM, but I'm
> getting errors when attempting to reach out over the ethernet. I know
> the physical network connection is OK because tcpip is working fine.
Wasn't there something about starting DECnet first? Try rebooting again
now that the reconfig is done.
De
Well, I never thought this would fix a VMS issue, but rebooting it solved the problem.
Sorry for wasting your bandwidth ;)
Thanks for the help!!!
Mark.
As Dave says, DECnet needs to change the MAC address on the network interface. If you booted and TCP/IP came up and then you fiddled with and started DECnet, the MAC address was already locked in by TCP And DECnet wasn't able to change it. The rebooting allowed things to happen in the proper order. Technically, you could have stopped TCP and then started DECnet and then re-started TCP and it probably would have worked - unless the sysgen parameters were needed and then only the reboot would have done it.
John H. Reinhardt