>> (...) Why does it have to obtain the
machine's IP, that of the tftp
>> server and what else via rarp?
> It can't obtain anything but its own address via rarp. [...]
(Well, and the address of the machine that answered the RARP request.)
It's
possible that it initially queries whoever answered its RARP,
but if it gets no answer it broadcasts the query - and I think it
broadcasts the TFTP request too if necessary.
Funny...I don't remember setting
up a bootp(aram)d, I started getting
tftp requests as soon as the rarp table was setup.
Then I guess it must TFTP from whoever answered the RARP.
I also don't think the requests were broadcast: I
was running another
machine ready to serve tftp at the same time and that one didn't get
any requests.
That's normal if the TFTP is answered, but...
I was even able to shut down Linux after the rarp
resolution (if tftp
was disabled), bring the same system up with Windows (under the same
IP) and have the Sun slurp its bootloader image from there.
...this is unusual, if the other machine *still* didn't get any
requests.
I suppose it must be a PROM version difference, with some machines, or
some versions, behaving differently from others. I'm quite sure I've
seen requests - TFTP requests, I think, but maybe not - being sent
unicast at first and then broadcast if the first one goes unanswered.
Oh well.
It looks like I can initiating the execution of
unnamed subroutine
(f00...) by entering f00... execute; any gotchas there?
I have no idea; I don't (didn't) know enough FORTH to try that.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B