From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 974E6200373 for ; Thu, 8 Dec 2011 03:40:43 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id pB8Beehx021089; Thu, 8 Dec 2011 03:40:40 -0800 Date: Thu, 8 Dec 2011 03:40:40 -0800 (PST) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jow@openwrt.org, Stephen Walker , cerowrt-devel@lists.bufferbloat.net, Felix Fietkau Subject: Re: [Cerowrt-devel] Nuking the device naming scheme in cerowrt X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 11:40:43 -0000 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