DBUS services, not to start/stop
your private instance repeatedly every time the network topology changes.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
Dan Williams wrote:
On Wed, 2012-04-18 at 09:36 -0700, Howard Chu wrote:
Would also like an option to tell NM to never write /etc/resolv.conf, but no
point in writing that patch until there's been some discussion of this DBUS
patch.
What I'm very interested in here are the failure cases
Ubuntu laptop had everything commented out,
thus provided no services at all. That seems like the most sensible shipping
default - if you've gone to the trouble of installing it, you can certainly
take the trouble to configure it.
--
-- Howard Chu
CTO, Symas Corp. http
address=/tribalfusion.com/yieldmanager.com/0.0.0.0
address=/yieldmanager.edgesuite.net/adsdk.com/0.0.0.0
address=/kontera.com/googlesyndication.com/0.0.0.0
address=/netfirms.com/zedo.com/0.0.0.0
interface=lo
bind-interfaces
bogus-nxdomain=64.94.110.11
--
-- Howard Chu
CTO, Symas Corp
Would also like an option to tell NM to never write /etc/resolv.conf, but no
point in writing that patch until there's been some discussion of this DBUS patch.
Howard Chu wrote:
Just refreshing a patch I posted here before...
http://mail.gnome.org/archives/networkmanager-list/2011-January
using this patch for my systems using dhclient without NM:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2009q2/003009.html
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http
with RAlink RT3070, it frequently
takes much longer than 30 seconds to authenticate to my WPA-EAP network. I
don't know that there's any specific reason other than that there's a lot of
other networks in the neighborhood and a lot of interference.
--
-- Howard Chu
CTO, Symas Corp. http
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http
Dan Williams wrote:
On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote:
Dan Williams wrote:
On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote:
Howard Chu wrote:
This is probably more related to the ath9k driver, but I wanted to start here
in case anyone is familiar
Roy Marples wrote:
Howard Chu wrote:
Understood. At any rate, it works for me; I run by own build from git
with this patch (plus the no-scanning-while-connected patch). (It's far
better than what I used to have to do, rewriting BIND's forwarders.conf
file on every interface change
Roy Marples wrote:
Howard Chu wrote:
I guess you missed the discussion on this list the first time I posted
this stuff. Writing new resolv.conf files is not a good way to go. You
can pick up on this from the archives if you want.
I'm guessing you have no clue what resolvconf does or how
Roy Marples wrote:
Howard Chu wrote:
I know what it does. Now please think about system integrity, read-only
root filesystems, and needless rewriting of system files, particularly
in the context of laptops with hard power constraints. Think about
premature wear-out of SSDs caused by repeated
Dan Williams wrote:
On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote:
Howard Chu wrote:
This is probably more related to the ath9k driver, but I wanted to start here
in case anyone is familiar with it. I've been seeing this for the past couple
months, and I just now rebuilt NM fresh from
://mail.gnome.org/archives/networkmanager-list/2008-September/msg00042.html
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
Alexander Sack wrote:
On Mon, Apr 20, 2009 at 03:37:20PM -0700, Howard Chu wrote:
Howard Chu wrote:
This is probably more related to the ath9k driver, but I wanted to start here
in case anyone is familiar with it. I've been seeing this for the past couple
months, and I just now rebuilt NM
Alexander Sack wrote:
On Mon, Apr 20, 2009 at 06:24:33PM -0700, Howard Chu wrote:
Since killing NM prevents the problem from showing up, I don't see how
this can be a wpa_supplicant bug. ?? Should I add another comment to the
bug report?
To verify that its really the scan making your driver
Howard Chu wrote:
This is probably more related to the ath9k driver, but I wanted to start here
in case anyone is familiar with it. I've been seeing this for the past couple
months, and I just now rebuilt NM fresh from git and it's still happening:
I seem to have ruled out the driver; doing
]
periodic_update(): Roamed from BSSID 00:12:17:26:56:10 (HighlandSun) to (none)
((none))
The signal strength is consistently 80% or better, I'm only 10 feet from the
AP and have a clear line of sight to the antenna. What is this trying to tell me?
--
-- Howard Chu
CTO, Symas Corp
Tony Espy wrote:
Dan Williams wrote:
On Wed, 2009-02-04 at 15:40 -0800, Howard Chu wrote:
OK. I suggest a compromise then, since fetching kernel time will also be
expensive if done frequently - just fetch it at driver load and resume time,
and store it as abase in the driver. Cache entries
Howard Chu wrote:
Tony Espy wrote:
I still think simple ( ie. either have mac80211 handle the expiration or
flush of scan results on resume ) wins out over the more complicated
approach of having the connection manager handle expiration of older
scan results.
Also a mobile device ( eg
fetch it at driver load and resume time,
and store it as a base in the driver. Cache entries then store base+jiffy.
This allows cache stamps to continue to be cheap, but also solves the
sleep/resume mismatch.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland
Dan Williams wrote:
On Wed, 2009-01-14 at 12:51 -0800, Howard Chu wrote:
Howard Chu wrote:
I think you need to acknowledge that single AP deployments are a very common
occurrence. Yes, there are offices and hotels and other large buildings that
deploy multiple APs throughout a campus, where
in the new location
but it also still shows the AP I was last associated with (even though it's
not in the present location) and tries (fruitlessly) to reassociate with it.
It should just forget the old info and only use the new scan results.
--
-- Howard Chu
CTO, Symas Corp. http
Dan Williams wrote:
On Tue, 2009-01-13 at 14:28 -0800, Howard Chu wrote:
I also noticed that in NM 0.7 prereleases, scans did not occur on my ath9k
when it was associated, but after 0.7 was released, this behavior changed. (I
found the commit that changed this, saying it was removing a hack
and that frankly
isn't reality.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
___
NetworkManager-list mailing list
it was removing a hack...) I
reinstated the hack on my build, because it was disrupting my streaming wifi
traffic. All in all, I would love to see scans only occurring on demand, and
not at any other time.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun
Dan Williams wrote:
On Wed, 2008-10-01 at 16:14 -0700, Howard Chu wrote:
Message: 5
Date: Wed, 1 Oct 2008 23:58:22 +0200
From: Alexander Sack[EMAIL PROTECTED]
Subject: [PATCH] hostname support for ifupdown plugin + allow
read-only hostname system provider + move nm_inotify_helper
sethostname() to tell the kernel what it already knows?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
Jim Popovitch wrote:
On Fri, Sep 26, 2008 at 01:28, Howard Chu[EMAIL PROTECTED] wrote:
Current versions of BIND don't give you much control over forwarding either;
dnsmasq does.
Bind9 does. At least it does so for me. Dnsmasq does too, but I need
bind9 for other things (outside the scope
Jim Popovitch wrote:
On Fri, Sep 26, 2008 at 02:59, Howard Chu[EMAIL PROTECTED] wrote:
Hm. So what exactly did you mean by saying the user needs some level of
control over which connections are allowed to update resolv.conf ?
Certainly not control of packet routing. All I meant
Jim Popovitch wrote:
On Fri, Sep 26, 2008 at 03:29, Howard Chu[EMAIL PROTECTED] wrote:
The point is that users need a level of control over how name resolution is
done. Once you resort to adding/removing entries from resolv.conf you've
completely removed the possibility of retaining local
Alexander Sack wrote:
Hi,
some initial comments:
Hi again,
any further comments on the updated patch?
On Sat, Sep 06, 2008 at 04:47:33AM -0700, Howard Chu wrote:
+static gboolean
+dnsmasq_update(NMNamedManager *mgr)
+{
+ NMNamedManagerPrivate *priv;
+ GSList *iter
/etc/resolv.conf configured exactly as I
set it, so I get consistent name lookups no matter where I am. It also
obviates the need for most of the /etc/ppp/ip-{up,down} scripts too, for the
same reasons.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun
Dan Williams wrote:
On Thu, 2008-09-25 at 19:28 +0200, Alexander Sack wrote:
On Thu, Sep 25, 2008 at 05:23:17AM -0700, Howard Chu wrote:
I realize there are a lot of different use cases being targeted here, but
I don't believe that overriding a non-NULL current hostname is a good
behavior
the command line or via the system settings service or
something like that
I guess an explicit switch/setting to enable this feature makes sense. Then it
would be a fatal configuration error if the DBUS listener isn't present when
NM starts up. Should NM abort its startup in that case?
--
-- Howard Chu
.
The resolution rules in resolv.conf shouldn't depend on what network you're
plugged into.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
Date: Thu, 25 Sep 2008 21:43:54 -0400
From: Jim Popovitch [EMAIL PROTECTED]
On Thu, Sep 25, 2008 at 18:27, Howard Chu [EMAIL PROTECTED] wrote:
From: Jim Popovitch[EMAIL PROTECTED]
How about a NM option to disable updating of resolv.conf. This
should be settable in 3 different places
Date: Fri, 26 Sep 2008 00:04:26 -0400
From: Jim Popovitch [EMAIL PROTECTED]
On Thu, Sep 25, 2008 at 23:34, Howard Chu [EMAIL PROTECTED] wrote:
Perhaps it seems that way to you, but consider the case where someone
might want DNS fixed (ie. to a local caching server that is configured
Howard Chu wrote:
I've installed dnsmasq on Ubuntu 8.10alpha4, and configured it with
enable-dbus. My belief was that this would allow dnsmasq to pick up nameserver
changes directly from NetworkManager, but instead NM is just overwriting
/etc/resolv.conf. I don't see any commandline options
it where dbus/dbus.h was included because they're related,
but you're right, it should just go in the .c file.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
Howard Chu wrote:
Alexander Sack wrote:
Is there a particular reason to put that include here instead of the
.c file where its used?
Not really. I put it wheredbus/dbus.h was included because they're related,
but you're right, it should just go in the .c file.
Revised patch, doesn't touch
pointers the second time around.
A better fix would just eliminate the redundant call. (Why is it being called
multiple times in the first place?)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
it is, no matter what network I connect to.
Why should my resolv.conf's domain and search list change just because I've
moved to a different physical location?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc/
Chief
the function, the
patch is attached. It's probably not the cleanest approach, but it works for me.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
44 matches
Mail list logo
