On Wed, 15 Oct 2008 13:40:25 +1100, [EMAIL PROTECTED] wrote: > On Fri, Sep 26, 2008 at 12:07:17AM -0400, Joel Newkirk wrote: [elided long post quote regarding dnscache and changes to resolvconf+/etc/resolv.conf+dhcp] > > > I've been discussing this with a mate who showed some interest in the > dillema. > > Every time we thought we had something there was a small gotcha, > primarily that the requirement for the dns/metric change stems from > the aquisition of a dhcp lease and in turn the addition of new routing > and dns info. As the aquisition can occur outside of linkstate, > meaning the link can be active but no dhcp client associated, actioning > based on interface status didn't seem valid, or at least a little > premature or a little too assuming. > > So to us, the primary flag for action was the aquisition of a lease. > > Seeing as we are generally dealing with on the fly network association > we didn't bother taking into account static assignment. > > We also figured that the general rule of thumb for metric would be: > > 1 - wired > 2 - wireless > 3 - vpn/tap/tun > > Which should be configurable anyway. Something easy to implement that > can be expanded on is the idea. > > With that in mind and without altering udhcpc to populate an alternate > resolv.conf (avoiding modifications to generic network tools completely), > it seems the process should go something like: > > * obtain lease > * read resolv.conf > * create lookup (iface, ip, metric, searchdomain, dns1, dns2) > * recreate resolv.conf from lookup and config file > * modify routing table > > We avoided dealing with a cache purely because it will generally > conflict with generic dhcpc function, we were trying to wrap rather > than reconfigure. In saying that, a config file could determine > whether 127.0.0.1 is written/rewritten and an alternate resolv.conf > updated. So the caching daemon could be easily incorporated. > > Removal from the lookup should possibly be based on linkstate. > > As with any detailed process, the hardest part was trying to figure > out just how to start ... where and how to watch for the change and > the most cost effective way. The process is relatively simple. > > I don't suppose there is dhcp client dbus integration as standard? > > Being notified rather than polling would be good. > > Anyway ... that's where we got to. The overall benefit from our > perspective was that we could use something like this on any > *nix-like operating system that we have. Also the typical ifwatchd > and wpa_supplicant delays would not have any effect. > > Outside of all that, I know netbsd has had some work done to the > dhcp client to allow multiple instances to communicate via a socket, > so maybe something like this is actually being incorporated into the > dhcp client code, which would make sense as it really is, all-in-all, a > side effect of using dhcp in the first place. It would be nice to see > something provided by ISC. > > I think I've rambled on long enough ... :) > > Sarton
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 simpler. 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. 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 ;) 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) 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. 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 ;) 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'. j _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community