[Cerowrt-devel] CeroWrt bits not in OpenWrt (renamed thread)

Sat Feb 28 16:41:25 EST 2015

On Sat, 28 Feb 2015, Dave Taht wrote:

> You all are right, there are several distinct classes of
> cerowrt-specific mods. I certainly would like to leverage their
> enormous build system (popping out two builds on all arches every
> day), and not have to do regular builds and testing again myself, ever
> again (for as long as I live!). Ideally I would just hand off our
> latest (dumb or smart) bit of code, developed on an x86 and magically
> have someone hand me a huge set of test results on platform of choice,
> a day later.
>
> It is really amazing the architecture coverage they have:
>
> http://downloads.openwrt.org/snapshots/trunk/
>
> A) The most troublesome problem is kernel hacks.

how much of what's left is kernel hacks?

I haven't dug down into it much, but I think I've seen from the discussions thta 
OpenWRT has the ability for you to specify a different kernel version than 
stock. The answer may be to maintain a fork of the kernel with the changes.

> A thought would be to ask the openwrt devs to have a cerowrt repo (or,
> more likely, a make-wifi-fast repo at this point),
> but still several of these patches and future work planned are going
> to be pretty invasive (hitting the mac80211 layer hard as well as
> ath9k). Hopefully felix and co are going to handle much of that, and
> our role here will be more of testing it...
>
> Several other patches are not as invasive - all the different qdiscs
> under test, for example, could easily go into their own
> package. The problem I have here is I am resistant to putting buggy
> code into public repos. For example, the "pfq_codel" version
> does not work worth a damn, and I keep it around because one day it
> might provide insight into why packet fairness doesn't
> work well (or the code may merely be buggy). Similarly, "cake2" is not
> fully baked yet. My own preference for new development
> is to have a small, intelligent, educated number of testers before
> stuff goes upstream.

Ok, there are two cases here.

1. stuff that didn't work out

2. new stuff being experimented with

I'll point out that once it's in a git repo, you can always resurrect something 
old, just keep a record of the commit that deletes the old stuff and you can 
resurrect it by reverting that commit. This does assume that you don't need to 
keep modifying the old stuff to keep it working with kernel changes.

Especially if you are maintaining a kernel fork, I don't see anything wrong with 
including the experimental stuff, and not much problem with you keeping the old 
stuff around (just make sure you add a comment to the help text or description 
that says that it didn't work well)

> I am fully aware that it took too long to get the good stuff done here
> pushed upstream on a regular basis, so certainly working more upstream
> than we did would be good.

for the kernel, you have two upstreams, kernel.org and OpenWRT. The question is 
how frequently you want to go through the work of merging with upstream. I 
personally would love to see you developing against kernel.org kernels and 
pushing your changes that work there, but that means that about every two months 
you will have a bunch of changes to merge into your work (I don't know how much 
upstream development is actually taking place in the areas that you will be 
working on), but this puts you in the best position to merge your changes 
upstream and have OpenWRT collect them by default when they upgrade their 
kernel.

> B) Then there is stuff that is largely configuration, and I can see
> that being a meta package that you
> would have to install manually after flashing, with specialized other
> packages (like an iproute2-cerowrt) with the needed
> other patches - but that is likely to break on many an architecture in
> terms of correctly modifying the network, wireless,
> firewall and dhcp configurations
>
> ... and it presently is invasive in the boot process itself, renaming
> the core network interfaces there.

Yes, this is why I think that it may be worthwhile to make a run at getting this 
change upstream into OpenWRT. It's extremely invasive, but I think the case can 
be made that it simplifies things for users. This can't be done in a stable 
branch, and I would expect that there will be a lot of debate around it, so we 
may be far enough in CC that this won't actually happen until DD, but the sooner 
the discussion starts, the better.

> as an example, the wndr4300 uses vlans by default. The archer has 3
> radios. Everything is just mildly, maddeningly,
> different.

:-)

multiple radios makes sense, why does the wndr4300 use vlans by default?

> The core thing is that in order to sanely test wifi, the darn
> interfaces need to be unbridged, and nearly everything else we had to
> do
> to do that, fell out of that. And as it turned out, we never really
> got around to tackling wifi in the last release, going all ga-ga over
> fixing the ISP link. (which of course, I am very happy about. :))

I agree with this, but I don't think that this is something that we need to make 
the default upstream. A metapackage to change the configs from bridged to 
routed, or pushing a config option upstream to have it support alternate config 
packages. This would be a huge amount of work to create initially, but ongoing 
maintinance is mostly just adding it to new devices, and it's made much easier 
with functional naming. Thinking about it, this may be the way to get functional 
naming in, make it a set of optional configs and then in DD or EE change it to 
the default.

