Re: Stop nm-system-settings when NM is stopped
Michael Biebl a écrit : since NM 0.7 has hit the Debian archive, I got several bug reports, where users changed the configuration in /etc/network/interfaces, restarted NetworkManager (via /etc/init.d/network-manager restart), and wondered, why their changes were not picked up. Same problem here when changing HOSTNAME in /etc/sysconfig/network on Fedora 10: ignored until next reboot. The Linux hostname landscape is already very confusing (google Linux+hostname for fun). This new problem does not help. Tested with version 0.7.0.99 release 5.git20090326.fc10 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Stop nm-system-settings when NM is stopped
On Tue, Apr 21, 2009 at 11:02:49AM +0100, Marc Herbert wrote: Michael Biebl a écrit : since NM 0.7 has hit the Debian archive, I got several bug reports, where users changed the configuration in /etc/network/interfaces, restarted NetworkManager (via /etc/init.d/network-manager restart), and wondered, why their changes were not picked up. IMO we should just killall nm-system-settings on restart and reload. Thoughts? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Stop nm-system-settings when NM is stopped
Thoughts, Opinions? Technically, NetworkManager doesn't start nm-system-settings daemon (nor wpa_supplicant), so I don't think it should kill it either. It's a DBus activated service and it should have the same life cycle as DBus system daemon. Also, requiring NM/system settings restarts to modify a single NMConnection doesn't sound very nice. So in my opinion, you should just implement monitoring like keyfile,rh, and opensuse plugins do. I think system administrators are not necessarily interested in such technical details, they just want one and only one button to press after reconfiguration. People are used to type something like /etc/init.d/foo restart and job's done, they do not really care how many processes/buses/daemons this involves behind the scene. They do not care either if the script is overkill and restarts way too many processes for the change they made: as long as it works in less than a few seconds, everyone is happy. I would assume most people understand /etc/init.d/NetworkManager as the new /etc/init.d/network[ing] incarnation: that is a global _service_ restart as opposed to a single process restart. This could be where the core problem is: in the definition of this user interface. If restarting nm-system-settings does the job, then watching configuration files sounds a bit like over-engineering to me. But I admittedly know nothing about DBus nor any other implementation detail. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Stop nm-system-settings when NM is stopped
On Tuesday 21 April 2009 11:31:15 Alexander Sack wrote: On Tue, Apr 21, 2009 at 11:02:49AM +0100, Marc Herbert wrote: Michael Biebl a écrit : since NM 0.7 has hit the Debian archive, I got several bug reports, where users changed the configuration in /etc/network/interfaces, restarted NetworkManager (via /etc/init.d/network-manager restart), and wondered, why their changes were not picked up. IMO we should just killall nm-system-settings on restart and reload. Thoughts? I think we should killall nm-system-settings on restart, reload, stop. Rob signature.asc Description: This is a digitally signed message part. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Stop nm-system-settings when NM is stopped
On Tue, Apr 21, 2009 at 12:23:01PM +0100, Marc Herbert wrote: Thoughts, Opinions? Technically, NetworkManager doesn't start nm-system-settings daemon (nor wpa_supplicant), so I don't think it should kill it either. It's a DBus activated service and it should have the same life cycle as DBus system daemon. Also, requiring NM/system settings restarts to modify a single NMConnection doesn't sound very nice. So in my opinion, you should just implement monitoring like keyfile,rh, and opensuse plugins do. Seems that reply didnt got to mailing list (at least i didnt get it). Isnt NetworkManager supposed to give the system service a few seconds time to reappear before considering all previously used connections gone? If not, we should consider to implement that. Monitoring and applying modified config files straight away is considered impolite by admins and i think its really bad practice that keyfile,rh do that. Usually admins want to decide about the when after they edited a config file. Think about your webserver and mailserver monitoring config files and and just reloading config when the admin saves the file - in whatever state it might be at that point ;). In turn, the init reload/restart mechanism is what admins are used to do; why wouldn't we want to suppor that semantic instead? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
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 fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. I would think that the driver doesn't like background scanning. This has been reported in launchpad bug 291760 where the initial report mentions that he network manager roames to a none bssid and back, this happens in more or less two minute which coincidentially matches the max scan timeout NM uses (120 seconds). Thanks for the reminder, I had forgotten about that bug report and the last time I had encountered this problem. As I mentioned in January (and forgot) http://mail.gnome.org/archives/networkmanager-list/2009-January/msg00107.html restoring the madwifi hack to NM/src/nm-device-wifi.c makes the problem go away for me. I've posted the patch to the launchpad bug. I.e., reverting this commit: commit 98f392b085985a75274fe02ec8aa92f4ac0d8a80 Author: Dan Williams d...@redhat.com Date: Sat Oct 11 18:32:24 2008 + 2008-10-11 Dan Williams d...@redhat.com * src/nm-device-wifi.c - (can_scan): remove old madwifi hack for not scanning while -- -- 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://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
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 behave badly you could do the kill -9 trick you mentioned above and then check whether you can make your network stuck by calling the scan dbus method of wpa supplicant. Probably an iwlist scan would also trigger it while you are in that state. Maybe check that too. I tried iwlist scan but it didn't seem to break anything. It still had a noticeable effect though, as seen by ping: 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.57 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.56 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=4607 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=3604 ms 64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=2604 ms 64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1604 ms 64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=604 ms 64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.54 ms 64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=1.54 ms 64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1.54 ms Obviously the usual ping time is ~1.5ms; iwlist scan slows that down quite a lot. I didn't see any obvious way to send the right command to wpa_supplicant using dbus so I didn't try that yet. -- -- 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://mail.gnome.org/mailman/listinfo/networkmanager-list
Problem shown in KDE System Tray
Hi, I cutted a part of image in the previous E-mail, to fit in the E-mail's size limit. Latest Linux Fedora F10-x86_64, with latest KDE. Also happens with Gnome. I can't solve the problem shown in KDE system tray(Snapshot210409_part.png added). I think it has to deal with Firefox starting in off-line mode. It works when turned to on-line mode. Please, somebody can help me? Thanks, -- Lucélio Gomes de Freitas ETFCSF- U.G.F.- P.U.C.(RJ) Engº, Analista Suporte(Free Mind), Consultor. Email: aa.luce...@gmail.com Tel: +55 0XX 21 91242599 inline: snapshot210409_part.png___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Wireless connection to (none)
I found these archived messages through Google, and I have the same problem - the connection works fine, and the Connection Established message displays the right AP name, but the tray icon says there is a Wireless network connection to '(none)', and there are no bars showing signal strength. nm-list shows the connected AP at the top of the list, but there is no *. Re: Wireless connection to (none) * From: Dan Williams dcbw redhat com * To: sanjeev sharma sanjeevsharmaengg gmail com * Cc: networkmanager-list gnome org * Subject: Re: Wireless connection to (none) * Date: Wed, 04 Feb 2009 11:50:05 -0500 On Wed, 2009-02-04 at 11:39 +0530, sanjeev sharma wrote: Hi Dan, As we had Already Discussed this and I had Created an Patch for this Bug which is in NetworkManager.And you had a look into it earlier.Could I checked in this patch Into NetworkManager CVS.So We could Closed this Bug after checked in patch. I believe my last comment on the patch was that it only covers over the problem, it doesn't actually fix the problem. You'll only get this issue when NetworkManager cannot find the currently associated AP in the scan list, which could be either a driver bug, or a NetworkManager bug. Using nm-tool will help determine whether its in the applet, or in NetworkManager. Dan Regards sanjeev sharma On Tue, Feb 3, 2009 at 10:02 PM, Dan Williams dcbw redhat com wrote: On Sun, 2009-02-01 at 00:57 +0100, Ermanno Bonifazi wrote: Network manager shows in the tooltip to be connected to (none) network name, even if is connected to a specific Wireless LAN (e.g. WLAN) and is correctly working. In fact is I right click on connection information the name WLAN with the correct IP is shown. Any hint? What version of NetworkManager? When you see this bug, and you run 'nm-tool', does a * show up next to the wifi network you should be connected to? Dan ___ NetworkManager-list mailing list NetworkManager-list gnome org http://mail.gnome.org/mailman/listinfo/networkmanager-list * References: o Re: Wireless connection to (none) + From: Dan Williams o Re: Wireless connection to (none) + From: sanjeev sharma ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
