BootP problem

Posted on 1997-06-13
Medium Priority
Last Modified: 2008-02-26
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!
Question by:wstreete
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3

Accepted Solution

dhm earned 680 total points
ID: 1584876
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

Author Comment

ID: 1584877
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, <waltje@uwalt.nl.mugnet.org>
# Modified for Debian Linux by Ian A. Murdock <imurdock@shell.portal.com>
# Modified for RHS Linux by Marc Ewing <marc@redhat.com>
# <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


Author Comment

ID: 1584878
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.

Stressed Out?

Watch some penguins on the livecam!


Expert Comment

ID: 1584879
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.

Author Comment

ID: 1584880
Adjusted points to 179

Author Comment

ID: 1584881

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:"linuxone.patrickind.com" vend-rfc1395 SM:255
.255.255.0 GW: DNAM:"patrickind.com"


Expert Comment

ID: 1584882
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.


Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I have seen several blogs and forum entries elsewhere state that because NTFS volumes do not support linux ownership or permissions, they cannot be used for anonymous ftp upload through the vsftpd program.   IT can be done and here's how to get i…
Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
If you're a developer or IT admin, you’re probably tasked with managing multiple websites, servers, applications, and levels of security on a daily basis. While this can be extremely time consuming, it can also be frustrating when systems aren't wor…
In this video, Percona Solution Engineer Dimitri Vanoverbeke discusses why you want to use at least three nodes in a database cluster. To discuss how Percona Consulting can help with your design and architecture needs for your database and infras…
Suggested Courses

719 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question