[Cerowrt-devel] Nuking the device naming scheme in cerowrt

[david at lang.hm]

On Thu, 8 Dec 2011, Dave Taht wrote:

> This is about the 5th? in a string of emails talking about what might
> be dropped from the next release of cerowrt.
>
> One change I made early on was that I renamed the devices to be
> semantically equivalent to what they did, rather than what they were.
> I also encoded what physical radio a given virtual ssid was attached
> to.
>
> The device naming string is defined here:
>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Device_naming_scheme
>
> I did this for several reasons.
>
> 1) *I* can never remember that 'eth0' is the gateway to the internet
> and eth1 the gateway to the internal network, or is it br-lan the
> bridge that's the internal network, or what?

first off, I am extremely familiar with Linux, but only somewhat with 
openWRT, so things that are a limitation of the GUI I will probably get 
wrong.


Linux allows you to rename interfaces, and bridges, but I find that it 
seldom really helps a lot.

That being said, openwrt by default names the default uplink network 'wan' 
(with the interface eth1) and everything else 'lan' (technically br-lan, 
with all the other interfaces bridged in to this), it gives you the 
ability to name the networks and even name the interfaces.

this already is available today with the stock software, including the 
luci gui, but the user needs to decide to use the names.

> 2) I wanted to make more apparent the concept of 'guest' interfaces
> that would let you share correctly with another router, or your
> neighbor.

openwrt supports this, but you do have to setup the mapping yourself. the 
good news is that you usually only have to do this once.

It would probably not be a bad thing to have the default configuration 
that you ship include a 'guest' set of networks (SSIDs on each radio and a 
VLAN that's defined as wired guest, but with no interfaces assigned to it 
yet)

> 3) I wanted to be able to have firewall rules and nat not have to be
> re-applied when an interface went up or down, thus not breaking
> existing connections.

firewall rules being applied to an interface do not have to break the 
existing connections, flushing the connection table will break the 
existing connections, and if a connection has heavy enough traffic on it 
so that a packet arrives in the brief period where the interface is down 
it will bounce and trigger a connection close.

This may just be getting a flag in place somewhere to not flush the 
connection tracking table.

My fireall at home is an ancient pentium 166 (I really do need to around 
to replacing it one of these years :-) and about 6 months ago one of the 
NICs started getting flaky where it would stop transmitting. As a 
temporary work-around I ended up setting up a cron job that did a ping to 
an internal server once a minute and bounced the interfact if the ping did 
not work. this ran for about 3 months (before I moved to a different 
interface on the box) and was triggering a couple dozen times a day and I 
never had a connection broken as a result.

> 4) I wanted to be able to easily express the complexity involved in
> writing firewall rules that did  the right thing. For example, with 6
> interfaces, you ended up with a combinatorial complexity in creating
> firewall rules, otherwise, and dealing with that, is hard.
>
> With semantically named interfaces, we could theoretically achieve all
> the above without explosion in complexity or performance loss: e.g
>
> iptables -o g+ -j dealwithguestinterfaces
> iptables -o s+ -j dealwithsecureinterfaces
>
> (the '+' is a pattern match character)
>
> 5) Firewall rules and extensive packet classification really impacted
> performance at the time. (hugely) They still do, but not as much as
> they once did, in part due to nbd's unaligned access improvements, in
> part because I took the crazier classification rules and rewrote them
> in C.


There is a huge amount that can be done with iptables that is really hard 
to do in a generic way. As a result, every firewall GUI and configuration 
tool that I have seen (including the 6 figure commercial ones) manages the 
rules for each interface independantly.

what you really want to do is to make real use of custom firewall chains, 
so that you do one pass of rules to categorize the traffic (usually by 
source/destination), and then jump to a chain to do the ugly, detailed 
decision making stuff.

At work I have a firewall that had a 200 line iptables ruleset on it. 
using one of the 6 figure commercial firewall management tool and putting 
the same effective rules in it, the result was a 2000+ line ruleset, that 
was MUCH harder to understand. The performance is also significantly 
better if you can take the tree approach to your ruleset instead of having 
one massive list of rules (the time it takes to go through the iptables 
rules is proporional to the number of rules that you need to evaluate 
before hitting an decision, this is analogious to a dpeth first search 
through a tree vs a linear search on a list)

OpenWRT has a good start on this in the firewall zone definitions, but 
unfortunantly when you are creating the rules you can't really take 
advantage of this.

> Problems:
>
> 1) openwrt's methods of dealing with the firewall involve treating
> firewalling as a separate subsystem from the interfaces, and since
> they don't create a lot of interfaces, the added complexity I was
> trying to simplify doesn't appear. There are also, certainly,
> compelling reasons to treat firewalling and nat as separate from the
> interfaces themselves.
>
> Regardless, I'd still really like to see support for the + syntax
> arrive up in the gui and scripts, but I haven't got around to fixing
> it myself, like so many other things.
>
> 2) And it really bugs me that 'nat' is not a discoverable property of
> the interface.

NAT actually has very little to do with the interface. NAT is the result 
of decision making rules, and you can have NAT on some packets that go out 
an interface, but not others, even from the same source IP to the same 
destination IP (although anyone doing so needs to have their head examined 
:-)

> 3) I never got around to creating a scheme that handled vlans well.
> The industry standard naming system of device.X doesn't map well into
> the above pattern matching scheme!!
>
> 4) This change REALLY confused openwrt veterans and people that were
> just used to seeing eth0 and stuff like that. Their fingers 'just
> type' eth0.

not just openWRT venterans, I'll bet it confused a lot of linux veterans 
as well.

> Conversely, it didn't bother new users at all.
>
> Now, part of this idea was accepted upstream - wireless devices are
> now named wlanX-Y, where X is the radio name - which is good.
>
> Dropping the naming scheme would involve some headache, but bring back
> more backward compatability with 'normal' openwrt.

this would be a very good thing

> I'd like to go back and more thoroughly analyze the performance
> problems we ran into with extensive rules and classification we were
> doing then, particularlly with ipv6, and see what they really cost
> now, and what the semantic change to the device naming scheme can do
> to improve both performance and correctness.
>
> On the other hand, it's just another headache all it's own, unlikely
> to be adopted unless some advantage can be shown to work well.

I'd need to see the rules that you were creating, but I would be surprised 
if there wasn't a way to do some cleanup of them to improve the 
performance.

David Lang