Hello,

I'm trying to debug some DHCP behavior on my UniFi home network.

The Unifi Security Gateway is a router responsible for handing out IPs for
all of my VLANs. On the USG:
- eth1 has 192.168.1.1/24
- eth1.10 has 192.168.10.1/24

Both subnets are configured for DHCP, and it mostly works as desired...
however:
Sometimes, for clients connecting on VLAN 10, I'll see activity in the
dnsmasq logs indicating that dnsmasq is acting on the DHCP traffic twice:
once for eth1.10, and once for eth1. I'll include a dump of such activity
at the end.

As far as I can tell, this is due to the way Linux handles 802.1Q traffic.
A bug was addressed in the ISC DHCP server, with following note describing
the issue:

>       /*  Use auxiliary packet data to:
>        *
>        *  a. Weed out extraneous VLAN-tagged packets - If the NIC driver
is
>        *  handling VLAN encapsulation (i.e. stripping/adding VLAN tags),
>        *  then an inbound VLAN packet will be seen twice: Once by
>        *  the parent interface (e.g. eth0) with a VLAN tag != 0; and once
>        *  by the vlan interface (e.g. eth0.n) with a VLAN tag of 0 (i.e
none).
>        *  We want to discard the packet sent to the parent and thus
respond
>        *  only over the vlan interface.  (Drivers for Intel PRO/1000
series
>        *  NICs perform VLAN encapsulation, while drivers for PCnet series
>        *  do not, for example. The linux kernel makes stripped vlan info
>        *  visible to user space via CMSG/auxdata, this appears to not be
>        *  true for BSD OSs.).  NOTE: this is only supported on linux
flavors
>        *  which define the tpacket_auxdata.tp_vlan_tci.

-- https://github.com/isc-projects/dhcp/commit/acbecb2e

Am I on the right track? If so, would a patch that does a similar
discarding of packets be desirable?

Here's my log showing eth1 and eth1.10 fighting over who should respond:

May 30 15:32:43 dnsmasq-dhcp[19767]: DHCPREQUEST(eth1) 192.168.1.104
a4:fc:77:xx:yy:zz
May 30 15:32:43 dnsmasq-dhcp[19767]: DHCPACK(eth1) 192.168.1.104
a4:fc:77:xx:yy:zz DESKTOP-HOSTNAME
May 30 15:33:29 dnsmasq-dhcp[19767]: DHCPREQUEST(eth1.10) 192.168.1.104
a4:fc:77:xx:yy:zz
May 30 15:33:29 dnsmasq-dhcp[19767]: DHCPNAK(eth1.10) 192.168.1.104
a4:fc:77:xx:yy:zz wrong network
May 30 15:33:29 dnsmasq-dhcp[19767]: DHCPDISCOVER(eth1.10)
a4:fc:77:xx:yy:zz
May 30 15:33:29 dnsmasq-dhcp[19767]: DHCPOFFER(eth1.10) 192.168.10.23
a4:fc:77:xx:yy:zz
May 30 15:33:29 dnsmasq-dhcp[19767]: DHCPREQUEST(eth1.10) 192.168.10.23
a4:fc:77:xx:yy:zz
May 30 15:33:29 dnsmasq-dhcp[19767]: DHCPACK(eth1.10) 192.168.10.23
a4:fc:77:xx:yy:zz DESKTOP-HOSTNAME
May 30 15:33:31 dnsmasq-dhcp[19767]: DHCPREQUEST(eth1) 192.168.10.23
a4:fc:77:xx:yy:zz
May 30 15:33:31 dnsmasq-dhcp[19767]: DHCPNAK(eth1) 192.168.10.23
a4:fc:77:xx:yy:zz wrong network
May 30 15:33:33 dnsmasq-dhcp[19767]: DHCPREQUEST(eth1) 192.168.10.23
a4:fc:77:xx:yy:zz
May 30 15:33:33 dnsmasq-dhcp[19767]: DHCPNAK(eth1) 192.168.10.23
a4:fc:77:xx:yy:zz wrong network
May 30 15:33:36 dnsmasq-dhcp[19767]: DHCPDISCOVER(eth1) a4:fc:77:xx:yy:zz
May 30 15:33:36 dnsmasq-dhcp[19767]: DHCPOFFER(eth1) 192.168.1.104
a4:fc:77:xx:yy:zz
May 30 15:33:36 dnsmasq-dhcp[19767]: DHCPREQUEST(eth1) 192.168.1.104
a4:fc:77:xx:yy:zz
May 30 15:33:36 dnsmasq-dhcp[19767]: DHCPACK(eth1) 192.168.1.104
a4:fc:77:xx:yy:zz DESKTOP-HOSTNAME
May 30 16:47:56 dnsmasq-dhcp[19767]: DHCPREQUEST(eth1.10) 192.168.1.104
a4:fc:77:xx:yy:zz
May 30 16:47:56 dnsmasq-dhcp[19767]: DHCPNAK(eth1.10) 192.168.1.104
a4:fc:77:xx:yy:zz wrong network
May 30 16:47:56 dnsmasq-dhcp[19767]: DHCPDISCOVER(eth1.10)
a4:fc:77:xx:yy:zz
May 30 16:47:56 dnsmasq-dhcp[19767]: DHCPOFFER(eth1.10) 192.168.10.23
a4:fc:77:xx:yy:zz
May 30 16:47:56 dnsmasq-dhcp[19767]: DHCPREQUEST(eth1.10) 192.168.10.23
a4:fc:77:xx:yy:zz
May 30 16:47:56 dnsmasq-dhcp[19767]: DHCPACK(eth1.10) 192.168.10.23
a4:fc:77:xx:yy:zz DESKTOP-HOSTNAME
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to