rarpd clobbered any AF_INET information already configured for a given
interface name, so interfaces with more than one IP address made rarpd
listen only for the last address out of all IP aliases.
I changed this, so that AF_LINK information is always collected first
(to ensure the interface name gets its link-layer address associated),
but while looking for AF_INET addresses, the configuration is cloned
if there has already been one IP address seen for that interface name.
Thus, rarpd now effectively listens on all subnets.
MFC after: 1 week
- Use getifaddrs() instead of rolling our own buggy one. Previously,
rarpd(8) would fail to see some interfaces because of a hardcoded limit.
It now successfully sees any interface in the system, and this also makes
the code _much_ simpler.
- Replace strncpy() calls with strlcpy() calls. Some uses of strncpy()
were bogus ; the code wasn't ensuring that the string was NUL terminated.
- Don't try to guard about select() FD_* macros being undefined.
- Use IF_NAMESIZE and ETHER_ADDR_LEN macros where appropriate.
- Add static keywords to function definitions for consistency, since
the prototypes have it (I wonder why GCC didn't complain about this).
- Remove compat code for very old BSD versions and SunOS.
- Remove code for systems not having the dirent.h header.
- The code is now WARNS=5 clean so mark it as such.
- Don't add -DTFTP_DIR="/tftpboot" to the build command line since it's
the default.
MFC after: 2 weeks
an alternative to /tftpboot. This is useful it you're using tftpd
with an alternative root (using -s), and would like rarpd to respond
selectively to RARP requests using the same criteria as tftp.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
sends error messages to stderr, normal output to stdout, instead of
logging everything via syslog.
Turn off the FORMAT_AUDIT in the Makefile, until I can figure out how
to disable the check for one single line in the source :(
Reviewed by: dd, silence on -audit
MFC after: 1 month
(e.g., on alphas, or even on i386's with a POSIX-200x-conformant
ntohl() (ntohl() returns uint32_t which is u_int on i386's)).
Fixed related bugs and bogons while I'm here:
- ntohl() was "fixed" for printing in 1 place by casting to
"(unsigned int )". This breaks the value on systems where u_int
is smaller than uint32_t, and has 2 style bugs.
- spell u_int consistently (never use "unsigned").
- break K&R support some more (don't cast malloc()'s arg to a wrong
type...).
Once again, as explained in my messages to -audit, the ANSIfication comes
as part of the preparation to add a new -d command-line flag to send
output to stdout/stderr. That commit will come in a week, pending any
further comments/objections. For those who have missed the -audit mails,
it's at http://people.FreeBSD.org/~roam/bsd/rarpd/usr.sbin-rarpd-d.patch
Asbestos suit: on ;)
Reviewed by: dd, silence on -audit
MFC after: 1 month
configure FreeBSD so that various databases such as passwd and group can be
looked up using flat files, NIS, or Hesiod.
= Hesiod has been added to libc (see hesiod(3)).
= A library routine for parsing nsswitch.conf and invoking callback
functions as specified has been added to libc (see nsdispatch(3)).
= The following C library functions have been modified to use nsdispatch:
. getgrent, getgrnam, getgrgid
. getpwent, getpwnam, getpwuid
. getusershell
. getaddrinfo
. gethostbyname, gethostbyname2, gethostbyaddr
. getnetbyname, getnetbyaddr
. getipnodebyname, getipnodebyaddr, getnodebyname, getnodebyaddr
= host.conf has been removed from src/etc. rc.network has been modified
to warn that host.conf is no longer used at boot time. In addition, if
there is a host.conf but no nsswitch.conf, the latter is created at boot
time from the former.
Obtained from: NetBSD
Explanation of the bug: when processing its first request, rarpd
opens a routing socket to send requests to the arp table. It keeps
that socket open afterwards, while waiting for new RARP requests.
Meanwhile, the data received on the routing socket fill up until
they are about 8Kbytes in size. Any additional data is lost.
When rarpd receives its next RARP request, it tries to access the
ARP table via a routing socket call, then waits for the answer to
its own request. This answer is lost because the received data is
already filled: when looking for the reply, rarpd receives only
8kbytes worth of data, then loops waiting forever.
Someone please test it on -STABLE and commit it. We can close the PR
when testing on STABLE is done.
PR: bin/5669
Submitted by: Pierre Beyssac <pb@fasterix.freenix.org>
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
Fenner was kind enough to point out the error of my ways. This incorporates
diffs from him which:
- Keep everything in network order.
- Log the booted ether & ip address, instead of my address on that net
- change several exit()'s to return()'s, so that rarpd continues running
even if it thinks it's in a weird state.
One small tweak by me: in rarp_bootable(), we have to make sure to
construct 'ipname' in host byte order (if we don't, we have to
specify /tftpboot/<remote IP in hex> with <remote IP in hex> in
network byte order, which is confusing).
Also restored use of <dirent.h> rather than <sys/dir.h> as pointed
out by bde.
Also updated the man page so that the -v flag is documented.
With any luck, I won't have to touch this thing again.
This includes the following changes:
- Support for poking ARP entries into the local table is now built
in, so the arptab.c module I hacked together is no longer needed.
- rarp_process() and rarp_reply() now accept a len argument which is
passed down from rarp_loop() which tells rarp_reply() exactly how
long the original RARP frame was. (Usually, it's 60 bytes, which is
the minimum.) Previously, the length was calculated using the sum
of sizeof(struct ether_header) + sizeof(struct ether_arp) (plus the
ethernet frame header, I think). The result was a total packet
length of 42 bytes. Now, rarp_reply() sends out packets that are
the same size as those it recieves (60 bytes). This agrees with the
behavior of rarpd on SunOS (as observed with tcpdump). The unused
extra bytes are zeroed.
frame type in network byte order. The htons() that wasn't needed in
2.1 is now required in 2.2.
Ultimately, this rarpd should be replaced with the more recent one
supplied with the new BPF distribution.
