BootP problem

I've been searching for information on how to set-up my Linux box to act as a BootP server.  I have to take my Twinax connected IPDS printers and connect them to my ethernet IP network which requires an I-data box which in turn requires BootP to acquire it's IP address, netmask, and gateway (router address) on power-up.

My server is a P133 with a 3C590 PCI NIC running RedHat Linux 4.1.  IP is up and running... I can ping to/from it and telnet to it from anywhere in my intranet.  I've also been able to have it serve as a TFTP, FTP and web server and it currently is acting as a DNS (named).  I've looked at the man pages and I think I have things set-up properly.  I've also placed a sniffer on the network segment I'm testing this on.  It shows the bootp request from the i-data box followed by a bootp response from my Linux box.  The response however is only sending the IP address for the intended host -- nothing else.  It continues in that cycle until I kill the I-data box.  I print the test sheet from the I-data box which shows it's unable to communicate with the bootp server and it's IP address is the one I placed in the bootptab file but NO NETMASK and NO GATEWAY.  

If anyone has any ideas on this one I would be forever indebted.  If not specific to this problem I could also use some pointers on where possible error logs from bootp might be stored and how to shut down and restart the bootp server.

I'll increase points if the entire question is answered. Again, any help is welcome and greatly appreciated!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Could you post your /etc/bootptab file?  I've never had trouble with bootp (RH-4.1) so I'd guess that you've got something wierd in there.  Incidentally, if you have another linux box, you can test bootp without getting out the sniffer: there's a program called bootptest that sends a request packet to the server and prints out what it gets back.  If you make a fake entry with the other linux box's ethernet address and the rest of the entry copied from your printer, maybe bootptest will tell you something.

Your other questions:

I think the stock RH-4.1 setup has bootpd started from inetd (you have to uncomment the line in /etc/inetd.conf).  Once it's been started, it keeps running for the number of minutes specified in the "-t" option (forever if there is no "-t").  You can also start it in stand-alone mode (don't forget to turn off the bootp line in /etc/inetd.conf and send a HUP signal to inetd).  In standalone mode, bootpd keeps running forever.  (The bootpd man page is a little confused on all this, but none of it should affect you.)

If you want to have bootpd re-read its configuration file, send it a HUP signal.  If you want to find out what information is in the bootp database to be sent to clients, send a USR1 signal -- bootp will write that information into /tmp/bootpd.dump.

Finally, the best place to look for errors and other messages from bootpd is /var/log/messages.  That file is maintained by syslog, a daemon whose job is to log info/warning/error messages. There's a config file for syslog, too (/etc/syslog.conf); if you're trying to debug some system service and you can't find the error messages, temporarily turn on *all* message logging and check again.  To turn on all messages, add a line like:

*.*      /tmp/everything.log

to /etc/syslog.conf and send syslogd a HUP signal.  That'll create a file called "/tmp/everything.log" and store all messages there.  When you get done debugging, don't forget to turn it off -- it can get big pretty quickly!

BTW, I've said "send a signal" several times; in case you don't know how, here's a quick explanation:

Find the PID of the daemon you want to signal:

ps -ax | grep daemon-name | grep -v grep

You'll see a line like:

  120  ?  S    0:04 syslogd

The first number on the line is the PID.  To send it a signal, say:


For example:

kill -HUP 120

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
wstreeteAuthor Commented:
Thanks for the response (and the explanation of sending a signal). I'll try what you suggested tomorrow.  In the mean time the files you wanted to see are shown below.  As soon as I get comments on the bootptab file I'll grade your answer. I'm not sure if this is correct -- the examples I had for the I-data box were for OS/2 and AIX.  The IBM AIX example resembled Linux the most so I assimilated it.  Thanks again for the response.

Here's the bootptab file, 2 lines, 1st one with a \ then CR:

[streetew@linuxone /etc]$ cat bootptab\

