[LEDE-DEV] [RFC 0/1] x86: Add support for the PC Engines APU2 Board

[Dave Taht]

Everything important in CeroWrt long ago made it upstream - the apu2
(which, btw, I have been using as my main test platform for the
make-wifi-fast work) has BQL on the intel network drivers, already,
fq_codel is the default in lede, sch_cake is available as an optional
package, and the make-wifo-fast ath9k work is partially upstream in
lede, with only the airtime fairness patches remaining to get folded
in (http://blog.cerowrt.org/post/real_results/ more detail here:
https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html
).

dnsmasq-dnssec is an optional package in lede as are the sqm-scripts,
luci-app-sqm, and the bcp38 support.

So all that is pretty generic to lede/openwrt now. Ath10k needs work,
mt72 needs work, but in neither case is that specific to the apu2.

What never made it to openwrt from cerowrt was:

A) the controversial "rename the devices to reflect the security
model" portion of the firewall code. That code allowed for never
having to reload the firewall as it used a pattern match on the device
name to dynamically add devices to a secure or guest zone. Instead of
having one rule for eth0, eth1, eth2, I renamed devices to se00, se01,
ge00, and used "s+" as the match.

I never figured out how to make that work with vlans, and it was my
hope we'd end up with something using nftables that did the same
thing. Not huge on reloading firewall rules all the time....

B) homenet support - that's available in openwrt but not well
incorporated. That's hnetd, and babeld and the mdns-proxy stuff.

C) routing, not bridging, by default, Routing makes a lot of sense in
a lot of cases, and making sure openwrt does that well is something
that should be on-going tested - with batman, babel, olsr, etc. The
rest of the time bridging is generally faster and simpler.

There may well be other cerowrt features I'm forgetting, but that's
all I can think of.

I look forward to migrating my apu2s to lede soon!