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

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 11, 2015 18:02 UTC (Fri) by josh (subscriber, #17465)
In reply to: OpenWrt "Chaos Calmer" 15.05 released by michel
Parent article: OpenWrt "Chaos Calmer" 15.05 released

I have the same problem. I'm increasingly tempted to make my next router a relatively cheap system with a pair of Ethernet ports, a wifi card capable of access-point mode and a large external antenna, and a full installation of Debian.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 14, 2015 16:57 UTC (Mon) by smckay (guest, #103253) [Link] (11 responses)

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.

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 (guest, #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 (guest, #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.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 17, 2015 8:27 UTC (Thu) by fb (guest, #53265) [Link]

Consider buying one of the supported editions of the Archer C7/C5 http://wiki.openwrt.org/toh/tp-link/tl-wdr7500

They have been a very popular choice for OpenWrt.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 21, 2015 11:12 UTC (Mon) by mstone_ (subscriber, #66309) [Link] (1 responses)

I suggest just building a router that's a router, and using an access point that's an access point--mixing the two just ends us causing more work in the long term. Routers are well understood and rock solid, while wireless drivers are always either unstable, buggy, or obsolescent; there's no up side to screwing up the router/firewall with wifi.

OpenWrt "Chaos Calmer" 15.05 released

Posted Sep 22, 2015 8:09 UTC (Tue) by dlang (guest, #313) [Link]

what? you mean you don't want a router/firewall between your wifi and your sired network?

your wifi device has a constant speed wired network on one side and a variable speed wireless network on the other side. that takes a lot of smarts to handle (and arguably, nothing currently handles it right)

wifi drivers are a problem, but so are the drivers for the DSL/Cable/Fiber interfaces (you don't think that they are normal ethernet do you?)

Also, since many people don't have any wired devices, why add the additional failure points of having two devices instead of one?

The cost of adding wired router functionality to a wifi device is really low. A stand-alone 5 port switch sells for <$40 retail with the need for a separate case, power supply, stock number packaging, shipping,e tc. how much do you think it costs to add the switch chip and ethernet jacks to a wifi systems? I'll bet it's somewhere in the low single digital $ range, and wouldn't be surprised if it's <$1