On 22/11/15(Sun) 18:30, Momtchil Momtchev wrote:
> On 22/11/2015 17:48, Martin Pieuchot wrote:
> >On 22/11/15(Sun) 16:56, Momtchil Momtchev wrote:
> >>On 22/11/2015 15:52, Martin Pieuchot wrote:
> >>>
> >>>When you say "the bridge changed somewhat" are you saying that you see
> >>>a regression? Could you share your setup that, I guess work with 4.9,
> >>>and no longer work with 5.8.
> >>>
> >>>
> >I don't understand what you mean with "_BLOCKNONIPV6_ bridge". ifconfig(8)
> >clearly say:
> >
> > blocknonip interface
> > Mark interface so that no non-IPv4, IPv6, ARP, or Reverse ARP
> > packets are accepted from it or forwarded to it from other
> > bridge member interfaces
>
> I have a modified bridge that adds a new bridge option - BLOCKNONIPV6 -
> to block IPv4 traffic but pass IPv6 traffic. There's no regression, my only
> problem was that in 4.9 bridge_output() was never used in my particular
> case. In 5.8 bridge_output() is used for some strange forwarding of ARP
> packets - every ARP request on the internal side coming from a bridge
> interface without an IP address (yes, only on interfaces without an IP
> address) spawns an ARP request on the external side. That request is coming
> from bridge_output(), not the usual bridge code path in bridgeintr().
The result of your analysis is either incorrect or there's a bug I
couldn't found by looking briefly at the code. In both cases I can't
help you because you're not sharing the important pieces of informations.
When an ARP packet is received on a bridge member bridgeintr() is called.
So what you say about "strange forwarding of ARP packets" doesn't match
with what you say as "That request is coming from bridge_output()".
> In a
> non-modified stock OpenBSD bridge this would be the correct behaviour, so
> there is no bug here.
What would be this correct behaviour? I don't understand what you're
describing so I cannot say if I agree that there's no bug here. But I'd
be glad if I could understand.
> It is just somewhat weird that some ARP requests are
> forwarded through bridge_output(), not through the usual code path.
Why do you think it is weird? What make you think that it isn't taking
the "usual code path". What is the "usual code path" for you?
> My question is who uses bridge_output()? Except one obscure case for
> sending back ICMP errors,
Why do you think it is an obscure case?
> normally all local traffic should originate in the
> output() function of the underlying interface? Or am I missing something?
What do you mean by "local traffic"? I thought your were talking about
forwarding?
The picture is as follow:
RECEIVING SENDING
(userland) (userland)
^ |
INCOMING (interrupt handler) | |
| | |
v v
if_input -> pseudo_input -> | STACK | -> if_output -> if_enqueue -> if_start
^
| |
`-------------> | BRIDGE | -------------'
> If you think that my feature presents any interest, I can tidy it up and
> submit it. It splits BLOCKNONIP into BLOCKNONIPV4 and BLOCKNONIPV6. I need
> it because in my particular case IPv4 should be NATed and IPv6 should be
> switched as you cannot split IPv6 into arbitrary subnets below /64, so you
> have to keep it whole. It is the only way to route and filter both IPv4 and
> IPv6 traffic with one particular French broadband service provider but there
> could maybe be other uses for it.
I think it might be interesting, at least to better understand your uses
case and the possible bug/limitation in bridge(4).
