On 23/11/15(Mon) 12:57, Momtchil Momtchev wrote: > [...] > So here is my setup: > > NETWORK A is a wired network with private IPv4/24 addr a public IPv6/64 > addr > NETWORK B is a wireless network with private IPv4/24 addr a public > IPv6/64 addr > The Broadband equipment provides a single IPv4/32 public addr and a > public IPv6 /64 addr (French broadband provider Free/Proxad) > So the OpenBSD box (PC Engines APU) has one public IPv4/32 addr and one > public IPv6 addr on a /64 network. > > > NETWORK A <-> (re0) (bridge0) (re2) <-> Broadband equipment > NETWORK B <-/ (athn0) > > TV Decoder <-> (re0 vlan 100) (bridge1) (re2 vlan 100) <-> IPTV Server > > > The only way I can manage this setup is by bridging the IPv6 traffic and > routing/NATing the IPv4 traffic. > So what I did, I started from the BLOCKNONIP code and made a bridge that > passes only IPv6 traffic. > This setup is very common in France and was working perfectly with my > patch on OpenBSD 4.x. > > There is a bridge0 with > re0 > athn0 > re2 (modified blocknonip) > > And a bridge1 with > re2.100 > re0.100 > > Since I upgraded to 5.8 I found that IPv4 ARP requests were slipping > through my version of blocknonip. This is a problem because the broadband > equipment picks them up. When I started looking at the code, I found that > ARP requests from NETWORK B (only from NETWORK B, never NETWORK A, don't > know why, maybe because B doesn't have an IP address assigned) were being > resent to the external network via new code path that didn't exist in > 4.8/4.9.
It's hard to discuss without seeing your "version of blocknonip". But still what have you seen? You're still giving your conclusion instead of what you observed. Did you use tcpdump(8) on the interfaces? What kind of ARP request are we talking about here? echo, reply? Sent from which host? To which destination? > Also, ARP requests on the bridge1 are being resent to the bridge0. > Those packets are being sent by bridge_output(). That seems to be a known regression on 5.8 because re(4) supports hardware VLAN. The problem is that bridge_input() is called before vlan_input() for every packet received on a physical interface. Since the hardware have already removed the VLAN header you see it in bridge0. This should be fixed in -current as long as you configure your pseudo interfaces in the order you need: # ifconfig bridge0 add re0 # ifconfig vlan0 vlan 100 vlandev re0 This way vlan_input() will run before bridge_input() and the packets with a VLAN ID 100 wont enter bridge0 > Those packets are being sent by bridge_output(). These are not forwarded > packets. Which packets? Sorry but I don't understand what kind of packets you're talking about so I cannot help. > In my setup, receiving an ARP request from athn0 will spawn another > ARP request on re0. Receiving an ARP request on re2.100 will spawn another > request on re0 (besides forwarding the request to re0.100). That one does > not feel very right even without my patch. So my questions were : > > First of all, is bridge_output() used to forward packets now? Or is it > only for local traffic? If it is sometimes used to forward packets, then a > check against BLOCKNONIP would be needed? Reyk Floeter confirmed that it was > used only for local traffic. It is only used to send local traffic, just like Reyk said. > Second, why bridge_output()? In my understanding output is never done > directly on the bridge, it is always on one of the underlying interfaces? Please look at the code, we write Free Software for a reason: http://bxr.su/search?q=bridge_output&defs=&refs=&path=&project=OpenBSD > This could have implications for pf too? I don't understand your question. What could have implication? > From what I saw bridge_output() is > used directly only in one obscure case for sending back ICMP errors. Why do you think it's an obscure case? > But it > is also the output function of the interface? This is why I have a hard time > finding the origin of those ARP requests. So this is my real question, who > sends ARP requests directly on the bridge via bridge_output()? One do not find who send packets by looking at the code but by looking at the packets. Since the beginning of this thread we don't know the content of the packets, so we don't if they are forwarded or not, if they are multicast or not if they are addressed to the OpenBSD machine or not, if they are reply to other packets: we know nothing. Plus we don't know the output of your ifconfig nor which code you're running. Come on, if you want some help, let others help you ;) Cheers, Martin
