5 ms·

Iptables (aka linux's netfilter) processes DHCP packets like any other packets. The ISC DHCP server though listens for raw packets and thus completely by-pass

Iptables (aka linux's netfilter) processes DHCP packets like any other packets. The ISC DHCP server though listens for raw packets and thus completely by-pass the netfilter rules. This is similar to how you can use wireshark to see raw packets received on the physical port, before any filtering. Any Linux process running with CAP_NET_RAW can by-pass the firewall in such a way, this includes your typical DHCP server running as root. The question then should be why is ISC DHCP server using raw sockets? That is probably because DHCP sits in-between OSI layers, it bridges the gap between the mac address world and IP address world. I'm not sure of the exact technical reason though. The linked SO answers talk about some case where NAT rules could be altering packets, not sure how common NAT+DHCP is used... In the case of a DHCP client, you do need raw sockets because the Linux IP layer will not let a normal socket send packets with a NULL IP source address.

allarm 3y ago
> The question then should be why is ISC DHCP server using raw sockets? I don’t know much about Linux network stack, but probably it’s because DHCPDISCOVER messages sent to ff:FF:FF:FF:FF:FF, and Linux network driver only accepts frames sent to the interface address? Not sure if that’s true though.
- ilyt 3y ago
  It's the fact that TCP/UDP socket interface doesn't expose macaddress, dnsmasq IIRC does the same
- smashed 3y ago
  This is just a normal udp broadcast packet sent to FF:FF:FF:FF:FF:FF / 255.255.255.255. You do not need raw sockets to receive it. There is an ISC dhcp article here with more info on why they need it: https://kb.isc.org/docs/aa-00379 https://kb.isc.org/docs/aa-00379 But I just thought about it some more.. In a normal unix socket, you don't set the destination mac address when sending a packet. You just set the destination IP address and the kernel figures out the destination MAC address using a static, cached or dynamic ARP lookup. But since the dhcp client has not been assigned the IP yet, ARP would fail. The DHCP server would need to set a static ARP entry before sending the response, and hope the kernel properly fills the destination MAC. This causes more problems.. Its much easier and reliable to just craft the exact headers required as-per the RFC, especially in a cross-platform piece of software like the ISC dhcp server.

allarm 3y ago

> The question then should be why is ISC DHCP server using raw sockets? I don’t know much about Linux network stack, but probably it’s because DHCPDISCOVER messages sent to ff:FF:FF:FF:FF:FF, and Linux network driver only accepts frames sent to the interface address? Not sure if that’s true though.

ilyt 3y ago
It's the fact that TCP/UDP socket interface doesn't expose macaddress, dnsmasq IIRC does the same
smashed 3y ago
This is just a normal udp broadcast packet sent to FF:FF:FF:FF:FF:FF / 255.255.255.255. You do not need raw sockets to receive it. There is an ISC dhcp article here with more info on why they need it: https://kb.isc.org/docs/aa-00379 https://kb.isc.org/docs/aa-00379 But I just thought about it some more.. In a normal unix socket, you don't set the destination mac address when sending a packet. You just set the destination IP address and the kernel figures out the destination MAC address using a static, cached or dynamic ARP lookup. But since the dhcp client has not been assigned the IP yet, ARP would fail. The DHCP server would need to set a static ARP entry before sending the response, and hope the kernel properly fills the destination MAC. This causes more problems.. Its much easier and reliable to just craft the exact headers required as-per the RFC, especially in a cross-platform piece of software like the ISC dhcp server.