1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
## Last updated : Tue Dec 15 03:57:57 1998
When the bootpc code fails to find a suitable server or reply it
prints a message like:
> Unable to locate an IP address for this host.
> ***Please report this problem**
>
> [Unable to continue]
>
The client then goes into a loop forwever sleeping. The reason for
this is that carrying on is probably foolish so it waits for a human
to interrupt it and sort out the problem. If you really know what you
are doing then you can set --returniffail to cause it to return.
Using bootpc like this you can tell if your machine is connected to
the network. I use this for machines which are sometimes on the net,
but get taken home by their users sometimes.
If it fails try running --debug --verbose to see if this sheds any
light on the problem.
The reasons it can fail that I've encountered are:
o You are running on a 2.1.x Linux kernel which will not pass the
bootp reply back to the client since the dest address doesn't match
ours (yet).
x Try the --serverbcast flag. It is a hack but seems to work with
most of the common bootp servers and gets round the problem for now.
A proper fix would either require kernel changes (which AC and ANK
disaprove of), or reading the packets at a lower level and
re-implementing most of the IP/UDP stuff in userland. If the
--serverbcast flag doesn't work you *might* want to try using the
kernel REDIRECT code from the firewall. I've not tested this.
o No bootp server is serving this client on this network
x Set one up. If you want to disable networking if there is no
reply to bootp see the --returniffails option. There is support
for this in rc.bootp now.
o Your default network card doesn't get you to the local network, or is
filtered or firewalled and not letting bootp packets through.
x Try using --server IPaddress of the server, check the routes
you have set allow all broadcast route to the local network.
o You are using --server to point to a server which doesn't run a
bootp server
x Try not using it.
o Packets from bootpc don't reach the server, watching the network
they seem to go somewhere else.
x You have a default route set up which doesn't reach the bootp
server. E.g. testing bootpc on a live system with the default
route pointing at your external router.
The rc.bootp script sets up a simple default route to the local
net. If you can't see the bootp server from this you need a
router which understands the bootp gateway protocol. For testing,
just set --server to point at your local subnet's broadcast
address. e.g. I use 131.111.16.255.
o You are using --hwaddr and the bootp server responds directly to
the MAC address quoted not to the machine generating the request.
x Try not using it. In modern bootp servers you can tell it to
broadcast the replies or reply to a known other address, this can
be helpful for debugging.
o The server doesn't understand RFC1497 cookies (you get not all the
information back and a "WARNING bp_xid mismatch" probably.)
x Install a newer bootp server, or make do with the information you
can get from the old one.
If these don't seem to be the problem, use strace to trace the
execution with --debug and --verbose and mail me the output, repeat
also with --server IPaddress so I can try to see what went wrong.
e-mail them to J.S.Peatfield@damtp.cam.ac.uk, I'll try to reply with
suggestions or more questions pretty soon.
-- Jon
|
