Re: bridge(4) - feedback local packets into ether_input()

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Fri, Apr 22, 2016 at 10:14 AM, Roy Marples <roy%marples.name@localhost> wrote:
> Hi List!
>
> So my goal is to run a DHCP server and client on two virtual interfaces
> and get them talking to each other. After the initial idea of
> vether/pair was shot down I looked into what bridge(4) could do after
> much prompting by our beloved Taylor.
>
> Here is what I am trying to achieve WITHOUT BPF* (it works with BPF):
> DHCP Server --- > tap0 --- > bridge0 <---- tap1 <----- DHCP client
>
> Because tap(4) will drop packets if there is nothing using it as a TAP
> device (in this scenario we're just treating it as an endpoint) we have
> to solve the problem in bridge(4).
>
> Because DHCP is essentially a broadcast operation, I copied the logic
> from bridge_broadcast() into bridge_output() (used for originating local
> packets) where we send the packet to ether_input() if it's broadcast or
> multicast. Because bridge_output has coding for if src_if == dst_if I
> reversed the logic on sending it to ether_input (src_if != dst_if) so
> that the receiving interface doesn't double up.
>
> The attached patch allows this to work fine.
> Comments are welcome, especially if you think it breaks something.

It at least doesn't break ATF tests under tests/net :)

I don't notice any issues by the change for now. So no objection
from me.

BTW with the change can we write ATF tests of dhcpcd without interfering
the host (or with minimum affects)?

  ozaki-r