[Cerowrt-devel] Nuking the device naming scheme in cerowrt
Dave Taht
dave.taht at gmail.com
Wed Dec 7 22:52:08 PST 2011
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?
2) I wanted to make more apparent the concept of 'guest' interfaces
that would let you share correctly with another router, or your
neighbor.
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.
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.
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.
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.
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.
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.
Thoughts?
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
More information about the Cerowrt-devel
mailing list