The attached patch provides support for VLAN tagging in the DHCP forwarder daemon by introducing a new config.h option (USE_VLAN_802_1Q). This option can be used when the daemon is installed in a system with interfaces that have VLAN tagging support. It cannot extract the VLAN tag from the interface, though, it has to be specified in the configuration file (with 'v')

There are also some minor changes that add some more logging in the daemon to be able to trace DHCP requests received and sent.

For reference, this is the email I sent to Enrico some time ago that details the changes in the code.

------------------------------------------------------------------

Hi Enrico,

I just wanted to thank you for dhcp-forwarder, and provide you a patch
that might be useful for others users.

To fill you in:

At my company we've been setting up a solution for a client using DHCP
relay in a Crossbeam X40 chasis [1] which uses RedHat 7.3 and runs
Check Point Firewall-1. Clients are sitting behind a big trunk using
VLAN tagging, a single interface is used to connect those clients to
the Crossbeam chasis which, itself, connects to a network with the
DHCP server.

A network    ---|
                ---- Switch -- (Trunk) -- Crossbeam -- D network
B network    ---|


With this setup, one of our engineers was unable to make any solution
(ISC's or dhcp-forwarder) work. He actually saw the following when
setting up a dhcp relay agent:

1- DHCP BOOTREQUEST was sent from one of those networks
2- Relay agent running in Crossbeam saw the request and forwarded it
3- The DHCP server in D network answered back with a BOOTREPLY

When using ISC's dhcprelay there were no more packets sent (except
from the same behaviour again and again since the client would not get
a DHCPOFFER).

When using dhcp-forwarder we would see:

4- The relay agent sends the BOOTREPLY to the client

However, none of the packets sent in step 4 reached the client. After
debugging this issue with dhcp-forwarder (I've not analysed dhcprelay
behaviour yet) I found out that the main problem was that the packets
created by dhcp-forwarder would not include VLAN tag identifiers and,
thus, would not be forwarder by the switch to any of the networks
where DHCP clients reside.

I'm actually not sure if this is something that should be done by the
relay agent or something that the Linux kernel should do (since
applications cannot query the interface in Crossbeam easily to see if
it's a VLAN-tagged interface, as a custom LInux kernel is used there).
In any case, I've produced the following patch that, when compiled
defining USE_VLAN_802_1Q will actually make dhcp-forwarder add the
VLAN tags to the replies that are resent to the clients.

I've made the following changes:

- - introduce a USE_VLAN_802_1Q into config.h.in so it can be
'configure'd in (I have not made changes to the configure.ac since I
cannot rebuild those with the ancient RedHat system I need to use for
compilations, aclocal and automake there are way out of date)

- - modify the DHCPllPacket definition in inet.h so that a new struct
(defined in vlan.h, borrowed from the VLAN tagging code in the kernel)
is used if using VLAN tagging

- - modify parser.c so that a new configuration option ('vlanid IFACE
VLANID') is retrieved from the configuration file in order to define
which vlanid should be used for a given interface.

- - modify main.c so that the DHCPllPacket is created with a proper VLAN
tag definition based on the vlanid configured for it.

- - Some other changet to be able to compile this package in an ancient
RedHat 7.3 system (no need to put them into the current code, but just
so you know these changes are needed in our environment)

There are also some minor changes to the code I introduced in order to
try to make it log the packets to the logfile, but I'm unable to have
that work. Does logging to stdout or to the logfile actually work?

The code does work (in my lab environment) with VLAN tagging and we
are currently testing it in production. I just thought it might be
useful for you too. Some caveats:

1.- I'm not sure if the code is needed at all for Linux (or other)
kernels. To me it seems perfectly reasonable that the network
interface code could repack ethernet frames with the appropiate VLAN
id when a packet without VLAN id is sent through a VLAN-tagged
interface. I have not investigated if this is done in the Linux
kernel, however.

Question: Your changelog entry of july 2003 says: "This version allows
`.' characters in interface-names to make it work with VLAN kernels."
Do you know of people using dhcp-forwarder with VLAN-tagged
environments? Haven't they experienced these issues?

2.- With this code you either have VLAN tag support for replies or you
don't. There is currently no way to send packets without VLAN tags
when they are not configured, which would seem a perfectly reasonable
thing to do (i.e. have iface definitions with an without VLAN tags and
add them when needed). The code currently uses VLAN tag '1' for
interfaces without a defined VLAN tag, I'm not sure if this will
actually work when you are not using VLAN tagging, however.

I just hope these features are useful for you and maybe to other
dhcp-forwarder users. Don't hesitate to ask for additional information
if you want to understand the environment or the code is not clear enough.