Hello, 

t1...@protonmail.ch (Tinker), 2018.03.02 (Fri) 02:36 (CET):
> Err, that became too wordy. This is what I wanted to ask:
>
> The common sense way to run a machine is to run it minimalistic, if not
> else then for sleeping well at night.
>
> Now running DHCPD, I like it not to touch any other interface than the
> dedicated LAN interface - makes general sense, does it not?

That's what happens:

$ uname -a
OpenBSD aa.bb.cc 6.2 GENERIC.MP#6 amd64

$ dhcpd -d
Listening on carp2 (A.B.C.D).
Can't listen on carp1 - dhcpd.conf has no subnet declaration for E.F.G.H.
Can't listen on carp0 - dhcpd.conf has no subnet declaration for I.J.K.L.
Can't listen on em2 - it has no IP address.
Can't listen on em1 - dhcpd.conf has no subnet declaration for M.N.O.P.
Can't listen on em0 - it has no IP address.

On the same machine:
(using ntpd(8) as an example other than dhcpd(8))

$ fstat | grep -e ntpd -e dhcpd | grep -e bpf -e internet
_dhcp    dhcpd       9001    4 clone 1156  crw------- rw bpf0
_dhcp    dhcpd      67012    4 clone 1156  crw------- rw bpf0
_dhcp    dhcpd      67012    5* internet raw icmp 0x0
_ntp     ntpd        7658    6* internet6 dgram udp [::1]:123
_ntp     ntpd        7658    7* internet6 dgram udp [fe80::1%lo0]:123
_ntp     ntpd        7658    8* internet dgram udp 127.0.0.1:123
_ntp     ntpd        7658    9* internet dgram udp M.N.O.P:123
_ntp     ntpd        7658   10* internet dgram udp I.J.K.L:123
_ntp     ntpd        7658   15* internet dgram udp M.N.O.P:123
_ntp     ntpd        7658   16* internet dgram udp A.B.C.D:123
_ntp     ntpd        7658   17* internet dgram udp <out>
_ntp     ntpd        7658   18* internet dgram udp <bound>
_ntp     ntpd        7658   19* internet dgram udp <conn>
_ntp     ntpd        7658   20* internet dgram udp <ections>

The IPs are three different RFC1918s and one public IPv4. 

> The only thing that's unique about the LAN interfaces is that among all
> interfaces, it's the only one to have the unique value pair of its
> netmask (e.g. 255.255.255.0), and its IPv4 IP (e.g. 1.2.3.4)
> bitwise-and the netmask (yielding 1.2.3.0).
> 
> Is that dhcpd's selection criteria for what interfaces to touch, i.e.
> resolve the IF:s that match netmask and ip-bitwiseand-netmask?

>From dhcpd(8):

The names of the network interfaces on which dhcpd should listen for
broadcasts may be specified on the command line.  This should be done on
systems where dhcpd is unable to identify non-broadcast interfaces, but
should not be required on other systems.  If no interface names are
specified on the command line, and the -u option is not given, dhcpd will
identify all network interfaces which are up, eliminating non-broadcast
interfaces if possible, and listen for DHCP broadcasts on each interface.

And, because it's referenced:

-u[bind_address]
        Use a UDP socket instead of BPF for receiving and sending
        packets.  Only DHCPINFORM messages can be handled on this socket;
        other messages are discarded.  With this option, dhcpd can answer
        DHCPINFORM from clients on non Ethernet interfaces such as tun(4)
        or pppx(4).  If bind_address is specified, dhcpd will bind to
        that address; otherwise the limited broadcast address
        (255.255.255.255) is used as the default.

For more details on the selection criteria you might need to go for the
source.

Further info from official documentation:

innovations.html:
     * Privilege separation: First implemented by Niels Provos and
       Markus Friedl in OpenSSH in March 2002, released with OpenBSD
       3.2. The concept is now used in many OpenBSD programs, for
       example bgpd(8), dhclient(8), *dhcpd(8)*, dvmrpd(8), eigrpd(8),

faq6.html usage example:

# rcctl set dhcpd flags em1 em2
[...]
# rcctl set dhcpd flags vether0

faq/pf/example1.html usage example:

# rcctl enable dhcpd
# rcctl set dhcpd flags em1 athn0

With OpenBSD documentation such examples are rarely just typed away but
carefully chosen. 

62.html
     * dhcpd(8)/ dhcrelay(8) improvements:
          + Take greater care to process all data read, and only data
            read, from the bpf(4) socket.

61.html
     * dhclient(8)/ dhcpd(8)/ dhcrelay(8) improvements:
          + Stop leaking option data received on the udp socket.

plus59.html
     * In dhclient(8), dhcpd(8) and dhcrelay(8), be very careful
       accepting packets via bpf(4).

This is not the end of the grep(1) results. Get www.openbsd.org onto
your local disk (available via cvs(1), see cvsintro(7)) and do the
grepping yourself ;-)

Marcus

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On February 28, 2018 12:48 PM, Tinker <t1...@protonmail.ch> wrote:
> 
> > Hi Marcus,
> ..
> > On February 27, 2018 3:41 PM, Marcus MERIGHI mcmer-open...@tor.at wrote:
> > 
> > > t1...@protonmail.ch (Tinker), 2018.02.27 (Tue) 07:12 (CET):
> > > 
> > > > Just so I not missed anything in reading the man pages \[1\]:
> > > > 
> > > > If you have a machine with an external and an internal NIC e.g. em0 and
> > > > 
> > > > em1 , and you want to serve DHCP only on em1 , then the only way to do
> > > > 
> > > > that is as a dhcpd argument, e.g. add a line 'dhcpd="em1"' to
> > > > 
> > > > /etc/rc.conf.local or alternatively add a line "dhcpd em1" to
> > > > 
> > > > /etc/rc.local - there is no way to specify in /etc/dhcpd.conf which
> > > > 
> > > > network interfaces dhcpd will bind/serve on, right?
> > > > 
> > > > Has this been for a particular reason (i.e. it's a feature) or just
> > > > 
> > > > noone bothered?
> > > > 
> > > > The usecase I describe above should be typical.
> > > 
> > > dhcpd(8) reads the subnet declarations from dhcpd.conf(5) and get's to
> > > 
> > > the interface from there. It does not listen like other network daemons
> > > 
> > > but uses bpf(4). Try to block it with pf(4)... ;-)
> > > 
> > > Marcus

Reply via email to