strandedinnz wrote:
oooh sudden thought ... I'm thinking Dina might only netboot a server that it has seen broadcast it's MAC address out onto the LAN in a request to get an IP (from Dina), and that the TFTP session might get tied to that MAC address/IP address.
You are absolutely correct Mark.
That is the way Dina is working and I will explain why.
When an SGI computer requests a netboot it first request an IP number from a BOOTP or DHCP server and once it get it will request the files to be transfered by TFTP.
There are three things that complicates this process.
1 When an SGI request an IP number it can send a "prefered" IP number to the BOOTP server.
The BOOTP server can honor this request or it can disregard it and give another IP number. If I remember correctly the boot sequence did not work if the bootp server didn't honor the request.
One way of ensuring this is to clear the "netaddr" environment variable as this holds the preferred IP. The SGI machine will store any BOOTP received IP in this variable so it will only be clear until the next netboot atempt.
2 The way the TFTP request work is really strange.
Instead of just asking the boot server directly for the file you have specified. It will send the TFP request string with server name (or IP) and path for the TFTP file to the BOOTP server.
Please note that this is no TFTP request.
This initial communication simply sends the
String
that it will later on use to make the TFTP request. This string is sent as part of the IP request to the BOOTP server.
The BOOTP server will then return the string back to the Client together with the IP number it has granted the client.
At this time the Client will set its IP number and then make a regular TFTP request to the server and to the path that it got from the BOOTP server.
So if the BOOTP server want to it can alter the TFTP string and point to a different server or to a different file. Now it actually never does this. It always returns the TFTP string unaltered, expect in one case, and that brings us to issue three.
3 The ISC DHCP server that is standard in NetBSD has a bug (feature??) that makes it blank out the TFTP string if it returns a IP number to a client that is not listed in its config files for hosts.
Now the listing of hosts with their MAC numbers and their corresponding IP addresses is purely optional. It is only used when you want to make sure that a specific computer gets a specific IP number in return from the DHCP server.
This is rarely used nowadays as you are normally only interested in getting
any
IP number from a DHCP server.
Well I guess TFTP isn't used that much any more as the ISC DHCP server clearly has a bug that alters (blanks) the TFTP string if it cant find a MAC and IP number for the client in it's config files.
So to solve this rather unfortunately chain of circumstances in the interoperability of an SGI client and an ISC DHCP server one could just simply add the MAC address of all ones SGI computers in the ISC config files and modify the netaddr variable in the SGI computer to match the given IP number but I didn't like that so I came up with a script that does that automatically.
For this to work, the DHCP server has to be the one to decide what IP number the SGI computer must use.
Thats the reason why you
must
clear the netaddr variable. If you don't, the SGI computer thinks
it
can decide what IP number to use.
Quote:
1) Disable DHCP on your home router
2) Do not assign an IP address to your indigo ... "unsetenv netaddr" ... or maybe clear things completely and resetenv ?
3) Then try : boot -f bootp()<IPaddressofDina>:/irix/6.5/1/stand/fx.ARCS --x
See if the fx program gets loaded.
Regards
Mark
You are right again Mark.
As outlined in my documentation, this is the correct way to ensure that you can netboot from Dina to either run fx or the stand-alone shell.
//Harry
