dhcpd 3.1.1, linux vlans since 2.6.27 and listening on the untagged device
Oliver Wagner
owagner at vapor.com
Sat Nov 8 13:03:22 UTC 2008
Hi,
I've submitted this as a bug to ubuntu, but my current best guess is
that this is actually a problem in dhcp3 3.1.1 which started to show up
with a recent change in the way how LPF works with regards to vlans.
Comments welcome.
Best Regards,
Olli
===8<======8<======8<======8<======8<===
https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/295520
Binary package hint: dhcp3-server
Description: Ubuntu 8.10
Release: 8.10
dhcp3-server:
Installed: 3.1.1-1ubuntu2
Candidate: 3.1.1-1ubuntu2
Version table:
*** 3.1.1-1ubuntu2 0
500 http://de.archive.ubuntu.com intrepid/main Packages
100 /var/lib/dpkg/status
libpcap-dev:
Installed: (none)
Candidate: 0.9.8-5
Version table:
0.9.8-5 0
500 http://de.archive.ubuntu.com intrepid/main Packages
-- Let's have both an untagged "eth0" and a vlan "vlan2" which uses eth0
as it's raw device.
-- Assign 192.168.0.1/24 to eth0
-- and 192.168.3.1/24 to vlan2.
-- Configure both subnets in dhcpd3.conf
When a request on the untagged network comes in, everything is fine:
dhcpd receives and answers it on eth0.
Nov 8 10:33:49 grate dhcpd: DHCPDISCOVER from 00:0d:4b:0d:03:b8 via eth0
Nov 8 10:33:50 grate dhcpd: DHCPOFFER on 192.168.0.233 to
00:0d:4b:0d:03:b8 (RadioKueche) via eth0
When a request on the vlan comes in, dhcpd first receives and answers it
on vlan2 (ok), then *also* on eth0 (not ok):
Nov 8 10:39:57 grate dhcpd: DHCPDISCOVER from 00:04:f2:16:9d:f2 via vlan2
Nov 8 10:39:57 grate dhcpd: DHCPDISCOVER from 00:04:f2:16:9d:f2 via eth0
Nov 8 10:39:58 grate dhcpd: DHCPOFFER on 192.168.3.252 to
00:04:f2:16:9d:f2 via vlan2
Nov 8 10:39:58 grate dhcpd: DHCPOFFER on 192.168.0.220 to
00:04:f2:16:9d:f2 via eth0
The box in question is dist-upgraded from 8.04. With 8.04, this
seemingly did NOT happen: The vlan tagged request was only processed on
vlan2.
Some investigation suggests, however, that this is a problem in dhcpd3
which just didn't always show up in 8.04. There is a change regarding
the handling of VLAN packets and packet filters in kernel 2.6.27 which
makes sure that vlan tagged packets are always presented to filters on
the underlying device (eth0 in this case) with the vlan tag removed from
the packet data. Previously (depending on the ethernet driver, from what
I could understand) the raw data was also presented, but with the vlan
tag still present.
Thus, before 2.6.27 and as a side-effect of not expecting the vlan tag,
dhcpd's LPF code would filter the vlan tagged packet away as not a valid
bootp/dhcp packet, and the dhcpd3 application code was only seeing the
packet which was received via the "vlan2" device.
Starting with 2.6.27, the LPF code now matches for both the vlan2
received packet, and the eth0 received packet, thus causing above problem.
If the analysis is correct, this needs to be fixed upstream in dhcpd's
linux interfacing code.
More information about the dhcp-users
mailing list