failed to start nm-applet
Hi, I upgraded my old version of NM(svnr2984) to 0.7.1 version on my ARM platform. However I am facing couple of issues - 1. nm-applet does not start on its own during system boot-up. NetworkManager runs successfully. 2. When I try to run nm-applet --sm-disable on console, I got (nm-applet:1201): Gtk-WARNING **: cannot open display: export DISPLAY=':0.0' helped me got rid of this problem and nm-applet ran fine thereafter. However I can not export the above from any init script that runs before K28NetworkManager. Meaning export does not work during boot-up init scripts. How can I successfully run nm-applet without doing an export? Could anybody share some pointers on this? Thanks for your time. Regards, Saurav ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: failed to start nm-applet
saurav barik a écrit : I upgraded my old version of NM(svnr2984) to 0.7.1 version on my ARM platform. However I am facing couple of issues - 1. nm-applet does not start on its own during system boot-up. NetworkManager runs successfully. Just like any graphical application, nm-applet requires a graphical DISPLAY. So you cannot run it early at boot when you are not yet logged in a graphical session. 2. When I try to run nm-applet --sm-disable on console, I got (nm-applet:1201): Gtk-WARNING **: cannot open display: export DISPLAY=':0.0' helped me got rid of this problem and nm-applet ran fine thereafter. This worked because you already had a graphical session started on DISPLAY :0.0. You just sent nm-applet to this session. However I can not export the above from any init script that runs before K28NetworkManager. Meaning export does not work during boot-up init scripts. export works in any shell script but is not system-wide; it exports the given variable only to child processes. There is no way up; as soon as an init script is completed its environment variables die. How can I successfully run nm-applet without doing an export? nm-applet is meant to be started from within a graphical session (where DISPLAY is already defined and exported for you). Run nm-applet from there. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager NetworkManagerDispatcher couldn't start up!
On Fri, 2009-08-07 at 14:10 +0800, liumin wrote: hello , i am confused by what i met these weeks,hope to get help here.I build network-manager-0.6.6 and nm-applet-0.6.6,install them in a ARM-11 machine with kernel and rootfs. I'd suggest using NetworkManager 0.7.1; 0.6.x is rather old. 0.7.1 is quite a lot more flexible. Are you stuck with 0.6.6 for some reason? Dan starting the machine using the same rootfs via three different ways:burning it into flash, with nfs and making a sdcard rootfs. the daemons NetworkManager NetworkManagerDispatcher couldn't start up when i burn rootfs into flash. the dhcdbd couldn't work for some error about dbus service.and the two deamons aboved couldn't be found too.I tried to restart hald ,but failed. and i don't have the same problem when using nfs-rootfs and sdcard rootfs. I thought i could get help here,or the possible reasons,thanks! Best Regards! liumin --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --- ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to convert Cisco VPN PCF to something network-manager-vpnc can use?
On Thu, 2009-08-06 at 20:29 -0400, Jamie Jackson wrote: My corp is phasing out the old vpn server, and we've been given a new profile for the new server. For the old vpn server, I was able to use some info from the pcf profile file, and trial-and-error/guess the rest of the pieces, and was able to configure the VPN connection through the NM VPN configuration GUI. Recent versions of NetworkManager-vpnc (0.7.1) should be able to import PCF files and get you most of the way there. Is that not working for some reason? Updates after 0.7.1 will even decrypt the group secret for you automatically. Dan However, I haven't been so lucky with the current file, as the trial-and-error hasn't worked out so far. What's the best way to translate the PCF into something I can use in NM-vpnc? Some manual way to translate (I could type into the GUI), or some automated way to convert the file... either way would be fine, as long as the end result is working VPN through NM. (BTW, I can already decrypt Cisco VPN secrets, so that's not the issue, it's the other options that I think I'm having trouble with.) I've googled this, but it seems that the information is outdated, when it comes to newer versions of NM (at least that's how it seems). NetworkManager Applet 0.7.0.100 Thanks, Jamie ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipv4 over firewire
On Fri, 2009-08-07 at 03:26 +0300, Maxim Levitsky wrote: Hi, For debugging purposes, I have set up a firewire connection between my desktop and laptop. But it so happens, that it is nice to use it as a network link, and it has about 12 Mbytes/s rates, more that enough for me. (ethernet port on desktop is used for main network connection, and laptop connected wirelessly) It seems that NM ignores the firewire eth1394. and newer firewire-net. Is that true? Probably. There's nothing that says we couldn't add support for it, but I think there's just some missing bits for recognizing the bus type or something. Got a pointer guide on how to set it up in Linux that I could take a look at? I might at least be able to narrow down where NM is ignoring the device. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Working with a local DNS cache
On Thu, 2009-08-06 at 12:04 -0700, Marcel Holtmann wrote: Hi Dan, 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. These days I'd rather just use a local caching nameserver by default in NM, and let those that don't want it turn it off or something. The most common local caching nameserver is currently dnsmasq, and it also provides a D-Bus interface. If at all possible, we should try to use *one* dbus interface. Not sure if you've looked at the dnsmasq dbus API, but it might be worth a glance. I did look at it. It is the worst D-Bus API I have seen in a long time and not helpful. Someone would have to fix it first. The amount of parameter overloading it does is just insane. Otherwise dnsmasq has a pretty nice set of features. Ok, fair enough. If that's the case, perhaps we should gently propose fixes to Simon? He's quite responsive. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Working with a local DNS cache
On Fri, 7 Aug 2009, Dan Williams wrote: The most common local caching nameserver is currently dnsmasq, and it also provides a D-Bus interface. If at all possible, we should try to use *one* dbus interface. Not sure if you've looked at the dnsmasq dbus API, but it might be worth a glance. I did look at it. It is the worst D-Bus API I have seen in a long time and not helpful. Someone would have to fix it first. The amount of parameter overloading it does is just insane. Otherwise dnsmasq has a pretty nice set of features. Ok, fair enough. If that's the case, perhaps we should gently propose fixes to Simon? He's quite responsive. If imposing a local DNS cache, please use Unbound or Bind, as those are currently the only ones supporting DNSSEC. I hope we can enable one of those with DNSSEC per default on every fedora install soon, but that will take some convincing I think and won't happen overnight. But DNSSEC is another good reason why every host should run its own (validating) caching resolver. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Working with a local DNS cache
On Fri, 2009-08-07 at 18:25 -0400, Paul Wouters wrote: On Fri, 7 Aug 2009, Dan Williams wrote: The most common local caching nameserver is currently dnsmasq, and it also provides a D-Bus interface. If at all possible, we should try to use *one* dbus interface. Not sure if you've looked at the dnsmasq dbus API, but it might be worth a glance. I did look at it. It is the worst D-Bus API I have seen in a long time and not helpful. Someone would have to fix it first. The amount of parameter overloading it does is just insane. Otherwise dnsmasq has a pretty nice set of features. Ok, fair enough. If that's the case, perhaps we should gently propose fixes to Simon? He's quite responsive. If imposing a local DNS cache, please use Unbound or Bind, as those Hah :) The reason I ripped out the DNS local caching code before was because of more than a few (unfounded) complaints that people didn't want to run bind on their desktop machine. Thus a more lightweight solution like dnsmasq was desirable. But in any case, if bind were to grow a usable dbus interface (while the one it had before was OK, the bind D-Bus code itself was *horrible*) then we could certainly add support for it too. are currently the only ones supporting DNSSEC. I hope we can enable one of those with DNSSEC per default on every fedora install soon, but that will take some convincing I think and won't happen overnight. But DNSSEC is another good reason why every host should run its own (validating) caching resolver. DNSSEC is a good point though. Perhaps we prefer local caching nameservers that can do DNSSEC before falling back to those that can't? Dan ___ 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
On Wed, 2009-08-05 at 19:46 +0200, Hadmut Danisch wrote: 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. It depends; reasons change, and so do implementations. Nothing is set in stone. 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 Completely wrong. NetworkManager is *NOT* a Red Hat tool. Novell has contributed immensely to it, as have quite a few others from other distributions. It just happens that I am paid by Red Hat to spend 110% of my time working on NetworkManager. Nobody else has made that commitment. If some other company or person decided to invest time in NetworkManager, then that person or companies goals would also obviously be reflected in the feature set of the final product. 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. It is not simply the admins and packagers problem. It's also the user's problem. 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. So lets add some cold hard facts to the discussion. What things are people doing in pre-down scripts? Beyond the dispute whether two or four phases should be supported, Network Manager does not pass the required Information to the up/down scripts. See below. What other information do you need? Is there some reason the tools you're running in these phases cannot use D-Bus for network even notifications if they are already running as a service somewhere? If they are not running as a service, then yes, a one-shot script-based approach may be more appropriate. 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. The UUID is already passed to the scripts, and has been for a long time. As are all the IPv4 details, and the DHCPv4 lease details if any. What version of NM are you using? 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). Tools before NetworkManager didn't work for a more dynamic environment (especially wifi), thus we created NetworkManager. I certainly don't want a pile of shell glued together with duct-tape and chewing-gum, which is what most of the previous networking system were. I've written about that extensively in various places. That said, I'm perfectly willing to have a discussion about the merits or shortcomings of NetworkManager, and what we are already doing to improve it. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Question regarding the features for the next release
Dan, I see that PAN support is coming in 8.0 but your blog post mentioned that Bluetooth DUN would be a bit more difficult. Is that going to make the next release or would it be further down the road? I am primarily interested in being able to use Bluetooth to my Blackberry since that device won't show up as a serial device. Thank you! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Working with a local DNS cache
On Fri, Aug 7, 2009 at 3:25 PM, Paul Woutersp...@xelerance.com wrote: If imposing a local DNS cache, please use Unbound or Bind, as those are currently the only ones supporting DNSSEC. For the purposes of NetworkManager, so long as the DBus interface exists, the underlying server doesn't matter. It appears that I need to make the IP config code asynchronous as a first step. I'll start hacking on that. AGL -- 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: gnome-bluetooth integration
Hi Dan, NAP means that the iPhone would access the Internet using your computer, not your computer accessing the internet through your iPhone... no, if the phone tells you NAP, then this means that the iPhone acts as Network Access Point. The computer connecting to the phone would be the PANU. This patch is 100% correct. Anyhow it works flawlesly for me with gnome-bluetooth 2.27.8, bluez 4.46 and current git versions of NM and nm-applet and iPhone 3G OS 3.0. Thanks for that - it makes my life a whole lot easier. Awesome, great to know! I just pushed the fix to the GUI bits that should fix your original problem. We got everything right in NM, but the gnome-bluetooth plugin wasn't checking the right capability bit. I still don't understand why gnome-bluetooth is involved in the PAN support for NM? To be honest NM could pick up paired devices that allow PAN connection directly without the round-trip via the UI. I must be missing something here since I don't get it. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
