dhcp3-server vlan support seems to be broken

[owagner]

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.1724 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.

[Chuck Short (zulcss)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/. Thanks again and we appreciate your help.

[Chuck Short (zulcss)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[Anders Kringstad (akai)]

I can confirm this bug with Ubuntu Hardy Heron 8.04.3 LTS and kernel 2.6.24-24-generic. ISC dhcp3-server version: 3.0.6.dfsg-1ubuntu9.1.

I will try to upgrade to 9.10 to see if this helps resolve the problems.

[Chuck Short (zulcss)]

Thanks for the response.

Regards
chuck

[gsupport (support-gatsby)]

DistroRelease: Ubuntu 9.10
Package: dhcp3-server 3.1.2-1ubuntu7.1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 2.6.31-19.56-server

I can confirm that even with the recent configuration above any DHCP requests that come over a tagged VLAN are also seen by the untagged interface. Here is a sample request coming over VLAN 5;

DHCPDISCOVER from 00:23:8b:27:06:8b via eth1
DHCPDISCOVER from 00:23:8b:27:06:8b via eth1.5
DHCPOFFER on 192.168.213.152 to 00:23:8b:27:06:8b via eth1
DHCPOFFER on 192.168.205.150 to 00:23:8b:27:06:8b via eth1.5

In case there is any doubt;

#> grep VID /proc/net/vlan/eth1.5
eth1.5 VID: 5 REORDER_HDR: 1 dev->priv_flags: 1

The DHCP server still sees the tagged VLAN packets when the VLAN interface isn't listed in INTERFACES.

#> dhcpd3 -d eth1
...
Listening on LPF/eth1/00:04:23:ab:3e:ea/192.168.213/24
Sending on LPF/eth1/00:04:23:ab:3e:ea/192.168.213/24
Sending on Socket/fallback/fallback-net
DHCPDISCOVER from 00:23:8b:27:06:8b via eth1
DHCPOFFER on 192.168.213.152 to 00:23:8b:27:06:8b via eth1

Naturally, the device doesn't see the offer as it is going out on the untagged VLAN.

[gsupport (support-gatsby)]

Reading the linux-netdev archives ( http://marc.info/?l=linux-netdev&m=124836694205107&w=2 );

 "ISC dhcp3d [sic] does not use libpcap, and does not query the packet socket for the VLAN tag, so it treats every VLAN's packets as for the default VLAN.".

This is just as the OP describes. So unless the behaviour of the raw interface changes back to the old way or ISC adopts libpcap, then a single instance of dhcpd will never be able to handle the default interface with additional VLAN interfaces off the same NIC.

A suggested enhancement/workaround would be to have out-of-the-box support for an instance per interface.