Re: Why I can't use NM (but want to)
On 26/02/07, Simon Geard <[EMAIL PROTECTED]> wrote: This part is most likely due to the madwifi drivers, which don't report signal strength the same way as most other drivers. How so? Do you mean reporting the strength out of ninty-four? I've got the same problem - NM is currently reporting 15%, even though I'm only 5 or 6 metres from the access point. That sort of thing happens to me too, though not wuite as badly. I'm no more than a metre and a half away and I'm at forty odd percent. Oddly, I've got several much more distant access points with > 100% signal reported, which seems more than a little dubious. Yes! Often at my college, this happens. The dawson (that's its name) essid will briefly jump to 130% and then drop to 5% in no more than half a minute. Anyway, I occasionally have problems with it continuously losing the connection, but things mostly work fine despite the supposedly poor signal. Tell me, since we seem to be experiencing the same phenomena, what is your setup? I have a Toshiba A70 lappy with atheros AR5212 wireless card inside. Fiddling with the antenna sometimes helps, not sure why, since it makes little difference to reported signal... I take it, then, that your set up is a destop. Why is it, though, that I won't get kicked off and stay off with out NM? WIth NM, if I get kicked off, its happiness all round to be reconnected. -- —A watched bread-crumb never boils. —My hover-craft is full of eels. —[...]and that's the he and the she of it. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Why I can't use NM (but want to)
On 25/02/07, David R. Litwin <[EMAIL PROTECTED]> wrote: > > Is your school using some type of EAP or is it a web based login? Thanks for the quick reply! It is a web-based login, I believe. EAP is an authentication, is it not? It in indeed a web-based log in. Opening the browser brings me to a novell log in page which allows me to log in with the server and get a connexion. -- —A watched bread-crumb never boils. —My hover-craft is full of eels. —[...]and that's the he and the she of it. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet suddenly offers no options
Peter, First, I would rule out driver problems by attempting to connect to an open or WEP network with the network utility originally used in Ubuntu. Since you can connect to your home network, this seems unlikely to be a driver problem. You also mention ath0/wifi0 - do you have 2 wireless devices? The commands "ifconfig" and "iwconfig" may give useful information too. It sounds like you are connecting to the networks (at least partially?) though - is that through network manager or another utility? Once in awhile my nm-applet does something similar, but it usually works after re-enabling networking. On a final note, have you tried re-installing network manager? The wireless drivers? Sorry I couldn't be of more assistance, Seth On 2/26/07, Peter Flynn <[EMAIL PROTECTED]> wrote: Seth Howard wrote: > There is a quirk in ubuntu (I think it will be "fixed" with feisty) > that doesn't allow network-manager to see devices that are listed in > /etc/network/interfaces. Cute design idea :-) > Try commenting out all lines EXCEPT (this is important - you will > have an unbootable system if these lines aren't there): > > auto lo > iface lo inet loopback Thanks...I've tried all permutations of commenting out lines, doing an /etc/init.d/network restart and HUPping NM, but nm-applet still stubbornly refuses to admit that *any* network interface exists. With judicious uncommenting I can get eth0 to work over CAT5 into my router, natch. Trying to use ath0/wifi0 shows the DHCP request being granted a lease, but any attempt at connecting from an application gets a timeout. Even trying to ping the router (the very one that granted the lease) gets a sendmsg: Operation not permitted. > That has worked for me in the past. But if for some reason it doesn't > work, you can always uncomment the other lines and try something > else. This is rather baffling, especially as it was all working perfectly three days ago. Enlightenment was the only intruder. I wonder what piece of binary randomness it introduced which slew NM? ///Peter ___ 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: nm-applet suddenly offers no options
Seth Howard wrote: > There is a quirk in ubuntu (I think it will be "fixed" with feisty) > that doesn't allow network-manager to see devices that are listed in > /etc/network/interfaces. Cute design idea :-) > Try commenting out all lines EXCEPT (this is important - you will > have an unbootable system if these lines aren't there): > > auto lo > iface lo inet loopback Thanks...I've tried all permutations of commenting out lines, doing an /etc/init.d/network restart and HUPping NM, but nm-applet still stubbornly refuses to admit that *any* network interface exists. With judicious uncommenting I can get eth0 to work over CAT5 into my router, natch. Trying to use ath0/wifi0 shows the DHCP request being granted a lease, but any attempt at connecting from an application gets a timeout. Even trying to ping the router (the very one that granted the lease) gets a sendmsg: Operation not permitted. > That has worked for me in the past. But if for some reason it doesn't > work, you can always uncomment the other lines and try something > else. This is rather baffling, especially as it was all working perfectly three days ago. Enlightenment was the only intruder. I wonder what piece of binary randomness it introduced which slew NM? ///Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: settings daemon D-Bus interface proposal
On Tue, 2007-02-20 at 20:51 -0500, David Zeuthen wrote: > Hi, > > So I have one beef with this proposal and that is that it builds upon > the same idea of a NetworkManagerInfo-ish service. As you might know, > one of the features we're doing for Fedora 7 is fast user switching; > it's basically done with what we have in Rawhide. There's one slight > problem with NetworkManager though - consider this screenshot where "Tom > Ripley" is a user I just created > > http://people.freedesktop.org/~david/nm-with-fus.png > > In the background (on another VT) I have my normal desktop running as > user davidz and since this one was the first to start, the nm-applet > instance running for davidz gets to tell the system-wide NetworkManager > daemon what connections to use. This is somewhat broken (but still > probably good enough for Fedora 7). > > So wouldn't it be a lot nicer to do this the traditional way where only > NetworkManager is the server / mechanism (doesn't specify any policy > whatsoever) and each client doesn't need to own any services? > > Notably, you wouldn't need NM to keep state like "these are the VPN > connections I can connect to" (or keep these for N users all logged in > at the same time); that would solely be in the client. > > For things like secrets NM would emit signals whenever it need more > secrets when doing a transaction on behalf of a client. So it would look > like this > >client (e.g. nm-applet) server (NetworkManager) > > Decides to connect to a network > > -- method: TransactionBegin (details) --> > <-- return: transaction id, transaction cookie -- > > does stuff; ugh need > some secret. Looks up > in system-wide secret > store (/var/blah); > if there continues; > otherwise: > ><-- signal: NeedInfo(id, details) - > > Looks up gconf > for stuff; asks > user > > -- method: ProvideInfo (id, cookie, details) --> > <--- return: void --- > ><-- signal: TransactionComplete(id, success) - > > > and so forth. NetworkManager would still maintain state such as what > interfaces are available, what state they are in and so forth. But it > wouldn't know *anything* about user settings such as what VPN > connections some user have or how he wants to obtain IP adresses. It > would be a pure mechanism. All the logic would be in the client (aka > policy manager, e.g. nm-applet and friends). Ok, nothing against this approach, but there are still problems not addressed: 1) How would NM know to deny a particular transaction if that connection is not allowed by system policy? 2) What provides that system policy and how would NM interact with it? Basically, if we don't run a system-level "trusted" policy/info daemon all the time, we cannot deny user-level requests because there's nothing to base that denial off of unless NM starts parsing random files, which I don't really want to do in NM. If we do run a system-level policy/info daemon that stores administrator approved settings, would NM pass transaction requests off to it for approval? If not, then NM still has to pull information from the system-level daemon to be able to allow/deny requests from user-level daemons, leading to policy in NetworkManager. There's nothing wrong with having some random user-level process push info or make arbitrary connection requests of NetworkManager, but we have to have allow/deny those requests based on administrator policy (if any). We also need something to push system-wide settings down to, because we cannot trust a user-level client to reliably report those to NM. There fundamentally needs to be a two-level hierarchy. There are user-level bits on top that can make requests to activate/deactivate particular connections, and there is a system-level policy thing beneath that allows/denies those requests, and can also impose policy of its own. However, for the near-term (ie, 0.7) we need to get something off the ground fast, which means not redoing the whole infrastructure right now. I agree in principle that we should be going in the less-policy-in-NM direction. The more I think about it, the more I believe we should stick with my proposal for 0.7 and then move in the direction you've advocated for the next major release. The reason being that we want to do 0.7 fairly quickly, and we don't want to take on more than we've already got. Does that sound OK? Dan > > On Tue, 2007-02-20 at 08:49 -0500, Dan Williams wrote: > > Proposal: > > > > The system settings service (what we were calling NMI) will run either > > as 'nobody' or 'root' (I'm not sure
Re: nm-tool and friends
On Mon, 2007-02-26 at 11:53 -0600, Steev Klimaszewski wrote: > Hey all, > > I noticed a lot of people suggesting the use of nm-tool to help with > debugging, and then I noticed that on Gentoo, we don't have this tool. > So as I was digging around in the sources, I noticed that it is in the > test directory - Is that the right place for it? It seems like it > should be under utils - and I noticed that what is in utils doesn't seem Right, it probably should be there. But at this time I haven't really decided to commit to stability of the tool, so while it works, I wouldn't like people relying on it for screenscraping and whatnot. > to get built either. And one other thing - we have an nm-applet.desktop > file in the NetworkManager source - intentional? Yes, up until the split of the applet and NM itself. After that, the .desktop file should be with the applet. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-tool and friends
Hey all, I noticed a lot of people suggesting the use of nm-tool to help with debugging, and then I noticed that on Gentoo, we don't have this tool. So as I was digging around in the sources, I noticed that it is in the test directory - Is that the right place for it? It seems like it should be under utils - and I noticed that what is in utils doesn't seem to get built either. And one other thing - we have an nm-applet.desktop file in the NetworkManager source - intentional? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for static IPs
Dan Williams wrote: > On Mon, 2007-02-26 at 17:32 +0100, dragoran wrote: > >> Dan Williams wrote: >> >>> On Sun, 2007-02-25 at 17:33 -0300, zer0halo wrote: >>> >>> I heard that support for static IPs in NetworkManager is slated for 0.7. Does anyone know if that feature already exists in HEAD, and if so, is HEAD stable enough to run (ie, on Ubuntu Edgy)? >>> No and no. >>> >>> >>> >> but its still planned? >> > > Oh yes, definitely. > > ok :) > Dan > > >>> Sorry, >>> Dan >>> >>> >>> ___ >>> 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: NM versus wpa_gui
On Mon, 26 Feb 2007 07:52:38 -0500, Dan Williams wrote: >> No, thats still broken. I think the correct behaviour for the popup >> should be >> A) go to top of the window stack >> B) not steal focus from the currently active window >> Right now, it goes behind all other windows :-( > > Patches appreciated... I looked at this quickly a while ago and > couldn't find anything out of the ordinary. The metacity maintainers apparently think that urgency is better conveyed by flashing the Window List entry than by showing the unfocussed dialog. So it works as intended. Volker ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet suddenly offers no options
On 2/26/07, Peter Flynn <[EMAIL PROTECTED]> wrote: > [Edgy, Dell Inspiron 4150; NEC PCMCIA ATERM WL54SC wifi card] > > I had NM working nicely for all my wireless networks. I then installed > Enlightenment (e16) to see what it offered (very nice) and found that I had > lost all connections except my default home wifi (which may well be being > detected and connected by some other daemon -- I don't know and can't tell). > > The Network Manager (and Dispatcher) daemons were running, but nm-applet > couldn't run because there is no systray in e16. > > I logged out and logged back into Gnome, and nm-applet is now dead: it shows > in the tray, but says: > > [hover] No network connection > [left-click] No network devices have been found > [right-click] Enable networking (checked); Connection information (greyed > out); About > > I went back into e16 and installed Trayer in an attempt to allow nm-applet to > execute, which it did, but it gave the same result. I have now uninstalled all > the Enlightenment packages and returned to Gnome. Still no spark from > nm-applet. > > I managed to get a wired connection in the office by manually rewriting > /etc/network/interfaces, and I've uninstalled NM and NM-gnome and reinstalled > them, but how do I get things back to the state where nm-applet sees my > network devices (eth0, ath0, wlan0...) and their associated configs and > keyring data. Right now there seems to be no way to force it to see that they > are there. > > [And if nm-applet is dead in the water, *what* is seeing my home wifi and > connecting to it?] > > Both wifi-radar and wireless assistant agree that the wireless networks I want > are there, in range, and active, and that they are the relevant office > networks, but as they are all using WPA/PEAP/Dynamic WEP, and my > username/password is in my keyring (presumably---still) I can't connect to > them without nm-applet. > > Does anyone know why nm-applet is refusing to see them? > > ///Peter On Ubuntu the maintainers modified NM to not manage devices that are configured in /etc/network/interfaces. Since you can connect to one network I suspect it is configured there. If you use the Ubuntu networking tools and set the interface to disabled and restart networking (or reboot) nm should manage your network cards again. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Running arbitrary commands on connect
Does this work for you? nm-tool | grep '*' | grep -v 'Current Network' | cut -d ':' -f1 | cut -d '*' -f2 Jon On Mon, 2007-02-26 at 09:37 -0500, Darren Albers wrote: > On 2/26/07, Yaakov Nemoy <[EMAIL PROTECTED]> wrote: > > These are good, thanks. The only part left, where can i find a DBUS > > reference to get the actual essid of the wireless network being > > connected to? > > > > I will let Dan answer the question about DBUS but another option would > be to use iwconfig and parse it for the SSID. > ___ > 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: Running arbitrary commands on connect
On 2/26/07, Yaakov Nemoy <[EMAIL PROTECTED]> wrote: > These are good, thanks. The only part left, where can i find a DBUS > reference to get the actual essid of the wireless network being > connected to? > I will let Dan answer the question about DBUS but another option would be to use iwconfig and parse it for the SSID. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Running arbitrary commands on connect
These are good, thanks. The only part left, where can i find a DBUS reference to get the actual essid of the wireless network being connected to? On 2/25/07, Darren Albers <[EMAIL PROTECTED]> wrote: > On 2/25/07, Dan Williams <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-02-25 at 19:33 -0500, Yaakov Nemoy wrote: > > > Hi, > > > > > > I'm looking at putting together a custom stack of apps to run when > > > creating an ad-hoc network (ie dhcp, dns). Is there a simple way to > > > have Network manager run an arbitrary command(s) on the creation of > > > specific ad-hoc networks? > > > > > > If not that, where can i find a reference on the DBUS interface so i > > > can create my own daemon to listen in on the status of network > > > manager? > > > > You can do this quite easily, or there is NetworkManagerDispatcher which > > should already be in your distros package. > > > > dan > > > > There are some example scripts available here: > http://www.darrenalbers.net/wiki/index.php?title=NetworkManagerScripts > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM versus wpa_gui
On Mon, 2007-02-26 at 07:52 -0500, Dan Williams wrote: > On Mon, 2007-02-26 at 05:08 +, Volker Braun wrote: > > On Mon, 26 Feb 2007 00:37:28 +, Phil Mayers wrote: > > >> Try the svn stable branch, there were some improvements. > > > Specifically in fixing the Z-order of the popup? > > > > No, thats still broken. I think the correct behaviour for the popup > > should be > > A) go to top of the window stack > > B) not steal focus from the currently active window > > Right now, it goes behind all other windows :-( > > Patches appreciated... I looked at this quickly a while ago and > couldn't find anything out of the ordinary. > Unfortunately I think this needs to be addressed within Metacity. They wanted 100% consistency with applications launching popup windows, so basically everything gets started in the background and hinted *urgent*. This behaviour has been driving me insane recently. It really doesn't work well when you have lot's of windows open. For a while I was wondering if libnotify would be a better user experience for most dialogs. That look consistent, stack, appear on the top layer of the screen and don't steal focus. Just a thought. Jon > > > > > > I'll try, but as I say when driven from "disconnected" to "associated" > > > by wpa_gui it takes well under a second to associate, and is rock solid > > > once done. > > > > If its that fast then NM ought to work fine. Try head = > > branches/NETWORKMANAGER_0_6_0_RELEASE from svn. > > > > Volker > > > > ___ > > 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: NM versus wpa_gui
On Mon, 2007-02-26 at 05:08 +, Volker Braun wrote: > On Mon, 26 Feb 2007 00:37:28 +, Phil Mayers wrote: > >> Try the svn stable branch, there were some improvements. > > Specifically in fixing the Z-order of the popup? > > No, thats still broken. I think the correct behaviour for the popup > should be > A) go to top of the window stack > B) not steal focus from the currently active window > Right now, it goes behind all other windows :-( Patches appreciated... I looked at this quickly a while ago and couldn't find anything out of the ordinary. Dan > > > I'll try, but as I say when driven from "disconnected" to "associated" > > by wpa_gui it takes well under a second to associate, and is rock solid > > once done. > > If its that fast then NM ought to work fine. Try head = > branches/NETWORKMANAGER_0_6_0_RELEASE from svn. > > Volker > > ___ > 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
nm-applet suddenly offers no options
[Edgy, Dell Inspiron 4150; NEC PCMCIA ATERM WL54SC wifi card] I had NM working nicely for all my wireless networks. I then installed Enlightenment (e16) to see what it offered (very nice) and found that I had lost all connections except my default home wifi (which may well be being detected and connected by some other daemon -- I don't know and can't tell). The Network Manager (and Dispatcher) daemons were running, but nm-applet couldn't run because there is no systray in e16. I logged out and logged back into Gnome, and nm-applet is now dead: it shows in the tray, but says: [hover] No network connection [left-click] No network devices have been found [right-click] Enable networking (checked); Connection information (greyed out); About I went back into e16 and installed Trayer in an attempt to allow nm-applet to execute, which it did, but it gave the same result. I have now uninstalled all the Enlightenment packages and returned to Gnome. Still no spark from nm-applet. I managed to get a wired connection in the office by manually rewriting /etc/network/interfaces, and I've uninstalled NM and NM-gnome and reinstalled them, but how do I get things back to the state where nm-applet sees my network devices (eth0, ath0, wlan0...) and their associated configs and keyring data. Right now there seems to be no way to force it to see that they are there. [And if nm-applet is dead in the water, *what* is seeing my home wifi and connecting to it?] Both wifi-radar and wireless assistant agree that the wireless networks I want are there, in range, and active, and that they are the relevant office networks, but as they are all using WPA/PEAP/Dynamic WEP, and my username/password is in my keyring (presumably---still) I can't connect to them without nm-applet. Does anyone know why nm-applet is refusing to see them? ///Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Always Use VPN w/ this Connection (was Singe DES encryption should be enabled)
On Sat, 2007-02-24 at 08:10 -0500, Dan Williams wrote: > On Fri, 2007-02-23 at 23:24 +, Jack Spaar wrote: > > [*snipped*] > > Any thoughts on whether this is useful/appropriate/realistic ? It > > seems at least the "Start a VPN automatically" is within easy reach. > > I believe you're right, and this is a good idea. How UI bits get done > depend on how you look at it. Should there be a picker in the setup UI > for a _connection_ that says "always use this VPN", or should the VPN > setup bits have a picker for "when this connection is made, start me"? > > Thanks for the response Dan. I hadn't looked at it from the VPN-side picker angle. Agonizing out loud for a bit: since my use case is many connections but only one VPN, I still view the VPN-to-connection relation as a property of the connection instead of the other way around. A VPN-side picker has the advantage of not requiring the user to decide at "connect to other network" (connection creation) time that a VPN will be used. And has minimal impact on existing UI. Instead once I'm connected to an AP, I could select a VPN connection just as I would now, but have an optional "start me whenever this connection is made" checkbox at that point. Either way, that thought experiment makes wish for an editable connection properties dialog box. > If this option was checked, we'd probably want to suppress the > connection state signals until the VPN connection was successful (like I > think you suggest), just to avoid inadvertent leakage. Exactly. I *never* want Evolution to broadcast unencrypted POP credentials by auto-checking mail while the VPN isn't up. In pipe-dream land I'd love to be able to hand a gconf-locked-down laptop to a non-tech roadwarrior and know they'd always be network-safe. But for now auto-starting the VPN while suppressing the connection state signal until the VPN is up is a useful step forward. > I don't think it would be all that hard, actually. But remember, doing > stuff must not impede a "Just Works" default, and I think it's fairly > easy to make sure that tying a VPN to a connection would not do so. > > Fair enough. I'll take that as: "Patches welcome" % "Just Works". ;) --Jack ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
