Relicense NetworkManager under LGPL-2.1+
I, Bryan Clark agree to re-license my contributions to NetworkManager as LGPL-2.1+ as proposed by Thomas Haller. Some of my work may be held under copyright by Red Hat, Inc. I do not speak for that entity. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
And a very small error in ModemManager
Unintialized variable.
-Bryan
diff --git a/src/mm-plugin-base.c b/src/mm-plugin-base.c
index 198108c..3b21930 100644
--- a/src/mm-plugin-base.c
+++ b/src/mm-plugin-base.c
@@ -666,7 +666,7 @@ get_driver_name (GUdevDevice *device)
{
GUdevDevice *parent = NULL;
const char *driver;
-char *ret;
+char *ret = NULL;
driver = g_udev_device_get_driver (device);
if (!driver) {
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
git current compile error
$ ./configure && make ... libtool: link: gcc -Wall -Werror -std=gnu89 -g -O2 -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wfloat-equal -Wno-unused-parameter -Wno-sign-compare -fno-strict-aliasing -o .libs/test-settings-defaults test_settings_defaults-test-settings-defaults.o -pthread ../../libnm-util/.libs/libnm-util.so -L/usr/lib64/nss -L/usr/lib64/nspr /usr/lib64/libgthread-2.0.so -lrt /usr/lib64/libdbus-glib-1.so /usr/lib64/libdbus-1.so /usr/lib64/libgobject-2.0.so /usr/lib64/ libglib-2.0.so -luuid -lssl3 -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -pthread ../../libnm-util/.libs/libnm-util.so: undefined reference to `nm_setting_olpc_mesh_error_quark' ../../libnm-util/.libs/libnm-util.so: undefined reference to `nm_setting_olpc_mesh_get_type' Not sure what the issue is here: $ grep -Rni nm_setting_olpc_mesh_get_type * ... libnm-util/nm-setting-olpc-mesh.h:10:#define NM_TYPE_SETTING_OLPC_MESH(nm_setting_olpc_mesh_get_type ()) libnm-util/nm-setting-olpc-mesh.h:44:GType nm_setting_olpc_mesh_get_type (void); libnm-util/libnm-util.ver:306: nm_setting_olpc_mesh_get_type; I'm not really sure what to look for in this case. Thanks. -Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM CLI
Well, why not all three: CLI, curses-based (like aptitude), and the current
GUI.
I see no reason why there can't be a backend that does all the dbus work
("nm-client-lib" and that's all it would need to do) while the frontends
populate that the information via the interfaces listed above.
And yeah, headless wireless servers - me likey for my tiny webserver at
home, and with connection-sharing even better. And writing scripts that do
"ip r a blah", and "iwconfig wlan0 blah" is silly when NetworkManager would
potentially make life so much easier. I'm seeing more usage of dbus on
server applications (e.g. dnsmasq).
And on fluxbox, or other WM's that currently aren't supported, a real dbus
backend library would still be useful to support those WM's. And even if
these users go the curses route, then you might as well have a good ol' CLI
interface as well, since it'll be easier to get functional and out to people
that are savvy enough to use it.
As far as these negatives:
1) I don't see NM that far behind the kernel and related utilities
(iproute2).
2) The NM plugins (ipsec, and openvpn) are going beyond normal users anyway.
3) I think NM has largely succeeded at getting networking easy to setup for
common users (mobile broadband and wifi is easier than windows imho).
4) And yes, I'm playing with 3g usb devices attached directly to my server,
because in the USA 3g has more reach for rural folk than DSL/Cable.
So why not start looking into the server, or non-desktop user. Btw, I'm
essentially going to do this, but I don't want to fork or create a silly
python client.
-Bryan
On Fri, Jun 26, 2009 at 12:23 PM, Mathieu Trudel-Lapierre <
mathieu...@gmail.com> wrote:
> Are you guys refering to something *purely* CLI, or simple some
> application (I'm thinking curses here, for example) that could be run
> from the command line?
>
> I could see something like network-manager for the command-line as an
> application similar to aptitude. I guess that could be done, and would
> maybe let users benefit from some of the simplicity that nm-applet
> brings to the GUI world.
>
> That said, if it's something entirely CLI, I personally find that it
> would probably be easier to just use ifconfig and whatnot. It takes
> care of most things simply, that is unless you're trying to play with
> wireless or 3g. :)
>
> I wonder if headless(wireless|3g) boxes really are all that common...
>
> Mathieu Trudel
> mathieu...@gmail.com
>
>
>
> On Thu, Jun 25, 2009 at 11:40 PM, John Mahoney wrote:
> > At the risk of contradicting my personal feelings towards a NM CLI, I
> would
> > have to say the idea of porting network manager to the command line is
> some
> > what of a paradox.
> >
> > NEG.
> > 1. NM's main goal has been to make network configuration transparent and
> > simple to the common user.
> > 2. NM will always be a few months behind the fundamental kernel drivers
> and
> > user space applications which drive networking and often require
> > understanding of scripting in BASH or comparable.
> > 3. The NM CLI based off the GUI would be even further behind the NM
> applet,
> > unless properly engineer.
> > 4. Most Linux users have come to appreciate the simplicity of NM and only
> > turn back to command line when NM is not yet able to implement a complex
> > networking feature.
> >
> > POS.
> > 1. User running headless box could also benefit from NM.
> > 2. Easily script NM configuration changes.
> > 3. If you are like myself using a GUI is like pulling teeth, yet I have
> > delightfully found NM to be the "laughing gas" of GUI's which has brought
> > some people to actually enjoy dentist visits.(obscure analogy)
> >
> > If someone was to implement a *real* CLI, I believe it would have to use
> the
> > same guts as the GUI or else it would be a QA nightmare. Anyone who read
> > this far thank you for your time and I would like to conclude by saying I
> > would be for a NM CLI if other felt it truly is possible.
> >
> > --
> > John
> > On Thu, Jun 25, 2009 at 7:03 PM, Bryan Duff wrote:
> >>
> >> I have. It's written in python, and needs a lot of work (fex, last time
> I
> >> checked it had no support for mobile broadband wireless).
> >>
> >> I'd prefer C over python, and I figured that wouldn't be too difficult
> >> given what nm-applet already offers. Pidgin might be a good example -
> they
> >> seem to have nm-applet functionality built in. So going the C lib route
> >> would allow for a cli program (library frontend) as well a bui
Re: NM CLI
I have. It's written in python, and needs a lot of work (fex, last time I checked it had no support for mobile broadband wireless). I'd prefer C over python, and I figured that wouldn't be too difficult given what nm-applet already offers. Pidgin might be a good example - they seem to have nm-applet functionality built in. So going the C lib route would allow for a cli program (library frontend) as well a building this functionality into other programs. In this sense python feels restrictive. -Bryan On Thu, Jun 25, 2009 at 3:29 PM, Rodney Morris wrote: > On Thu, Jun 25, 2009 at 2:26 PM, Bryan Duff wrote: > > Is there anyone going forward with this? > > > > It would be useful for non-X or non-KDE/GNOME setups. And if people do > > think it's worth doing (I do) then what is the best path? > > > > 1) Split nm-applet into nm-client-lib (backend - with dbus calls) and > gnome > > based nm-applet, then create an nm-cli. > > - I like this option the most because this should re-use a lot of code > > (libnm_* for example). > > > > 2) Or something I haven't thought of. > > > > I've seen a couple partial implementations of a NM cli, but they all use > > python (often poorly), and I think that's unnecessary. Hopefully I'm > late > > to the party and something is already being done about this. > > > (Forgot to repy to the list.) > > Have you looked into cnetworkmanager? According to its discription on > the Fedora build system: > > "Cnetworkmanager is a command-line client for NetworkManager, intended > to supplement or replace the GUI applets." > > You can get more information and download the source at > http://vidner.net/martin/software/cnetworkmanager/. > > I have no idea how well it works as I've never used it. I just > noticed the program a couple of weeks ago when a bunch of updates were > pushed out for F10 and F11. > > Rod > ___ > 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 CLI
Is there anyone going forward with this? It would be useful for non-X or non-KDE/GNOME setups. And if people do think it's worth doing (I do) then what is the best path? 1) Split nm-applet into nm-client-lib (backend - with dbus calls) and gnome based nm-applet, then create an nm-cli. - I like this option the most because this should re-use a lot of code (libnm_* for example). 2) Or something I haven't thought of. I've seen a couple partial implementations of a NM cli, but they all use python (often poorly), and I think that's unnecessary. Hopefully I'm late to the party and something is already being done about this. Thanks. -Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disable/Ignore access point
It still happened to me. I seleted my access point, then at some point it re-polled and select the unencrypted one (that was first on the list of available access points). This is after I deleted the unencrypted (and unwanted) connection from "Edit Connections->Wireless". -Bryan On Wed, Apr 29, 2009 at 8:20 AM, Derek Atkins wrote: > Derek Atkins writes: > > >> Any of them have an SSID of linksys? If you can reproduce the problem, > >> then we can whip up a small tool to figure out which settings service is > >> providing the 'linksys' connection. > > > > Not that I saw.. I do have a linksys123. > > However I do NOT see the linksys in the gconf dir anymore, either. > > Okay, re-doing this on more sleep.. The list appears to be in LRU > form, and Lo and Behold there is "Auto linksys". I just deleted > it from there so hopefully it wont auto-connect again. > > >> Dan > > > > -derek > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH > warl...@mit.eduPGP key available > ___ > 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
Disable/Ignore access point
My situation is that I have a number of accessible access points for me. I'll connect to the AP I want, but at some interval NetworkManager re-scans available AP's and picks an unencrypted AP (that I don't want). So I have to then, via nm-applet, reselect the AP I want to use. This is so irritating that I currently "killall -STOP NetworkManager" after a successful connection to my AP. Then the world is good, but that's not a super awesome solution. Could I disable/ignore that AP somehow? Via nm-applet's interface or NetworkManager itself? I'm running NetworkManager 7.1, and nm-applet 7.1. Perhaps there is some documentation for this? -Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Patch to correct a little wording mistake
Milan wrote: > Dan Williams wrote: > >> The problem with "interrupted" is that it implies that the connection >> will come back of it's own accord, or that you were always meant to be >> connected but that it just dropped out for a short period, which >> definitely isn't the case. We need something that implies that you have >> no network anymore. "Down" doesn't work (like somebody said) because >> WTF does down mean. The user just needs to know that they don't have a >> network connection anymore, even though there are a myriad of reasons >> that this even may have occurred. >> >> > I perfectly get your point here: the message should be clear and > precise. "Interrupted" may mislead the user. > > OTOH, "The network is disconnected" (as proposed by Peter) is not really > nice because the network is not (dis)connected: it exists, and you > (dis)connect to (from) it. So we would get the same problem with that > formulation. Network vocabulary is subtle to use... > > "The computer is no longer connected." "The machine has been > disconnected." "Your system is not connected anymore." "You are no > longer connected to ." "The network connexion to/via has been > stopped." "The network connexion is no longer active." > Or a variant (cable/wifi): "The network cable is unplugged"/"The > wireless network is no longer reachable" (requiring a code change) > These are other ideas to adapt/mix, though I'm not English so I can't > really find the right native expressions. > > My idea with this mail was more about raising the (little) problem and > giving you an easy way to correct that (no need to search in the source > to check and fix): feel free to choose the right expression, since your > are the English speaking developers (two reasons for you to know better > than me what to do ;-) ). Then we can simply edit the patches by hand to > change that, it takes 30 secs. > > Hope you may find the right word! I'd recommend you go with the slight anthropomorphism or perhaps vicarious text. Despite the fact that your system is what keeps disconnecting and reconnecting to the network that's not how people think about it. When someone asks you if your laptop is connected to the network they usually say; "Are you able to connect to the network?" despite the obvious problem that your appendages cannot associate to the access point in question. Nobody really says "Is your laptop connected to the network?" just because it's easier to leave the object out of the question and talk about the connection itself. "You are no longer connected to XXX" I recall the HIG recommended "jargon free" and simple messages, ~ Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Roadmap question
On 1/23/07, Dan Williams <[EMAIL PROTECTED]> wrote: On Tue, 2007-01-23 at 09:25 -0800, Shane Bryan wrote: > Does NM have plans (near or far) to also manage connections to > WiMax/WMAN (802.16) networks and/or Digital Cellular (aka WWAN) > networks? Both; but certainly cellular before WiMAX. What the cell bits require is the integrated PPP support, which we're working on. Is there a release target for PPP or is the support more "opportunistic". IOW, is anyone working on it now with good progress towards, say, the next release, or is it lower priority to other objectives and gets attention as time permits? Just trying to get a full understanding, not questioning anyones priorities or schedule. I'd really like to support WiMAX in the future too, but we'll need quite a few things before that happens. First, we need to know what the interface to the card looks like. Second, how much of the stack will be running in firmware versus how much will be running on the host. Third, how to tune various things that might need tuning, and fourth, we need drivers for WiMAX cards :) Heh, details, details... On that note, what are people hearing about OSS based drivers for these devices. I can name a few that are somming out with PCMCIA or SOC based solutions in the next year or two: - Intel Rosedale 2 (802.16d/e combined) - Sequans' SQN1110 SOC - ZyXEL WiMax PCMCIA - Beceem - Apparently has a ref design kit with PCMCIA card prototypes Any of these promise OSS Drivers? I know that if Intel makes WiMax part of their Centrino brand, then they have usually provided base functionality in some form of OSS driver (even if it has firmware chunks or user space proprietary code). What about other manufacturers? Companies like Sprint have committed to "mobile" WiMAX (802.16e) as their 4G cellular standard, and I would like to support them in the same manner as I'd like to support current GSM/CDMA cellular cards. I've seen recent announcements of WiMax deployments in the Portland, > OR area and other places around the world, and was curious if these > wireless networks (in the functional sense of the word) were > considered in scope for what NM is designed for, or is this lower > level than NM ( i.e. does it need to be implimented in wireless tools > or dscape or ???)? Well, WiMAX bits would certainly require a configuration interface of some kind to be able to receive stuff like strength and maybe other tunables. But GSM/CDMA cards get away without this sort of thing because they simply present a serial interface that you can dial and talk PPP over. Yeah, this is what I was thinking...that it's not all just kernel space. Authentication methodologies might differ enough to require UI changes in the collection of authentication information, correct? What else? If not NM, is anyone aware of other projects or companies working on > WiMax and WWAN connection manager/configuration tools similar to what > NM is doing for WLAN? The plan is to support the wider-area regulated frequency networks in much the same way as WLANs are right now, with the caveat that they never connect automatically unless you tell the configuration to do so, unlike current WLAN devices. Why the caveat? Perceived risk? Assumption that more local network is more secure, appropriate, or faster? Just curious. If I am connected to a the "Metropolis" WiMax network at home, why would it be assumed that I would want to connect to $tarbuck$ WiFi instead when I am enjoying my morning coffee? Wouldn't network consistancy be desirable, I mean that's one of the key selling features of Mobile WiMax isn't it? Again, having not been privy to the reasons behind the above caveat, I'm just interested in hearing the thoughts and reasons behind it. Thanks for the reply Dan, Shane... ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Roadmap question
I've searched the archives and not seen the topic I am curious about, so here goes... Does NM have plans (near or far) to also manage connections to WiMax/WMAN ( 802.16) networks and/or Digital Cellular (aka WWAN) networks? I've seen recent announcements of WiMax deployments in the Portland, OR area and other places around the world, and was curious if these wireless networks (in the functional sense of the word) were considered in scope for what NM is designed for, or is this lower level than NM (i.e. does it need to be implimented in wireless tools or dscape or ???)? If not NM, is anyone aware of other projects or companies working on WiMax and WWAN connection manager/configuration tools similar to what NM is doing for WLAN? Thanks, Shane... ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: couple of questions about the NM TODO
Dan Williams wrote: > On Thu, 2007-01-04 at 11:36 -0500, Bryan Clark wrote: > >> "Multiple Active Devices" >> >> I just wanted some clarifications about how this is going to effect our >> average laptop user. Lets say one of the situations we originally >> designed for, which was having your laptop on wireless and then plugging >> into a wired connection. I'm assuming that both wireless and wired will >> be active at this point and it seems that you plan (in this situation) >> to add the wired device as the default, higher priority, route. Is the >> wireless going to continue to be active? Is the user going to continue >> to receive notifications about changes in the secondary devices? Just >> thinking that if my wireless connection is bad and I plug into a wired >> connection, am I going to continue seeing my wireless connection bounce >> around even though I'm not (expecting that I'm) using it. Just looking >> for some clarifications to the behavior. >> > > We've had problems here before. People got mad when we automatically > switched no matter what, but that was because NM was cutting TCP > connections out from underneath apps. Right now NM will stick with a > connection you've explicitly chosen from the menu until that connection > is no longer valid, no matter how much you plug/unplug a cable if you've > picked a wireless AP. But that's confusing because many times you _do_ > want to switch when you perform an explicit action like plugging in the > cable. > > I think having multiple active devices will help this situation because > NM won't be deactivating a device just because another one activated. > So in the previous case, just plugging in the wired cable might change > the default route; but it won't terminate every TCP connection you > currently have open, which is the main gripe people have about the > current autoswitching behavior. > Sounds like a really good solution to me. > For multiple active devices, NM will switch the default route to point > through the "best" device, but would keep routes and such for other > devices until their link goes away. Apps wouldn't get signals about NM > being "disconnected" unless _every_ network device was disconnected. > Not really my concern here, just to nit pick you, if a newly run app (in the case above) uses the wired connection and then the cable is removed doesn't that app require a network disconnect signal? I can see that the app will continue to have a valid route, but it's TCP connections will still be terminated, right? > >> "Don't connect here again" >> >> I know NM keeps a laundry list of connections I've made like a personal >> wireless little black book. However we never spent much time on how to >> stop NM from connecting to certain wireless networks. Is something like >> > > One thing we're supposed to be doing here is _not_ autoconnecting to > manufacturer default SSIDs like 'linksys' or "Netgear". I think that's > broken in current CVS though, but we shouldn't be doing that. If people > find it annoying that NM won't connect automatically, then change the > damn SSID to something other than the manufacturer default :) > Yeah, I think the way that works is completely reasonable. Often there are more than one of those default access points available so having the person choose the right one is the best we can do. >> this in the works? For me this problem only really occurs in what I >> call the "conference scenario". Where you're at a conference and >> looking for the wireless, possibly trying a few different connections >> that don't work until you find one that does. However next time you're >> up and running NM continues to try all the other connections if it >> doesn't see the last one that worked. Since I haven't been to a >> conference in a while this isn't much of an issue for me anymore, but >> was something I wanted to think about fixing. >> > > By this, you mean that you can successfully connect to a network (ie get > an IP address) but that you need to either pay or log in or > something? That case we don't handle so well right now. Perhaps we > should "forget" save details of an unknown network that you were only > connected to for less than 3 minutes or something. Ideas? > Exactly, I keep connecting back to the 1369 network which costs $8 a day but I'd rather stay on the free city hall network which gets bounced every now and th
couple of questions about the NM TODO
Hey all ~ Saw the TODO linked from Dan's post and wanted to comment on some of the items, it's probably obvious which one I'm going to start with. "Warn users of (in)unsecure wireless networks...". I just wanted to say I think the idea is valiant, however the method is not going to achieve the idea. The people who care about security will have already setup a secure network to use and the people who don't care about security aren't going to change their behavior because of a dialog we put up, it'll just be annoying noise to both crowds. There's lot of evidence out there that these kinds of methods aren't effective, application developers have to decide best practices and make those defaults or it doesn't really matter. Near to this, I've seen mail traffic in the past with concerns about NM auto switching perhaps while you're away from the computer [1]. I think this is a different problem that can be handled differently but wanted to address it a little. If your system is idle when network manager auto switches networks perhaps the notification bubble should stick around until it's not idle and then behave as it normally does. That might be a behavior that needs to be looked into for other notification bubbles though. "Multiple Active Devices" I just wanted some clarifications about how this is going to effect our average laptop user. Lets say one of the situations we originally designed for, which was having your laptop on wireless and then plugging into a wired connection. I'm assuming that both wireless and wired will be active at this point and it seems that you plan (in this situation) to add the wired device as the default, higher priority, route. Is the wireless going to continue to be active? Is the user going to continue to receive notifications about changes in the secondary devices? Just thinking that if my wireless connection is bad and I plug into a wired connection, am I going to continue seeing my wireless connection bounce around even though I'm not (expecting that I'm) using it. Just looking for some clarifications to the behavior. "Don't connect here again" I know NM keeps a laundry list of connections I've made like a personal wireless little black book. However we never spent much time on how to stop NM from connecting to certain wireless networks. Is something like this in the works? For me this problem only really occurs in what I call the "conference scenario". Where you're at a conference and looking for the wireless, possibly trying a few different connections that don't work until you find one that does. However next time you're up and running NM continues to try all the other connections if it doesn't see the last one that worked. Since I haven't been to a conference in a while this isn't much of an issue for me anymore, but was something I wanted to think about fixing. I also have questions about the system wide policy stuff, but there's probably a better list to interrogate the davidz on how he plans for people to the set system wide policy options. Cheers, ~ Bryan [1] http://mail.gnome.org/archives/networkmanager-list/2006-May/msg00064.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Write to network interfaces and wpa_supplicant?
On 9/19/06, Dan Williams <[EMAIL PROTECTED]> wrote: > Out of curiosity, what needs this? I'm interested to know; a config > tool of some sort? Something that reports network status or > configuration? I'm wanting to try a couple of virtualization packages (VMWare and xen) which need to bridge the guest network interfaces to the host's. It doesn't seem to work when using the NM applet. Oh yeah, I should have specified that I was using the applet and not the regular GUI because this is a WPA encrypted network. Anyway, I happened to accidentally stumble across a page that in wpa_supplicant, the driver that must be specified if you have a 2.6.14 kernel or newer, that you must specify the "wext" driver if you have one of the ipw2100, ipw2200, ipw3945 Intel adaptors. After making that one small change, wpa_suppliant started working correctly. I really wish this little tidbit was a little more documented (esp. in the man page). Thanks for your help. Much appreciated. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: plans for "repair" button?
What's causing you to need to repair your connection? Incidentally I believe clicking on the active connection again will cause NM to re-connect anyway. ~ Bryan Markus Lutzer wrote: > Are there any plans to have a button in the menu of NM which fetch new > IP addresses (just executing "dhclient eth0/eth1/etc.")? Similar to the > "repair" entry in Windows but I would prefer a better terminology. This > would be very useful for me because executing "dhclient eth0" is the > only reason for me to keep a terminal window open. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM tidbits
Hi ~ Matthew Saltzman wrote: On Thu, 26 Jan 2006, David Zeuthen wrote: Clearly NM has the brains to do this itself and perhaps it should, at least when running battery. That's part of the point why we're making NM the single entity that controls networking. Sure, this leaves all the uhm people who like to configure their system to the last bit out in the cold but as pointed out repeatedly their are not the main audience for NM [1]. As a general rule of thumbwWe should never invent options when we can do the right thing automatically. Vote no on the "disable networking" proposition. Presumably, it would power down wireless when connected by wire? Are there other cases where you might want both? There are certainly cases where you would want neither, even when in range of a WAP. And of course, if I don't have wire, but I'm running on battery, I may want wireless anyway. I'm having a bit of trouble imagining a state diagram that doesn't have at least one human-activated switch in it. If I remember correctly we made the decision to do scans every so often to keep the access point list updated. This helps the case where you disconnect and want to be on wireless right away after that. With out the scanning it would take a while to scan for an available AP and then connect to it. There is a 'low power scanning' for when you're on battery and should conserve power in as many ways as possible for NM. I'm not sure if g-p-m has power management modes or policies, maybe David can answer that. But if you're really looking to squeeze the most battery life out of your system then presumably you'd use a "Maximize Battery Life" policy which NetworkManager would react to and attempt to conserve as much power as it could in that case. Cheers, ~ Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.5.1 still won't compile on suse 10.0
On Tue, 2005-10-25 at 22:07 +0200, Theetjuh wrote: > NM 0.5.1 requires wireless-tools 2.8pre9 do you have it installed ? > RPM DB indicates wireless-tools-28pre8-16, but I have since built and installed 28.pre10 from source. Maybe I still have a conflict with the RPM version, so I will try removing it and reinstalling the source. > Otherwise including the headers could help, it did for others :) I read this: "Possible fix is to define HEADERS_KERNEL when including iwlib.h (it works, but is it right?)." But since it sounded like a workaround rather than a fix, was expecting a response (never saw it) indicating if it was "her right thing" to do. Is this just suggesting to put "#define HEADERS_KERNEL" right before the #include line? Shane... ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM 0.5.1 still won't compile on suse 10.0
As reported earlier by others, I still get errors compiling 0.5.1 on suse 10.0 (include below). I saw some discussion of workarounds with #define HEADERS_KERNEL but no patch and it seemed like there was some discrepancy if this was the right solution. Anyone managing to get it to compile on suse 10.0 mind reporting their solution? Shane... -- make[3]: Entering directory `/usr/src/NetworkManager-0.5.1/src' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../src/named-manager -I../src/vpn-manager -I../src/dhcp-manager -I../utils -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -DDBUS_VERSION_MAJOR=0 -DDBUS_VERSION_MINOR=35 -DDBUS_VERSION_MICRO=2 -pthread -I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include-DDBUS_API_SUBJECT_TO_CHANGE -DG_DISABLE_DEPRECATED -DBINDIR=\"/usr/local/bin\" -DDATADIR= \"/usr/local/share\" -DSYSCONFDIR=\"/usr/local/etc\" -DARP_DEBUG-g -O2 -MT NetworkManager-NetworkManagerDevice.o -MD -MP -MF ".deps/NetworkManager-NetworkManagerDevice.Tpo" \ -c -o NetworkManager-NetworkManagerDevice.o `test -f 'NetworkManagerDevice.c' || echo './'`NetworkManagerDevice.c; \ then mv -f ".deps/NetworkManager-NetworkManagerDevice.Tpo" ".deps/NetworkManager-NetworkManagerDevice.Po"; \ else rm -f ".deps/NetworkManager-NetworkManagerDevice.Tpo"; exit 1; \ fi In file included from /usr/include/linux/mii.h:12, from NetworkManagerDevice.c:4308: /usr/include/linux/if.h:95: error: redefinition of ‘struct ifmap’ /usr/include/linux/if.h:131: error: redefinition of ‘struct ifreq’ /usr/include/linux/if.h:181: error: redefinition of ‘struct ifconf’ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] gui should reflect the actual state of vpn
Wait, so what is the user experience with this patch? I had thought we were going to move to a more reactive applet and this sounds like a less reactive applet. The reactive applet problem is where you click on a wireless network and it doesn't do anything right away. Presumably it's sent a dbus message to NetworkManager, however we really want the applet to instantly do something different to show that it's going to change. Cheers, ~ Bryan On Thu, 2005-08-25 at 15:38 -0400, Christopher Aillon wrote: > Currently, if the user selects a VPN connection, the GUI immediately > reflects there is a VPN connection active. If the connection then > fails, the composited lock icon goes away. This is bad since it is > confusing to users (it confused me the other day), and doesn't really > reflect the true state of VPN, which also has a (very tiny) risk of DNS > spoofing on a rogue AP. > > The attached patch sends dbus signals from NM to nm-applet letting it > know when the state changes, and removes the pull code from the applet, > which is overall much cleaner IMO. > > May I commit? > > ___ > 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: 2 questions...
On Mon, 2005-07-25 at 20:27 -0400, Derek Atkins wrote: > Colin Walters <[EMAIL PROTECTED]> writes: > > > Seriously, what's the difference to the end user? > > Having to type their password first? > Having to restart gaim or psi or other apps because there's a > race condition between login and network startup? These are apps that could use NM, but don't. Admittedly it's tough to expect the world to start using NetworkManager right away, but hopefully more and more will soon. But I believe the intention is that these apps get patched or fixed to not act this way in the future. As far as the password prompt is concerned, most people won't notice that missing or not. It's really a mystery to most people why and when the computer asks for passwords, thus why Trojan horses and other password stealer's have been successful. While the people that do understand authentication usually can spot these. > > As far as technical implementation I don't see using cached credentials > > to be less "straightforward" than trying to do network configuration > > before login. > > Caching credentials is a HARD problem. How is PAM supposed to > know my kerberos password, unless it stores it somewhere? I don't > want PAM to store my _kerberos_ password. > > Meanwhile, storing network passwords in a place that only root/NM > can get to it? Not so big a deal in my mind. These passwords > don't authenticate me, per se. They just let me on the network. > I still need to use Kerberos, SSH, etc. in order to _do_ anything > on the network. So this is kind of a rat hole of a discussion to get into, but... :-) John Dennis wrote up this bit on ccreds [1] and as he says, "This provides a good trade off between security and practical real world access for mobile users." So this ccreds system provides the kind of user experience we're looking for. And I always say that if a better technical implementation can pass the Turing test on our current user experience then I don't care what changed. The important part to me is the experience, if there's a more secure way of doing things with out crapping all over the fable people I try to defend all day, so be it. :-) Cheers, ~ Bryan [1] http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01038.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 2 questions...
On Mon, 2005-07-25 at 18:15 -0400, Derek Atkins wrote: > I think something like this would work.. But how would one configure the > "available" or "preferred" networks in the nobody context? Provided there is > some way for a user to push this list of networks/keys into the nobody context > I have no objection to it working this way. It's effectively what I wanted, > although I was thinking it would be done by NM itself. > > My personal preference is still to have NM store the data in a root-only > context > and NM-applet can pass the preferred list to NM.. That way NM can still make > decisions based on preferred networks without the applet. Perhaps user can > choose whether to tell NM to save the info in the global context or save it in > the user context? Part of the design of NetworkManager is not having choices about where or how things are stored. NM just does that work and people don't have to think about the context their passwords are stored in. It's actually the more secure method overall, since most people don't understand security at all they tend to make mistakes like entering their passwords for Trojan horses. To avoid this we don't give them any choices when it comes to security. Now this doesn't mean that there isn't room for some kind of NetworkManagerAdmin thing that allows _you_ to do crazy stuff, but it would take some work to design and implement that first. > Honestly... Am I really the only person here that considers laptops > effectively > single-user? It really sounds like you're architecting for a multi-user > laptop > and leaving the single-user laptops in a lurch, having to jump through a bunch > of hoops.. Isn't the network generally a system resource, not a user > resource? I agree that it would be nice to have a switch that let my OS know that it's a single user machine and I wouldn't have to bother with the attributes of multi-user machines. I've pushed for some kind of a system service that would store system settings and information like this. However until that happens I think we have a pretty good solution. ~ Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] redo tray icon.
On Fri, 2005-07-08 at 13:32 +0200, Tomislav Vujec wrote: > Trying to push the issue again. Volume applet is an applet. nm-applet is > a notification icon. Shouldn't we start thinking of either changing the > left-click menu to a dialog or converting nm-applet to a real applet? > The only thing is that with the latter, we'll disable potential KDE > users of the NetworkManager, so I would go with the first option Actually I've been intentionally trying to make no distinction between the two types. There is only the technical distinction that separates these two things right now. Since the nm-applet sits in the notification area instead of appearing and then disappearing like a real notification it is essentially acting as an applet. Some kind of Turing test would show that the nm-applet really thinks it is an applet and could fool any human into thinking that as well. ;-) I'm not so much worried about the GNOME/KDE problem since I imagine KDE people would want to create their own applet type thing using Qt-DBUS so it looks and works better on their desktop. But since it is an notification area icon we happen to get it working in KDE for free. There is some cleanup we need to do with the menus for left and right click ones. I've been working on some design documentation for NetworkManager so we can have a clear idea of how the menus should look and interact. There was some discussion starting about it before [1] but I kind of threw cold water on it since I highly disapprove of UI wanking unless I get to do some technical wanking. Soon we'll have a new web site where we can move all the documentation and notes. And I'm going to start sending out the usage scenarios soon so we can all see what kind of drugs I'm really on. Cheers, ~ Bryan [1] http://mail.gnome.org/archives/networkmanager-list/2005-June/msg00213.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] add remove right-click menu item.
On Thu, 2005-06-23 at 08:13 -0400, David Zeuthen wrote: > I'd suggest to only keep the primary options we'd except modern users to > use [1] in the primary menu: > > NotifIcon > +-+ > | [ ] Wired Network | > |Wireless Networks| > | ben [+-] | > | bk45g[+++---] | > | * davidznet[++] | > | linksys [--] | > | [L] private_net [+++---] | > | --- | > | More Connections> | > | --- | > | Connect To Other Wireless Network... | > | Create A New Wireless Network... | > +-+ > > and secondary items in the "More Connections" sub menu. This is, > perhaps, a little harder for novice users to grasp but they don't really > need these options and if they do (e.g. "Connection Properties") some > help desk will guide them through it through the telephone > > +-+ > | Connection Properties...| # rlove got a patch! take it! > | --- | > | Dial-up Connections > | # <-- doesn't exist yet! > | VPN Connections > | > | --- | > | Stop All Wireless Devices | > | Wireless Network Discovery> | > | --- | > | Share Internet Connection...| # <-- doesn't exist yet! > | Configure Networking Devices... | # <-- doesn't exist yet! > | --- | > | Help... | > | About...| > +-+ I think it's very important that we write this new applet in Scheme, we'll attract new developers (mostly from MIT) and Scheme will give us a simple, robust and more intuitive interface. Plus it will make our applet extensible enough that people can write their own handling code for it. Setting a network profile would be as simple as adding (setq preferred-wireless-network "kingdumb come") to your .nm-applet file. Perhaps we could look at integrating with emacs as well... Cheers, ~ Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] more stetic, broken up, 1/2
On Thu, 2005-06-16 at 21:30 -0400, Robert Love wrote: > Let's break these up into two patches, since I think some of these > changes are not contentious whatsoever. > > This patch: > > - Renames "Other Wireless Networks..." to "Connect to Other > Wireless Network..." > - Renames "Create new Wireless Network..." to "Create New > Wireless Network..." These changes look fine to me. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] more stetic, broken up, 2/2
Hi ~ On Thu, 2005-06-16 at 21:32 -0400, Robert Love wrote: > Meanwhile, this patch includes the following changes: > > - Don't center the "Wireless Networks" menu item. > - Actually make the "Wireless Networks" menu item inactive. > I realize this was done deliberately (with the nasty signal > hack), but the thing /is/ insensitive, unselectable, and a > label, not a menu item. The greyed-out look is in. > - Use gtk_menu_new_with_label(), not the previous complications. So that was definitely done purposefully, here's why. :-) We didn't use a disabled menu item because those are reserved for items that will _eventually_ become enabled. In your menus the items are either enabled, disabled with a possibility of becoming enabled, or not there at all. Since the 'Wireless Networks' item never actually becomes enabled we opted to leave it normal. Opposite is the 'Wired Network' menu which does become enabled when you have a wired connection, and thus we felt a disabled item was perfect for that. To make the Wireless Network item stand out as "something you won't be clicking on", we centered it. The centering also gives a header style look to it that I think works. I didn't pay attention to what was done to make that magic happen in the code, but I definitely think it's better to not make it a disabled menu item. The non-greyed-out look is retro these days and soon will be mainstream, at which point we'll be too cool for it and leave it. > - Consolidate a few seemingly related functions, all called from > the same place once, into one. That sounds cool to me... > - Draw a horizontal separator above the "Wireless Networks" > label. The line I think is a little excessive to add it. It makes the whole menu look very boxy, especially without the other label change. Cheers, ~ Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] making the applet stetic.
> Compare yourself. Current applet: > > http://rlove.org/images/nm-applet-1.jpg > > On the road to being stetic applet: > > http://rlove.org/images/networkmanager-progress-bar-20050615.png > Nice. I like the rearranging of the secure icon. Peace, ~ Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cisco VPN config files converter
On Tue, 2005-05-24 at 12:25 -0400, David Zeuthen wrote: > On Mon, 2005-05-23 at 23:12 +0100, Bastien Nocera wrote: > > Heya, > > > > As I didn't fancy entering all this data by hand in GConf, and that I > > realised I couldn't write Perl to save my life, I wrote this little C > > program to parse .PCF files from the Cisco VPN Client, and feed the data > > into GConf. > > > > As I haven't done quite enough work on making sure the keynames, and > > data that gets in GConf is sane, I didn't make it write to GConf > > directly. If David fancies, I'll integrate this into his VPN properties > > thingo as an import utility. Awesome stuff! > I think that would be great. I think maybe we just want a button "Import > from file..." in this dialog: > > http://people.redhat.com/davidz/nm-vpn-properties.png > > and then the entries would be automatically set? Can we just import them automatically on the first run of this dialog. Do something like: First Run of config dialog - | Would you like to import these| | configurations from Cisco VPN?| | [x] RH Bos | | [x] RH RDU | | [x] RH STU | | [Cancel] [OK] | - Import all checked options The first time you run this dialog, if you've been using Cisco VPN it would be nice to just offer to get all those options back so the person doesn't have to work through anything else. Maybe it even makes more sense to run this dialog from the nm-applet instead of waiting for the person to run the VPN configurations. Perhaps you could then offer the option to "Import Cisco VPN Connections to vpnc" (from the drop-down list of VPNs) give the same import options as above. Just thinking out loud for this part. Cheers, ~ Bryan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fix committed for crashing applet with GTK 2.6
You rock Dan! On Mon, 2005-01-24 at 13:15 -0500, Dan Williams wrote: > FYI: > > A fix for the crasher when selecting "Other Wireless Networks" when > using a GTK 2.6-based system has been committed to CVS. > > Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
