Re: Getting started netbooting a NeXTcube

Hi David,

When I was learning about how NEXTSTEP networking "works," I remember =
being very confused about BOOTP. It's entirely possible that my =
confusion was entirely due to lack of knowledge of TCP/IP and networking =
itself, but I do seem to recall some weird behavior that sounds like the =
race conditions you're describing.

I say go for it: Set up a BOOTP server and then see what happens. It's =
entirely possible that the race condition is a separate issue. But it's =
also possible that's normal behavior and the NeXT will take a different =
path if it receives a prompt reply to its BOOTP request.

Brian


On Sep 26, 2021, at 18:23, David Ross <[email protected]> wrote:
> Hey Brian,
>=20
> Thanks for that response, and it's great to know there are still
> people hanging out on this list.  =3D)
>=20
> The next thing I was going to try (and probably will try in any event)
> is in fact to set up a BOOTP server.  The reason I didn't go do that
> yet is only because the strange behavior I'm seeing from the NeXTcube
> makes me think it won't work.  To me, it looks like a kind of a race
> condition, where the link is only up for a very short period of time,
> and during that time, a BOOTP packet _might_ make it out.  When
> booting with "ben" I will see a BOOTP packet sometimes, but it's quite
> inconsistent.  And then I see the link immediately go down.  In fact,
> in some cases it appears the link never even turns on at all.  Maybe
> there's some setting configured that could cause this?
>=20
> My thinking is that I could have a BOOTP server responding to the
> BOOTP packet, but then the link will still go down regardless.  And it
> won't even work half the time because the BOOTP packet doesn't always
> go out.
>=20
> If anyone has free time and a NeXT handy, here's what might help a =
bit:
> 1)  Plug in an empty ethernet network switch into the NeXT, just to
> observe if the link LED turns on.
> 2)  Boot into the ROM monitor using Command-`
> 3)  Type "ben" to boot from the network.
> 4)  Observe what gets displayed on the console.  Also, does the link
> light on the ethernet switch turn on?  And if so, does it stay on or
> turn off after a second or two?
>=20
> Dave
>=20
> On Sun, Sep 26, 2021 at 6:05 PM Brian Willoughby =
<[email protected]> wrote:
>>=20
>> Hi David,
>>=20
>> When booting from disk, BOOTP is a critical step to getting on the =
network, and things like NetInfo won't even work without it.
>>=20
>> However, I'm not sure what happens if there isn't a BOOTP response. I =
assume that the NEXTSTEP OS on disk would still launch, but the network =
would not function, and all configuration from NetInfo would necessarily =
be absent.
>>=20
>> Since netboot has no disk to fall back on, I'm going to assume that =
BOOTP is absolutely essential to get working before the netboot can even =
begin.
>>=20
>> I became very familiar with BOOTP while creating my own multi-tier =
NetInfo hierarchy of NeXTcube, NeXTstation, and even SPARCstation =
machines. Some of the information is duplicated on multiple machines in =
case one machine goes down, because things won't boot if the BOOTP =
server is down. Obviously, I had to toss all that knowledge and learn =
DHCP with newer systems. I seem to recall that DHCP is a superset of =
BOOTP, and it might even be true that some or all DHCP servers have the =
ability to respond to BOOTP requests.
>>=20
>> I have very little knowledge of netboot, but I would recommend that =
you set up a BOOTP server in conjunction / coordination with the netboot =
server. Once the machine receives a BOOTP response, it will probably =
then continue on to load the OS from the netboot server.
>>=20
>> Just remember: NEXTSTEP is older than DHCP, and certainly older than =
ZeroConf (Bonjour).
>>=20
>> Brian
>>=20
>>=20
>> On Sep 26, 2021, at 15:53, David Ross <[email protected]> =
wrote:
>>> Hey port-next68k,
>>>=20
>>> I've managed to acquire a NeXTcube and I'm playing around with =
getting
>>> the old netbsd port up and running on it.  Since it was only ever =
set
>>> up to netboot, I'm starting there.  Unfortunately I'm seeing some
>>> really weird behavior...
>>>=20
>>> The ethernet network connection seems to work fine.  When I boot up
>>> via the hard drive, I see it recognizes when it's plugged in and
>>> attempts to retrieve network configuration.  Sniffing on the network =
I
>>> see BOOTP packets.
>>>=20
>>> However, when I attempt to netboot from the ROM monitor, I'm seeing
>>> that the network only comes up for a brief period of time, if at =
all.
>>> During that time, in some cases a BOOTP packet manages to make it =
out.
>>> I haven't gone any further to try to respond to the BOOTP packet =
yet.
>>>=20
>>> Any idea what might be causing this behavior, or how it might be
>>> fixed?  Can anyone attest to what the normal behavior is when
>>> netbooting?  (I'd expect the network comes up & stays up, and BOOTP
>>> packets continue to get sent on some interval until there's a
>>> response.)
>>>=20
>>> David Ross
>>> [email protected]
>>>=20
>>=20
>=20