Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Netbooting a PDP-11
299 views
Skip to first unread message
Bill Gunshannon
Jan 18, 2019, 6:48:12 PM1/18/19
to
I am starting to play with netbooting a PDP-11.
My DECServer looks for and requests a specific named file
from the mop server. My VXT2000+ likewise. The VAX looks
for a file with the name being its ethernet address and
typical .SYS ending the other systems use. What would
the PDP-11 be looking for? I tried the ethernet address
scheme but that wasn't it. Looking at the packets being
sent it does not appear to be some specific name. I know
that netbooting was never supported but the ROM sends MOP
DL packets to MOP Server so it must be looking for something.
bill
terry-...@glaver.org
Jan 19, 2019, 2:22:56 PM1/19/19
to
DEC Canada. As I recall, the DECserver 5x0 (the only PDP-11 based
ones) would take whatever file the MOP server cared to send it, and
the MOP server based that decision on the MAC address of the request
(the VMS MOP server stored the mappings in the DECnet database, my
RSTS/E one used a plain-text configuration file). This is because the
DX5x0 configuration was actually stored in the software download image
and not in configuration NVRAM on the DECserver (being a PDP-11, the
DS5x0 didn't have any such NVRAM). So the DS5x0 didn't know the name
of the image it wanted.
However, the DS5x0 used an S-handle PDP-11/53 or 11/53+ board with a
special set of boot ROMs, not the standard 11/53 console ROMs. So I'm
not sure if this will work for a generic 11/53 (or other PDP-11 model).
Just because the DEQNA/DELQA sends those requests doesn't necessarily
mean they'll ever make it to host memory and be executed.
Bill Gunshannon
Jan 19, 2019, 3:11:06 PM1/19/19
to
and several VS3100's all talking to my MOP Server. I can see by
watching both network traffic and debug output from the MOP server
that my PDP-11/93 is sending MOP requests to the MOP Server. What
I don't know is what is it requesting?
The DECServer wants: PR0801ENG.SYS
The VXT2000+ wants: VXT2000.SYS
The VS3100 wants: {MAC Address}.SYS
What does a PDP-11 want?
bill
John Forecast
Jan 19, 2019, 8:20:49 PM1/19/19
to
On Jan 19, 2019, Bill Gunshannon wrote
(in article <gaheio...@mid.individual.net>):
At this point probably a secondary loader which will ask for a tertiary
loader which will ask for the operating system.
On RSX (assuming a DEQNA, may be the same for a DELQA, I’m not sure):
Secondary loader: SECQNA.SYS
Tertiary loader: TERQNA.SYS
Typically the tertiary loader will ask for “Standard operating system”
(code -1) and rely on the MOP server to map the request
to an appropriate image.
John.
>
> bill
(in article <gaheio...@mid.individual.net>):
loader which will ask for the operating system.
On RSX (assuming a DEQNA, may be the same for a DELQA, I’m not sure):
Secondary loader: SECQNA.SYS
Tertiary loader: TERQNA.SYS
Typically the tertiary loader will ask for “Standard operating system”
(code -1) and rely on the MOP server to map the request
to an appropriate image.
John.
>
> bill
Bill Gunshannon
Jan 19, 2019, 9:45:41 PM1/19/19
to
But now another question. I assumed it would just ask for
a bootloader of some kind I just didn't know what file it
wou7ld ask for by name, but how can it ask for two
different ones? Once the first image gets downloaded it
would be in control and anything else loaded would be
asked for by it.
bill
Bill Gunshannon
Jan 19, 2019, 9:51:48 PM1/19/19
to
So if I put out a file on my MOP Server called SECQNA.SYS it will get
requested by the PDP-11 and sent by the MOP Server and it is up to
the PDP-11 to know what to do with it. Have to give it a try.
bill
John Forecast
Jan 19, 2019, 11:34:35 PM1/19/19
to
On Jan 19, 2019, Bill Gunshannon wrote
(in article <gai622...@mid.individual.net>):
servers may use different names. The initial
bootstrap issues a “request program” MOP request with “program type”
== 0, meaning secondary loader (this loader must
fit in a single message). The secondary loader issues another “request
program” MOP request with “program type” == 1,
meaning tertiary loader (this loader can occupy multiple messages). The
tertiary loader turns on memory management and
issues another “program request” with “program type” == 2, meaning
system and “software ID form” == -1 which means
standard operating system. Basically, the MOP server can use whatever names
it likes!
John.
Bill Gunshannon
Jan 20, 2019, 9:16:31 AM1/20/19
to
the MOP Server. You are saying the file is determined
by something called "program type" but the DECServer
request has the file name in the packet. I haven't
tried it lately, (but I will today just to see) but
I am pretty sure the VXT2000+ does as well. I would
have expected the PDP-11 to work the same way the VAX
does, but apparently it does not. Need more decodind
of packets before I can do this, I think.
bill
John Forecast
Jan 20, 2019, 12:57:24 PM1/20/19
to
On Jan 20, 2019, Bill Gunshannon wrote
(in article <gaje5t...@mid.individual.net>):
Bitsavers has the MOP spec(s) available in pdf/dec/decnet - 4.0.0 is the
latest but I was looking at v3. When requesting a system image the MOP server
should look at the optional “software ID” field. This is a counted string
with special handling when the count is <= 0:
0 - Not present, use default load image (same if the whole “software ID”
field is missing)
-1 - Load standard operating system
-2 - Load diagnostic image
If the count > 0, it is left up to the MOP server to translate the string
into a filename. The 4.0.0 spec includes a discussion of how this can happen
(page 111). The RSX implementation provides static images for each
secondary/tertiary loader so there is no way to the requested program - I’m
pretty sure it defaults to “standard O/S” or, more likely, “not
present". If you want something else you can force a particular image with
“NCP LOAD...” command.
My earlier comment about the sequencing of loaders was the worse case. DEQNA
is a dumb device and has to go through the whole sequence; primary ->
secondary -> tertiary -> O/S. DELQA is a more intelligent device with an
embedded M68K processor, it bypasses the secondary loader so the sequence is;
primary -> tertiary -> O/S.
John.
(in article <gaje5t...@mid.individual.net>):
latest but I was looking at v3. When requesting a system image the MOP server
should look at the optional “software ID” field. This is a counted string
with special handling when the count is <= 0:
0 - Not present, use default load image (same if the whole “software ID”
field is missing)
-1 - Load standard operating system
-2 - Load diagnostic image
If the count > 0, it is left up to the MOP server to translate the string
into a filename. The 4.0.0 spec includes a discussion of how this can happen
(page 111). The RSX implementation provides static images for each
secondary/tertiary loader so there is no way to the requested program - I’m
pretty sure it defaults to “standard O/S” or, more likely, “not
present". If you want something else you can force a particular image with
“NCP LOAD...” command.
My earlier comment about the sequencing of loaders was the worse case. DEQNA
is a dumb device and has to go through the whole sequence; primary ->
secondary -> tertiary -> O/S. DELQA is a more intelligent device with an
embedded M68K processor, it bypasses the secondary loader so the sequence is;
primary -> tertiary -> O/S.
John.
Bill Gunshannon
Jan 21, 2019, 9:41:38 AM1/21/19
to
for "DEC MOP" on Google does not find any of this.
> When requesting a system image the MOP server
> should look at the optional “software ID” field. This is a counted string
> with special handling when the count is <= 0:
>
> 0 - Not present, use default load image (same if the whole “software ID”
> field is missing)
> -1 - Load standard operating system
> -2 - Load diagnostic image
the MOP Server source again and try to find the part where it opens
files for transmission.
>
> If the count > 0, it is left up to the MOP server to translate the string
> into a filename. The 4.0.0 spec includes a discussion of how this can happen
> (page 111). The RSX implementation provides static images for each
> secondary/tertiary loader so there is no way to the requested program - I’m
> pretty sure it defaults to “standard O/S” or, more likely, “not
> present". If you want something else you can force a particular image with
> “NCP LOAD...” command.
>
> My earlier comment about the sequencing of loaders was the worse case. DEQNA
> is a dumb device and has to go through the whole sequence; primary ->
> secondary -> tertiary -> O/S. DELQA is a more intelligent device with an
> embedded M68K processor, it bypasses the secondary loader so the sequence is;
> primary -> tertiary -> O/S.
I am not sure what it is trying to "boot" considering there is already
and OS loaded and running on that particular PDP-11. I only worked
with RSX once about 35 years ago and wasn't impressed enough to try
any more.) I an still trying to figure out what the PDP-11, as
compared to the VAX and other devices, is trying to load from the
boot ROM.
bill
John Forecast
Jan 21, 2019, 1:58:11 PM1/21/19
to
On Jan 21, 2019, Bill Gunshannon wrote
(in article <gam410...@mid.individual.net>):
Well, my (emulated) VMS 7.3 and Ultrix 2.2 systems have the “NCP LOAD...”
command available. The “Enter MOP Mode” protocol message can be sent to
an unattended node to force a reboot and load a, potentially different, O/S
image. Unfortunately, the DEQNA does not handle this message itself and
requires the PDP-11 driver code to be active. The DELQA can process the
“Enter MOP Mode” message and force a reboot. I think down-line load
support first showed up in DECnet phase II and the only target supported was
RSX-11S. Over time, the protocol was extended to support VAXes, terminal
server and other disk-less servers.
Look in the MOP specification for “Request Program” - that will tell you
what can be requested. The only way to tell what the PDP-11 is actually
asking for is to capture the protocol exchange.
John.
(in article <gam410...@mid.individual.net>):
command available. The “Enter MOP Mode” protocol message can be sent to
an unattended node to force a reboot and load a, potentially different, O/S
image. Unfortunately, the DEQNA does not handle this message itself and
requires the PDP-11 driver code to be active. The DELQA can process the
“Enter MOP Mode” message and force a reboot. I think down-line load
support first showed up in DECnet phase II and the only target supported was
RSX-11S. Over time, the protocol was extended to support VAXes, terminal
server and other disk-less servers.
Look in the MOP specification for “Request Program” - that will tell you
what can be requested. The only way to tell what the PDP-11 is actually
asking for is to capture the protocol exchange.
John.
Bill Gunshannon
Jan 21, 2019, 2:54:48 PM1/21/19
to
name (like PR0801ENG.SYS for the DECServer 200) it isn't
really clear from the packet capture. I have been reading
the source for the MOP Daemon I hav ebeen running and it
may be that they didn't institute everything. It looks
like they were only really interested in the VAX so I may
need to modify that server to handles general; MOP DL packets
or find another MOP server.
Thanks for all the info, though. I have learned a lot the
past couple of days and that is always a good thing.
bill
Bill Gunshannon
Jan 22, 2019, 8:08:56 AM1/22/19
to
For those who were following and might still be interested in this
thread. I have determined that what the PDP-11/93 is asking for
when I say BOOT XH is the "tertiary loader", name unspecified. If
I could determine what the name should be I might get the MOP Server
to respond. I had already tried SECQNA but we now know it isn't
looking for the "secondary loader". So, I tried TERQNA, but that
also had no result. I then noticed the PDP-11 coding in the packet
that the ethernet was a DELQA and not DEQNA. So I tried TERLQA just
to see what happened. Nothing. It might still be that the MOP
Server is unaware of PDP-11's so further research and maybe code
modification are still needed.
bill
Bob Eager
Jan 22, 2019, 7:29:47 PM1/22/19
to
On Tue, 22 Jan 2019 22:47:10 +0000, Huge wrote:
> On 2019-01-22, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>
>> For those who were following and might still be interested in this
>> thread.
>
> I'm fascinated. I didn't know you even *could* netboot an '11!
It was homebrew, but we had a load of 11/03s that we booted down a DL-11.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
> On 2019-01-22, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>
>> For those who were following and might still be interested in this
>> thread.
>
It was homebrew, but we had a load of 11/03s that we booted down a DL-11.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Christian Corti
Jan 23, 2019, 4:50:01 AM1/23/19
to
Bill Gunshannon <bill.gu...@gmail.com> wrote:
> when I say BOOT XH is the "tertiary loader", name unspecified. If
> I could determine what the name should be I might get the MOP Server
> to respond. I had already tried SECQNA but we now know it isn't
Why don't you use wireshark/ethereal and sniff the network to find out
> when I say BOOT XH is the "tertiary loader", name unspecified. If
> I could determine what the name should be I might get the MOP Server
> to respond. I had already tried SECQNA but we now know it isn't
what packets are being sent/received and what data they contain?
Christian
Bill Gunshannon
Jan 23, 2019, 9:55:36 AM1/23/19
to
a "tertiary loader" is sent. The name is not specified and it
apparently assumes the MOP Server will know the name and send it.
I, however do not know the name and so I can't put a file on
the MOP Server to meet the request. And, I have not yet found
anything in the MOP Server source to answer the question. Still
working on it, among my many other Legacy System projects.
bill
Tim Sneddon
Jan 23, 2019, 10:15:24 AM1/23/19
to
a REPLY/ENABLE to get OPCOM messages. That might give you a
clue as to the name of the file if it can't be found. Obviously
you don;t seem to have it, but the MOP server from VMS may have
the inner magic to correctly construct the appropriate filename.
Regards, Tim.
Bill Gunshannon
Jan 23, 2019, 10:36:44 AM1/23/19
to
bill
John Forecast
Jan 23, 2019, 11:43:05 AM1/23/19
to
On Jan 22, 2019, Bill Gunshannon wrote
(in article <gaoiv6...@mid.individual.net>):
That all seems reasonable. I just checked my RSX-11M+ image and it doesn’t
include loaders for the DELQA (this is the last released version of
DECnet-M+). It’s really up to the MOP server to perform the mapping to
local file names. The PDP-11 or, in this case the DELQA, sends a request
“I’m a DELQA, send me a tertiary loader”, it’s only when you get to
O/S loading that a filename may be sent. BTW, early DELQAs sent 31 as their
device code while later versions sent 37 so the MOP server has to handle
both.
Newer systems such as terminal servers, routers etc had much larger ROMs than
PDP-11 and it’s possible that they completely bypass the secondary/tertiary
loaders and directly request O/S loading. If the MOP server you are using was
designed for loading such systems, it’s possible that it knows nothing
about PDP-11’s.
John.
(in article <gaoiv6...@mid.individual.net>):
include loaders for the DELQA (this is the last released version of
DECnet-M+). It’s really up to the MOP server to perform the mapping to
local file names. The PDP-11 or, in this case the DELQA, sends a request
“I’m a DELQA, send me a tertiary loader”, it’s only when you get to
O/S loading that a filename may be sent. BTW, early DELQAs sent 31 as their
device code while later versions sent 37 so the MOP server has to handle
both.
Newer systems such as terminal servers, routers etc had much larger ROMs than
PDP-11 and it’s possible that they completely bypass the secondary/tertiary
loaders and directly request O/S loading. If the MOP server you are using was
designed for loading such systems, it’s possible that it knows nothing
about PDP-11’s.
John.
Bill Gunshannon
Jan 23, 2019, 12:56:51 PM1/23/19
to
On 1/23/19 11:43 AM, John Forecast wrote:
> On Jan 22, 2019, Bill Gunshannon wrote
> (in article <gaoiv6...@mid.individual.net>):
>
>>
>> For those who were following and might still be interested in this
>> thread. I have determined that what the PDP-11/93 is asking for
>> when I say BOOT XH is the "tertiary loader", name unspecified. If
>> I could determine what the name should be I might get the MOP Server
>> to respond. I had already tried SECQNA but we now know it isn't
>> looking for the "secondary loader". So, I tried TERQNA, but that
>> also had no result. I then noticed the PDP-11 coding in the packet
>> that the ethernet was a DELQA and not DEQNA. So I tried TERLQA just
>> to see what happened. Nothing. It might still be that the MOP
>> Server is unaware of PDP-11's so further research and maybe code
>> modification are still needed.
>
> That all seems reasonable. I just checked my RSX-11M+ image and it doesn’t
> include loaders for the DELQA (this is the last released version of
> DECnet-M+). It’s really up to the MOP server to perform the mapping to
> local file names.
True.
> On Jan 22, 2019, Bill Gunshannon wrote
> (in article <gaoiv6...@mid.individual.net>):
>
>>
>> For those who were following and might still be interested in this
>> thread. I have determined that what the PDP-11/93 is asking for
>> when I say BOOT XH is the "tertiary loader", name unspecified. If
>> I could determine what the name should be I might get the MOP Server
>> to respond. I had already tried SECQNA but we now know it isn't
>> looking for the "secondary loader". So, I tried TERQNA, but that
>> also had no result. I then noticed the PDP-11 coding in the packet
>> that the ethernet was a DELQA and not DEQNA. So I tried TERLQA just
>> to see what happened. Nothing. It might still be that the MOP
>> Server is unaware of PDP-11's so further research and maybe code
>> modification are still needed.
>
> That all seems reasonable. I just checked my RSX-11M+ image and it doesn’t
> include loaders for the DELQA (this is the last released version of
> DECnet-M+). It’s really up to the MOP server to perform the mapping to
> local file names.
> The PDP-11 or, in this case the DELQA, sends a request
having a BOOT ROM with code in it they do nothing on their own.
> “I’m a DELQA, send me a tertiary loader”, it’s only when you get to
> O/S loading that a filename may be sent. BTW, early DELQAs sent 31 as their
> device code while later versions sent 37 so the MOP server has to handle
> both.
ethernet card.
My PDP-11's send DELQA or DEQNA.
My VAXes send DESVA.
My DECServer send DEUNA.
I don;t really know of what value that is to the MOP Server other
than pure info.
>
> Newer systems such as terminal servers, routers etc had much larger ROMs than
> PDP-11 and it’s possible that they completely bypass the secondary/tertiary
> loaders and directly request O/S loading.
some reason. The PDP-11's go straight for the "tertiary loader".
Which makes sense, because it can be as big as it needs to be to
load an OS or anything else limited only by the memory limitations
of the PDP_11.
> If the MOP server you are using was
> designed for loading such systems, it’s possible that it knows nothing
> about PDP-11’s.
I am using was. But I know it is used now to load DECServers and
VXT2000's from BSD Unix systems (there is talk of using it from
Linux as well, but I have been unable to get it to compile on any
current Linux distribution). And, for netbooting VAXes. I honestly
don;t think anyone has even looked at the concept of booting a
PDP-11 over the network like I am trying to do. I have seen
cases of "booting" it over serial lines, XINU and vtserver, but
I think I am in totally new ground.
bill
Richard
Jan 23, 2019, 1:04:59 PM1/23/19
to
[Please do not mail me a copy of your followup]
Bill Gunshannon <bill.gu...@gmail.com> spake the secret code
<gardj5...@mid.individual.net> thusly:
>On 1/23/19 4:31 AM, Christian Corti wrote:
>> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>> when I say BOOT XH is the "tertiary loader", name unspecified. If
>>> I could determine what the name should be I might get the MOP Server
>>> to respond. I had already tried SECQNA but we now know it isn't
>>
>> Why don't you use wireshark/ethereal and sniff the network to find out
>> what packets are being sent/received and what data they contain?
>>
>
>I have wireshark and moptrace and other tools. A request for
>a "tertiary loader" is sent. The name is not specified and it
>apparently assumes the MOP Server will know the name and send it.
IIRC, you were using a MOP Server on linux? If so, could you strace
the server to see what file it tries to load?
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Bill Gunshannon <bill.gu...@gmail.com> spake the secret code
<gardj5...@mid.individual.net> thusly:
>On 1/23/19 4:31 AM, Christian Corti wrote:
>> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>> when I say BOOT XH is the "tertiary loader", name unspecified. If
>>> I could determine what the name should be I might get the MOP Server
>>> to respond. I had already tried SECQNA but we now know it isn't
>>
>> Why don't you use wireshark/ethereal and sniff the network to find out
>> what packets are being sent/received and what data they contain?
>>
>
>I have wireshark and moptrace and other tools. A request for
>a "tertiary loader" is sent. The name is not specified and it
>apparently assumes the MOP Server will know the name and send it.
the server to see what file it tries to load?
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Bill Gunshannon
Jan 23, 2019, 2:06:10 PM1/23/19
to
On 1/23/19 1:04 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Bill Gunshannon <bill.gu...@gmail.com> spake the secret code
> <gardj5...@mid.individual.net> thusly:
>
>> On 1/23/19 4:31 AM, Christian Corti wrote:
>>> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>>> when I say BOOT XH is the "tertiary loader", name unspecified. If
>>>> I could determine what the name should be I might get the MOP Server
>>>> to respond. I had already tried SECQNA but we now know it isn't
>>>
>>> Why don't you use wireshark/ethereal and sniff the network to find out
>>> what packets are being sent/received and what data they contain?
>>>
>>
>> I have wireshark and moptrace and other tools. A request for
>> a "tertiary loader" is sent. The name is not specified and it
>> apparently assumes the MOP Server will know the name and send it.
>
> IIRC, you were using a MOP Server on linux? If so, could you strace
> the server to see what file it tries to load?
>
Not Linux, but close. :-) BSD. And the problem is it doesn't
> [Please do not mail me a copy of your followup]
>
> Bill Gunshannon <bill.gu...@gmail.com> spake the secret code
> <gardj5...@mid.individual.net> thusly:
>
>> On 1/23/19 4:31 AM, Christian Corti wrote:
>>> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>>> when I say BOOT XH is the "tertiary loader", name unspecified. If
>>>> I could determine what the name should be I might get the MOP Server
>>>> to respond. I had already tried SECQNA but we now know it isn't
>>>
>>> Why don't you use wireshark/ethereal and sniff the network to find out
>>> what packets are being sent/received and what data they contain?
>>>
>>
>> I have wireshark and moptrace and other tools. A request for
>> a "tertiary loader" is sent. The name is not specified and it
>> apparently assumes the MOP Server will know the name and send it.
>
> IIRC, you were using a MOP Server on linux? If so, could you strace
> the server to see what file it tries to load?
>
try to load any file. It takes in a request from the remote
system and if it knows what file and has that file it will try
to load it. If not, it just ignores the request (probably
assuming there is m ore than one MOP Server around and the
other may service this request.) Only the DECServer and the
VXT2000+ make their requests by name. The VAX and the PDP-11
request a type of file. The MOPServer knows what to do with
the VAX request, it does not know what to do with the PDP-11
request. Probably because no one ever asked before. :-)
bill
amp...@gmail.com
Jan 23, 2019, 4:18:15 PM1/23/19
to
On Wednesday, January 23, 2019 at 2:06:10 PM UTC-5, Bill Gunshannon wrote:
> Not Linux, but close. :-) BSD. And the problem is it doesn't
> try to load any file. It takes in a request from the remote
> system and if it knows what file and has that file it will try
> to load it. If not, it just ignores the request (probably
> assuming there is m ore than one MOP Server around and the
> other may service this request.) Only the DECServer and the
> VXT2000+ make their requests by name. The VAX and the PDP-11
> request a type of file. The MOPServer knows what to do with
> the VAX request, it does not know what to do with the PDP-11
> request. Probably because no one ever asked before. :-)
I'm not sure if there's more than one BSD mopd, but there's source for one at http://ftp.vim.org/os/BSD/NetBSD/NetBSD-current/src/usr.sbin/mopd/mopd/ and that ones man page seems to include this text:
> Not Linux, but close. :-) BSD. And the problem is it doesn't
> try to load any file. It takes in a request from the remote
> system and if it knows what file and has that file it will try
> to load it. If not, it just ignores the request (probably
> assuming there is m ore than one MOP Server around and the
> other may service this request.) Only the DECServer and the
> VXT2000+ make their requests by name. The VAX and the PDP-11
> request a type of file. The MOPServer knows what to do with
> the VAX request, it does not know what to do with the PDP-11
> request. Probably because no one ever asked before. :-)
"Upon receiving a request, mopd checks if the requested file exists in /tftpboot/mop. The filename is normally all uppercase and with an extension of .SYS. If the filename isn't given, the Ethernet address of the target is used as filename (e.g., 08002b09f4de.SYS), and it might be a soft link to another file."
that man page also says mopd can take option -d:
"-d Run in debug mode, with all the output to stdout. The process will run in the foreground."
Maybe try running it with -d and see if anything helpful is displayed?
Bill Gunshannon
Jan 23, 2019, 4:37:10 PM1/23/19
to
-d all along but it buys nothing. If mopd doesn't know the answer
it can't send it to the console for me to read. :-)
Actually, moptrace provides much more information about the exchange
between the MOP Server and the client.
bill
Bob Eager
Jan 23, 2019, 6:00:32 PM1/23/19
to
On Wed, 23 Jan 2019 13:18:14 -0800, amp1ron wrote:
> On Wednesday, January 23, 2019 at 2:06:10 PM UTC-5, Bill Gunshannon
> wrote:
>> Not Linux, but close. BSD. And the problem is it doesn't try to
> On Wednesday, January 23, 2019 at 2:06:10 PM UTC-5, Bill Gunshannon
> wrote:
>> load any file. It takes in a request from the remote system and if it
>> knows what file and has that file it will try to load it. If not, it
>> just ignores the request (probably assuming there is m ore than one MOP
>> Server around and the other may service this request.) Only the
>> DECServer and the VXT2000+ make their requests by name. The VAX and
>> the PDP-11 request a type of file. The MOPServer knows what to do
>> with the VAX request, it does not know what to do with the PDP-11
>> request. Probably because no one ever asked before.
>
>> knows what file and has that file it will try to load it. If not, it
>> just ignores the request (probably assuming there is m ore than one MOP
>> Server around and the other may service this request.) Only the
>> DECServer and the VXT2000+ make their requests by name. The VAX and
>> the PDP-11 request a type of file. The MOPServer knows what to do
>> with the VAX request, it does not know what to do with the PDP-11
>> request. Probably because no one ever asked before.
>
> I'm not sure if there's more than one BSD mopd, but there's source for
> one at
> http://ftp.vim.org/os/BSD/NetBSD/NetBSD-current/src/usr.sbin/mopd/mopd/
> and that ones man page seems to include this text:
>
> "Upon receiving a request, mopd checks if the requested file exists in
> /tftpboot/mop. The filename is normally all uppercase and with an
> extension of .SYS. If the filename isn't given, the Ethernet address of
> the target is used as filename (e.g., 08002b09f4de.SYS), and it might be
> a soft link to another file."
>
> that man page also says mopd can take option -d:
That is the same one that is a standard FreeBSD port as net/mopd.
> one at
> http://ftp.vim.org/os/BSD/NetBSD/NetBSD-current/src/usr.sbin/mopd/mopd/
> and that ones man page seems to include this text:
>
> "Upon receiving a request, mopd checks if the requested file exists in
> /tftpboot/mop. The filename is normally all uppercase and with an
> extension of .SYS. If the filename isn't given, the Ethernet address of
> the target is used as filename (e.g., 08002b09f4de.SYS), and it might be
> a soft link to another file."
>
> that man page also says mopd can take option -d:
terry-...@glaver.org
Jan 23, 2019, 6:01:28 PM1/23/19
to
On Wednesday, January 23, 2019 at 2:06:10 PM UTC-5, Bill Gunshannon wrote:
> And the problem is it doesn't
> try to load any file. It takes in a request from the remote
> system and if it knows what file and has that file it will try
> to load it. If not, it just ignores the request (probably
> assuming there is m ore than one MOP Server around and the
> other may service this request.) Only the DECServer and the
> VXT2000+ make their requests by name. The VAX and the PDP-11
> request a type of file. The MOPServer knows what to do with
> the VAX request, it does not know what to do with the PDP-11
> request. Probably because no one ever asked before. :-)
I think I said that, up in the very first reply to this thread 8-)
> try to load any file. It takes in a request from the remote
> system and if it knows what file and has that file it will try
> to load it. If not, it just ignores the request (probably
> assuming there is m ore than one MOP Server around and the
> other may service this request.) Only the DECServer and the
> VXT2000+ make their requests by name. The VAX and the PDP-11
> request a type of file. The MOPServer knows what to do with
> the VAX request, it does not know what to do with the PDP-11
> request. Probably because no one ever asked before. :-)
It turns out that I had the source to the RSTS/E MOP server I
wrote, available on my server all the time:
https://www.glaver.org/ftp/tmk-software/mop-server
In particular, note this from the README file:
| Correctly handle cases where the requesting devices passes no load
| image information, as well as the case where a 0-length image name is
| supplied. (PCSA remote boot, VAX/VMS satellite boot)
In that same directory you will find the official DEC documen-
tation for the MOP protocol (V4.0.0, despite the filename) and
the MOP Registry of defined device types and protocols.
Bill Gunshannon
Jan 23, 2019, 6:54:55 PM1/23/19
to
moment I am thinking my best bet would be to look at how the VAX
is handled in the MOP Server I am using and modify it to do the
same for the PDP-11. I only have DELQA and DEQNA to worry about.
Shouldn't be too hard to use those values as triggers.
bill
0 new messages