Responses
-------------------
The -d (1-4) flag gives you more log info, 4 being the most
information. Here's what I used in my inetd.conf when trying to set up
my
decservers.
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -d 4
I think this will give you what you are looking for. Hope it helps.
Britt
- Britton Johnson, Ass't System Admin. Lindenwood University, St.
Charles, MO -
Disclaimer: Any typos, grammatical errors, and/or lapses of
intelligence are purely intentional. Don't try this at home. ;-)
Results:
------------
The above response did exactly what I needed. It reported the MAC
address
now maybe we can figure out why it wants info.....
Original Post
-------------------
Recently in our daemon.log I have been seeing the following:
Jul 5 15:26:07 alpha bootpd[25792]: version 2.3.dec.5
Jul 5 15:41:07 alpha bootpd[25792]: exiting after 15 minutes of
inactivity
Jul 5 17:44:01 alpha bootpd[26502]: version 2.3.dec.5
Jul 5 17:59:01 alpha bootpd[26502]: exiting after 15 minutes of
inactivity
Jul 5 18:32:28 alpha bootpd[26099]: version 2.3.dec.5
Jul 5 18:47:28 alpha bootpd[26099]: exiting after 15 minutes of
inactivity
Jul 5 19:11:13 alpha bootpd[26893]: version 2.3.dec.5
Jul 5 19:26:13 alpha bootpd[26893]: exiting after 15 minutes of
inactivity
I'm assuming that some device is broadcasting a tftp request but is not
on my bootptab list so nothing is sent from our machine. Is there any
way to have the bootpd report the requestors MAC or IP address, so we
can try to find out what machine is asking for data?
Also using tcpdump I have noticed:
16:49:56.379664 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xc603c603
[|bootp]
16:49:56.426512 slack.news.bootps > 255.255.255.255.bootpc: [len=314]
xid:0xc603
c603 Y:10.10.100.248 [|bootp]
16:54:16.634400 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xcd01cd01
[|bootp]
16:54:16.677344 slack.news.bootps > 255.255.255.255.bootpc: [len=314]
xid:0xcd01
cd01 Y:10.10.100.86 [|bootp]
16:54:44.507520 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa603a603
[|bootp]
16:54:44.516304 slack.news.bootps > 255.255.255.255.bootpc: [len=314]
xid:0xa603
a603 Y:10.10.100.253 [|bootp]
16:56:54.110288 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x4c034c03
[|bootp]
16:56:54.142496 slack.news.bootps > 255.255.255.255.bootpc: [len=314]
xid:0x4c03
4c03 Y:10.10.100.247 [|bootp]
16:57:48.393328 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x9b029b02
[|bootp]
16:57:48.414800 slack.news.bootps > 255.255.255.255.bootpc: [len=314]
xid:0x9b02
9b02 Y:10.10.100.45 [|bootp]
MIght these be the culprit? If so how would I know where 0.0.0.0 is
originating from
We have all MAC & IPs indexed, so if we had either, finding it would be
simple.
Noting is being compromised, just like to keep the .log files from
having extra stuff
in them.
THanx
George Gallen
ggallen_at_slackinc.com
Received on Tue Jul 07 1998 - 20:43:27 NZST