roguemoko at roguewrt.org
Wed Oct 15 07:49:34 CEST 2008
On Wednesday 15 October 2008 15:36:40 Joel Newkirk wrote:
> Interesting - I've been approaching it from the other end, trying to alter
> base configuration instead of adding a 'network manager'-like layer
> wrapping it all. When I look at the default behavior of the various
> interfaces, and various means of bringing them up/down, I see differing
> approaches where some use /etc/resolv.conf, some use resolvconf (the
> binary), some do their own thing, but none of them really cooperating. I
> feel if they're all brought in tune (all handling route and DNS
> additions/removals centrally, instead of each handling route & DNS
> replacements as though they're king) that everything else becomes much
Same thought. The main reason for our approach was due to the varying systems
we maintain. More often than not they are *BSD, well for me anyway. This
approach should function regardless of the underlying system, so long as it
uses, say, udhcpc.
> I've been working on resolv.conf plus default routes lately, though most of
> the time I've been under Raster+FSO. (so frameworkd doing setup for GPRS,
> and requires it's own fixes to do what I want instead of within /etc/ppp)
> I've reached the conclusion that it will require changes to udhcpcd config
> (which currently does a blind replacement of /etc/resolv.conf) and
> ppp/ip-up.d/08setupdns (which currently creates /var/run/ppp/resolv.conf,
> then forces a symlink to it from /var/run/resolv.conf). /etc/resolv.conf
> is a symlink to /var/run/resolv.conf, and if udhcpcd works with it at
> /var/run/resolv.conf, (which might be better done via resolvconf bin
> instead, which works with /var/run/resolv.conf itself) then breaking that
> link is trivial, and the default behaviors would affect only that file, NOT
> /etc/resolv.conf which could be under new management, or a static 127.0.0.1
> if dns caching is installed. And changing udhcpcd and ppp config is needed
> to address default route headaches as well.
Yep, which is why we thought making the required changes as an afterthought or
delayed event at least, would mitigate the effect of any existing networking
changes being made by the OS facilities.
I really like the idea of a cache. I also like /etc/resolv.conf being a
symlink. In our possible approach, a config file specifying primary and
secondary resolv.conf files, with a 127.0.0.1 + opendns override for the
primary and the secondary containing whatever was last pushed to
/etc/resolv.conf would address static and dynamic dns assignment.
Metric per interface would be a config file option aswell.
> I currently have my Freerunner /almost/ working as I want, which is as
> follows: Local DNS cache with default upstream caches of opendns.org for
> unchanging simplicity (any static DNS would behave identically at this
> point in my setup), use Wifi if it's up for default route (metric 20),
> usbnet if wifi is down but usbnet is up (metric 30), and demand-dialed GPRS
> if usbnet is unavailable (metric 40). As I've got it, it should handle DNS
> changes properly, (subsystems are altering /var/run/resolv.conf) but that's
> untested since I'm running local caching. Once that's working fully
> automatically (getting close) I will check non-cached DNS and probably
> rewrite it to utilize resolvconf bin, then write the support script to tell
> dnscache to use dhcp-provided DNS servers as upstream caches, and finally
> look at VPN and a few more exotic possibilities. (I've got two USB
> ethernet adapters on a hub here that I've tested as a packet-sniffing
> bridge on the Freerunner, for example ;)
Nice ... and now I can grasp why you might be utilising multiple routing
I can definitely see your work filling the gap that currently exists, as much
as I don't like the look of resolvconf, I'm all for something that works and
this fits within the existing framework.
> I figured the rule for priority should be VPN first, followed by wifi, then
> any USB networking device (if in host mode) or usbnet to host (if in gadget
> mode), and finally (if desired) GPRS. For myself, I have the old T-Mobile
> unlimited (really, so far) internet3 'VPN' service, so my only concern with
> GPRS is avoiding its slowness when something faster is available - I
> realize other people who use GPRS may want to be more "in control" of it
> than I. (I've made a desktop icon to enable/disable it, which currently
> starts up the interface and leaves it in demand-dial waitstate, I'll
> eventually test it in direct up/down control)
Well I guess metric is a personal matter :) ... and I guess that if the VPN is
being added as a default route then the possibility of wanting it to be used
is highly likely. If it's a dedicated route then metric is moot.
OK, so mine should have gone VPN -> Wired -> Wireless -> GPRS.
Assuming usb can outperform wireless that is.
> My goal is to achieve everything without requiring a network manager of any
> significance. After that I'd like to have a widget in the top shelf to show
> status and interface in use, and let me turn GPRS or wifi on or off, select
> AP, etc, but the basic DNS and routing I want handled within the base
> networking configs and scripts, not within the manager.
Similar goal. With what we are suggesting you simply need request an IP via
dhcp. The activation of the device and deactivation would all be controlled
outside of the automated metric/dns shuffle.
> I'm hoping to have it all working smoothly by this weekend, but I keep
> getting sidetracked with other interests... (like playing with Qi and
> kernel 2.6.27, poking around dbus in FSO, developer environment vmware
> appliance, etc etc etc - not to mention my network admin day job, webapp
> developer night job, and single parent full-time job ;)
Drink coffee much? :)
You're making me feel awfully lazy!
> I'm working on documenting everything and will post it to my blog and/or
> the ML and/or the wiki, depending on complexity and how far it deviates
> from the present default arrangement. Hopefully by the weekend. I'd be
> interested to compare notes, and to see if my approach might simplify your
> own efforts - IE, having more consistent and (hopefully) sensible default
> behavior than we presently see 'out of the box'.
I still need the right prod to get me started. After having hashed over this a
few times I'm thinking, if the new features being added to dhcpc on netbsd can
facilitate this, maybe that's a better place to start. It does, after all, add
IPs, DNS servers and routes. If we can make this supremely configurable,
there'd be less need to modify, well, anything. It also eliminates the
assumption that 'I am king' unless you configure it so :)
I think I'll pose this question to a few more people and a few more mailling
lists. In the meantime, you are fixing and extending on what is currently
broken, which I for one, am appreciative of.
I look forward to seeing what you have, at the very least it will give me more
insight and if I can help in any way I will.
More information about the community