This is my inetd.conf file, bootps line is down in the file:
[streetew@linuxone /etc]$ cat inetd.conf|more
# inetd.conf    This file describes the services that will be available
#               through the INETD TCP/IP super server.  To re-configure
#               the running INETD process, edit this file, then send the
#               INETD process a SIGHUP signal.
# Version:      @(#)/etc/inetd.conf     3.10    05/27/93
# Authors:      Original taken from BSD UNIX 4.3/TAHOE.
#               Fred N. van Kempen, <>
# Modified for Debian Linux by Ian A. Murdock <>
# Modified for RHS Linux by Marc Ewing <>
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
# Echo, discard, daytime, and chargen are used primarily for testing.
# To re-read this file after changes, just do a 'killall -HUP inetd'
#echo   stream  tcp     nowait  root    internal
#echo   dgram   udp     wait    root    internal
#discard        stream  tcp     nowait  root    internal
#discard        dgram   udp     wait    root    internal
#daytime        stream  tcp     nowait  root    internal
#daytime        dgram   udp     wait    root    internal
#chargen        stream  tcp     nowait  root    internal
#chargen        dgram   udp     wait    root    internal
# These are standard services.
ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -a
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
gopher  stream  tcp     nowait  root    /usr/sbin/tcpd  gn
# do not uncomment smtp unless you *really* know what you are doing.
# smtp is handled by the sendmail daemon now, not smtpd.  It does NOT
# run from here, it is started at boot time from /etc/rc.d/rc#.d.
#smtp   stream  tcp     nowait  root    /usr/bin/smtpd  smtpd
#nntp   stream  tcp     nowait  root    /usr/sbin/tcpd  in.nntpd
# Shell, login, exec and talk are BSD protocols.
shell   stream  tcp     nowait  root    /usr/sbin/tcpd  in.rshd
login   stream  tcp     nowait  root    /usr/sbin/tcpd  in.rlogind
#exec   stream  tcp     nowait  root    /usr/sbin/tcpd  in.rexecd
talk    dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  in.ntalkd
#dtalk  stream  tcp     waut    nobody  /usr/sbin/tcpd  in.dtalkd
# Pop and imap mail services et al
pop-2   stream  tcp     nowait  root    /usr/sbin/tcpd  ipop2d
pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd  ipop3d
imap    stream  tcp     nowait  root    /usr/sbin/tcpd  imapd
# The Internet UUCP service.
#uucp   stream  tcp     nowait  uucp    /usr/sbin/tcpd  /usr/lib/uucp/uucico
# Tftp service is provided primarily for booting.  Most sites
# run this only on machines acting as "boot servers." Do not uncomment
# this unless you *need* it.
tftp    dgram   udp     wait    root    /usr/sbin/tcpd  in.tftpd
bootps  dgram   udp     wait    root    /usr/sbin/tcpd  bootpd
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers."  Many sites choose to disable
# some or all of these services to improve security.
# cfinger is for GNU finger, which is currently not in use in RHS Linux
finger  stream  tcp     nowait  root    /usr/sbin/tcpd  in.fingerd
#cfinger stream tcp     nowait  root    /usr/sbin/tcpd  in.cfingerd
#systat stream  tcp     nowait  guest   /usr/sbin/tcpd  /bin/ps -auwwx
#netstat        stream  tcp     nowait  guest   /usr/sbin/tcpd  /bin/netstat
-f inet
# Time service is used for clock syncronization.
time    stream  tcp     nowait  nobody  /usr/sbin/tcpd  in.timed
time    dgram   udp     wait    nobody  /usr/sbin/tcpd  in.timed
# Authentication
auth   stream  tcp     nowait    nobody    /usr/sbin/in.identd in.identd -l -e -
# End of inetd.conf

wstreeteAuthor Commented:
Forgot to add the bf=/etc/ida913.cfg file contents:


I-data's tech support suggested I add this and enable TFTP (which I did do).  If by some chance TFTP would work after the I-data box received it's IP address it would download the data in the above file into it's "default memory." The "default memory" is what the I-data box loads from on power-up if no boot-p server is found 1 min after power-up.

Starting with Angular 5

Learn the essential features and functions of the popular JavaScript framework for building mobile, desktop and web applications.

I don't know if it'll make a difference, but you might want to try massaging the format of your bootptab a little:


All I've done is re-order the entries a little (probably doesn't matter), put a tab at the beginning of the continuation lines (might not matter), and make sure there's a colon at the beginning *and* end of each line (most likely to matter).  Again, if you can't tell (I think the HTML on expert's exchange causes tabs to vanish) there's a tab at the beginning of the second and third lines of that entry.

I'll be interested to see what bootptest reports.
wstreeteAuthor Commented:
Adjusted points to 179
wstreeteAuthor Commented:

Thanks for the help!  With the suggestions and Linux commands you gave me,  my sniffer, and a book entitled "Internetworking with TCP/IP Volume I" which broke down the bootp packet,  I was able to figure out what was going on.  It seems that the I-data box is picky about how it gets it's subnet mask and extended info. After reading about how bootp packets are built I decided to investigate the VM  option in the bootptab file.  After trying auto and cmu I tried rfc1048.  After restarting the daemon, the I-data box stopped blinking and I was able to ping it and telnet to it.  The bootptab file and the bootpd.dump file (after restarting the daemon) are listed below along with a bootptest from my second Linux box.

Thanks ever so much for the help! I've bumped up the points as much as I could.

Walter Streeter

[streetew@linuxone /etc]$ cat bootptab

[streetew@linuxone /etc]$ cat /tmp/bootpd.dump
# bootpd 2.4.3
# /tmp/bootpd.dump: dump of bootp server database.
# Dump taken Mon Jun 16 11:49:20 1997
# Legend:       (see bootptab.5)
#       first field -- hostname (not indented)
#       Tn -- generic option tag n

bootptest: version 2.4.3
Sending to (request) htype:0 hlen:0 xid:5897 C: ven
Recvd from (reply) htype:0 hlen:0 xid:5897 C: Y:195
.122.10.218 S: sname:"" vend-rfc1395 SM:255
.255.255.0 GW: DNAM:""

Cool...glad to hear you got things working!  That was a nice bit of hackery on your part, too: figuring out what was wrong with the packet format from a book and a sniffer dump.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.