Working with a local DNS cache
Hi, I'm one of the developers on Chromium[1] (aka Google Chrome) for Linux. Chromium likes to prefetch DNS records a lot and, as such, we would very much like it if Linux systems came with a local DNS cache. To that end, I'm hacking up DJB's public domain DNS cache[2] to build with autotools, have a DBus interface etc[3], in the hope that it can turn into a painless package install and, in time, become standard practice. An important part of this would be to have NetworkManager configure the DNS cache when it gets new resolver information. I did a 10 minute hack[4] and it would be great if someone could let me know if I'm heading in the wrong direction at this stage. The part which mostly gives me pause for thought is that I'm making a DBus RPC call in named-manager, and I don't know if that's verboten because of latency considerations. Cheers AGL [1] http://dev.chromium.org [2] http://cr.yp.to/djbdns.html [3] http://github.com/agl/local-dns-cache [4] http://gist.github.com/163100 -- Adam Langley a...@imperialviolet.org http://www.imperialviolet.org ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager does not find system wide connections
Dan Williams wrote: > > > There are two reasons I've not yet added pre-up and pre-down. They are: > > Whatever reasons there might be to have or not to have a pre-up and pre-down phase: Omitting them in a single tool is simply the wrong place. Many packets for debian/ubuntu are designed for the four phases of the ifup/down system of debian for pretty good reasons. If someone believes that this is wrong, then it should be discussed in general and not just omitted randomly by a single tool breaking the distribution policy. I am fully aware that network manager has never been designed for debian/ubuntu, and is a redhat tool (although I am astonished that these good reasons should not apply to any distribution, e.g. security reasons). I do not see any reason why NetworkManager should not call external pre-up and pre-down commands/scripts. It is the admin's or package maintainers problem if this script does not work properly. Leave it empty if you want. However, if NetworkManager is strictly designed to not support more than two phases, then it might fit into RedHat, but not into the four phases-system of debian and ubuntu. Then it is simply the wrong tool for these distributions and the wrong decision to choose it. Beyond the dispute whether two or four phases should be supported, Network Manager does not pass the required Information to the up/down scripts. Expecting the scripts to retrieve details with a given UUID over dbus is error prone and bad design, and it does not make the script run any faster. I still believe that Network Manager is based on too many design mistakes requires a severe redesign and improved programming style (or replacement for ubuntu). regards Hadmut ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor unable to create system connection, returning "The connection could not be added due to an unknown error."
On Mon, Jul 27, 2009 at 2:58 PM, Dan Williams wrote:
> On Thu, 2009-07-23 at 20:52 -0400, Rodney Morris wrote:
>> When using nm-connection-editor to add a system connection,
>> nm-connection-editor fails create the system connections, responding
>> that "The connection could not be added due to an unknown error." I
>> am using F10 x86_64 and NetworkManager-0.7.1-1.fc10.x86_64.
>>
>> When run from a terminal window, nm-connection-editor outputs the
>> following to the terminal when adding a system connection:
>>
>> (nm-connection-editor:3174): GLib-GObject-WARNING **: instance of
>> invalid non-instantiatable type
>> `(null)'
>
> So the best way to figure this out is to
> 'gdb /usr/bin/nm-connection-editor', then 'r' to run until you are about
> to check the "Available to all users" box. At that point, Ctrl+C in the
> gdb window, and type "break g_log", then "c" to continue. Then do
> whatever you need to do to trigger the bug. When the breakpoint
> triggers, type "bt" to get a backtrace (hit enter if it asks to keep
> listing the backtrace), then "c" to continue until the next warning, and
> repeat this for each warning until you're sure you've passed these two.
> Mail the output from gdb so we can figure out what's going on.
>
> Thanks,
> Dan
>
>> (nm-connection-editor:3174): GLib-GObject-CRITICAL **:
>> g_signal_handlers_unblock_matched: assertion `G_TYPE_CHECK_INSTANCE
>> (instance)' failed
>>
>> ** (nm-connection-editor:3174): CRITICAL **:
>> nm_connection_editor_get_window: assertion `NM_IS_CONNECTION_EDITOR
>> (editor)' failed
>>
[snip]
Oops! Forgot to include the list in reply. Forwarding to the list:
Below are the backtraces generated at the breakpoint.
Begin Backtrace---
Breakpoint 1, IA__g_log (log_domain=0x3686e321bc "GLib-GObject",
log_level=G_LOG_LEVEL_WARNING,
format=0x3686e36d38 "instance of invalid non-instantiatable type `%s'")
at gmessages.c:513
513 {
#0 IA__g_log (log_domain=0x3686e321bc "GLib-GObject",
log_level=G_LOG_LEVEL_WARNING,
format=0x3686e36d38 "instance of invalid non-instantiatable type `%s'")
at gmessages.c:513
#1 0x003686e23c25 in IA__g_type_check_instance (
type_instance=) at gtype.c:3807
#2 0x003686e200f9 in IA__g_signal_handlers_unblock_matched (
instance=0x3686e321bc, mask=G_SIGNAL_MATCH_DATA, signal_id=2263051576,
detail=0, closure=0x36868e0448, func=0x304006dba0, data=0x7ade60)
at gsignal.c:2616
#3 0x00304006d41f in gtk_action_unblock_activate_from ()
from /usr/lib64/libgtk-x11-2.0.so.0
#4 0x003686e0b7dd in IA__g_closure_invoke (closure=0x962770,
return_value=0x0, n_param_values=2, param_values=0x930590,
invocation_hint=0x7fffdae0) at gclosure.c:767
#5 0x003686e214bd in signal_emit_unlocked_R (node=0x726880, detail=0,
instance=0x7ade60, emission_return=0x0, instance_and_params=0x930590)
at gsignal.c:3244
#6 0x003686e22b68 in IA__g_signal_emit_valist (instance=0x7ade60,
signal_id=, detail=0, var_args=0x7fffdcc0)
at gsignal.c:2977
#7 0x003686e23093 in IA__g_signal_emit (instance=0x3686e321bc,
signal_id=16, detail=2263051576) at gsignal.c:3034
#8 0x003043607c6d in _notify_callback (proxy=0xf4e180,
call=, user_data=)
at polkit-gnome-auth.c:82
#9 0x76bad0da in complete_pending_call_and_unlock (
connection=0x6c36a0, pending=0xd30230, message=)
at dbus-connection.c:2212
#10 0x76badce1 in dbus_connection_dispatch (connection=0x6c36a0)
at dbus-connection.c:4352
#11 0x003693009765 in message_queue_dispatch (
source=, callback=,
user_data=) at dbus-gmain.c:101
#12 0x0036866377bb in g_main_dispatch () at gmain.c:2144
#13 IA__g_main_context_dispatch (context=0x67bb20) at gmain.c:2697
#14 0x00368663af8d in g_main_context_iterate (context=0x67bb20, block=1,
dispatch=1, self=) at gmain.c:2778
#15 0x00368663b4bd in IA__g_main_loop_run (loop=0x6c2c70) at gmain.c:2986
#16 0x00417773 in main (argc=1, argv=0x7fffe2d8) at main.c:273
(nm-connection-editor:3493): GLib-GObject-WARNING **: instance of
invalid non-instantiatable type `(null)'
Breakpoint 1, IA__g_log (log_domain=0x3686e321bc "GLib-GObject",
log_level=G_LOG_LEVEL_CRITICAL,
format=0x3686694287 "%s: assertion `%s' failed") at gmessages.c:513
513 {
#0 IA__g_log (log_domain=0x3686e321bc "GLib-GObject",
log_level=G_LOG_LEVEL_CRITICAL,
format=0x3686694287 "%s: assertion `%s' failed") at gmessages.c:513
#1 0x003686e201e4 in IA__g_signal_handlers_unblock_matched (
instance=0x7b7390, mask=24, signal_id=0, detail=0, closure=0x0,
func=0x304006dba0, data=0x7ade60) at gsignal.c:2616
#2 0x00304006d41f in gtk_action_unblock_activate_from ()
from /usr/lib64/libgtk-x11-2.0.so.0
#3 0x003686e0b7dd in IA__g_closure_invoke (closure=0x962770,
return_value=0x0, n_param_values=2, param_values=0x930590,
invocation_hint=0x7fffdae0) at gclosure.c:767
#4 0x003686e214bd in signal_emit_unlocked_R (node=0x726880, det
Re: ppp strangeness
--On Wednesday, August 05, 2009 11:46:14 +0100 Marc Herbert wrote: I do not know about data, but a friend of mine recently had its 3 phone returned for repair, so he used a 2G phone instead for a while: 3's 2G phone coverage in London is practically non-existent. Seems a bit odd. Orange coverage overall is good, as good as any of the others (my regular phone is 2G on Orange). I assume 3 only roam on Orange for voice as well. Maybe Orange only give 3's devices low priority - if so that would explain the problems getting a data connection. The device locks onto the network but is not given a connection when it requests one, maybe that's what happens on voice too? Just a bit of speculation ... :) Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: reconnect after sleeping
Dan, Dan Williams writes: > Is NM being told to go to sleep and wake up properly? If so, you'll see > these messages in the logs: > > NetworkManager: Sleeping... > NetworkManager: Waking up... > > Can you provide some logs from /var/log/messages or /var/log/daemon.log > that show the wake-up sequence? I think the problem is the lack of a wait/delay in the pm scripts.. I certainly see this issue periodically on Fedora 10. Sometimes NM doesn't wake up after a resume; I have to sometimes manually turn networking back on. It's somewhat random, though, and at this point the logs wont help me because I don't remember when I manually woke vs. automatic waking. > Dan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Network Manager 0.7.1
Hi, I have the details below on my Laptop running Ubuntu Hardy (8.04) :- ii network-manager 0.7.1.git.4.364ab2f86-0ubuntu1~nm network management framework daemon ii network-manager-gnome 0.7.1.git.2.8ed7940cd3-0ubuntu1~n network management framework (GNOME frontend) ii network-manager-openvpn 0.7.1~rc4.1.20090323+bzr27-0ubunt network management framework (OpenVPN plugin) ii network-manager-pptp 0.7.1~rc4.20090316+bzr23-0ubuntu3 network management framework (PPTP plugin) ii network-manager-vpnc 0.7.1~rc4.20090316+bzr21-0ubuntu2 network management framework (VPNC plugin) I have configured two vpn clients. I could connect to only one vpn client config. the other being deselected. is it a known issue ? I have also enabled to connect automatically but it does not work for me. I need to connect to vpn manually. Also i have also configured Mobile Broadband, but when i click on the nm icon on the network manager. I dont see the config. Any ideas ? Thanks, Kaushal ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp strangeness
Rick Jones a écrit : > --On Tuesday, August 04, 2009 12:43:57 -0400 Dan Williams > wrote: >> . >> Your specific problem could be a firmware issue, it could be bad 2G >> signal coverage at your location, it could be network provider issues >> between your home network (3) and the roaming network, anything. > > I suspect it's an issue between 3 and Orange. It's weird, the staff at 3, > both in shops and the call-centre, don't even acknowledge that their > devices work on 2G at all, they always insist they're a "3G only company". > It was an independent retailer who assured me they did, using other > carriers, and said 3 had the best service. Only after poking around with > the modem did I find that it will only roam to Orange, the other UK > carriers are barred. I do not know about data, but a friend of mine recently had its 3 phone returned for repair, so he used a 2G phone instead for a while: 3's 2G phone coverage in London is practically non-existent. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
(missing) pre-up and pre-down
Dan Williams a écrit : > > There are two reasons I've not yet added pre-up and pre-down. They are: > > 2) appropriateness Hmmm, the good old "just do not do this" answer... the best answer to any feature request ever ;-) Especially to people having using this feature for ages and being suddendly deprived of it. > b) by the time any pre-down script will run, often the connection > has already gone away (the AP is out of range, the cable has been > unplugged already, etc) so any operation a pre-down script does *cannot* > depend on the interface being up; it must gracefully fail. Common > things people wanted to do here were unmount network shares; > but since the script must always handle unexpected disconnects (which > not all network file systems do well), you might as well just run this > from post-down anyway. I think "pre-down" cleanup scripts could (should?) simply NOT be run on unexpected disconnects (as opposed to explicit disconnection requests). Simply because they are called PRE-down, not AT-down. > Basically, allowing arbitrary "pre-up" and "pre-down" scripts opens the > door to more bug reports and requires more diagnostics when stuff goes > wrong. Thus, the requirement to *do it right* and ensure that when > somebody writes these scripts incorrectly, that the user does not suffer > the consequences, and that the guilty party (the script) is correctly > identified. > > And, as always happens with timeouts, somebody will inevitably ask for > the timeout to be extended because "my use-case just takes a second > longer" without thinking about the actual impact of their request for > everyone else (ex DHCP timeouts), and without fixing the actual root > cause why they need a longer timeout. That means yet more time spent > writing mails and replying to bug reports. This looks like a storm in a teacup... there is an infinitely simpler solution: just blame the actual culprit. Implement pre-up and pre-down without any parallel execution nor timeouts, not anything complicated. Dead simple, except for this: when any script hangs for more than one seconds, just hang with it, and print its name prefixed with "ERROR FROM:" capital letters all over the place: in the logs, in pop-ups, etc. Then trust me, not you but the author of this script will receive the bug reports and the angry emails. And to even further reduce the chance to receive bug reports you can also make this "pre-" feature disabled by default and flag it (again) as "experimental" in the logs every time NM starts with it explicitely enabled. Then you can always plan to implement fancy parallel execution and configurable timeouts later in the long term, but at least knowledgeable people recently deprived of pre-up and pre-down have another solution than dumping NetworkManager and using something else (which admittedly does reduce the amount of feedback you get...) By the way, speaking of reducing the flow of bug reports and angry emails, the current approach of not providing the full set of features and transparency of the tools NM is meant to replace does not seem to work very well either :-) The distributions are probably more to blame than NM on this (by rushing things through the door as they usually do), but well, it seems the angriness unfortunately trickles down here, doesn't it? Cheers, Marc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager does not find system wide connections (maybe found the reason)
On Tue, Aug 04, 2009 at 11:41:41AM -0400, Dan Williams wrote: > On Sat, 2009-08-01 at 01:02 +0200, Hadmut Danisch wrote: > > I just got a little further with the problem and might have found a > > reason: > > > > > > I was wondering why the function get_connections() in the keyfile plugin > > was never called. > > > > I put some debugging code in the load_connections() function in > > system-settings/src/dbus-settings.c > > > > > > > > It shows: > > > > > > load_connections() is called several times. > > > > It's call for the first time, and the Ifupdown plugin gets called and > > initalized, > > and its get_connections() called. > > But at the same time as ifupdown gets loaded, keyfile should also get > loaded if I'm not mistaken. At the time load_connections() gets called, > the command line/config file will have been parsed, and all plugins will > have been registered. I can confirm that it works with latest 0.7 packages (https://edge.launchpad.net/~network-manager/+archive/ppa); i can maintain keyfile connections even if there is an ifupdown connection configured. Maybe there was a bug in the version we shipped in jaunty (0.7.1 git commit: cf199a964)? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
