From f3d832b41f44c856003517c583fbd7af4dca722c Mon Sep 17 00:00:00 2001
From: Neil Jerram <Neil.Jerram@metaswitch.com>
Date: Fri, 8 Apr 2016 19:23:47 +0100
Subject: [PATCH] Fix DHCPv4 reply via --bridge-interface alias interface

Sending a DHCPv4 reply through a --bridge-interface alias interface
was inadvertently broken by

  commit 65c72120
  Author: Lung-Pin Chang <changlp@cs.nctu.edu.tw>
  Date:   Thu Mar 19 23:22:21 2015 +0000

      dhcp: set outbound interface via cmsg in unicast reply

        If multiple routes to the same network exist, Linux blindly picks
        the first interface (route) based on destination address, which might not be
        the one we're actually offering leases. Rather than relying on this,
        always set the interface for outgoing unicast DHCP packets.

because in the aliasing case, iface_index is changed from the index of
the interface on which the packet was received, to be the interface
index of the 'bridge' interface (where the DHCP context is expected to
be defined, and so needs to be looked up).

For the cmsg code that the cited commit added, we need the original
iface_index; so this commit saves that off before the aliasing code
can change it, as rcvd_iface_index, and then uses rcvd_iface_index
instead of iface_index for the cmsg code.

Thanks to Luis Carvalho for spotting the error.

Commit 51967f98 began treating SERVFAIL
as a successful response from an upstream server (thus ignoring future
responses to the query from other upstream servers), but a typo in that
commit means that REFUSED responses are accidentally being treated as
successful instead of SERVFAIL responses.

This commit corrects this typo and provides the behaviour intended by
commit 51967f98: SERVFAIL responses are considered successful (and will
be sent back to the requester), while REFUSED responses are considered
unsuccessful (and dnsmasq will wait for responses from other upstream
servers that haven't responded yet).