Solved

BootP problem

Posted on 1997-06-13
7
436 Views
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!
0
Comment
Question by:wstreete
  • 4
  • 3
7 Comments
 
LVL 3

Accepted Solution

by:
dhm earned 170 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:

kill -SIGNAL PID

For example:

kill -HUP 120
0
 

Author Comment

by:wstreete
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
ida.patrickind.com:sm=255.255.255.0:\
gw=195.122.10.250:ht=ethernet:ha=00036e002495:ip=195.122.10.247:bf=/etc/ida913.cfg:

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
 
-l
#
# 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 -
o
#
# End of inetd.conf

0
 

Author Comment

by:wstreete
ID: 1584878
Forgot to add the bf=/etc/ida913.cfg file contents:

i-data7913
default 195.122.10.247,255.255.255.0,195.122.10.250

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.

0
How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

 
LVL 3

Expert Comment

by:dhm
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:

ida:ht=ether:ha=00036e002495:\
      :ip=195.122.10.247:sm=255.255.255.0:gw=195.122.10.250:\
      :dn=patrickind.com:bf=/etc/ida913.cfg:

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.
0
 

Author Comment

by:wstreete
ID: 1584880
Adjusted points to 179
0
 

Author Comment

by:wstreete
ID: 1584881
dhm,

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.

Sincerely,
Walter Streeter

[streetew@linuxone /etc]$ cat bootptab
ida:ht=ether:ha=00036e002495:\
        :ip=195.122.10.247:sm=255.255.255.0:gw=195.122.10.250:\
        :dn=patrickind.com:vm=rfc1048:
 
linuxtwo:ht=ether:ha=00a024944178:\
        :ip=195.122.10.218:sm=255.255.255.0:gw=195.122.10.250:\
        :dn=patrickind.com:vm=rfc1048:


[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
 
ida:\
        :dn=patrickind.com:\
        :gw=195.122.10.250:\
        :ht=1:ha="00:03:6E:00:24:95":\
        :ip=195.122.10.247:\
        :sm=255.255.255.0:\
        :vm=rfc1048:
linuxtwo:\
        :dn=patrickind.com:\
        :gw=195.122.10.250:\
        :ht=1:ha="00:A0:24:94:41:78":\
        :ip=195.122.10.218:\
        :sm=255.255.255.0:\
        :vm=rfc1048:
 

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

0
 
LVL 3

Expert Comment

by:dhm
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.

Regards,
d.
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

Suggested Solutions

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…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

707 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

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now