--- Begin Message ---
I recently got a bug in my ear to try and get multiple-dhclients to
work on separate interfaces under Linux (a one-daemon-per-interface
model). Could use some advice from the linux masters (Jason, Andrew?)
if you can spare some time for me.
Another motivation is trying to kill our LPF support (switch to BSD
sockets or similar - so all we have to do is DHCP).
Our linux support with BSD sockets looks to see if the system has
SO_BINDTODEVICE, which purports to bind a socket to the named
interface (so we know packets received on it were received on that
interface, and packets transmitted to for example 255.255.255.255 will
exit that interface). In addition to this, we set SO_BROADCAST to
truth for obvious reasons.
In theory then, our current bsd sockets support should always have
worked without the need for LPF, which is more than a little
astonishing.
Except now that I test this and try to look at where it's breaking
down, I find that dhclient can't seem to receive the server's responses
(Linux kernel v. 2.6.13), either when it unicasts its response to the
client's assigned address (and unicast mac) or when I set the broadcast
flag and make it reply in broadcast (broadcast mac and IP address to
255.255.255.255).
None of our recvfrom()'s are getting tickled, and the socket buffer
on these sockets isn't increasing (so it's not because we're not
emptying the socket).
One kinda funny side-effect of this shows up in my dmesg:
martian source 255.255.255.255 from 192.168.0.2, on dev eth0
192.168.0.2 is my home NAT dhcp server, this is it's perfectly normal
broadcast response. I guess the kernel doesn't recognize that address
as a valid local destination.
In case you weren't aware, I'll explain real briefly, that up until
this point what we do is construct a "LPF" (packet filter) socket for
receiving and transmitting local subnet broadcast DHCP packets, and
a normal BSD socket (which we call the 'fallback interface') for any
unicast traffic that needs to be routed.
So, if I understand the current state of affairs for running DHCP on
Linux, to be able to run multiple daemons we will need to keep the
current LPF support and rework this 'fallback interface' support.
Chiefly, to only construct the fallback interface once at least one
interface assigned to the daemon's purview has acheived BOUND state,
and to bind() the socket to the address assigned to that interface
(which may mean having multiple 'fallback interfaces' if a daemon is
being asked to process multiple physical interfaces).
So, once the interface is addressed, construct the fallback interface
so that we can send our unicast renewals...if we fall out of BOUND
state, tear down this socket before clearing the interface config.
This avoids the problem of having multiple dhclient daemons all trying
to bind to 0.0.0.0:68, but is substantially more complex (and opens up
a corner case: duplicate addresses, but later in the plan we will solve
this while solving other problems).
Right, so the question is, is this the only way to move forward? Is
there a better way to get RFC2131 broadcast address compliance on Linux
without writing our own UDP packets?
--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--- End Message ---
