Date: Thu, 29 Nov 2012 22:54:24 -0500 (EST)
From: Mouse <mo...@rodents-montreal.org>
Message-ID: <201211300354.waa22...@sparkle.rodents-montreal.org>
On the general VLAn topic, I agree with all Dennis said - leave the VLAN tags
alone and just deal with them.
| > I believe every use of BPF by an application to send and receive
| > protocol traffic is a signal that something is missing
I think "was missing" might be a better characterisation.
| ...in general, I agree, but in the case of DHCP, I'm not so sure. It
| needs to send and receive packets to and from unusual IPs (0.0.0.0, I
| think it is), if nothing else.
But that's not it, the DHCP server has no real issue with 0 addresses,
that's the client (the server might need to receive from 0.0.0.0 but
there's no reason at all for the stack to object to that - sending to
0.0.0.0 would be a truly silly desire for any software, including DHCP
servers).
The missing part used to be (I believe we now have APIs that solve this
probem) that the DHCP server needs to know which interface the packet
arrived on - that's vital. The original BSD API had no way to convey that
information to the application, other than via BPF, or via binding a socket
to the specific address of each interface, and inferring the interface
from the socket the packet arrived on. The latter is used by some UDP apps
(including BIND) but is useless for DHCP, as the packets being received
aren't sent to the server's address, but are broadcast (or multicast for v6).
As the DHCP server needed to get the interface information, it had to
go the BPF route. Once that's written, and works, there's no real reason
to change it, even given that a better API (or at least "an API", by
definition it is better than the nothing that existed before, even though
it isn't really a great API) now exists. Retaining use of the BPF code allows
dhcpd to work on older systems, and newer ones, without needing config
options to control which way it works, and duplicate code paths to maintain.
kre
