: >Dennis's analysis seems dead-on to me.  The fix would be to have some
: >kind of BSD Sockets API extension that could be used to identify the
: >arriving interface for DHCP REQUEST packets.  Ideally, such an
: >extension would be coordinated with the other *BSD kernel folks,
: >so it could be more widely implemented than just NetBSD.

Getting back to the original part of this:

bpf requires that it be bound to a specific interface.  From bpf(4):

     BIOCSETIF (struct ifreq)
              Sets the hardware interface associate with the file.  This
              command must be performed before any packets can be read.

There isn't a bpf "listen on all interfaces at once" mode, or at least, the
manpage and API seem to say this.  And the code in dhcp seems to agree with
this assessment;  see src/dist/dhcp/common/bpf.c:if_register_bpf() (the only
function that opens the bpf device).  From line 128 of this file, after
opening the bpf device:

        /* Set the BPF device to point at this interface. */
        if (ioctl (sock, BIOCSETIF, info -> ifp) < 0)
                log_fatal ("Can't attach interface %s to bpf device %s: %m",
                       info -> name, filename);

        return sock;

Note that dhcpd *does* open a socket on port 68, bound to all interfaces,
for the purpose of direct communication and fallback.  So it's possible that
either (1) we have a bug in packet processing somewhere, or (2) the original
poster didn't have ipf set Correctly for testing (maybe just a simple
oversight).

This "bug" needs much more analysis before coming to conclusions about how
to "fix" it.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/