OpenWrt "Chaos Calmer" 15.05 released [LWN.net]

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 14, 2015 16:57 UTC (Mon) by smckay (guest, #103253)
In reply to: OpenWrt "Chaos Calmer" 15.05 released by josh
Parent article: OpenWrt "Chaos Calmer" 15.05 released

I did this, and in general it works very well. Having a full system makes it much easier to set up weird things like SSL interception with Squid. However, mDNS doesn't work quite right. I have the LAN port & 2 APs bridged together, and AFAICT the wifi cards don't like frames with spoofed MAC addresses, which is what bridged mDNS packets look like to the firmware. So if I may make a suggestion, it would be to leave each local interface on its own subnet and let avahi-daemon do the mDNS bridging. Other than that, I'm very happy with my router that can be administered properly and isn't a tiny box full of who-knows-what janky hardware with barely enough power to both store and forward.

to post comments

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 16, 2015 6:37 UTC (Wed) by marcH (subscriber, #57642) [Link] (10 responses)

> and AFAICT the wifi cards don't like frames with spoofed MAC addresses, which is what bridged mDNS packets look like to the firmware.

Could you elaborate? For instance are you referring to the wifi cards acting as APs or to the other, station ones? You wrote "spoofed"; does that mean the wifi firmware is looking at IP addresses? Sorry I'm confused.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 16, 2015 12:47 UTC (Wed) by smckay (guest, #103253) [Link] (9 responses)

Sorry, I forgot that the "wifi card firmware is at fault" hypothesis was just a hypothesis. What I observed with tcpdump was that mDNS works fine within a LAN segment, but mDNS answers got mangled crossing the bridge from one AP to the other. The source IP would be changed to the bridge's IP and the source port would be seemingly random. Looking at the chain of receiving card -> br0 -> transmitting card, I can only see the transmitting card as being motivated to change the packet.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 16, 2015 16:53 UTC (Wed) by raven667 (subscriber, #5198) [Link] (8 responses)

Bridging multicast, which brings with it the need to inspect IGMP, is more complicated than just unicast and broadcast but in your description it sounds more like the bridge is also running an mDNS daemon, such as Avahi, which may not be configured correctly to work on a bridge instead of an endpoint host.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 16, 2015 23:08 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

> Bridging multicast, which brings with it the need to inspect IGMP, is more complicated than just unicast and broadcast

It's only an issue for expensive, "enterprise" switches trying to be smart and optimize for large networks. Cheaper and simpler switches just broadcast multicast frames.

> it sounds more like the bridge is also running an mDNS daemon, such as Avahi, which may not be configured correctly to work on a bridge instead of an endpoint host.

By essence shouldn't software running on a software bridge not be aware of any bridging going on and see a single (bridge) interface? The real interfaces would normally not even have any IP configuration.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 17, 2015 3:19 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

Linux can do all sorts of things and you can still interact with the bridge member interfaces as well as the bridge virtual interface as far as I can tell, I just tested adding an IP and pinging a bridge member interface and it seemed to work. Linux packet forwarding, even before we get to OpenVSwitch, is complicated.

https://upload.wikimedia.org/wikipedia/commons/3/37/Netfi...

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 17, 2015 6:09 UTC (Thu) by marcH (subscriber, #57642) [Link]

I have no doubt you can do complicated things. I don't think you have to in such a relatively simple use case.

On the other hand I never found the bridge configuration super intuitive so I guess it's easy enough to make things artificially complicated by mistake.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 17, 2015 14:28 UTC (Thu) by smckay (guest, #103253) [Link] (4 responses)

I tried turning off avahi-daemon on the router--same behavior. Multicast packets crossing from one AP to the other have their source address changed to the router's. Some misconfiguration, maybe. It's not a huge deal, but this bridge is misbehaving and refusing to tell me whty--it's like learning vi all over again.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 17, 2015 16:12 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (3 responses)

The source address & port changes you described sound more like NAT than bridging.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 17, 2015 16:24 UTC (Thu) by smckay (guest, #103253) [Link] (2 responses)

Yeah, they do, which might make a little bit of sense if multicasts were also being sent out the WAN port, but they aren't.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 17, 2015 17:54 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

Perhaps the NAT rules for the WAN port are erroneously being applied to packets traversing the bridge? IIRC the decision of whether to mangle a packet for NAT is separate from the decision to route the packet out over any particular interface, and if you have multiple interfaces you need to include a condition (e.g. in my case it's "-A POSTROUTING -t nat -s $LOCAL_IP_RANGE -o $WAN_DEV -j MASQUERADE") to prevent NATing of internal packets. If the "-o $WAN_DEV" condition were omitted it could cause the symptoms you're seeing.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 17, 2015 18:23 UTC (Thu) by marcH (subscriber, #57642) [Link]

The easiest to troubleshoot bridging is to temporarily iptables --flush and see whether the problem still happens or not.