| >I've been unable to get bootpd with DHCP patches on SunOS 4.1.3
| >to work with our Windows NT clients. The problem appears to be
| >that the NT clients want the DHCP reply sent to 255.255.255.255,
| >but SunOS 4.x is unable to do that. The network number for the
| >DHCP client and bootp server is 199.4.88.0, and I can send the reply
| >to 199.4.88.255, but not 255.255.255.255. The sendto() fails with
| >ENETUNREACH.
For quick answer, skip to ***.
| It appears that you may just need to change the broadcast
| address defined on your ethernet interface. I did a "man ifconfig",
| and there is an (optional) parameter, broadcast address, which
| specifies what address broadcasts should be sent to. By default,
| it uses your subnet with the host part of all 0's.
|
| You could probably change the broadcast address to give
| the desired value of 255.255.255.255 using the ifconfig command with
| the appropriate parameters.
Actually, while you can change the interface's broadcast address
to 255.255.255.255, it is neither necessary nor sufficient to solve
this particular problem. The important thing to remember about the
BSD socket/ip code is that destination addresses are routed before
any kind of special broadcast address recognition is performed. (1)
This approach is rather at odds with the whole concept of the new
all-1s address (all-1s = 255.255.255.255 = ``local net broadcast'')
since there is no way, on a multi-homed host, to tell which particular
local net is intended as the destination of a sendto() call. (2)
[Opinion: The BSD socket API isn't broken (at least in this respect :);
all-1s is just generally unfriendly to multi-homed hosts.]
Fortunately, there is a work-around for the problem in most BSD-derived
systems, Solaris 1.x included. It is necessary to install a route for
the all-1s broadcast address pointing to the desired interface and using
a metric of zero. (The broadcast-address-detection code used by the
interface already understands that 255.255.255.255 should go out as
as a link-level broadcast, so it is not necessary to change the
interface's broadcast address.) To add the route, you want the effect of:
route add 255.255.255.255 <my interface ip address> 0
Unfortunately, because the inet_addr() function uses -1L for an error
return, the above will not work as the address will appear invalid.
You can, of course, write your own program that calls the same route
ioctl as this command and it will work fine. A quicker solution that
works on many systems is to define an entry in /etc/hosts with an
address of 255.255.255.255 (call it, say, inaddr_broadcast). You
can then use this name in cases where an explicit 255.255.255.255
would be (incorrectly) found invalid:
route add inaddr_broadcast <my interface ip address> 0
This works because the traditional /etc/host-parsing routines don't
care if inet_addr() returns -1L. Unfortunately, Solaris 1.x uses
slightly different routines to build the Yellow Pages (NIS) maps
and it won't let you get away with the inaddr_broadcast trick. A
different bug (or at least lack in address checking) allows for a
different quick-fix in this environment(***):
route add 255.255.255.0 <my interface ip address> 0
The above will allow the DHCP response to be sent as required. Another
approach that will probably work for the original poster is to add a
default route (which he presumably does not have given the error) with
a metric of zero:
route add default <my interface ip address> 0
This has the side effect of causing other unknown addresses to generate
ARP requests on the local network. That may or may not be an issue
depending on local configuration.
Notes:
(1) In fact, there is some early (pre-routing) address recognition. If
the first inet interface configured in a system is a broadcast device,
the low-level bind routines (used even with sendto()) will detect the
special 255.255.255.255 destination and replace it with the broadcast
address of that interface. This code is usually inactive because the
first interface configured on many systems is the loopback device (lo0)
and it does not support broadcasts. In any case, this hack won't do
what you want because the actual destination is re-written before the
packet goes out. (Setting the interface's broadcast address to all-1s
doesn't help--it will then fail the routing code. Catch-22.)
(2) Some systems send copies of the datagram to *all* local nets in
this case. They may or may not re-write the destination address to
the directed (subnet) broadcast for the particular local net. This
behavior satisfies some applications and perhaps it's the best (only?)
compromise.
Dan Lanciani
by