Re: Annoyance with notification in Ubuntu
On Tue, 2010-09-21 at 11:04 +0300, Tero Miettinen wrote: > Hello, > > I'm suggesting this diff to fix the bug left at Launchpad: > https://bugs.launchpad.net/bugs/383404 > This explains the bug best: > http://launchpadlibrarian.net/56069067/screenshot3.png > > The file in question is src/applet-device-wifi.c and the diff fixes the > "Click on this icon" to "Click on the network icon" > > Feedback and discussion is always welcome. It's been around for a long time mainly because Ubuntu was the first (and only?) distro to ship with a notification system that did not support actions. As such, I'd pretty much expected Ubuntu to locally patch nm-applet to deal with that, but since we're already carrying some code to deal with action-less notification systems upstream, I've pushed a fix to handle this case. Note that we can't include the wording "network menu above" because the panel is *not* always above the bubble. The applet can be placed anywhere (even on a bottom or side panel) so the wording cannot reference the location of the panel like the bug report's patch tries to do. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: multiple VPN connections
On Fri, 2010-08-27 at 08:41 +0200, Ma Begaj wrote: > Any plans to implement this? > > Some older comments by Dan Williams: > http://old.nabble.com/multiple-VPN-%28PPTP%29-connections-at-once-td19852170.html. > > Is it only GUI problem? Sort of, but honestly we'd have to do a bit of work in NM to make sure it would all work well. While we've tried to plan for it when adding new code, there's no guarantee that everything would work together. It just hasn't been a priority yet and thus hasn't gotten a lot of attention. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: my modem does not work on NM
On Fri, 2010-08-27 at 10:06 +0100, Joao Ferreira gmail wrote: > On Thu, 2010-08-26 at 11:13 +0200, Jirka Klimes wrote: > > On Thursday 26 of August 2010 00:36:51 Joao Ferreira gmail wrote: > > > > > > But... I was never able to use my 3G modem properly. Recently I updated > > > to Debian squeeze, with NM 0.8.1-1, but the modem still does not work. > > > It's a Huawei E220 (Portuguese provider Vodafone). > > > > > > Hi Jirka, please see below the informations/logs you suggested > > > E220 should work with NetworkManager (ModemManager). In order to found the > > issue, please provide more information on what are the symptoms, how you > > configure the connection, etc. > > I used NetworkManager "(mouse right button menu) -> Edit Connections... > -> Mobile Broadband" dialog Wizard to configure the connection. > > Then I plug the modem in and I select the "Enable Mobile Broadband" > option (mouse right button menu). So the problem you have is that the NM version you've installed was not built against the pppd version you have installed: - /usr/sbin/pppd: Plugin /usr/lib/pppd/2.4.5/nm-pppd-plugin.so is for pppd version 2.4.5, this is 2.4.4 - You'll either need to rebuild NM against pppd 2.4.4, or update your pppd to 2.4.5. Usually your distro should make sure that is working correctly, but if you built it yourself you could run into issues with this. Dan > Then usualy the icon changes to a status like "I'm trying" (2 small > circles and a thingye circling around). After a while the icon returns > to the normal "disconnected" status. Seems like it is trying to obtain > an IP address but it dos not succeed. > > more below... > > > > > What NetworkManager and ModemManager versions do you use? > > I use Debian Squeeze; (had same problem in Lenny); from dpkg: > - modemmanager 0.4+git.20100624t180933.6e79d15-1 > - network-manager 0.8.1-1 > > > What lsusb says about the modom? > > Bus 003 Device 005: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 > HSDPA Modem / E270 HSDPA/HSUPA Modem > > > What's in /var/log/daemon.log? > see logs in the end of this e-mail... > > > > > You can follow the steps at [1] in 'Debugging NetworkManager 0.8.x 3G > > connections' section to get detailed traces. > see logs in the end of this e-mail... these logs correspond to 2 > attempts to bring up the modem; once for connection 'Vodafone Default 1' > and another for connection 'Vodafone Default 2' > > > > > For a reference, you can look at [2]. > > > > Jirka > > > > [1] http://live.gnome.org/NetworkManager/Debugging > > [2] > > http://gardiary.wordpress.com/2010/01/04/configure-modem-vodafone-huawei- > > e220-in-opensuse-11ubuntu-9/ > > > LOGS (as suggested in [1]): > > Network-Manager > > r...@squeeje:/home/jmf# NM_PPP_DEBUG=1 /usr/sbin/NetworkManager > --no-daemon > NetworkManager[2406]: NetworkManager (version 0.8.1) is > starting... > NetworkManager[2406]: Read config > file /etc/NetworkManager/nm-system-settings.conf > NetworkManager[2406]: modem-manager is now available > NetworkManager[2406]:SCPlugin-Ifupdown: init! > NetworkManager[2406]:SCPlugin-Ifupdown: update_system_hostname > NetworkManager[2406]:SCPluginIfupdown: management mode: unmanaged > NetworkManager[2406]:SCPlugin-Ifupdown: devices added > (path: /sys/devices/pci:00/:00:1c.1/:0c:00.0/net/wlan0, > iface: wlan0) > NetworkManager[2406]:SCPlugin-Ifupdown: device added > (path: /sys/devices/pci:00/:00:1c.1/:0c:00.0/net/wlan0, > iface: wlan0): no ifupdown configuration found. > NetworkManager[2406]:SCPlugin-Ifupdown: devices added > (path: /sys/devices/pci:00/:00:1c.2/:09:00.0/net/eth0, > iface: eth0) > NetworkManager[2406]:SCPlugin-Ifupdown: device added > (path: /sys/devices/pci:00/:00:1c.2/:09:00.0/net/eth0, > iface: eth0): no ifupdown configuration found. > NetworkManager[2406]:SCPlugin-Ifupdown: devices added > (path: /sys/devices/virtual/net/lo, iface: lo) > NetworkManager[2406]:SCPlugin-Ifupdown: device added > (path: /sys/devices/virtual/net/lo, iface: lo): no ifupdown > configuration found. > NetworkManager[2406]:SCPlugin-Ifupdown: devices added > (path: /sys/devices/virtual/net/pan0, iface: pan0) > NetworkManager[2406]:SCPlugin-Ifupdown: device added > (path: /sys/devices/virtual/net/pan0, iface: pan0): no ifupdown > configuration found. > NetworkManager[2406]:SCPlugin-Ifupdown: devices added > (path: /sys/devices/virtual/net/vboxnet0, iface: vboxnet0) > NetworkManager[2406]:SCPlugin-Ifupdown: device added > (path: /sys/devices/virtual/net/vboxnet0, iface: vboxnet0): no ifupdown > configuration found. > NetworkManager[2406]:SCPlugin-Ifupdown: end _init. > NetworkManager[2406]: Loaded plugin ifupdown: (C) 2008 Canonical > Ltd. To report bugs please use the NetworkManager mailing list. > NetworkManager[2406]: Loaded plugin keyfile: (c) 2007 - 2008 Red > Hat, Inc.
Re: stopping modem manager
On Mon, 2010-08-23 at 17:31 +0100, Rune Gellein wrote: > Hi, > I tried to just kill the modem manager, but Network manager started it > again, so if you remove it, network manager will continue to try to > start it in the background. > And because of these dependencies, when you update the system again, > the modem manager will be pulled back in (at least in gentoo). > > So what I am looking for is a setting in the Network manager > configuration to stop it from loading the modem manager at all. > > Anything like that available? At this time, you either remove the modem-manager package, or you remove the dbus auto-activation file referenced earlier in this thread. I have various ideas how to only run ModemManager on-demand, which basically revolve around using udev to spawn ModemManager if it's not already running when a new serial port appears, and have MM quit if it's not managing any modems. NM would then stop poking MM automatically, and just rely on its presence. The one thing that doesn't solve is if MM crashes, it wouldn't necessarily get restarted automatically, which is quite useful to recover from bugs for users that don't know how to manually restart it. Dan > Rune > > On Fri, Aug 20, 2010 at 3:00 PM, Alexander Sack > wrote: > > On Fri, Aug 20, 2010 at 01:42:58PM +0100, Rune Gellein wrote: > > Hi, > > I just upgraded from Network manager 0.7.2 to 0.8.1 and I > noticed it now > > automatically starts the modem manager. > > > > I am using wireless lan (using ndiswrapper). So I don't > need the modem manager > > which also seem to load lots of modem specific plugins into > memory. > > > > Is it anyway to stop Network Manager from loading modem > manager on startup? If > > not, any plans to add this? > > > For ubuntu my answer would be to remove the modemmanager > package > ... that would do the trick. > > - Alexander > > > ___ > 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: modem-manager: No-Plugins and networkmanager not able to detect modem device
On Mon, 2010-08-30 at 17:52 -0700, hong sheng wrote: > Hi Bin, > > I solved the problem and now the modem can do auto-connection. The > original problem was caused by sid 0 re-signed to be sid 99 issue as > posted in the website > > https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/456612 What does the modem indicate for the AT+CSS response? Note that ModemManager 0.4 includes support for Qualcomm DIagnostic Monitor mode on modems that support that (which is almost all CDMA devices) and when there is a QCDM port available, that port is used for serving system and status detection instead of the AT port. SO it might be that you have an older version of ModemManager or a version of NetworkManager that does not support ModemManager. MM has had quite a number of fixes in the past year to work around various modem firmware bugs that cause false indication of network registration, and I think we've got it fixed quite well now. Dan > > Thank you very much for the help. One more confusing question, will > networkmanager 8.0 always need modem-manager to manage modem or itself > can do modem management if I just need connectivity rather than need > sms or signal strength detection? > > thanks > > Xiaohong > > > > > > On Mon, Aug 30, 2010 at 1:15 PM, hong sheng > wrote: > Hi Bin, > > Thank you very much for the quick response. It solves my > problems. > > However, the follow up trouble I met is that the modem is not > be able to be activated. The modem I am using has 4 ttyUSB > ports. I think one of the port is used for modem while others > are used for other purpose. I am using a keyfile TestModem1 > for auto-activating modem. > > > Could you please help me out on this issue? Also, if I want to > specify the ttyUSB port, for example, force to use ttyUSB2, > how can I set it in the keyfile (for my case, TestModem1 in > the /usr/NetworkManager/system-connection)? > > > Again, thank you very much > > > hong > > Here is part of the message > > NetworkManager: nm-modem-cdma.c: stage1_prepare_done > NetworkManager: stage1_prepare_done(): CDMA modem > connection failed: (32) No service > NetworkManager: nm-device.c: nm_device_state_changed > NetworkManager: (ttyUSB0): device state change: 4 -> 9 > (reason 0) > ... > NetworkManager: Marking connection 'TestModem1' > invalid. > .. > NetworkManager: Activation (ttyUSB0) failed. > NetworkManager: nm-device.c: failed_to_disconnected > > NetworkManager: nm-device.c: nm_device_state_changed > > NetworkManager: (ttyUSB0): device state change: 9 -> 3 > (reason 0) > > > NetworkManager: (ttyUSB0): deactivating device > (reason: 0). > > > > > > > > > > > > On Sun, Aug 29, 2010 at 12:52 AM, Bin Li > wrote: > On Sat, Aug 28, 2010 at 10:12 AM, hong sheng > wrote: > > Hi: > > > > I am using modem-manager 0.3, when I run > modem-manager, it complains: > > "No-plugins". What does it mean? I am new to > modem-manager. > > Which distribution do you use? Could check your > /usr/lib/ModemManager/ ? The plugins should be there. > > > When I run networkManger 0.8.0, it seems > networkmanager doesn't detect the > > modem in the query_devices with udev_manager. > However, I see the device > > under /dev/ttyUSB0, Can anyone tell me why > udev_manager doesn't detect the > > modem? > > you can get it from dmesg. > > > thanks for the help > > > > Xiaohong > > > > > > > > ___ > > 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 ___ networkmanager-list mailing list networkmanager-list@
Re: nm cannot correctly set interface as unmanaged
On Wed, 2010-09-15 at 13:11 +0200, Simone wrote: > Hi, > thank you for answers. > > 2010/9/15 Mathieu Trudel : > > Does eth1 get recognized any better if you leave NM enabled but just remove > > the comment for gateway? > > I tried to edit my "/etc/network/interfaces" decommenting[1] and removing[2] > the > "gw" line but nm-status prints out the same output :: > > - Device: eth1 > State: unmanaged > - Device: eth0 [Auto eth0] > State: connected This is a design choice in the ifupdown plugin so that people who already had set up configuration information in /e/n/i wouldn't automatically have NM take over that interface. The ifupdown system settings plugin will "unmanaged" well-known devices, by which it means any device that has explicit configuration in /e/n/i. To turn that off, you make /etc/NetworkManager/NetworkManager.conf (or /etc/NetworkManager/nm-system-settings.conf if that's what you already have) look like this: [ifupdown] managed=true and restart NM. NM should then manage those ethernet and wifi interfaces defined in /e/n/i, and it should also use the exact configuration you've specified there. If it doesn't, thats a bug we need to fix in ifupdown. Dan > Simone > > > "/etc/network/interfaces" (gw line decommented): > > auto lo > iface lo inet loopback > up nameif > > auto eth0 > iface eth0 inet dhcp > > auto eth1 > iface eth1 inet static > address 192.168.5.166 > network 192.168.5.0 > netmask 255.255.255.0 > gateway 192.168.5.254 > > "/etc/network/interfaces" (gw line removed) : > > auto lo > iface lo inet loopback > up nameif > > auto eth0 > iface eth0 inet dhcp > > auto eth1 > iface eth1 inet static > address 192.168.5.166 > network 192.168.5.0 > netmask 255.255.255.0 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Re:GSM modem enable failed: (32) Failed to find a usable modem character set
On Thu, 2010-09-16 at 00:08 +0530, Shakthi Prasad GS wrote: > Hi, > I had been trying to connect my SAMSUNG Mobile USB Modem. I had the > same problem. I could successfully hack Networkmanager and Modemmanager > to support my device. > > My guess is that your 3g based modem not supported by currently > available modem manager plug-ins and generic GSM plug-in is not working > for you. > If you really want to support the modem you can roll your own and hack > it. Just comment out few places where modem manager checks for the best > character set; so that it works fine even if it is horrid, and > evil.(Just what I did- It may not be right way) Note that I believe I have fixed this upstream this past week. ModemManager will now allow use of the GSM charset if thats the only charset the device supports. Dan > For debugging, you can make following arrangements. > 1.Remove NM from upstart -Otherwise it keep on re-spawning and makes > difficult to debug > 2.Kill NM - stop currently running instance > 3.Kill modem manager > 4.Launch modem manager on a debugger with break points (may be > mm-generic-gsm.c: mm_generic_gsm_enable_complete a good place to start) > 5.Launch NM on separate terminal with --no-daemon > > All the best > -shakthi > > ___ > 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: Patch: Wildcard for no-auto-default.
On Thu, 2010-09-16 at 18:24 +0200, Jirka Klimes wrote:
> On Friday 09 of July 2010 18:59:08 Pat Suwalski wrote:
> > Hello,
> >
> > I had a request a few weeks back about how to get the system settings
> > daemon to ignore all cards without hardcoding MAC addresses into the
> > nm-system-settings.conf file. It was mentioned that there's a workaround
> > for RedHat-based systems. I wanted something more explicit.
> >
> > The attached trivial patch lets the user specify "no-auto-default=*" to
> > have all of the connections blacklisted by the system settings daemon.
> >
> > --Pat
>
> Strictly speaking, "no-auto-default" option doesn't cause ignoring devices.
> Rather it is used to specify that for a device, NM shouldn't create a default
> wired connection (Auto eth0), which is normally done for all managed devices
> that doesn't any connection.
>
> If you would have a connection with 'autoconnect=true' that applies to a
> device, listing the device in "no-auto-default" doesn't prevent the device
> from being activated.
>
> Nevertheless, I think it's a good feature to support glob. And in case you
> didn't configure a connection manually, it will solve your issue.
>
> I've updated a patch a bit not to add the MAC to the list when "*" is already
> there. And to ignore leading and trailing whitespaces.
>
> Dan, are you for the patch?
Sure, though a mild style change. Instead of:
if (foo)
{
...
}
lets do:
if (foo) {
...
}
Thanks!
Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: connection lost on roaming wifi networks
On Mon, 2010-09-20 at 11:24 +0200, Jirka Klimes wrote: > On Monday 20 of September 2010 09:36:27 Frederik Himpe wrote: > > On Fri, 17 Sep 2010 10:55:23 +0200, Jirka Klimes wrote: > > > On Wednesday 15 of September 2010 14:52:02 Frederik Himpe wrote: > > >> I'm using Debian Squeeze kernel 2.6.32-21 (iwlagn 1.3.27ks) with an > > >> Intel Corporation Ultimate N WiFi Link 5300 [8086:4235]. > > >> > > >> Whenever I use my laptop in a place where different APs provide roaming > > >> for a wifi network, my system seems to suddenly (without moving) roam > > >> to another AP, after which the connection stops working completely > > >> (cannot ping anymore, etc) while NetworkManager shows I'm still > > >> connected. > > >> > > >> I can easily reproduce this, on two different roaming networks. > > >> > > >> I also tried kernel 2.6.35-1~experimental.3, but it has the same > > >> problematic behaviour. > > > > > > There's a problem with getting IP from DHCP server. See DHCPREQUEST > > > requests, but no reply. Is the DHCP server properly running, replying? > > > Try to capture packets in wireshark to see if there is any DHCP server > > > response. > > > Or just configure the connection with static IP to verify that the > > > issues are indeed due to DHCP. > > > > No, the issue is not DHCP: the fact that there is no reply to the > > DHCPREQUEST is just a symptom of my problem, but it is not the cause. The > > problem already starts from Sep 14 09:14:43, when it decides to roam. > > From that moment on, the connection is broken. A few minutes later, when > > my old DHCP lease expires, and then it fails to get a new one because the > > wifi connection is broken. > > The issue can be caused by a number of things. DHCP was just a guess from the > logs you've provided. > Try to collect and analyze more logs to find the real issue. > One cause of the problem could be the iwlagn driver. Is anything interesting > in dmesg? Try removing and inserting the driver: rmmod iwlagn; modprobe iwlagn > You can also disable "n" band using driver options: see > https://bugzilla.redhat.com/show_bug.cgi?id=587825#c8 > > What about wpa_supplicant logs? Supplicant logs would be quite necessary to figure out what's going on. But you're entirely right... it could be wpa_supplicant, the driver itself, the wifi card firmware, or mac80211. It's highly unlikely that it's NM itself, because NM is not actually much involved in intra-ESS roaming. That's all the driver and wpa_supplicant. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Basic questions [Was: How to monitor NM progress?]
On Mon, 2010-09-20 at 15:58 +0200, Rafal Wojtczuk wrote: > On Wed, Sep 15, 2010 at 02:50:46PM +0100, Marc Herbert wrote: > > > So, the device is not managed if and only if the STATE field == > > > 'unavailable' ? > > > > I do not think so: > > > > LC_ALL=C nmcli dev > > DEVICE TYPE STATE > > eth1 802-3-ethernetunmanaged > > eth0 802-3-ethernetunmanaged > > > > > [I am a bit embarassed to ask such basic questions, but I am unable > > > to find a comprehensive NM documentation, and reading its sources is > > > a bit resource consuming]. > > > > http://live.gnome.org/NetworkManager/SystemSettings > > In this page, I do not see an answer to the following question: is it > possible to tell nm-applet to _not_ display unmanaged interfaces at all ? > > Thanks for all the answers so far btw. No, there is no option for that. We specifically added that functionality because many, many Ubuntu users were highly confused tha their network devices were unknown to NetworkManager, because NM 0.6 did hide them from the UI when they were unmanaged. The mailing list would get at least one "where's my network device?" mail from some Ubuntu user every week, because of how the ifupdown plugin handles unmanaged interfaces. To make the situation clearer, and to show users /why/ their network devices were not handled by NetworkManager, we made nm-applet show unmanaged devices. This alerts users to exactly why things don't necessarily work out of the box on distros that unmanaged devices in more common use-cases. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Sierra Wireless dongle enable failed
On Mon, 2010-09-20 at 12:28 -0400, John Connolly wrote: > Questions inline > > On Wed, 2010-05-26 at 10:25 +0200, Maxime Boure wrote: > > Thanks for your answer ! > > > > > > Indeed it is a timing problem. The 6 ttyUSB created make the enabling > > longer. I got lucky once and the first ttyUSB enabled was the right > > one and I got connected. > > What are my options ? modify this timeout value and recompile NM ? > > > >Actually I'd encourage you to use the latest MM 0.4 beta release, which > >has the following improvements that will be relevant to you: > >1) doesn't expose modem on D-Bus until *all* ports have finished > >probing; your traces show that NM starts to enable the device before MM > >has really finished initializing it > > > >2) prints a timestamp for debug output allowing me to easily see delays > >without having to ask you > > > >then lets do the same thing and see if we still get the problem, and if > >so, what we can do about it. > > Was there a resolution for this? I'm using modem-manager 3 on my embedded > device but I see the identical problem. > > Some background though: I'm dropping in a config file into > /etc/NetworkManager/system-connections/ resetting NM and I get the same error. > > > > My config: > /etc/NetworkManager/system-connections/AT\&T\ Data\ Connect\ 1 > > > [connection] > id=AT&T Data Connect 1 > uuid=5f817c66-9373-4a52-8819-bd5f5a21947e > type=gsm > autoconnect=false > > > timestamp=0 > > [ppp] > noauth=true > refuse-eap=false > refuse-pap=false > refuse-chap=false > refuse-mschap=false > refuse-mschapv2=false > nobsdcomp=false > nodeflate=false > no-vj-comp=false > require-mppe=false > > > require-mppe-128=false > mppe-stateful=false > crtscts=false > baud=0 > mru=0 > mtu=0 > lcp-echo-failure=0 > lcp-echo-interval=0 > > [ipv4] > method=auto > ignore-auto-routes=false > ignore-auto-dns=false > > > dhcp-send-hostname=false > never-default=false > > [gsm] > number=*99# > username=...@cingulargprs.com > password=CINGULAR1 > apn=ISP.CINGULAR > network-type=-1 > band=-1 > > > allowed-bands=1 > > [serial] > baud=115200 > bits=8 > parity=110 > stopbits=1 > send-delay=0 > > > My error: > > Sep 20 17:18:28 bug20 NetworkManager: Re-checking deferred serial > ports > Sep 20 17:18:28 bug20 NetworkManager: (ttyUSB3): new Modem device > (driver: 'sierra') > > > Sep 20 17:18:28 bug20 NetworkManager: (ttyUSB3): exported as > /org/freedesktop/Hal/devices/usb_device_1199_6890_noserial_if3_serial_usb_0 > Sep 20 17:18:28 bug20 NetworkManager: (wlan0): device state change: 2 > -> 3 (reason 0) > > > Sep 20 17:18:28 bug20 NetworkManager: (wlan0): supplicant interface > state: starting -> ready > Sep 20 17:18:33 bug20 NetworkManager: (ttyUSB3): device state change: > 1 -> 2 (reason 2) > > > Sep 20 17:18:33 bug20 NetworkManager: (ttyUSB3): deactivating device > (reason: 2). > Sep 20 17:18:33 bug20 NetworkManager: > nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' > failed > > > Sep 20 17:18:33 bug20 NetworkManager: > nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' > failed > Sep 20 17:18:33 bug20 NetworkManager: (ttyUSB3): device state change: > 2 -> 3 (reason 0) > > > Sep 20 17:18:33 bug20 NetworkManager: Activation (ttyUSB3) starting > connection 'AT&T Data Connect 1' > Sep 20 17:18:33 bug20 NetworkManager: (ttyUSB3): device state change: > 3 -> 4 (reason 0) > > > Sep 20 17:18:33 bug20 NetworkManager: Activation (ttyUSB3) Stage 1 of > 5 (Device Prepare) scheduled... > Sep 20 17:18:33 bug20 NetworkManager: Activation (ttyUSB3) Stage 1 of > 5 (Device Prepare) started... > > > Sep 20 17:18:33 bug20 NetworkManager: [1284999513.177490] > nm_serial_device_open(): (ttyUSB3) opening device... > Sep 20 17:18:38 bug20 usb 1-2.3: NetworkManager timed out on ep0out len=0/0 > Sep 20 17:18:38 bug20 ehci-omap ehci-omap.0: reused qh ffc00780 schedule > > > Sep 20 17:18:38 bug20 usb 1-2.3: link qh2-0001/ffc00780 start 1 [2/0 us] > Sep 20 17:18:43 bug20 usb 1-2.3: NetworkManager timed out on ep0out len=0/0 > Sep 20 17:18:48 bug20 usb 1-2.3: NetworkManager timed out on ep0out len=0/0 > > > Sep 20 17:18:53 bug20 usb 1-2.3: NetworkManager timed out on ep0out len=0/0 > Sep 20 17:18:53 bug20 NetworkManager: Activation (ttyUSB3) Stage 1 of > 5 (Device Prepare) complete. > Sep 20 17:18:58 bug20 usb 1-2.3: NetworkManager timed out on ep0out len=0/0 > > > Sep 20 17:19:09 bug20 NetworkManager: Retrying modem initialization > (0) > Sep 20 17:19:09 bug20 NetworkManager: nm_serial_device_add_timeout(): > Trying to add a new time out while the old one still exists > > > Sep 20 17:19:19 bug20 NetworkManager: init_done(): Modem > initialization timed out > Sep 20 17:19:19 bug20 NetworkManager: (ttyUSB3): device state change: > 4 -> 9 (reason 28) > Sep 20 17:19:19 bug20 NetworkManager: [1284999559.003539] > nm_serial_device_close(): Closing device 'ttyUSB3' > >
Re: Using 2 interfaces with network manager
On Thu, 2010-09-23 at 02:07 +0300, Uwe Geuder wrote: > Hi! > > I've never understood how network manager works if more than > 1 network interface is in use. Is it designed for such usage at all? Yes, it is. > What I want to do: > > - use wlan0 to connect to the internet using network manager. Access > points might change from time to time, e.g. when travelling. > > - use eth0 for internet connection sharing (ICS). (using a cross connected > Ethernet cable to provide an Internet connection to another device) > I don't think network manager can do it, but I'm comfortable to do > it manually (interface definition, IP forwarding and NAT) > > So I configure eth0 in /etc/network/interfaces as > > auto eth0 > iface eth0 inet static > address 192.168.77.1 > netmask ... > ... It doesn't appear that the ifupdown plugin supports 'shared' connections, which is what you're trying to do here with eth0. When you create a "shared" connection in NM, NM itself will run dnsmasq in forwarding DNS mode, and will also start a DHCP server on that interface to provide addressing services to other computers on that interface. You don't need to set up anything manually for ICS with NM. > The other parts are not relevant for the discussion here. > > Ideally I want to leave this definition there, whether I use the ICS > at the moment or not. (I don't think I have the need or even > possibility to connect to a wired network) So in this case, you could have *two* connections. Your normal static one, and a second ICS one that NM manages. Becuase the ifupdown plugin does not appear to support NM ICS/"shared" connections yet, you'll need to use the 'keyfile' plugin for the shared connection. > > This works without problems in Kubuntu Lucid (nm 0.8.0) with > knetworkmanager. This likely works because the 'shared' connection is probably a user-session connection, which supports all connection types including 'shared' ones. > However, in Ubuntu Lucid and Xubuntu Lucid (same nm version), which > both use nm-applet instead of knetworkmanager there is a nasty > problem. It works as long a previously defined WLAN is in > range. But whenever no previously defined WLAN is in range, > nm-applet is completely invisible. The "not connected" icon is just > not there. And without having nm-applet visible I cannot really use > any network. Yeah, this is interesting. At least in GNOME (and expected for nm-applet generally) is that it is shown whenever its running. I've added code to nm-applet 0.8.2 that logs when the applet is shown by GTK and when it's not to debug this very issue. It's pretty hard to debug otherwise because the interaction of the notification area applets is hard to debug with nm-applet. I think we've done just about everything we can do in nm-applet itself to protect against this, and the logging in NM 0.8.2 will finally allow us to figure out where to point the blame. > Well, I could scan for WLANs from the commandline, start > nm-connection-editor from the command line and define the network. But > then I have still to log out (or even reboot?) What i currently do is > to edit /etc/network/interfaces each time I want to connect to a new > WLAN. I remove eth0 from there and reboot (at least I have not found > any way without rebooting. Just shutting eth0 down does not help.) > After having defined the new WLAN using nm-applet I can revert the > changes in /etc/network/interfaces. > > Needless to say, that's not really pain free networking. > > Is there any better solution? Is it a bug or feature that nm-applet > gets completely invisible? No, it shouldn't be. It should be shown whenever it is running and whenever NetworkManager itself is running. How it should work: whenever the cable is plugged in, NetworkManager will bring up the "shared" connection and wait for a main internet connection. The main internet connection may shift around depending on where you're at, but that shouldn't matter. The integrated NAT support that NM provides should allow seamless switches between wifi networks while ICS clients are connected. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: vpnc: can't open pidfile /var/run/vpnc/pid for writing
On Mon, 2010-09-20 at 17:45 -0500, Dan Williams wrote: > On Thu, 2010-09-09 at 09:40 -0400, Tom Sutherland wrote: > > yes - free space is not an issue. > > Normally on RPM-based distros the package would create and own that > directory, but I guess we need to create it if it doesn't exist. Actually, I've decided it's a disto problem. Because NM-vpnc is not actually passing the pidfile path to vpnc, vpnc itself is determining where to put the pidfile (and this isn't known to anything other than vpnc itself). Thus it's not really NM's responsibility to set up the pidfile environment for vpnc. Were NM passing an explicit pidfile path, then it would be NM's responsibility. Dan > Dan > > > On Wed, 2010-09-08 at 12:40 -0400, José Queiroz wrote: > > > Is there free space in the FS that holds "/var/run/vpnc"? > > > > > > 2010/9/7 Tom Sutherland > > > From my syslog: > > > > > > > > > Sep 7 13:31:07 angry-butler09 vpnc[7137]: can't open > > > pidfile /var/run/vpnc/pid for writing > > > Sep 7 13:31:08 angry-butler09 NetworkManager[1112]: > > > VPN connection 'WolverineECC' (IP Config Get) complete. > > > Sep 7 13:31:08 angry-butler09 NetworkManager[1112]: > > > Policy set 'LabConn' (eth0) as default for IPv4 routing and > > > DNS. > > > Sep 7 13:31:08 angry-butler09 NetworkManager[1112]: > > > VPN plugin state changed: 4 > > > Sep 7 13:31:08 angry-butler09 nm-dispatcher.action: Script > > > '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with > > > error status 1. > > > Sep 7 13:37:37 angry-butler09 vpnc[7137]: select: Interrupted > > > system call > > > Sep 7 13:37:37 angry-butler09 vpnc[7137]: terminated by > > > signal: 15 > > > > > > The tunnel interface comes up, routes are populated, but no > > > traffic seems to flow across tunnel. > > > > > > If I manually create /var/run/vpnc directory prior to starting > > > the connection, all seems to work properly. > > > > > > > > > version: > > > network-manager/maverick uptodate 0.8.1 > > > +git.20100810t184654.ab580f4-0ubuntu2 > > > > > > > > > uname -a: > > > Linux angry-butler09 2.6.35-20-generic #29-Ubuntu SMP Fri Sep > > > 3 14:55:28 UTC 2010 x86_64 GNU/Linux > > > > > > > > > Any ideas? Is this a distro-specific thing? > > > > > > Regards, > > > Tom Sutherland > > > > > > > > > > > > > > > > > > > > > ___ > > > 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 > > > ___ > 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: NetworkManager Won't Save Passwords
On Tue, 2010-09-21 at 17:43 -0500, alkos333 wrote: > On Mon, Sep 20, 2010 at 5:43 PM, Dan Williams wrote: > > On Mon, 2010-09-13 at 12:08 -0500, alkos333 wrote: > >> On Mon, Sep 13, 2010 at 11:12 AM, Robby Workman wrote: > >> > Does it work in a desktop environment (e.g. kde or xfce)? > >> > > >> > It's fine here in xfce, fwiw. > >> > >> I haven't tried with KDE or xfce - just fluxbox. > > > > nm-applet uses gnome-keyring, which needs a bit of setup when used in > > non-GNOME environments. If gnome-keyring isn't built with D-Bus > > support, then you need to start "gnome-keyring-daemon --daemonize > > --login" when your desktop session starts. This will print out an > > environment variable that needs to be inserted into the environment of > > any other program that starts in the session, which looks like this: > > > > GNOME_KEYRING_CONTROL=/tmp/keyring-hSwpKJ > > > > this lets programs like nm-applet know where to look for the keyring > > daemon, which is what actually stores your passwords securely. If you > > google around there used to be instructions on how to get KDE to handle > > running gnome-keyring-daemon manually, I'd assume that whatever session > > manager is starting up your desktop probably has the same functionality. > > > > Dan > > > > > > > > Thank you for this explanation, Dan. This helped me resolve the > issue. Now gnome-keyring only prompts for the master password when I > first start fluxbox and that's it. Yes, that's expected behavior. Though normally there's a 'login' keychain that somehow gets created and is locked with your login password. At least in GNOME it gets unlocked automatically for you when you log in. Not entirely sure how that works though :) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: NetworkManager reset MAC address
On Wed, 2010-09-22 at 10:29 +0200, Jirka Klimes wrote: > On Tuesday 21 of September 2010 00:47:42 Dan Williams wrote: > > On Wed, 2010-09-01 at 16:31 +0200, Jirka Klimes wrote: > > > On Tuesday 31 of August 2010 12:26:05 mms...@gmail.com wrote: > > > > I wrote a udev rule to change the MAC address of my wireless card and > > > > it worked correctly until I upgraded to > > > > NetworkManager-0.8.1-4.git20100817.fc13.x86_64 > > > > today. Now I find the MAC is reset back to the original address by > > > > NetworkManager. > > > > How to stop this new feature? > > > > > > The new NetworkManager has implemented MAC spoofing feature just for this > > > purpose. > > > In connection editor, on 'Wireless' tab there is a new edit box 'Cloned > > > MAC address'. If you put your desired MAC here, it will be set on an > > > interface when the connection is activated. And you don't need to change > > > your MAC in udev or any other way. > > > See https://bugzilla.redhat.com/show_bug.cgi?id=447827 > > > > Yeah, though I think if something has set the MAC before NM starts, we > > probably want to make NM read that MAC address in as a spoofed MAC when > > NM starts. I'm not sure we do that yet? Basically respect the > > configuration that exists for both permanent MAC and spoofed MAC when NM > > starts up if we can. > > > > Dan > > > > The problem is that we currently reset the MAC to permanent MAC address and > thus ignoring the MAC that has been changed before NM starts. > The attached patch reads the MAC set on interface when NM starts and when > uses > that when resetting MAC. Thus, NM won't interfere with other settings and > won't annoyingly keep putting permanent MAC to the interface. Looks good, please push to both 0.8 and master. Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: How to find the NM version?
On Wed, 2010-09-22 at 16:46 +0200, Jirka Klimes wrote: > On Wednesday 23 of September 2009 06:40:03 Dan Williams wrote: > > On Tue, 2009-09-22 at 17:44 -0700, Raj Sidh wrote: > > > Hello, > > > > > > I find that some NetworkManager dbus APIs are of older version in some > > > distros (e.g. Ubuntu 8.04) whereas Fedora 9 seems to have what is listed > > > under http://projects.gnome.org/NetworkManager/developers/spec.html > > > which apparently is 0.7.0. How do I determine what version of NM I am > > > running so I can make right choices (bus.GetDevices() vs. > > > bus.getDevices() and similar) ? > > > > Programmatically, you can use some tricks to figrue it out like you > > mention, but Tambet also proposed the addition of a Version property on > > the /org/freedesktop/NetworkManager base object that we can add to both > > 0.7.2 and 0.8+. > > > > 0.7.0 vs. 0.7.1 shouldn't be difference to care about, it's mostly > > between 0.6, 0.7, and 0.8. > > > > Dan > > > > I think Version property is really helpful. I don't know whether a patch > exists. Anyway, I'm attaching a patch to add the property. Looks good, please push it to 0.8 and master. Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
modem-manager fails to reconnect
Hi, I've noticed a strange behavior with my 3g dongle (Onda MSA405 HS / 19d2:0037). When I plug it, it connects with ease. After some time, if I disconnect it and try to reconnect, it fails, and I have to unplug/plug again the device or restart modem-manager process to get the connection back. I've turned on loggin on modem-manager, and I saw that when it states that the connection transitioned from "connected -> disconnecting" and from "disconnecting -> registered", I can reconnect it. But sometimes, it transitions from "connected -> disconnecting" and then "disconnecting -> connect". When this happens, I cannot reconnect unless unplug or restart modem-manager. This sometimes happens in the first reconnection, sometimes it takes some reconnections to happen, but sooner or later will happen. I'm using: Kubuntu Lucid 10.04, NetworkManager 0.8.1+git.20100810t184654.ab580f4-0ubuntu3~nmt3~lucid modem-manager 0.4+git.20100922t210758.618dc06-0ubuntu1~nmt1~lucid I also saw that in a normal disconnect, ttyUSB2 (data port) and ttyUSB1 send a "NO CARRIER" message; when the disconnection fails, only ttyUSB1 says "NO CARRIER". This is a piece of modem-manager debug. I can consistently reproduce the symptom, if needed. ** (modem-manager:11224): DEBUG: <1285364689.581337> (ttyUSB2): network_mode => 8 ** (modem-manager:11224): DEBUG: <1285364689.581337> (ttyUSB2): username => "tim" ** (modem-manager:11224): DEBUG: <1285364689.581337> (ttyUSB2): number => "*99#" ** (modem-manager:11224): DEBUG: <1285364689.581337> (ttyUSB2): apn => " www.tim.com.br" ** (modem-manager:11224): DEBUG: <1285364689.581337> (ttyUSB2): allowed_mode => 4 ** (modem-manager:11224): DEBUG: <1285364689.581337> (ttyUSB2): password => "tim" ** (modem-manager:11224): DEBUG: <1285364689.581451> (ttyUSB2): simple connect state 0 ** (modem-manager:11224): DEBUG: <1285364689.581492> (ttyUSB2): simple connect state 2 ** (modem-manager:11224): DEBUG: <1285364689.581541> (ttyUSB2): --> 'AT+CREG?' ** (modem-manager:11224): DEBUG: <1285364689.591677> (ttyUSB2): <-- '+CREG: 1,1OK' ** (modem-manager:11224): DEBUG: <1285364689.591776> (ttyUSB2): simple connect state 4 ** (modem-manager:11224): DEBUG: <1285364689.591821> (ttyUSB2): --> 'AT+CGDCONT?' ** (modem-manager:11224): DEBUG: <1285364689.613745> (ttyUSB2): <-- '+CGDCONT: 1,"IP","www.tim.com.br","0.0.0.0",0,0+CGDCONT: 2,"IP","www.tim.com.br","0.0.0.0",0,0+CGDCONT: 3,"IP"," bandalarga.claro.com.br","0.0.0.0",0,0+CGDCONT: 4,"IP","tim.br ","0.0.0.0",0,0OK' ** (modem-manager:11224): DEBUG: <1285364689.613907> (ttyUSB2): simple connect state 5 ** (modem-manager:11224): DEBUG: <1285364689.613961> Modem /org/freedesktop/ModemManager/Modems/0: state changed (registered -> connecting) ** (modem-manager:11224): DEBUG: <1285364689.614001> (ttyUSB2): --> 'ATD*99***1#' ** (modem-manager:11224): DEBUG: <1285364689.634906> (ttyUSB2): <-- 'CONNECT 115200' ** (modem-manager:11224): DEBUG: <1285364689.635012> (ttyUSB2): port now connected ** (modem-manager:11224): DEBUG: <1285364689.635055> Modem /org/freedesktop/ModemManager/Modems/0: state changed (connecting -> connected) ** (modem-manager:11224): DEBUG: <1285364689.635098> (ttyUSB2): simple connect state 6 ** (modem-manager:11224): DEBUG: (net/ppp0): could not get port's parent device ** (modem-manager:11224): DEBUG: <1285364691.463726> (ttyUSB1): <-- '+ZPASR: "HSDPA"' ** (modem-manager:11224): DEBUG: <1285364701.3719> (ttyUSB1): --> 'AT+CSQ' ** (modem-manager:11224): DEBUG: <1285364701.13901> (ttyUSB1): <-- '+CSQ: 16,99OK' ** (modem-manager:11224): DEBUG: <1285364701.14020> (ttyUSB1): --> 'AT+ZPAS?' ** (modem-manager:11224): DEBUG: <1285364701.34469> (ttyUSB1): <-- '+ZPAS: "HSDPA","CS_PS"OK' ** (modem-manager:11224): DEBUG: <1285364708.9169> Modem /org/freedesktop/ModemManager/Modems/0: state changed (connected -> disconnecting) ** (modem-manager:11224): DEBUG: <1285364708.9302> (ttyUSB1): --> 'AT+CGACT=0,1' ** (modem-manager:11224): DEBUG: <1285364708.42966> (ttyUSB2): network_mode => 8 ** (modem-manager:11224): DEBUG: <1285364708.42966> (ttyUSB2): username => "tim" ** (modem-manager:11224): DEBUG: <1285364708.42966> (ttyUSB2): number => "*99#" ** (modem-manager:11224): DEBUG: <1285364708.42966> (ttyUSB2): apn => " www.tim.com.br" ** (modem-manager:11224): DEBUG: <1285364708.42966> (ttyUSB2): allowed_mode => 4 ** (modem-manager:11224): DEBUG: <1285364708.42966> (ttyUSB2): password => "tim" ** (modem-manager:11224): DEBUG: <1285364708.43083> (ttyUSB2): simple connect state 0 ** (modem-manager:11224): DEBUG: <1285364708.43126> (ttyUSB2): simple connect state 2 ** (modem-manager:11224): DEBUG: <1285364710.903746> (ttyUSB2): <-- '+ZPASR: "UMTS"' ** (modem-manager:11224): DEBUG: <1285364710.903941> (ttyUSB1): <-- '+ZPASR: "UMTS"' ** (modem-manager:11224): DEBUG: <1285364710.925500> (ttyUSB1): <-- 'OK' ** (modem-manager:11224): DEBUG: <1285364710.927614> (ttyUSB2): <-- 'NO CARRIER' ** (modem-manager:11224): DEBUG: Got failure code 3: No carrier ** (modem-manager:11224): D
Re: NM vs. suspend/resume
On Fri, 2010-09-24 at 09:37 -0400, Neal Becker wrote: > Jirka Klimes wrote: > > > On Friday 24 of September 2010 13:00:58 Neal Becker wrote: > >> NetworkManager-0.8.1-6.git20100831.fc13.x86_64 > >> knetworkmanager-0.9-0.20.20100603.fc13.x86_64 > >> > >> When resumed, NM does not notice wired eth0 if when suspended it was > >> running on wifi. Restarting NM fixes it. > >> > >> Or perhaps the problem is knetworkmanager not noticing the change? > >> > > > > Could you grab NetworkManager logs (var/log/messages)? > > Do you see the device in nm-tool output? > > > > Jirka > > See attached. nm says nothing about eth0 when resumed. Then nm is > restarted and everything works. So that log indicates that NM isn't getting the suspend/resume signals at all, actually. Unless that log doesn't show NM actually being suspended and resumed? NM >= 20100831 has two mechanisms for suspend: pm-utils (which has historically had these types of issues) and listening to upower signals. I spent a bunch of yesterday testing wifi suspend/resume on an up-to-date F13 and could not reproduce these issues. I'll next test wired suspend/resume. However, if you don't see suspend/resume messages in /var/log/messages, then it's likely a problem with communication between pm-utils and/or upower. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM vs. suspend/resume
Jirka Klimes wrote: > On Friday 24 of September 2010 13:00:58 Neal Becker wrote: >> NetworkManager-0.8.1-6.git20100831.fc13.x86_64 >> knetworkmanager-0.9-0.20.20100603.fc13.x86_64 >> >> When resumed, NM does not notice wired eth0 if when suspended it was >> running on wifi. Restarting NM fixes it. >> >> Or perhaps the problem is knetworkmanager not noticing the change? >> > > Could you grab NetworkManager logs (var/log/messages)? > Do you see the device in nm-tool output? > > Jirka See attached. nm says nothing about eth0 when resumed. Then nm is restarted and everything works.Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) starting connection 'nbecker' Sep 24 06:47:56 nbecker1 NetworkManager[1351]: (wlan0): device state change: 3 -> 4 (reason 0) Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Sep 24 06:47:56 nbecker1 NetworkManager[1351]: (wlan0): supplicant connection state: scanning -> disconnected Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Sep 24 06:47:56 nbecker1 NetworkManager[1351]: (wlan0): device state change: 4 -> 5 (reason 0) Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0/wireless): access point 'nbecker' has security, but secrets are required. Sep 24 06:47:56 nbecker1 NetworkManager[1351]: (wlan0): device state change: 5 -> 6 (reason 0) Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Failed to update connection secrets: 1 802-1x Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Sep 24 06:47:56 nbecker1 NetworkManager[1351]: (wlan0): device state change: 6 -> 4 (reason 0) Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Sep 24 06:47:56 nbecker1 NetworkManager[1351]: (wlan0): device state change: 4 -> 5 (reason 0) Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0/wireless): connection 'nbecker' has security, and secrets exist. No new secrets needed. Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Config: added 'ssid' value 'nbecker' Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Config: added 'scan_ssid' value '1' Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Config: added 'key_mgmt' value 'WPA-PSK' Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Config: added 'psk' value '' Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Sep 24 06:47:56 nbecker1 NetworkManager[1351]: Config: set interface ap_scan to 1 Sep 24 06:47:56 nbecker1 openvpn[18484]: RESOLVE: Cannot resolve host address: nbecker.dyndns.org: [TRY_AGAIN] A temporary error occurred on an authoritative name server. Sep 24 06:47:56 nbecker1 openvpn[18484]: RESOLVE: Cannot resolve host address: nbecker.dyndns.org: [TRY_AGAIN] A temporary error occurred on an authoritative name server. Sep 24 06:47:57 nbecker1 dhclient[23755]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 Sep 24 06:47:58 nbecker1 ntpd[1446]: Deleting interface #6 wlan0, 192.168.1.113#123, interface stats: received=142, sent=142, dropped=0, active_time=47659 secs Sep 24 06:47:58 nbecker1 ntpd[1446]: 192.43.244.18 interface 192.168.1.113 -> (null) Sep 24 06:47:58 nbecker1 ntpd[1446]: 216.45.57.38 interface 192.168.1.113 -> (null) Sep 24 06:47:58 nbecker1 ntpd[1446]: 63.240.161.99 interface 192.168.1.113 -> (null) Sep 24 06:47:58 nbecker1 NetworkManager[1351]: (wlan0): supplicant connection state: disconnected -> scanning Sep 24 06:48:01 nbecker1 openvpn[18484]: RESOLVE: Cannot resolve host address: nbecker.dyndns.org: [TRY_AGAIN] A temporary error occurred on an authoritative name server. Sep 24 06:48:04 nbecker1 dhclient[23755]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 Sep 24 06:48:04 nbecker1 dhclient[23755]: DHCPOFFER from 10.32.112.2 Sep 24 06:48:04 nbecker1 dhclient[23755]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Sep 24 06:48:04 nbecker1 dhclient[23755]: DHCPACK from 10.32.112.3 Sep 24 06:48:04 nbecker1 dhclient[23755]: bound to 10.32.112.161 -- renewal in 36902 seconds. Sep 24 06:48:04 nbecker1 NetworkMa
Re: NM vs. suspend/resume
On Friday 24 of September 2010 13:00:58 Neal Becker wrote: > NetworkManager-0.8.1-6.git20100831.fc13.x86_64 > knetworkmanager-0.9-0.20.20100603.fc13.x86_64 > > When resumed, NM does not notice wired eth0 if when suspended it was > running on wifi. Restarting NM fixes it. > > Or perhaps the problem is knetworkmanager not noticing the change? > Could you grab NetworkManager logs (var/log/messages)? Do you see the device in nm-tool output? Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM vs. suspend/resume
NetworkManager-0.8.1-6.git20100831.fc13.x86_64 knetworkmanager-0.9-0.20.20100603.fc13.x86_64 When resumed, NM does not notice wired eth0 if when suspended it was running on wifi. Restarting NM fixes it. Or perhaps the problem is knetworkmanager not noticing the change? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to get modem connection objpath and modem device objpath? Re: how to let http brings up networkmanager modem connectivity?
On Friday 24 of September 2010 01:36:45 hong sheng wrote: > Hi Jirka, > > Thanks for the help. However, it seems for my Case, the Connection is /3 if > I put the wifi start config into /etc/NetworkManager/system-connection, > but it has to change to /1 if I remove those wifi start config and just put > modem start config in /system-connection. In addition, the device objpath > is changed to: /org/freedesktop/ > > > NetworkManager/Devices/1. (wifi is on /0). > > So, my question is: How can I dynamically know the device objpath and > connection objpath? Is there any signal or callback function or dbus method > call to get the modem device objpath and modem connection objpath? How can > I write a simple program to get these information? > > thanks a lot > > Xiaohong > Yeah, object paths change. You can list all available connections (object paths) via ListConnection() method on org.freedesktop.NetworkManagerSettings interface. And get settings of the connection using GetSettings(). There is also NewConnection signal emitted (with object path as a parameter) when a new connection becomes available. List of available devices is produced by GetDevices() method of org.freedesktop.NetworkManager interface. See [1] for that stuff. e.g.: dbus-send --system --print-reply \ --dest=org.freedesktop.NetworkManagerSystemSettings \ /org/freedesktop/NetworkManagerSettings \ org.freedesktop.NetworkManagerSettings.ListConnections dbus-send --system --print-reply \ --dest='org.freedesktop.NetworkManagerSystemSettings' \ '/org/freedesktop/NetworkManagerSettings/0' \ org.freedesktop.NetworkManagerSettings.Connection.GetSettings org.freedesktop.ModemManager provides EnumerateDevices() to list modem devices' object paths and there is a signal DeviceAdded emitted while devices are plugged [2]. You can use these D-Bus means to wire a script. However, that's not all necessary. You can just use nmcli to activate a connection identifying it via its name (id) or uuid (that doesn't change). And, you don't need to know D-Bus objects paths. Jirka [1] http://projects.gnome.org/NetworkManager/developers/spec-08.html [2] http://projects.gnome.org/NetworkManager/developers/mm-spec-04.html > On Fri, Sep 17, 2010 at 1:07 AM, Jirka Klimes wrote: > > On Wednesday 15 of September 2010 23:49:56 hong sheng wrote: > > > Hi > > > > > > I would skip the networkmanager applet in our platform. In stead, I > > > want > > > > to > > > > > let the http brower automatically bring up the 3G connectivity for > > > NetworkManager. So, what d-bus message I should send to bring up the 3G > > > connectivity ? > > > > > > Thanks > > > > > > Hong > > > > To activate a connection, ActivateConnection method should be called via > > D-Bus > > on org.freedesktop.NetworkManager interface. The NM D-Bus API can be > > found at > > http://projects.gnome.org/NetworkManager/developers/spec-08.html > > > > You can do it e.g.: > > #!/bin/bash > > > > SERVICE="org.freedesktop.NetworkManagerSystemSettings" > > CONNECTION="/org/freedesktop/NetworkManagerSettings/2" > > DEVICE="/org/freedesktop/NetworkManager/Devices/0" > > > > dbus-send --system --print-reply --type=method_call -- > > dest='org.freedesktop.NetworkManager' \ > > '/org/freedesktop/NetworkManager' > > org.freedesktop.NetworkManager.ActivateConnection \ > > string:"$SERVICE" objpath:"$CONNECTION" objpath:"$DEVICE" objpath:"/" > > > > or use command line tool nmcli: > > nmcli nm con up id "your connection name" > > or > > nmcli nm con up uuid > > > > List connections with: > > nmcli con list > > > > Jirka > > > > Note: > > org.freedesktop.NetworkManagerSystemSettings service means system > > connections > > managed by NM itself (and stored via a plugin, e.g. keyfile) ~ "Available > > to > > all users" > > org.freedesktop.NetworkManagerUserSettings service is run by clients (nm- > > applet) and is available just while the client is up. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
