| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 9477.1 | bootp compatibility mode? | MIPSBX::"[email protected]" | Brian Haley | Mon Apr 14 1997 12:23 | 18 |
| Hi,
Make sure you have joind configured for bootp compatibility. In xjoin
it's on the Server/Security Parameters window, or you can edit
/etc/join/server.pcy and make sure support_bootp is uncommented.
If other systems can do bootp ok, then you might want to do a tcpdump
(or sniffer) trace to see what file the DECserver is asking for.
Sometimes the request will just be for 'file' and not '/tftpboot/file',
you might have to specify a directory or absolute path in the /etc/bootptab
entry because I don't believe joind will look in an alternate directory
for files like bootpd does.
Bootpd is on the obsolete subsets now, OSFOBSOLETE400 if you're
running V4.0.
-Brian
[Posted by WWW Notes gateway]
|
| 9477.2 | Still not working... | CSC32::A_LICAUSE | | Mon Apr 14 1997 14:47 | 22 |
| Thanks to .1
Question: We have checked /etc/join/server.pcy and noticed that the
line support_bootp exists and is uncommented. But when I go into xjoin
and manipulate the BOOTP Compatibility switch under Server/Security
Parameters as you suggested, it doesn't change the value of this line
in server.pcy or place or remove the comment.
Are the two related?
As I recall this is set to true in the customers system.
We have checked inetd.conf and have added the -r /tftpboot information
to tftpd and have tested it with tftp 0 and it does work.
We have tried different image file names for the terminal server load
file and it still doesn't work. It is simply not engaging tftp and it
is not placing any information in daemon.log.
We'll try tcpdump next.
Al
|
| 9477.3 | joind does not invoke tftpd | NNTPD::"[email protected]" | Farrell Woods | Wed Apr 16 1997 16:45 | 38 |
| when joind serves bootp clients (and this goes for bootpd as well), all it
does is to respond to a boot request with a pile of information. It's
up to the bootp client, whatever that may be, to do something with the
information that is handed to it by the bootp server.
In other words, the client then has to ask for the boot file after the
bootp server tell it what file to ask for. That act on the part of the
client is what kicks tftpd into action.
BTW you have a class B network but you're using a class C netmask? This
doesn't seem right...
You can use the packetfilter to see what occurs between the client and the
server. Once you have the packetfilter configured, this one-liner will
be sufficient to see all of the relevent traffic:
% tcpdump -i tu0 -l -s 360 port 67 or port 68 or port 69
Ports 67 and 68 are the bootp client and server ports, as you may already
know. Port 69 is the tftp control/command port. You should see a "tftp
read request" get sent to the server by the client on this port. Obviously
this should happen after the initial bootp request/reply.
You could possibly be running into some hassles if the server is not on
the same IP subnet as the client. In this case the client has to go to
a bit more trouble in order to properly communicate with the tftp server
(that is, it may have to use a router.) In this case the bootptab file
must also have extra fields set up to reflect such a configuration.
Joind's debugging info should also tell you if joind sees and is responding
to the client's boot requests.
-- Farrell
[Posted by WWW Notes gateway]
|