On Apr 22, 5:50pm, Robert Elz wrote:
}
} 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).
Obtaining an address via DHCP is a four step process, and the
client can't legitimately use the new address until the fourth step is
completed. To what address would you like the DHCP server to send its
responses? I suppose the DHCP server could send responses to the
broadcast address, but I couldn't guarantee that every client would be
listening for them there (it's been a while since I looked at the
details).
} 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.
We use ISC's DHCP server. As third party software, it is designed
to be portable to many systems. BPF is a fairly portable interface,
thus a reasonable interface for it to use.
}-- End of excerpt from Robert Elz
