Re: Atheros abg / madwifi trouble
On Sun, 30 Jan 2005 22:52:59 -0500, Lance A. Brown wrote: Dan Williams wrote: I've committed some updates to CVS that may fix this, but Monday at work a coworker has an Atheros abg card that I'll test out and see if I can come up with a definite fix. NM isn't pushing my Atheros into mode 1 (802.11a) mode anymore, and the NIC associates with my AP properly now, but NM isn't finding out the NIC has hardware link. It sits forever waiting. This is a definite improvment over getting put into 802.11a mode. I'm glad to see progress! --[Lance] yes. great improvement over the version of nm released with fc3! i experience the same here. as soon as i the card associates, nm reports no hardware link and waits for another ap forever. dan, i hope you find the bug today. bye stefan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: MII-less network card support
Dan Williams wrote: Anyone got any better ideas? We can't just have a timeout (because it might miss data on the socket that came before it was called) and we can't just have the GIOChannel callback (because then we'd never get called to set LINK = FALSE when no data arrived after a certain time, and because it might get called TOO often), but having both seems a bit complicated. I've got a few thoughts, but they all depend on just how much traffic you see on a 'idle' network. Anyone with more knowledge of ethernet traffic patterns than me? However, I've still got a few thoughts. Best idea I've had so far consists of 1) The GIOChannel waits for data for 3 seconds (or another small time - must be small enough to not induce significant delay in the link removed detection, but not so small that we get false positives). Actually, looking over the docs, GIOChannel looks like a bad option. A separate thread with plain simple fd's looks like a better option, because then we can do blocking 'peek' operations on the channel, which GIOChannel's don't appear to be able to do AFAIK. 2) If we see data, announce 'link created' if that's a change in state (this will only be in the init phase), wait for a second or so, then go to step 1. 3) If we don't see data after 3 seconds, announce 'link removed'. 4) Wait eternally for frames. If we see one, announce 'link created' and go to step 1. There is the timeout problem and that we may see data followed by several seconds of quiet, but I don't know *how* quiet for ethernet. If it's almost quiet, but some frames then we're ok, otherwise we may see some false positives. People connecting to hubs and/or busy networks are on good ground here... I'd rather see how this approach works first, and if it doesn't work well enough with quiet networks, then go with the data intensive one. Just my 2 eurocents, Tom -- [EMAIL PROTECTED] - http://tevp.net Illegitimus non carborundum ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gtk-qt-engine breaks NetworkManagerNotification
Hi, NetworkManagerNotification creates its own GTK style (using the current theme's colors of course) so that the text on the menu items will be white when the cursor is over that item, rather than black. I didn't do that code, and its been known to break before (switch themes, for instance and the menu will have a totally white background). So I wouldn't totally exclude NMN from the picture here :) Dan On Tue, 1 Feb 2005, Sebastien Estienne wrote: hello i think that the person working on gtk-qt would be the one to talk about this bug. On Mon, 31 Jan 2005 17:58:29 -0700, Andrew Hahn [EMAIL PROTECTED] wrote: First off, wonderful program. Thanks! I use KDE on my laptop and gtk-qt-engine to keep some continuity between application appearance. However, I have found that it breaks NetworkManager. When using gtk-qt-engine the wired connection will be detected and configured properly, but wireless connections are never made. The output from NetworkManager --no-daemon gives: NetworkManager: Activation (eth1) started... NetworkManager: Activation (eth1/wireless): waiting for an access point. NetworkManager: Updating allowed wireless network lists. NetworkManager: nm_dbus_get_networks(): org.freedesktop.NetworkManagerInfo.NoNetworks raised There were are no wireless networks stored. NetworkManager: Updating allowed wireless network lists. When I click on the system tray icon an empty drop down menu appears and then an error dialog with: The Application NetworkManagerNotification has quit unexpectedly. When I click 'ok', NetworkManagerNotification is respawned and the tray icon reappears. Without gtk-qt-engine everything works perfectly. This is all with fc3 NetworkManager cvs20050131 (and earlier) gtk-qt-engine-0.60-0.fdr.1.3 kde 3.3.2 gnome 2.8.0-3 Just passing on what I have learned, I'll keep testing to see if I can find out why. Andrew ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Sebastien Estienne ___ 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
GNOME list moderator service
Hi, I'm sending this e-mail to all owners of a mailing list on 'mail.gnome.org'. I've been thinking of ways to improve the GNOME mailman service, in particular, how to make list moderation easier for list owners, and the GNOME sysadmin team. Currently, many of the lists are owned (or co-owned) by '[EMAIL PROTECTED]', which is an alias to '[EMAIL PROTECTED]'. Yes, the GNOME sysadmins also get tons of mailman moderator requests every day, and a whole batch of daily reminders too. I've noticed, from watching the flood of daily reminders over the last few months, that the number of moderator requests for some lists just keeps going up - i.e. the real list owners are failing to moderate their list, so in some cases it's being left to the 'gnome-listadmin' co-owner (the sysadmins!). Every now and then, I spend a while going through them, and have mostly managed to keep the number of outstanding requests per list down to less than triple figures, but as 'gnome-listadmin' is not the (co)-owner for all the lists, there are possibly still some lists whose moderation queue had grown by several months. I figured that what we need is for all of the moderator requests to be directed to a small 'moderator team', a number of people in different timezones whose responsibility is to respond to the moderator requests each morning for their timezone. This is intended to remove the moderator burden from the list owner who may already be overburdened with development duties. It also acts to ensure that there is a reasonable response time for genuine requests, so people don't send important mail to a list only for it to be sucked into a rotting moderator queue. It also means that 'gnome-listadmin' (the sysadmins) can be relieved of much of the daily moderation trivia. So, if you would like the moderator team to moderate your list for you, please set the moderator field for your list(s) to '[EMAIL PROTECTED]' and remove any reference to '[EMAIL PROTECTED]' from the owner field. I would propose doing this step automatically, but there may be some lists for which moderation might not be appropriate, and/or some list admins might prefer to moderate their own lists. Please also send a brief note to '[EMAIL PROTECTED]' so that I can maintain a 'list of moderated lists' and so I can set a moderator password for your list, which will be known to the moderator team. Currently, the moderator team is just me, so moderation requests will be dealt with once a day (most days anyway), until I can find more volunteers. If you, or anyone you know can spare a few minutes a day to deal with a few moderation requests, please contact me. People in uncommon timezones would be ideal ;) For more details on this hare-brained scheme, this e-mail was based on a similar one I sent earlier to gnome-infrastructure: http://mail.gnome.org/archives/gnome-infrastructure/2005-January/msg00015.html Regards, -- Ross ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: signal strength problem for multiple ap's w/ the same essid
On Tue, 2005-02-01 at 10:51 -0500, Dan Williams wrote: The gdesklet is on crack actually, and those values don't really come from anywhere and break with different cards. NM is using the values _directly_ from the driver, the same values you see in 'iwconfig'. If the driver's idea of quality and max quality is off, then the solution is to fix the driver, not work around it with code like gdesklet does that doesn't make any sense for all cards... true enough. i guess it works for me right now... also, i deduce everything from what i have and see, which is only the atheros abg card. it seems to me that when i compare iwconfig and /proc/net/wireless the link quality #'s are the same... again, i don't know the code or where it's coming from, it's just an observation. i do see and acknowledge the need to have a universal solution, and i trust your assessment of the situation: the drivers suck (and there are too many of them ;-). and i appreciate all the effort you and the other NM developers put in to find a linux wireless networking solution that works (and does not suck). apart from that: could it be that NM sometimes takes the signal strength form the wrong AP (in the situation i described, with AP's with the same essid)? and what about the change in signal strengths? Sven ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: signal strength problem for multiple ap's w/ the same essid
On Tue, 2005-02-01 at 11:32 -0500, Sven wrote: On Tue, 2005-02-01 at 10:51 -0500, Dan Williams wrote: The gdesklet is on crack actually, and those values don't really come from anywhere and break with different cards. NM is using the values _directly_ from the driver, the same values you see in 'iwconfig'. If the driver's idea of quality and max quality is off, then the solution is to fix the driver, not work around it with code like gdesklet does that doesn't make any sense for all cards... apart from that: could it be that NM sometimes takes the signal strength form the wrong AP (in the situation i described, with AP's with the same essid)? and what about the change in signal strengths? No, it always uses the signal strength as reported by the card using SIOCGIWSTATS, namely it uses the exact same values you see in the Link Quality x/y section of 'iwconfig', and simply does % = x / y * 100. Note that /proc/net/wireless doesn't report any maximum quality, but iwconfig does. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