> C) I would certainly like, in particular, for someone to improve
> openwrt's firewalling system in general, there is a need for a
> "fw4" which would generate nf_tables rules rather than iptables.

While I agree with you on this, I think you need to think of this as a separate 
major project in it's own right.

If functional naming gets upstreamed, making changes to the default firewalling 
gets MUCH easier, and a lot of the different firewall rules for the existing 
configs get simplified. The firewall rules would get simplified further with the 
pattern based rules (once you have functional names to pattern match against)

switching to nf_tables rules rather than iptables rules is a major step beyond 
that, and realistically I think it would need to wait until sysadmins start 
using nf_tables rules on servers and firewalls. Otherwise you are making it much 
harder for people to understand and tweak the rules made by the GUI. A fw4 that 
can make either iptables or nf_tables rules could go in quickly, and a tool like 
that would make it much easier for people to get comforatable with nf_tables 
(and see what benefits there are of switching)

David Lang

>
> On Sat, Feb 28, 2015 at 7:25 AM, Rich Brown <richb.hanover at gmail.com> wrote:
>> Folks,
>>
>> Two thoughts:
>>
>> 1) I'm renaming this thread so that it is easily found in the archives (it was "Just FYI: WNDR3700 (v2???) refurbs available on Amazon for USD49.99")
>>
>> 2) I've been maintaining the CeroWrtScripts (https://github.com/richb-hanover/CeroWrtScripts) that has a shell script to set lots of the parameters of CeroWrt into a consistent state. To the extent that the capabilities below are simple config changes, we can use this script as a base for converting "Stock OpenWrt" into something more CeroWrt-like.
>>
>> Best,
>>
>> Rich
>>
>> On Feb 27, 2015, at 11:44 PM, David Lang <david at lang.hm> wrote:
>>
>>> On Fri, 27 Feb 2015, Dave Taht wrote:
>>>
>>>>> you may have posted this and I'm just not remembering, but do you have a
>>>>> list of what's in CeroWRT that OpenWRT won't take upstream (and any info on
>>>>> why they won't take the items)?
>>>>>
>>>>> Daivd Lang
>>>
>>> trying to break this down by what's a config policy vs what's code (or significant config logic)
>>>
>>>> * Unbridged interfaces - routing only
>>>
>>> simple config
>>>
>>>> * Device Naming by function rather than type
>>>
>>> is this code or just a set of config settings?
>>>
>>>> * More open to ipv6 firewall
>>>
>>> is this just default settings?
>>>
>>>> * Firewall using device pattern matching to avoid O(n) complexities in
>>>> firewall rules
>>>
>>> This sounds like default settings.
>>>
>>>> * Babels on and preconfigured by default
>>>
>>> any code here? or is just that it's there by default?
>>>
>>>> * Oddball IP address range and /27 subnets
>>>
>>> simple config
>>>
>>>> * Polipo Web proxy
>>>
>>> is this just a different default than upstream?
>>>
>>>> * Samba by default
>>>
>>> simple config
>>>
>>>> * Faster web server
>>>
>>> just a different default?
>>>
>>>> * Weird port for the configuration web server
>>>
>>> simple default
>>>
>>>> * Pre-enabled wifi and wifi mesh interfaces
>>>
>>> different defaults
>>>
>>>> * Huge amount of alternate qdiscs (like pie, ns2_codel, cake, cake2, etc)
>>>
>>> any custom code here or is this just different kernel config options being turned on?
>>>
>>>> And:
>>>>
>>>> A build that includes all these things by default.
>>>
>>> The vast majority of these seem to be config selections rather then code. Which shows a huge amount of progress from the early days.
>>>
>>> There seem to be a couple policy points that are worth trying to fight to get upstream
>>>
>>> 1. Device Naming by function
>>>
>>> 2. Firewall rules by device pattern matching.
>>>
>>> 3. pre-enabled wifi and mesh interfaces
>>>
>>> 4. Samba default (see the recent discussion of common authentication)
>>>
>>> 5. possibly the web proxy
>>>
>>> Things that are probably not worth fighting for
>>>
>>> 1. a build that includes all of this by default
>>>
>>> 2. all the alternate qdiscs enabled by default
>>>
>>> 3. weird port for the config web server
>>>
>>> 4. oddball IP ranges, /27 subnets, bables, and routing between interfaces by default. (This is an approach that is perfect for the "super-duper" builders, although this may just end up being a different default config)
>>>
>>> any major disagreements or things I missed?
>>>
>>>
>>> It hit me as I was finishing this that a couple things may combine here.
>>>
>>> By doing device naming by function, firewall rules by device (which ends up being by function), it may make it far easier to have alternate configs, one for bridging, one for routing, and to have options to pre-enable the wifi and mesh interfaces.
>>>
>>> Thoughts from those who have been more involved with pushing things upstream?
>>>
>>> David Lang
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
>
>
>