Agreement to relicense NetworkManager under LGPL-2.1+
I, Robert Love, agree to relicense my contributions to NetworkManager as LGPL-2.1+ as proposed by Thomas Haller. Some of my work may be held under copyright by Novell, Inc. I do not speak for that entity. Robert ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: name caching?
On Fri, 2007-01-26 at 06:23 -0500, Neal Becker wrote: I've been using nm with a local named for caching. Works fine, but probably overkill. What is the simplest way to use nm and get some local name caching? nscd, glibc's caching daemon. Robert ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: T-Mobile (and other) support
On Sat, 2006-12-02 at 16:28 -0500, Jim Popovitch wrote: In order to connect to T-Mobile (and presumably some other) 802.1x networks (Not the current tmobile WEP), NM needs to use PAP for the secondary (Inner Auth). I'm presently using NM v0.6.3-2ubuntu6, which doesn't support this. Is there a newer alpha/beta version that does? If not is someone presently investigating this? Finally, if there is no present effort underway, what are some starting points for me to look at implementing this? I'm a competent programmer, but not at all entirely familiar with underpinnings or dbus or gnome. We don't currently support two-phase authentication (inner/outer auth), in the current or unstable version, but we do have it on the plan. It would not be hard to add; wpa_supplicant supports it. We would need to do two things 1. Expand the Enterprise UI to support two-phase auth. This is not hard to implement but hard to get right. This UI is currently a mess and needs work. 2. Expand the DBUS API to do two-phase auth. Probably want to do it in 0.7 first and then consider back-porting it. To do it cleanly we need to break the DBUS API, which isn't acceptable in 0.6. Best, Robert ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [Patch] Mark devices disabled on suse
On Thu, 2006-11-30 at 11:49 +0200, Tambet Ingo wrote: Here's a small patch to mark devices disabled when they're disabled in yast. I have one concern about this...people might have various settings as their STARTMODE from when they used ifup, NetworkManager currently works, and then they upgrade and one of their devices stops working. This is specifically an issue with manual, because some users might have had the wired interface set as auto and the wireless set as manual. Note also we have NM_CONTROLLED as a possible option, to allow users to disable NM for one interface. Your call, though. Robert ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Autoip - icon
On Tue, 2006-11-14 at 09:41 +0100, Martin Vidner wrote: Hey, Martin. How about a small superimposed 1:1 or 2 to hint that this kind of connection is only useful for an ad-hoc connection of two computers? There are also Apple-style networks without a DHCP server (or anything else) where there might be more than two machines. But your fundamental point is spot on: We should somehow show graphical that a Zeroconf IP is in use. Robert ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Starting Network Manager?
On Thu, 2006-10-19 at 13:25 -0400, Christopher Aillon wrote: Given that --sm-disable is for all intents ubiquitous, I wonder whether we ought to make that the default. I suggested this before (we do so in our SUSE package) but it was rejected. I'd be happy to do so--its a one-line change. Robert ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Proposing nm-applet for GNOME 2.18?
On Mon, 2006-10-02 at 14:51 +0200, Vincent Untz wrote: IIRC, there was some interest to propose nm-applet for GNOME 2.18. Is this still the case? If yes, a small mail to d-d-l would be great ;-) Yah, I stirred that up before. I will do it right now. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cannot activate two NIC's at the same time?
On Sat, 2006-09-30 at 15:16 +0200, Erik Wellander wrote: If I want to access two networks at the same time through two different NIC's in my server, what dio I need to do? I'm only able to activate one at the time. We do not support that yet, but we intend to! Right now, we support multiple network interfaces, but only one can be up at a time. Multiple concurrently-up interfaces is a feature slated for our 0.7 development tree. Best, Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Does anyone understand NetworkManager?
On Mon, 2006-08-14 at 11:15 -0400, Dan Williams wrote: IBM T60p laptop builtin wireless. I'm not sure who manufactures that part of the circuit, but it's a Centrino Duo so probably Intel. Likely an ipw2200, ipw2915, or ipw3945, right? Do an 'lsmod | grep ipw' from a terminal and let us know what you find. The T60 has an ipw3945, which is a great chip. Try using the latest version of the driver and firmware. I had issues with earlier versions, but the current stuff is great. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Does anyone understand NetworkManager?
On Mon, 2006-08-14 at 13:28 -0400, David Abrahams wrote: You mean the Windows driver with ndiswrapper around it? Or is there a Linux driver for ipw3945? There is an excellent ipw3945 native Linux driver. See http://ipw3945.sourceforge.net/ and firmware. I have the latest BIOS for this machine, if that's what you mean. No, I mean firmware for the ipw3945. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH RFC] set SSID before launching wpa_supplicant
On Fri, 2006-08-11 at 02:01 -0300, Thiago Bauermann wrote: NM as it is in CVS today cannot always connect to the LEAP network in my work. Sometimes wpa_supplicant is able to associate to the AP, and some times it isn't. I discovered that setting the SSID of the network on the interface before launching wpa_supplicant solves the problem. The patch containing the change is attached. What do you think? Can you apply this? Unfortunately I don't use other wireless networks so I don't know if this has any nasty consequence... Well, it probably does not hurt anything. But we should not need it. What wireless driver do you have? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: boot process and networkManager
On Fri, 2006-08-11 at 13:02 -0400, Brent S. Elmer wrote: When does networkmanager actually set up the network? It seems that the actual network connection and setup is too late in the boot process. I am running openAFS which starts during the end of the boot process. During the openAFS startup, it checks to make sure that it can connect to the afs server. This works fine when not using networkmanager. However, when using networkmanager, it doesn't appear that dns lookup is enabled yet. This is because NM has launched but presumably not yet obtained a network connection, and your distro does not block the boot process until such time. So AFS (or whatever) starts when there is no IP. Ideally, apps would not be so dumb. Instead, we have two choices (1) Launch network-related apps via NM's dispatcher.d, not via init.d. (2) Stick nm-online in NM's init script, after you launch it. This will block the initscript until NM obtains a network connection or N seconds elapse (whatever happens first). I think (1) is ideal, but that requires a bit of work. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: boot process and networkManager
On Fri, 2006-08-11 at 16:19 -0400, Dan Williams wrote: Note that NetworkManager will daemonize and do its work in the background, and therefore you must have some smartness in either (a) the app or (b) the service start scripts for openAFS. You have to wait until NetworkManager says you've got a network connection. There are tools to do this, Robert Love has one somewhere. src/nm-online in CVS. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
HEAD now requires glib 2.10 or later.
On Fri, 2006-08-04 at 10:30 -0400, Dan Williams wrote: If there aren't any objections, why not start using it in HEAD, since 0.7 isn't going to be ready next week or next month. By the time it gets out later this year, I think we can rely on distros that adopt it to have the right versions of glib. Agreed. I converted a bunch of g_malloc/g_new calls to g_slice_new, bumped out glib requirement to 2.10, and checked it into HEAD. Everyone, please test. Also, I found a memory leak in the process. I back-ported that to the 0.6 branch. Enjoy, Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH]: Endian problem in libnm-util
On Fri, 2006-08-04 at 13:59 -0400, Dan Williams wrote: Thanks for finding this; though I think rather than using compile-time flags we should be doing runtime endianness conversions... No architecture we care about (that I know of) has machine types with varying endianness. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
g_slice considered awesome.
Party people,
I did some preliminary testing[1] the other day with beaglefs[2], to
measure the performance gain or hit from using glib's new memory
slices[3].
In a workcase where many objects are created and freed[4], I measured a
sizable performance gain from memory slices over g_malloc. Even without
heavy thread usage of multiprocessors[5]. The glib API manual has this
to say:
For newly written code it is recommended to use the new g_slice
API instead of g_mallc() and friends, as long as objects are not
resized during their lifetime and the object size used at
allocation time is still available when freeing.
Essentially anywhere we use g_new() or g_malloc(sizeof(foo)), we should
switch to g_slice_new() and g_slice_free().
The caveat? Memory slices are only in glib 2.10 and later (2.12 is
current). We currently only require 2.6.
So we have, as I see it, four options:
1. Do nothing. In lieu, burn buildings and riot. Topple cars.
2. Require glib 2.10 or later and move all applicable memory
allocators to the super-cool memory slice API.
3. Put ifdef's in the code, checking for the glib version and
doing the appropriate thing. Cons: Ugly. Pros: Do not have to
introduce our own wrapper.
4. Introduce our own wrapper. Pros: Pretty. Cons: Another
wrapper. As a plus, it can be an inline function in a header,
at least.
I like #4 the most. We can do it in both branches, even. One nice
thing about #4 is that we can make our wrapper mirror the slice API and
we can do a mass find-and-replace and remove it once we do require glib
2.10.
I would be happy doing #2 in HEAD and #4 in the 0.6 branch. What would
others feel about requiring glib 2.10 in HEAD?
#4 would look like the following, in lib/nm-utils.h:
#define nm_alloc_new (__type__) do { \
#if GLIB_CHECK_VERSION(2,10,0)
g_slice_new (__type__); \
# else
g_new (__type__, 1); \
#endif
} while(0)
Assuming the preprocessor bastardization works. But you get the idea.
Comments?
Best,
Robert Half Wolverine Love
[1] Sorry, I don't have the results in a meaningful format. If I find
the time, I will retest and generate presentable data. Even better,
play on your own!
[2] http://www.kernel.org/pub/linux/kernel/people/rml/fuse/beaglefs/
[3] http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slices.html
[4] The freeing being where g_slice shines, as it provides effectively
an uber-smart object cache / free-list.
[5] Another area where memory slices should shine.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Setting access point MAC address?
Pat Suwalski wrote: What seems to happen is that iwconfig shows that it continues hopping even if wpa_supplicant (and NetworkManager for that matter) are not running. So, I think it's the driver. But I don't know that it's consistent across all drivers. Yah, the drivers have issues, whether or not my hunch w.r.t. wpa_supplicant is correct. madwifi, for example, just blows up when it roams. I wonder if locking the BSSID makes sense? It has other benefits, too -- e.g., security. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Setting access point MAC address?
On Thu, 2006-07-20 at 14:36 -0400, Pat Suwalski wrote: Would it make sense for NetworkManager to lock to an access point? I know the real problem is that we have the same ESSID without the bridging you'd expect with that setup, but it's just not usable as it is. I am wondering if wpa_supplicant does dumb things with roaming. We sure have a lot of issues surrounding AP roaming. Does wpa_supplicant consider roaming association loss, and kill the connection? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw3945
Mattias Stahre wrote: Is the ipw3945 even supported in linux? Yes. What you could try with is to use ndiswrapper, and use the windowsdriver to it. I'm using a couple of cards thatway in nm without worries. :) Eh, I would not do this -- Linux drivers are available. On SLED10, ipw3945 and NM work fine out-of-the-box, although there are a few known bugs in the driver. Perhaps try a more recent driver and firmware. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[announce] NetworkManager 0.6.4
I rolled NetworkManager 0.6.4: http://ftp.acc.umu.se/pub/gnome/sources/NetworkManager/0.6/ Since 0.6.3, the only changes have been a crapload of bug fixes, including some good improvements by Dan in the last couple of days. Users of the stable branch are encouraged to upgrade. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [announce] NetworkManager 0.6.4
On Thu, 2006-07-13 at 12:45 -0400, Matthew Saltzman wrote: Please push to FC5 updates-testing. Thanks! I don't work for Red Hat. Please bring this up on a fedora list. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC5 NM/Madwifi roaming loses IP Address
On Tue, 2006-07-11 at 15:05 -0400, Derek Atkins wrote: I'm sitting here in Montréal at the IETF and noticed a really annoying problem. When I wander from one room to another I have to roam from one AP to another, and NM seems to disconnect the network. When I arrive at the other room I have to manually re-select the network and when it comes back up it's forgotten my DHCP lease and gets me a new IP Address. Actually, I think Madwifi has a bug where it cannot roam. Instead of silently roaming to a new AP (a process that does not involve NM), the driver loses association. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC5 NM/Madwifi roaming loses IP Address
On Wed, 2006-07-12 at 12:14 -0400, Derek Atkins wrote: Or even if it's the same ESSID (regardless of whether the BSSID is cached or not)? If I walk across the IETF floor quickly it's possible that my ultimate destination might not be a BSSID that was in range at the beginning of the session, so the BSSID might not be cached. Or I might never have been in that room before. Indeed, as a /user/ I should never have to worry about the BSSID sitting under the ESSID (except, perhaps, in the case where there's an (a) vs. (b/g) network difference). But this wouldn't be a problem if roaming worked ... Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM Drops Connections
On Tue, 2006-07-04 at 12:03 -0400, jim lawrence wrote: Updated to kernel 2.6.17-1.2139_FC5 have NetowrkManager version NetworkManager-0.6.3-1.fc5 Updated the Firmware to 3.0 cuz the 2.4 would not work with the newer kernel. What network card? I have a dump from /var/log/messages if needed where it shows all is well and a hour later drops the connection. I then have to add my AP again. How repeatable / reproducible? Please attach the log. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Early timeouts connecting to unencrypted network with ndiswrapper on FC5
On Thu, 2006-06-22 at 10:53 -0400, Dan Williams wrote: If drivers were better, and we could trust their strength information (which we can't), we'd likely even remove APs from the scan list if their strength was 15% or something like that. Anything below that and you're pretty much screwed. We are almost to the point, though, where we can trust strength values, no? I think Orinoco does strength with the latest driver, no? And madwifi has bogus strength, but I have a patch to fix that (special cases the driver, though). Would be nice to remove, as you say, low scoring AP's. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-edit (was: Re: [3/3] Do something with trusted networks)
On Thu, 2006-06-15 at 15:54 -0400, Pat Suwalski wrote: I've decided to take you up on this. If nothing else, so that I can mooch BEvERages off of you at OLS (you're coming for the kernel summit, I take it?). :) I actually don't know yet. It is a sore point. If I am in Ottawa, we drink! I started a very simple gtk-glade project, just about a 100-lines of code. It can currently connect to the keyring, retrieve the known access points, write back, and delete. Super-simple, it's all functions and no interface at the moment. Nice. Before I get too far on the interface, I want to solidify some things. First, only WEP keys are actually stored in human-readable form (the way the user entered them). So, I can't think of a nice way to let users handle something like WPA-PSK, unless nm-applet also stored the original passphrase in the keyring. Not sure what you mean here. Both WEP keys and WPA passphrases should be stored in the keyring, today. Next up, do we want people to be able to add a Network? If so, the nicest implementation (with the least amount of duplicated code) would be to have nm-applet listen to a dbus message asking it to pop up the add network dialog. For now, I'd ignore this. This is really easy to do. My program can do this already. In theory, you delete a network and when you select it in nm-applet it doesn't know anything about it and asks for a new key or whatever. Excellent. However, more functionality will be a big plus for 802.1x/certificates. Perhaps something that can even interface a little with Seahorse for certificate management down the road. Whatever we decide here, it's largely a learning experience for me using libglade and gnome-keyring, and maybe some dbus. If you come up with a nice UI for editing WPA Enterprise, we should put that in the applet. The current UI is pretty heavy -- but so are the number of WPA-EAP options. Is this bad boy in C? I don't see any reason not to stick it in CVS, under gnome/editor or similar. Dan? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-edit
On Fri, 2006-06-16 at 02:34 -0400, Pat Suwalski wrote: Unfortunately, I don't see wpa passphrases stored. I see the output of what the supplicant's wpa_passphrase would output, a rather long hex key. Oh, sorry. I thought you meant nothing was stored in the keyring. Correct, we only stored the encoded form of the key, so editing is not possible. We could look at changing that, but for now run with it as it is. So, if Billy entered dog into nm-applet, they wouldn't see that. I guess in this case, the GUI wouldn't show anything, would just have an option to change it. Nod. I actually think the current dialog isn't too bad. It has widgets for all of the details. The only thing that would make senses is to space the widgets based on logical groupings -- the order of the widgets already hints at this. But that might just make it more confusing. The Windows applet has all of the information spread over several tabs, IIRC, so I think this is better as is. I'll think about it. Yah, given the mess of information, the current dialog is not half bad. One big thing is that it does not enforce sane configurations. Is this bad boy in C? I don't see any reason not to stick it in CVS, under gnome/editor or similar. Dan? The boy's not so bad yet, but, yes, it is C. I don't grok python. And I just the existence of libnm-util and libnm-glib, which probably have all sorts of useful functions. Three cheers for obliviousness. I'll try making it a little more useful before seeking a home for the code. Do you think this should build off of the NetworkManager/gnome subdirectory like vpn-properties or have its own autotooled structure? I think it should build in gnome/editor just like the applet builds in gnome/applet, personally. There is already a WITH_GNOME option for building stuff in that directory. I think we want to integrate the editor and the applet tightly, but keep them separate processes. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: cvs commit policy?
And over to my question, should i commit fixes to the distribution specific code in both branches? Or will these branches be merged at specific times? (I guess that you do multiple commits and don't merge MAIN and release branches.) Dan or I will probably never manually merge your disto-specific commits. If your commit is appropriate for the stable branch, by all means commit there, too. But keep in mind that the branch is indeed stable ... Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [3/3] Do something with trusted networks
On Thu, 2006-06-08 at 10:17 -0400, Dan Williams wrote: My initial thought was that it violated spec, but I decided to do some checking. It appears that SSID-BSSID mappings are a gray area of the spec, and that there are products that do multiple SSID on a single BSSID. The catch is that you can only have one SSID be a broadcast SSID in this scheme, the rest _must_ be hidden. That right there is a nice, fat, bright red warning flag, as are notes about the downside is less client compatibility... Furthermore, broadcast traffic is somewhat undefined in this scenario, and other information leakage between SSIDs is also possible because they are sharing the same BSSID. This is ludicrous. The spec actually mentions hidden networks? And a spec actually says the downside is less client compatibility? How does broadcast traffic work? If a network is hidden but shares the MAC of a non-hidden network, how on Earth is anything supposed to ever differentiate it? I have a multiple-SSID-in-single-box AP, but it gives different BSSID's to each network. Seems easy enough. So here's a thought (started out as two different options, but this one is clearly better): So, you are really arguing here for two points, right? The first is that we should change the merge-AP-into-existing-list code in NetworkManagerAPList.c to not just coalesce AP X and Y if their BSSID matches, but also check if their security (or some other attribute) matches? Isn't the main point of the coalescing code detecting changes in a given AP? Where you add X to the scan list and X is really Y, which is already in the list? In other words, why have the merging code at all for BSSIDs? Just keep the merge code for ESSIDs. The BSSID - ESSID mapping happens elsewhere, so we should be able to ditch the merging code and still do the mapping (which I agree we 100% want to do) bit. The second point you offer is moving from ESSID to UID-based object paths. I'm not against this -- not having to escape the network names would prove nice -- but this will prove a bit of work. And the UID will probably end up containing an escaped ESSID. ;-) But its probably worth it, because we DO have a problem (ignoring this absurdity) with different networks sharing an ESSID. We probably need to face the facts that the only proper identifier for an AP is its unique (ESSID,BSSID) pair. Not one or the other, but both. This is a problem, though, because we also have a concept of network which is really a set of one or more AP's, and thus we have a list of BSSIDs... We mix these paradigms at times. We store networks, but you connect to AP's. Etc. In short, I have words for whoever wrote the wireless spec. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [announce] NetworkManager 0.6.3
On Thu, 2006-06-08 at 17:45 +0200, Michael Biebl wrote: Just noticed that the Remove option from nm-applets' context menu has been removed. Is that intentional? I found it quite handy to be able to stop the applet via a nice gui an not via kill on the command line. Yes, it was removed awhile back. Users found it confusing and it offered little gain. Sorry that you liked it! Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [3/3] Do something with trusted networks
On Thu, 2006-06-08 at 13:30 -0400, Derek Atkins wrote: I would ask that you also add 802.11 mode to this mix.. In particular separating 802.11(a) from 802.11(b/g) would be a GOOD THING. Good point. It is definitely not a spec violation to mix ESSID or BSSID on 11a and 11b/g. Although I'd still punch a vendor for reusing the same BSSID. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: N-M doesn't work without gnome keyring?
On Thu, 2006-06-08 at 12:20 -0500, Paul Johnson wrote: Perhaps the NetworkManager RPM should have a pre-requisite of gnome-keyring-manager. It should. But this is a Fedora issue. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
fallback support is checked into HEAD.
fallback support is in HEAD. Enjoy! You can mark a network as fallback via other-network-dialog or the tool nm-set-fallback. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[1/3] Do something with trusted networks
Currently we have the concept of trusted versus preferred networks, but
we do not act on the trusted attribute. We have some minimal support in
the daemon for marking a network as trusted, but we do nothing with that
information and the applet is totally trusted-unaware. Also, most of
the DBUS API's are not trusted-aware.
The following three patches do the following three things:
- This one, the first, starts using the trusted bit everywhere,
saving it in gconf, passing it around, adding it to the
missing DBUS APIs, and so on. The net effect on behavior is
zero because still nothing sets it. Since this is basically
a clean up to support an existing feature, with no behavioral
changes, we can commit this regardless of the direction we
go with the next two patches.
- The second adds UI for setting networks trusted.
- The third adds behavioral and policy changes for trusted
networks. This is an open item of discussion.
So here is the first one. This patch makes both the applet and daemon
respect and preserve the trusted attribute on networks. Right now that
support is only half there. Since nothing actually sets the trusted bit
true, this is merely a cleanup, the net effect is null.
All of these are against the STABLE 0.6 branch but also apply to HEAD.
You will want to `cvs up` as of now, because I just committed some bug
fixes.
Robert Love
Index: gnome/applet/applet-dbus-devices.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet-dbus-devices.c,v
retrieving revision 1.51.2.4
diff -u -r1.51.2.4 applet-dbus-devices.c
--- gnome/applet/applet-dbus-devices.c 17 May 2006 20:03:56 - 1.51.2.4
+++ gnome/applet/applet-dbus-devices.c 7 Jun 2006 17:08:53 -
@@ -1253,7 +1253,7 @@
*
*/
void nma_dbus_set_device (DBusConnection *connection, NetworkDevice *dev, const char *essid,
- WirelessSecurityOption * opt)
+ gboolean trusted, WirelessSecurityOption * opt)
{
DBusMessage * message;
gboolean success = TRUE;
@@ -1272,6 +1272,7 @@
/* Build up the required args */
dbus_message_append_args (message, DBUS_TYPE_OBJECT_PATH, dev_path,
DBUS_TYPE_STRING, essid,
+ DBUS_TYPE_BOOLEAN, trusted,
DBUS_TYPE_INVALID);
/* If we have specific wireless security options, add them */
Index: gnome/applet/applet-dbus-devices.h
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet-dbus-devices.h,v
retrieving revision 1.11
diff -u -r1.11 applet-dbus-devices.h
--- gnome/applet/applet-dbus-devices.h 27 Feb 2006 06:26:31 - 1.11
+++ gnome/applet/applet-dbus-devices.h 7 Jun 2006 17:08:53 -
@@ -49,7 +49,7 @@
void nma_dbus_device_update_one_network (NMApplet *applet, const char *dev_path, const char *net_path, const char *active_net_path);
void nma_dbus_device_remove_one_network (NMApplet *applet, const char *dev_path, const char *net_path);
void nma_dbus_update_strength(NMApplet *applet, const char *dev_path, const char *net_path, int strength);
-void nma_dbus_set_device (DBusConnection *connection, NetworkDevice *dev, const char *essid, WirelessSecurityOption *opt);
+void nma_dbus_set_device (DBusConnection *connection, NetworkDevice *dev, const char *essid, gboolean trusted, WirelessSecurityOption *opt);
void nma_dbus_create_network (DBusConnection *connection, NetworkDevice *dev, const char *essid, WirelessSecurityOption *opt);
void nma_free_data_model (NMApplet *applet);
Index: gnome/applet/applet-dbus-info.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet-dbus-info.c,v
retrieving revision 1.45.2.3
diff -u -r1.45.2.3 applet-dbus-info.c
--- gnome/applet/applet-dbus-info.c 17 May 2006 14:57:04 - 1.45.2.3
+++ gnome/applet/applet-dbus-info.c 7 Jun 2006 17:08:54 -
@@ -822,6 +822,7 @@
nmi_save_network_info (NMApplet *applet,
const char *essid,
gboolean automatic,
+ gboolean trusted,
const char *bssid,
NMGConfWSO * gconf_wso)
{
@@ -860,6 +861,10 @@
g_free (key);
}
+ key = g_strdup_printf (%s/%s/trusted, GCONF_PATH_WIRELESS_NETWORKS, escaped_network);
+ gconf_client_set_bool (applet-gconf_client, key, trusted, NULL);
+ g_free (key);
+
if (bssid (strlen (bssid) = 11))
{
GConfValue * value;
@@ -958,6 +963,7 @@
NMApplet * applet = (NMApplet *) user_data;
char * essid = NULL;
gboolean automatic;
+ gboolean trusted;
NMGConfWSO * gconf_wso = NULL;
DBusMessageIter iter;
char * bssid;
@@ -988,7 +994,15 @@
}
dbus_message_iter_get_basic (iter, automatic);
- /* Third argument: Access point's BSSID */
+ /* Third argument: Trusted (BOOLEAN
[2/3] Do something with trusted networks
Two things here. First is a patch adding a UI widget, a checkbox labeled Trusted Network, to the Connect to Other Networks dialog. By default unchecked, checking the box will mark the network as trusted. Also attached is a simple utility for marking/unmarking an existing network as trusted. Use is simple: $ ./nm-set-trusted network true|false Yes, we need a wireless networks editor. I agree with you all. Robert Love nm-set-trusted Description: application/shellscript Index: gnome/applet/applet.glade === RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet.glade,v retrieving revision 1.4.2.8 diff -u -r1.4.2.8 applet.glade --- gnome/applet/applet.glade 29 May 2006 03:35:15 - 1.4.2.8 +++ gnome/applet/applet.glade 7 Jun 2006 17:14:18 - @@ -426,7 +426,7 @@ child widget class=GtkTable id=table1 property name=visibleTrue/property - property name=n_rows4/property + property name=n_rows5/property property name=n_columns2/property property name=homogeneousFalse/property property name=row_spacing6/property @@ -548,8 +548,8 @@ packing property name=left_attach0/property property name=right_attach1/property - property name=top_attach2/property - property name=bottom_attach3/property + property name=top_attach3/property + property name=bottom_attach4/property property name=x_optionsfill/property property name=y_options/property /packing @@ -569,8 +569,8 @@ packing property name=left_attach1/property property name=right_attach2/property - property name=top_attach2/property - property name=bottom_attach3/property + property name=top_attach3/property + property name=bottom_attach4/property property name=x_optionsfill/property property name=y_optionsfill/property /packing @@ -589,9 +589,31 @@ packing property name=left_attach0/property property name=right_attach2/property - property name=top_attach3/property - property name=bottom_attach4/property + property name=top_attach4/property + property name=bottom_attach5/property + property name=x_optionsfill/property + /packing + /child + + child + widget class=GtkCheckButton id=trusted_button + property name=visibleTrue/property + property name=can_focusTrue/property + property name=label translatable=yes_Trusted Network/property + property name=use_underlineTrue/property + property name=reliefGTK_RELIEF_NORMAL/property + property name=focus_on_clickTrue/property + property name=activeFalse/property + property name=inconsistentFalse/property + property name=draw_indicatorTrue/property + /widget + packing + property name=left_attach1/property + property name=right_attach2/property + property name=top_attach2/property + property name=bottom_attach3/property property name=x_optionsfill/property + property name=y_options/property /packing /child /widget Index: gnome/applet/other-network-dialog.c === RCS file: /cvs/gnome/NetworkManager/gnome/applet/other-network-dialog.c,v retrieving revision 1.29.2.1 diff -u -r1.29.2.1 other-network-dialog.c --- gnome/applet/other-network-dialog.c 27 Mar 2006 16:02:10 - 1.29.2.1 +++ gnome/applet/other-network-dialog.c 7 Jun 2006 17:14:18 - @@ -410,19 +410,24 @@ WirelessSecurityOption * opt; GtkComboBox * security_combo; GtkTreeIter iter; + GtkWidget * trusted_button; char *str; NetworkDevice * dev; + gbooleantrusted; gtk_combo_box_get_active_iter (GTK_COMBO_BOX (combo), iter); gtk_tree_model_get (model, iter, NAME_COLUMN, str, DEV_COLUMN, dev, -1); + trusted_button = glade_xml_get_widget (xml, trusted_button); + trusted = gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (trusted_button)); + security_combo = GTK_COMBO_BOX (glade_xml_get_widget (xml, security_combo)); opt = wsm_get_option_for_active (wsm, security_combo); if (create_network) nma_dbus_create_network (applet-connection, dev, essid, opt); else -nma_dbus_set_device (applet-connection, dev, essid, FALSE, opt); +nma_dbus_set_device (applet-connection, dev, essid, trusted, opt); } } ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[3/3] Do something with trusted networks
And here is policy and behavioral changes for the daemon to do something
with trusted networks.
Two such changes:
First, given no better options and a disconnected state, NM will now try
to blindly connect to trusted networks, round robin. The idea being
that if your card is shitty or the network is hidden, you might not see
the network. Also, on boot, NM does not have the network MAC addresses
and won't see any hidden networks.
Second, trusted networks now persist in the scan list, even if NM does
not see them. Like bookmarks or favorites. This is useful if your card
is broken and cannot scan, if your card is broken and does not return
hidden networks, or if your network is hidden and you don't know all of
the MAC addresses.
What we do here is debatable. This is one such solution.
Robert Love
Index: src/NetworkManagerAPList.c
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerAPList.c,v
retrieving revision 1.51.2.2
diff -u -r1.51.2.2 NetworkManagerAPList.c
--- src/NetworkManagerAPList.c 20 Apr 2006 20:39:52 - 1.51.2.2
+++ src/NetworkManagerAPList.c 7 Jun 2006 17:18:47 -
@@ -422,6 +422,56 @@
return (found_ap);
}
+/*
+ * nm_ap_list_merge_trusted
+ *
+ * Merges the user's trusted networks, if any, into the scan list. We treat these networks
+ * as persistent, always in the scan and allowed list regardless of their presence in a scan.
+ */
+void nm_ap_list_merge_trusted (NMDevice80211Wireless *dev)
+{
+ NMAccessPointList * allowed_list;
+ NMAccessPointList * scan_list;
+ NMAPListIter * iter;
+ NMData * app_data;
+
+ app_data = nm_device_get_app_data (NM_DEVICE (dev));
+ allowed_list = app_data-allowed_ap_list;
+ scan_list = nm_device_802_11_wireless_ap_list_get (dev);
+
+ iter = nm_ap_list_iter_new (allowed_list);
+ if (iter)
+ {
+ NMAccessPoint * allowed_ap;
+
+ while ((allowed_ap = nm_ap_list_iter_next (iter)))
+ {
+ if (nm_ap_get_trusted (allowed_ap))
+ {
+NMAccessPoint * ap;
+GTimeVal cur_time;
+
+ap = nm_ap_new ();
+nm_ap_set_essid (ap, nm_ap_get_essid (allowed_ap));
+nm_ap_set_timestamp_via_timestamp (ap, nm_ap_get_timestamp (allowed_ap));
+nm_ap_set_trusted (ap, TRUE);
+nm_ap_set_security (ap, nm_ap_get_security (allowed_ap));
+
+/*
+ * Fake it as if we see the AP right now. We process the scan results _after_ this, thus
+ * if the AP is seen in a scan we will favor that AP when we merge.
+ */
+g_get_current_time (cur_time);
+nm_ap_set_last_seen (ap, cur_time);
+nm_ap_set_artificial (ap, TRUE);
+
+nm_ap_list_merge_scanned_ap (dev, scan_list, ap);
+nm_ap_unref (ap);
+ }
+ }
+ nm_ap_list_iter_free (iter);
+ }
+}
/*
* nm_ap_list_merge_scanned_ap
Index: src/NetworkManagerAPList.h
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerAPList.h,v
retrieving revision 1.15.2.1
diff -u -r1.15.2.1 NetworkManagerAPList.h
--- src/NetworkManagerAPList.h 20 Apr 2006 20:39:52 - 1.15.2.1
+++ src/NetworkManagerAPList.h 7 Jun 2006 17:18:47 -
@@ -51,6 +51,8 @@
voidnm_ap_list_copy_essids_by_address (NMData *app_data, NMDevice80211Wireless *dev, NMAccessPointList *dest, NMAccessPointList *source);
voidnm_ap_list_copy_one_essid_by_address (NMData *app_data, NMDevice80211Wireless *dev, NMAccessPoint *ap, NMAccessPointList *search_list);
+voidnm_ap_list_merge_trusted (NMDevice80211Wireless *dev);
+
gboolean nm_ap_list_merge_scanned_ap (NMDevice80211Wireless *dev, NMAccessPointList *list, NMAccessPoint *merge_ap);
NMNetworkType nm_ap_list_get_type(NMAccessPointList *list);
Index: src/nm-device-802-11-wireless.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-device-802-11-wireless.c,v
retrieving revision 1.60.2.11
diff -u -r1.60.2.11 nm-device-802-11-wireless.c
--- src/nm-device-802-11-wireless.c 2 Jun 2006 20:00:49 - 1.60.2.11
+++ src/nm-device-802-11-wireless.c 7 Jun 2006 17:18:48 -
@@ -675,8 +675,10 @@
NMActRequest * req = NULL;
NMAccessPoint * trusted_best_ap = NULL;
NMAccessPoint * untrusted_best_ap = NULL;
+ NMAccessPoint * blind_best_ap = NULL;
GTimeVal trusted_latest_timestamp = {0, 0};
GTimeVal untrusted_latest_timestamp = {0, 0};
+ GTimeVal blind_latest_timestamp = {0, 0};
NMData * app_data;
g_return_val_if_fail (self != NULL, NULL);
@@ -762,27 +764,68 @@
}
}
-g_slist_foreach (user_addrs, (GFunc)g_free, NULL);
+g_slist_foreach (user_addrs, (GFunc) g_free, NULL);
g_slist_free (user_addrs);
}
- if (!blacklisted nm_ap_get_trusted (tmp_ap) (curtime-tv_sec trusted_latest_timestamp.tv_sec))
- {
-trusted_latest_timestamp = *nm_ap_get_timestamp (tmp_ap);
-trusted_best_ap = scan_ap;
-nm_ap_set_security (trusted_best_ap, nm_ap_get_security (tmp_ap));
- }
- else if (!blacklisted
Re: [3/3] Do something with trusted networks
On Wed, 2006-06-07 at 14:26 -0400, Darren Albers wrote: Great work! Thanks! So I just had a little talk with Dan (sorry it was off-list) and I think we are going to go with these patches, with the following changes: - Rename trusted to fallback - Don't persist fallback networks in the scan list, but do perform the fall-back brute-force thingy. And then...PROFIT. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
fallback functionality with persistence.
So I am redoing the patches for CVS. We are ditching the trusted
network stuff -- we have no good use for it -- and renaming it to
fallback.
We will add the fallback behavior to CVS, but not the
persistence-in-the-scan-list.
The attached patch does all of this, and is ready to commit, except it
still does the persistence thing.
This is because it is EASIER to do the persistence than not (everything
is sort-of free if we just fake a scan result).
So I need to come up with an elegant way to ditch the persistence but
keep the fallback behavior.
For now, here is a reworked single patch of the previous three.
Robert Love
Index: gnome/applet/applet-dbus-devices.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet-dbus-devices.c,v
retrieving revision 1.51.2.4
diff -u -r1.51.2.4 applet-dbus-devices.c
--- gnome/applet/applet-dbus-devices.c 17 May 2006 20:03:56 - 1.51.2.4
+++ gnome/applet/applet-dbus-devices.c 7 Jun 2006 19:53:49 -
@@ -1253,7 +1253,7 @@
*
*/
void nma_dbus_set_device (DBusConnection *connection, NetworkDevice *dev, const char *essid,
- WirelessSecurityOption * opt)
+ gboolean fallback, WirelessSecurityOption * opt)
{
DBusMessage * message;
gboolean success = TRUE;
@@ -1272,6 +1272,7 @@
/* Build up the required args */
dbus_message_append_args (message, DBUS_TYPE_OBJECT_PATH, dev_path,
DBUS_TYPE_STRING, essid,
+ DBUS_TYPE_BOOLEAN, fallback,
DBUS_TYPE_INVALID);
/* If we have specific wireless security options, add them */
Index: gnome/applet/applet-dbus-devices.h
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet-dbus-devices.h,v
retrieving revision 1.11
diff -u -r1.11 applet-dbus-devices.h
--- gnome/applet/applet-dbus-devices.h 27 Feb 2006 06:26:31 - 1.11
+++ gnome/applet/applet-dbus-devices.h 7 Jun 2006 19:53:49 -
@@ -49,7 +49,7 @@
void nma_dbus_device_update_one_network (NMApplet *applet, const char *dev_path, const char *net_path, const char *active_net_path);
void nma_dbus_device_remove_one_network (NMApplet *applet, const char *dev_path, const char *net_path);
void nma_dbus_update_strength(NMApplet *applet, const char *dev_path, const char *net_path, int strength);
-void nma_dbus_set_device (DBusConnection *connection, NetworkDevice *dev, const char *essid, WirelessSecurityOption *opt);
+void nma_dbus_set_device (DBusConnection *connection, NetworkDevice *dev, const char *essid, gboolean fallback, WirelessSecurityOption *opt);
void nma_dbus_create_network (DBusConnection *connection, NetworkDevice *dev, const char *essid, WirelessSecurityOption *opt);
void nma_free_data_model (NMApplet *applet);
Index: gnome/applet/applet-dbus-info.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet-dbus-info.c,v
retrieving revision 1.45.2.4
diff -u -r1.45.2.4 applet-dbus-info.c
--- gnome/applet/applet-dbus-info.c 7 Jun 2006 17:34:20 - 1.45.2.4
+++ gnome/applet/applet-dbus-info.c 7 Jun 2006 19:53:49 -
@@ -395,7 +395,7 @@
char * escaped_network = NULL;
char * essid = NULL;
ginttimestamp = -1;
- gboolean trusted = FALSE;
+ gboolean fallback = FALSE;
DBusMessageIter iter, array_iter;
GConfClient * client;
NMGConfWSO * gconf_wso;
@@ -435,9 +435,9 @@
if (!nm_gconf_get_int_helper (client, GCONF_PATH_WIRELESS_NETWORKS, timestamp, escaped_network, timestamp) || (timestamp 0))
timestamp = 0;
- /* Trusted status */
- if (!nm_gconf_get_bool_helper (client, GCONF_PATH_WIRELESS_NETWORKS, trusted, escaped_network, trusted))
- trusted = FALSE;
+ /* Fallback status */
+ if (!nm_gconf_get_bool_helper (client, GCONF_PATH_WIRELESS_NETWORKS, fallback, escaped_network, fallback))
+ fallback = FALSE;
/* Grab the list of stored access point BSSIDs */
gconf_key = g_strdup_printf (%s/%s/bssids, GCONF_PATH_WIRELESS_NETWORKS, escaped_network);
@@ -468,8 +468,8 @@
/* Second arg: Timestamp (INT32) */
dbus_message_iter_append_basic (iter, DBUS_TYPE_INT32, timestamp);
- /* Third arg: Trusted (BOOLEAN) */
- dbus_message_iter_append_basic (iter, DBUS_TYPE_BOOLEAN, trusted);
+ /* Third arg: Fallback? (BOOLEAN) */
+ dbus_message_iter_append_basic (iter, DBUS_TYPE_BOOLEAN, fallback);
/* Fourth arg: List of AP BSSIDs (ARRAY, STRING) */
dbus_message_iter_open_container (iter, DBUS_TYPE_ARRAY, DBUS_TYPE_STRING_AS_STRING, array_iter);
@@ -818,6 +818,7 @@
nmi_save_network_info (NMApplet *applet,
const char *essid,
gboolean automatic,
+ gboolean fallback,
const char *bssid,
NMGConfWSO * gconf_wso)
{
@@ -856,6 +857,10 @@
g_free (key);
}
+ key = g_strdup_printf (%s/%s/fallback, GCONF_PATH_WIRELESS_NETWORKS
[announce] NetworkManager 0.6.3
Dan I are happy to announce the release of NetworkManager 0.6.3. You can grab a tarball from GNOME (needs another minute or two to sync): http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.6/ Or check out the NETWORKMANAGER_0_6_3_RELEASE tag from CVS. There are a ton of bug fixes since 0.6.2. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [3/3] Do something with trusted networks
Jens Lautenbacher wrote: Please, reconsider the decision to not shown the trusted networks in an easily accessible list... this would help so much here :-) The old behavior (as of the last patch I posted) would not have solved this, either. Are you saying you have two wireless networks, with two different ESSID's, but sharing one BSSID? That violates the wireless spec, I am 99% sure. Who makes the access point? The reason NM chokes on it is that we have logic to merge two AP objects into one if they share the same BSSID. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [3/3] Do something with trusted networks
Jens Lautenbacher wrote: The old behavior (as of the last patch I posted) would not have solved this, either. Why? The internal network would have been marked as trusted, and would always be displayed, so I can select it to try to connect to the AP. Heh, I wrote the code, I know. ;-) Because of the merge BSSID stuff, we will take the fallback network and merge it into the scanned networks (which are merged into one). We want to merge fallbacks and the scan, for myriad reasons. Sad. All the windows laptops have no problem with this situation... By the way, you didn't say anything to the idea to at least display all fallback networks as a drop-down/select-menu in the connect dialog so I don't have to enter the same information over and over again... Could this be possible? Well I suppose we could just list all of the stored networks, not just the fallback. But that seems useful in very few cases. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: nm-applet asks several times for keyring password
On Tue, 2006-05-30 at 18:02 +0200, Rémi Cardona wrote: Filed it as bug #343404 : http://bugzilla.gnome.org/show_bug.cgi?id=343404 I believe that this bug is now fixed in CVS, in which case this bug is a dupe of #341297. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet asks several times for keyring password
On Tue, 2006-05-30 at 16:09 -0400, Dan Williams wrote: Robert, we should probably look at rolling a 0.6.3, just for kicks :) Sound like a plan? Yup, definitely. PS - One possibly painful thing I'd like to do with 0.6.x though is not change the VPN dbus API anymore... which means all new stuff goes to HEAD, or gets vendor-patched instead. I agree. I'd like to lock all API, though -- NMI, too. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet asks several times for keyring password
On Tue, 2006-05-30 at 16:49 -0400, Jon Nettleton wrote: Was the fix a work a round for the way gnome-keyring was behaving, or an actual problem with the way the NetworkManager code was using libgnome-keyring? I am curious because if it is something that can be cleaned up in gnome-keyring I would like to fix it asap. Both, really. NetworkManager could have been smarter about what it was doing, but GNOME keyring really should not pop up more than one dialog. The real kicker is if two apps both unlock the keyring, you get two dialogs. Luckily, we have a patch for the latter issue, too: See Joe Shaw's patch at http://bugzilla.gnome.org/show_bug.cgi?id=331003 Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 802.1x wep?
Morgan Read wrote: - Nothing, my point. Worry not, the TODO list is not even remotely all-inclusive. And it is mostly architectural changes. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 802.1x wep?
Morgan Read wrote: No, NetworkManager does not do 802.1x authentication with wep. Nor does it look like it ever will from the NetworkManagerToDo page: http://live.gnome.org/NetworkManagerToDo I am unsure what on this page leads you to believe that NM will never support 802.1X, but that is untrue. We want it. I do not have a time table, but it is certainly on the list -- if you write a patch tomorrow, we'd merge it! Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem compiling CVS
On Wed, 2006-05-17 at 16:18 -0500, Steev Klimaszewski wrote: This is what I am getting when attempting to compile cvs Partial check-in of something? nm-device-802-11-wireless.c: In function ‘nm_device_802_11_wireless_update_bssid’: nm-device-802-11-wireless.c:159: error: ‘NMDevice80211WirelessPrivate’ has no member named ‘scan_mutex’ nm-device-802-11-wireless.c:196: error: ‘NMDevice80211WirelessPrivate’ has no member named ‘scan_mutex’ Whoops. I checked in the STABLE patch on HEAD. Fixed, now. Thanks, Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager CVS detects bcm43xx as wired
On Mon, 2006-05-15 at 19:17 +0100, Steven Cote wrote: It does say that it is a wireless card, here's the relevenat output that I get: Actually, it doesn't, in the standardized manner NM expects it: net.80211 set in info.category. But I don't see net.8023 set, either, which is odd. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[patch] my latest wireless drivers workaround patch.
Here it is. A bunch of crap we sadly should never need but
unfortunately do.
Robert Love
Index: src/nm-device-802-11-wireless.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-device-802-11-wireless.c,v
retrieving revision 1.60.2.5
diff -u -r1.60.2.5 nm-device-802-11-wireless.c
--- src/nm-device-802-11-wireless.c 27 Mar 2006 16:11:53 - 1.60.2.5
+++ src/nm-device-802-11-wireless.c 20 Apr 2006 16:06:48 -
@@ -214,22 +214,13 @@
if ((data_len = minlen) range-we_version_compiled = 18)
{
- if (range-enc_capa IW_ENC_CAPA_WPA)
- {
caps |= (NM_802_11_CAP_PROTO_WPA
| NM_802_11_CAP_KEY_MGMT_PSK
| NM_802_11_CAP_KEY_MGMT_802_1X);
- }
- if (range-enc_capa IW_ENC_CAPA_WPA2)
- {
caps |= (NM_802_11_CAP_PROTO_WPA2
| NM_802_11_CAP_KEY_MGMT_PSK
| NM_802_11_CAP_KEY_MGMT_802_1X);
- }
-
- if (range-enc_capa IW_ENC_CAPA_CIPHER_TKIP)
caps |= NM_802_11_CAP_CIPHER_TKIP;
- if (range-enc_capa IW_ENC_CAPA_CIPHER_CCMP)
caps |= NM_802_11_CAP_CIPHER_CCMP;
}
@@ -1829,23 +1820,21 @@
int orig_rate = 0;
struct iwreq wrq;
+ /* Must be in infrastructure mode during scan, otherwise we don't get a full
+ * list of scan results. Scanning doesn't work well in Ad-Hoc mode :(
+ *
+ * We only set the mode and unlock the frequency if the card is in adhoc mode,
+ * in case doing so is a costly operation for the driver or the driver prefers
+ * IW_MODE_AUTO.
+ */
orig_mode = nm_device_802_11_wireless_get_mode (self);
if (orig_mode == IW_MODE_ADHOC)
{
orig_freq = nm_device_802_11_wireless_get_frequency (self);
orig_rate = nm_device_802_11_wireless_get_bitrate (self);
- }
-
- /* Must be in infrastructure mode during scan, otherwise we don't get a full
- * list of scan results. Scanning doesn't work well in Ad-Hoc mode :(
- */
- nm_device_802_11_wireless_set_mode (self, IW_MODE_INFRA);
-
- /* We only unlock the frequency if the card is in adhoc mode, in case it is
- * a costly operation for the driver.
- */
- if (orig_mode == IW_MODE_ADHOC)
+nm_device_802_11_wireless_set_mode (self, IW_MODE_INFRA);
nm_device_802_11_wireless_set_frequency (self, 0);
+ }
wrq.u.data.pointer = NULL;
wrq.u.data.flags = 0;
@@ -2253,13 +2242,11 @@
}
-#define NM_SUPPLICANT_TIMEOUT 20 /* how long we wait for wpa_supplicant to associate (in seconds) */
+#define NM_SUPPLICANT_TIMEOUT 60 /* how long we wait for wpa_supplicant to associate (in seconds) */
static unsigned int
get_supplicant_timeout (NMDevice80211Wireless *self)
{
- if (self-priv-num_freqs 14)
- return NM_SUPPLICANT_TIMEOUT * 2;
return NM_SUPPLICANT_TIMEOUT;
}
@@ -2425,13 +2412,28 @@
const char * iface = nm_device_get_iface (NM_DEVICE (self));
gboolean success = FALSE;
inttries = 0;
+ const char * wpa_driver;
+ const char * kernel_driver;
if (!(ctrl = wpa_ctrl_open (WPA_SUPPLICANT_GLOBAL_SOCKET, NM_RUN_DIR)))
goto exit;
+ kernel_driver = nm_device_get_driver (NM_DEVICE (self));
+
+ /*
+ * We want to work with the generic wext wpa_supplicant driver, but some kernel drivers
+ * are just utter junk. For those losers, we use a specific wpa_supplicant driver.
+ */
+ if (!strcmp (kernel_driver, ath_pci))
+ wpa_driver = madwifi;
+ else if (!strcmp (kernel_driver, prism54))
+ wpa_driver = prism54;
+ else
+ wpa_driver = wext;
+
/* wpa_cli -g/var/run/wpa_supplicant-global interface_add eth1 wext /var/run/wpa_supplicant */
if (!nm_utils_supplicant_request_with_check (ctrl, OK, __func__, NULL,
- INTERFACE_ADD %s\t\twext\t WPA_SUPPLICANT_CONTROL_SOCKET \t, iface))
+ INTERFACE_ADD %s\t\t%s\t WPA_SUPPLICANT_CONTROL_SOCKET \t, iface, wpa_driver))
goto exit;
wpa_ctrl_close (ctrl);
@@ -2468,6 +2470,7 @@
gboolean user_created;
const char * hex_essid;
const char * ap_scan = AP_SCAN 1;
+ const char * kernel_driver;
guint32 caps;
gboolean supports_wpa;
@@ -2489,12 +2492,39 @@
|| (caps NM_802_11_CAP_PROTO_WPA2);
/* Use AP_SCAN 2 if:
- * - The wireless network is non-broadcast or user created
- * - The wireless driver does not support WPA
+ * - The wireless driver does not support AP_SCAN 1
+ *(orinoco, prism54, airo, and ndiswrapper)
+ * - The wireless network is hidden and the driver
+ *does not support AP_SCAN 1 with hidden SSIDs (ipw2100)
+ * - The wireless network is user created
+ * - The wireless driver does not support WPA
+ * Otherwise, we prefer AP_SCAN 1.
*/
user_created = nm_ap_get_user_created (ap);
- if (!nm_ap_get_broadcast (ap) || user_created || !supports_wpa)
+ kernel_driver = nm_device_get_driver (NM_DEVICE (self));
+ if (!strcmp (kernel_driver, orinoco_cs))
+ ap_scan = AP_SCAN 2;
+ else if (!strcmp (kernel_driver, prism54))
ap_scan = AP_SCAN 2;
+ else if (!strncmp (kernel_driver, airo, 4))
+ ap_scan = AP_SCAN 2;
+ else if (!strcmp (kernel_driver
Re: Ad-Hoc networks again
On Thu, 2006-05-11 at 14:44 -0400, Darren Albers wrote: I know this has come up in the past but I can't remember if anything was ever decided on it, but I have been traveling a lot lately and while in airports I have mistakenly tried to connect to misconfigured laptops running in ad-hoc mode that has carried over the SSID from somewhere else (This happens to windows users who have their system configured to connect to any available AP). Was anything ever decided on if Ad-hoc networks were going to be marked or hidden in the UI? It is not a big deal, just a minor annoyance since I can use iwlist or kismet to see which ones are real access points. Other than this Network-Manager has been rock solid for me! I (and I suspect Mr Williams, as well) would be totally happy to get a patch that somehow distinguished Ad-Hoc networks in the UI. It just needs to be stetic. We probably need new icons. It can be handled in the same way we do secure networks now, with a different icon. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Rekeying and vpnc...
On Tue, 2006-05-02 at 17:05 -0400, Dan Williams wrote:
Index: vpn-daemons/vpnc/src/nm-vpnc-service.c
===
RCS file: /cvs/gnome/NetworkManager/vpn-daemons/vpnc/src/nm-vpnc-service.c,v
retrieving revision 1.17
diff -u -p -r1.17 nm-vpnc-service.c
--- vpn-daemons/vpnc/src/nm-vpnc-service.c 29 Mar 2006 19:26:53 -
1.17
+++ vpn-daemons/vpnc/src/nm-vpnc-service.c 2 May 2006 20:58:55 -
@@ -495,6 +495,7 @@ static gboolean nm_vpnc_config_options_v
{ IKE DH Group,
OPT_TYPE_ASCII },
{ Perfect Forward Secrecy,
OPT_TYPE_ASCII },
{ Application Version,
OPT_TYPE_ASCII },
+ { Rekeying interval,
OPT_TYPE_ASCII },
{ NULL,
OPT_TYPE_UNKNOWN } };
unsigned inti;
What else do we need (vpnc patches, etc.) to make rekeying work?
And no NM changes should break users without a patched vpnc.
Robert Love
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: change the gnome keyring manager password
On Wed, 2006-03-29 at 22:14 -0600, Eli Criffield wrote: And how do you set it to have no password ? I don't think he said that he did. He wants to change it. If it is ever not set, it will prompt you for a new one on first use. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: change the gnome keyring manager password
On Wed, 2006-03-29 at 19:48 -0500, jim lawrence wrote: How can I change the gnome keyring manager password ?? This is sad, but there seems to be no way to do so. Best thing is to delete ~/.gnome2/keyrings/, which will cause gnome-keyring to prompt for a new password on the next use of the keyring. Of course, you will lose all of your data, too. Pretty lame! Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [announce] NetworkManager 0.6.2 - dhcdbd
On Tue, 2006-03-28 at 02:32 +0200, Michael Biebl wrote: The behaviour of NM changed as it now doesn't start dhcdbd itself anymore. Took me a while staring a the log file to notice that. While I found a corresponding Changelog entry it would have been a good idea to put that info into the NEWS file. I added a note to NEWS on the top of the branch. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with errors in starting nm-applet
On Tue, 2006-03-28 at 08:30 -0600, [EMAIL PROTECTED] wrote: When I start nm-applet I get the following errors: (nm-applet:5719): libglade-WARNING **: unknown property `urgency_hint' for class `GtkDialog' (nm-applet:5719): libglade-WARNING **: unknown property `urgency_hint' for class `GtkDialog' I don't know what these errors mean. Do anyone else? Warnings, not errors. I suppose your libglade is old. It works fine with 2.5.x. Does everything work fine, otherwise? If so, don't sweat it. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Notification icon removed
On Tue, 2006-03-28 at 10:01 +0200, Nil Gradisnik wrote: My problem is that I accidentally clicked Remove in 0.6.2 version, so the icon dissapeared from notification area. Now I'm on 0.6.0 back and the icon is still not there. You accidentally clicked Removed and then you accidentally answered Yes. How can I put the icon back in notification area ? gnome-session-properties should allow you to reenable the service. Otherwise, do `rm ~/.config/autostart/nm-applet.desktop`. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA2 Enterprise (and other things)
On Fri, 2006-03-24 at 17:32 +, Jon Escombe wrote: Anyway, full patch attached. Thank you, sir. I banged on this with various networks. Works good and looks right. Committed to HEAD and the 0.6 branch. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Two small build fixes
On Sat, 2006-03-25 at 08:49 -0500, Dan Williams wrote: Is the if.h change OK? I fear another back-and-forth with kernel vs. userspace hearders here... I do too, but it seems to work for me, and we should prefer glibc to kernel headers when possible ... so, committed. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: too many information messages
On Sun, 2006-03-26 at 23:31 +0200, [EMAIL PROTECTED] wrote: why debugging at all? what about not passing any -d's? Also possible, but don't expect anyone to be able to debug any problems. I find -d a nice balance between noise and signal. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Fri, 2006-03-24 at 07:23 -0800, Jouni Malinen wrote: I've been working with more documentation for wpa_supplicant configuration and one part of this is a configuration wizard that can be used to generate example configurations. It is not yet complete and is likely to miss something. Anyway, the list of EAP types and their options should include most of the commonly used options. The test version is available at http://hostap.epitest.fi/wpa_supplicant/conf/configure.html and it may help in figuring out some of the configuration strings needed for wpa_supplicant. Much thanks for this information, Jouni. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA2 Enterprise (and other things)
On Fri, 2006-03-24 at 17:32 +, Jon Escombe wrote: From memory, if I enter insufficient values into the WPA Enterprise dialog, NM will happily launch wpa_supplicant with what it's been given. Correct. There are myriad possible configurations and I simply did not check for any specific combination. Adding the validation is easy (we have infrastructure for it), but someone (probably me, at some point) is going to need to sit down and code up code to enforce the options. But I need to be sure to nab every possible configuration, first. Maybe we will scrap the UI before then. Presumably if the connection isn't successful then the configuration details aren't stored? Correct. Anyway, full patch attached. Thank you, sir. I'll bang on it. Dan, what do you think? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: KNetworkManager SCM
On Thu, 2006-03-23 at 07:48 -0500, Dan Williams wrote: Third option: freedesktop.org SVN (or CVS). Chris Aillon and I were punting around the idea of putting NM onto freedesktop.org, since it really is desktop agnostic, a lot like HAL. If there aren't any objections, I guess that's the options I'd prefer. That way, we have everything together in one place, and it's in a place that's got a track record of both KDE and GNOME devs working together :) So long as it is f.d.o SVN (not CVS), I am 100% for this. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Thu, 2006-03-23 at 11:48 +0100, Dennis Kaarsemaker wrote: How about: _ Key type:| Wep 40 \/ | |-| | Wep 64 | | WPA | | WPA2| '-' _ Authentication type: | Open system \/ | |-| | Shared key | | 802.1x | '-' The problem with this is that once you select 802.1x you really want the WPA-EAP dialog. Which isn't impossible to do, but its a bit of code changes for us. Dan is right: The current dialog is a mess. But, on the other hand, I don't see it as untenable. It just isn't easy to pile all these options into a single UI. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Thu, 2006-03-23 at 10:04 -0500, Pat Suwalski wrote: Finally, if you've gotten this far, there is a patch I'm planning to write that will automatically detect the WEP type, there is no need for a drop-down box. Hex will be hex, 26 characters/nibbles long. The password mode for that does no get that long. This won't fly. As just one example, my passphrase at home is a legitimate hex key (I am, yes, an idiot). Differentiating between ASCII and passphrase is even harder. We need to ask. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] dont set invisible_char
On Wed, 2006-03-22 at 23:29 +0100, [EMAIL PROTECTED] wrote: NetworkManager right now sets invisible_char to the default value of * in all .glade files, that is not needed and poses an even bigger problem if the system default is changed. attached patch removes all property name=invisible_char*/property entries from .glade files in cvs Good catch. Committed to HEAD and the 0.6 branch. At least in my version, Glade sets this property for me. So another patch would be to have glade not set the field whatsoever, by default. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Thu, 2006-03-23 at 10:15 -0500, Pat Suwalski wrote: Robert Love wrote: This won't fly. As just one example, my passphrase at home is a legitimate hex key (I am, yes, an idiot). Differentiating between ASCII and passphrase is even harder. We need to ask. I've seen this in an implementation. It works beautifully. Basically: WEP key: 26 characters, [A-F]|[a-f]|[0-9] String: 26 characters, no restrictions. I am saying, my passphrase is a legitimate hex key. It cannot work beautifully if ASCII and Hex keys are also valid passphrases. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Thu, 2006-03-23 at 10:22 -0500, Dan Williams wrote: Passphrases can be any length, up to 64 characters. That includes exactly 26 characters, and since the hex key character space is a subset of the passphrase character space, there's absolutely no way to differentiate between the two automatically. Maybe we can do some smart heuristics, such that if it's exactly 26 characters and all hex, then _likely_ it's a hex key, but I think we're more likely to get it wrong and confuse users this way, rather than just asking. Agree with Mr Williams. I think many users these days, and most users going forward, use passphrases, so the best bet we can have is default to passphrase as the key type and expect our users to change it if needed. Otherwise, as Dan wrote, we are just asking for confusion. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Thu, 2006-03-23 at 10:43 -0500, Pat Suwalski wrote: I don't see how -- to the best of my knowledge, the ascii keys are not allowed to be 26 characters long, and the hex keys must be 26 characters long... Right, but passphrases can be either of those things. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Thu, 2006-03-23 at 10:51 -0500, Pat Suwalski wrote: Hm. Well, then something that would alleviate the annoyance is if the text box didn't get cleared when the mode is changed. I always end up pasting in or typing in the key and then selecting the method, only to lose about 2 minutes of typing hex... Yah, this would be nice. We would have to re-run our validation function on the input and clear it if it no longer matched, though. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: KNetworkManager SCM
On Thu, 2006-03-23 at 12:44 -0500, David Zeuthen wrote: It's very difficult to deal with translations if you're hosted on fd.o servers. I recommend that you at least keep the applet in GNOME CVS/SVN. This raises a good point. We need the translators. Also, Dan, I had another issue I wanted to discuss: I wanted to propose NetworkManager (or at least nm-applet) for the GNOME Desktop proper, as g-v-m is now a member. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] dont set invisible_char
On Thu, 2006-03-23 at 14:01 -0500, Christopher Aillon wrote: You're right, although I wonder how that snuck in. I made sure that NetworkManager was not setting the default invisible character when I was converting Fedora to use a different default Anyway, thanks for catching it. Glade seems to be setting it, so it snuck in when I or someone else last edited the file, I guess. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP timeout patch
On Thu, 2006-03-16 at 16:09 +0100, Radek Vokál wrote: Hi, I've realized that 25sec DHCP timeout limit is not enough on my slow network, so I've proposed a small patch on RH bugzilla for adding new option to NetworkManager, allowing to specify the timeout value. Please see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185611 I would prefer that we just set the timeout to a sensible value by default and leave it at that -- making it configurable seems a bit much, particularly at compile-time. I have had other bug reports that users need DHCP timeouts in the 30~40 second range. To be sure, most ifup scripts wait longer than 25s. Dan, any thoughts here on a bump? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA Enterprise TTLS
On Wed, 2006-03-22 at 18:38 +, [EMAIL PROTECTED] wrote: Today I've been trying to connect to a wireless network that uses 802.11x. I was told by someone who connected using an Apple laptop that I needed to use TTLS with PAP. In the WPA Enterprise window that appeared when I tried to connect using Network Manager, there was no option I could see to choose PAP instead of anything else. Is this a missing feature or am I missing something? I'm using the version in FC5. I can send a log file if that would be helpful. If you need to use PAP as the second-stage authenticator, we do not support that. I have been intending to add second-stage authentication, but I don't know a lot about it. If you could get a hold of a working wpa_supplicant.conf for your configuration, that would be a start. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Dynamic WEP support.
Hi, guys. I checked a first-pass at Dynamic WEP into CVS, on both HEAD and the 0.6 branch (since it was not overly complex). Jan and Dennis, I would love to hear if it works for you and, if not, what goes wrong. Thanks! Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Wed, 2006-03-22 at 14:50 -0500, Robert Love wrote: I checked a first-pass at Dynamic WEP into CVS, on both HEAD and the 0.6 branch (since it was not overly complex). Jan and Dennis, I would love to hear if it works for you and, if not, what goes wrong. If not obvious: Select Dynamic WEP as the Key type in the WPA Enterprise configuration. Another question is, if NM detects your Dynamic WEP-based AP, does it think it is doing WPA Enterprise? It should. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA Enterprise TTLS
On Wed, 2006-03-22 at 20:58 +0100, Dennis Kaarsemaker wrote: Sorry to hijack this thread but that would also explain (parts of) my 802.1x/WEP problem I posted about 2 days ago - that one uses PAP too. AFAIK you can simply send wpa_supplicant this parameter via the control channel at the same time you send the other parameters. ... if you can do this while testing Dynamic WEP, that would be helpful. ;-) Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Dynamic WEP support.
On Wed, 2006-03-22 at 21:14 +0100, Jan Mynarik wrote: Another question is, if NM detects your Dynamic WEP-based AP, does it think it is doing WPA Enterprise? It should. No, when I select this network from nm-applet's list, n-m tries to connect and then opens dialog asking for WEP (passphrase|40-bit|104-bit key). Hrm. That is a problem. Kind of sucks if there is no way for the AP to advertise that it does half-WPA/half-WEP. I presumed it would advertise the WPA-EAP stuff, but then non-WPA cards might not grok that. Anyhow ... you can test it by doing Connect to Other ... and selecting WPA Enterprise with a key type of Dynamic WEP and filing out the other fields selectively, as needed. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 802.1x + WEP
On Tue, 2006-03-21 at 15:37 +0100, Jan Mynarik wrote: I read the config once again later and said that to myself too :-) Our admins at work told me it's WEP/TLS. And n-m offers me only WEP when I connect to our wifi network. I need to use Connect to other wireless network to be able to set WPA. It is WEP/TLS (or WEP/TTLS). I think how it works is that you authenticate using WPA TTLS and that gets you a key, which you then use for WEP. This provides some additional security without requiring WPA-capable hardware. But I still don't see what in this file says do WEP. We can almost generate this exact configuration now... Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 802.1x + WEP
On Tue, 2006-03-21 at 12:24 +, Jan Mynarik wrote: same here (802.1x EAP/TLS) and no n-m's WPA profile works (via Connect to Other Wireless Network). I am going to look at adding this -- but, what in here actually says use WEP ? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[announce] NetworkManager 0.6.1
We released NetworkManager 0.6.1 yesterday. Tarballs are available: http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.6/ CVS users can check out the tag NETWORKMANAGER_0_6_1_RELEASE. This release contains several clean ups and fixes over the big 0.6 drop, and is recommended for all users of the 0.6 branch. See ChangeLog and NEWS for the full scoop. Enjoy, Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[patch] madwifi-ng driver fix.
Recent madwifi-ng releases (since r1451 or so) have been busted.
The attached patch fixed it for me.
Robert Love
diff -ur madwifi-ng-r1451-20060212/net80211/ieee80211_input.c madwifi-ng-r1451-20060212.mod/net80211/ieee80211_input.c
--- madwifi-ng-r1451-20060212/net80211/ieee80211_input.c 2006-02-03 12:28:14.0 +0100
+++ madwifi-ng-r1451-20060212.mod/net80211/ieee80211_input.c 2006-03-03 14:11:44.0 +0100
@@ -1199,8 +1199,12 @@
vap-iv_stats.is_rx_auth_fail++;
ieee80211_new_state(vap, IEEE80211_S_SCAN,
IEEE80211_SCAN_FAIL_STATUS);
- } else
+ } else {
+ /* mark the port authorized */
+ if (ni-ni_authmode != IEEE80211_AUTH_8021X)
+ieee80211_node_authorize(ni);
ieee80211_new_state(vap, IEEE80211_S_ASSOC, 0);
+ }
break;
case IEEE80211_M_MONITOR:
break;
@@ -3025,7 +3029,7 @@
rates = xrates = wme = NULL;
while (frm efrm) {
- IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1]);
+ /*IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1]);*/
switch (*frm) {
case IEEE80211_ELEMID_RATES:
rates = frm;
@@ -3040,8 +3044,6 @@
}
frm += frm[1] + 2;
}
- if (frm efrm)
- return;
IEEE80211_VERIFY_ELEMENT(rates, IEEE80211_RATE_MAXSIZE);
rate = ieee80211_setup_rates(ni, rates, xrates,
IEEE80211_F_DOSORT | IEEE80211_F_DOFRATE |
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: no vpn plugin tarballs for 0.6
On Mon, 2006-03-06 at 14:30 -0500, Christopher Aillon wrote: Why not create a new module? We don't need one for every VPN implementation, but I think NetworkManager-VPN would be an acceptable module. See e.g. epiphany-extensions, gnome-games-extra-data, etc. On w.g.o, how do you manage tarballs that don't match the module name? I don't think you can. So we can do this, but we'd have to put all of the VPN plugins in one tarball. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: no vpn plugin tarballs for 0.6
On Mon, 2006-03-06 at 15:22 -0500, Rémi Cardona wrote: I'm no distro maintainer but it wouldn't be any harder than it is for GStreamer which ships 4 tarballs (base, good, bad, ugly) for more than a dozen plugins. It isn't the distro, it is the GNOME machines. See http://ftp.gnome.org/pub/GNOME/sources/gstreamer/0.10/ Only one basename to the tarball. I don't think the existing tools for managing new releases support tarballs where the tarballs basename does not match the module name. So far, there are only three vpn modules for NM, imho it seems reasonable to put them in one tarball. The downside to this is that it defeats the point of the VPN modules being separate, externally managed plugins with their own releases in the first place. Plus, we would then have to synchronize releases. And if we were going to do this, we might as well put the VPN plugins in the base NetworkManager package. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No WPA under Wireless Security
On Mon, 2006-03-06 at 23:01 +0100, krischan wrote: WEP and VPN worked perfectly. This is because your wireless driver does not support WPA (or more likely reports that it does not). What driver? NM only displays security methods that your driver supports. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: no vpn plugin tarballs for 0.6
On Sun, 2006-03-05 at 10:34 -0500, [EMAIL PROTECTED] wrote: nice to see that 0.6 is out, where can i find the latest tarballs for the vpn plugins, vpnc, openvpn and pptp. would be nice to see those at http://ftp.gnome.org/pub/GNOME/sources/NetworkManager/0.6/ Unfortunately, the way ftp.gnome.org works I am not sure that we can do this. It is fairly automated and we may be unable to submit tarballs to directories that don't match the module name. The other issue is that these releases are not in sync. E.g., there was not a corresponding release of the VPN plugins (nor does there need to be), so we do not necessarily have something to release. I agree it would be nice to get tarballs of these packages up. I can talk with the gnome.org folks and see what we can do other than created n new modules for all of the VPN plugins. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Re: wireless driver workarounds
On Sat, 2006-03-04 at 16:42 +0100, [EMAIL PROTECTED] wrote: But If I was in Infraestructure mode get_mode() return IW_MODE_AUTO, is it not the same for Ad-Hoc mode? If it does, that is another bug, elsewhere. When we go into Ad-Hoc mode, we explicitly set IW_MODE_ADHOC. You might be right, and there is still a problem, but I think this patch is fine. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Fri, 2006-03-03 at 13:56 +0100, [EMAIL PROTECTED] wrote:
This patch work fine for me and all changes are needed
Alright, thanks.
Dan, what do you think? It seems the real issue is that ndiswrapper
doesn't want to be out of IW_MODE_AUTO, not that the set_mode()
operation itself is costly.
+ if (!strcmp (nm_device_get_driver (NM_DEVICE (self)),
ndiswrapper)) {
+ driver= g_malloc(sizeof(char)*(strlen(ndiswrapper)+1));
+ driver= strcpy(driver, ndiswrapper);
+ }
+ else if (!strcmp (nm_device_get_driver (NM_DEVICE (self)),
ath_pci)) {
+ driver= g_malloc(sizeof(char)*(strlen(madwifi)+1));
+ driver= strcpy(driver, madwifi);
+ }
+ else {
+ driver= g_malloc(sizeof(char)*(strlen(wext)+1));
+ driver= strcpy(driver, wext);
+ }
+
aj2r, just as an FYI, you don't need dynamic allocations here.
const char *driver = madwifi;
is sufficient. As it stands, this code allocates both a static
character array and a dynamic one. Just a tip ;-)
Robert Love
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Fri, 2006-03-03 at 16:17 +0100, [EMAIL PROTECTED] wrote: Ok, thanks. But later you don't make driver=ndiswrapper because you are using non reserved memory, no? I am not sure what you mean? This is okay (and preferred): const char *driver; if (foo) driver = cat; else if (bar) driver = dog; else driver = fox; And you do not free it. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
wireless driver workarounds
Attached patch is a collection of workarounds for madwifi, orinoco, and
ndiswrapper that I have worked on or that have been posted to this list.
We are probably not going to merge any of this. If NM does not work for
you but works with this patch, we would like to know.
Robert Love
Index: src/nm-device-802-11-wireless.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-device-802-11-wireless.c,v
retrieving revision 1.59
diff -u -r1.59 nm-device-802-11-wireless.c
--- src/nm-device-802-11-wireless.c 2 Mar 2006 23:01:33 - 1.59
+++ src/nm-device-802-11-wireless.c 3 Mar 2006 15:19:13 -
@@ -1834,14 +1834,16 @@
/* Must be in infrastructure mode during scan, otherwise we don't get a full
* list of scan results. Scanning doesn't work well in Ad-Hoc mode :(
- */
- nm_device_802_11_wireless_set_mode (self, IW_MODE_INFRA);
-
- /* We only unlock the frequency if the card is in adhoc mode, in case it is
- * a costly operation for the driver.
+ *
+ * We only set the mode and unlock the frequency if the card is in adhoc mode,
+ * in case doing so is a costly operation for the driver or the driver prefers
+ * IW_MODE_AUTO.
*/
if (orig_mode == IW_MODE_ADHOC)
+ {
+nm_device_802_11_wireless_set_mode (self, IW_MODE_INFRA);
nm_device_802_11_wireless_set_frequency (self, 0);
+ }
wrq.u.data.pointer = NULL;
wrq.u.data.flags = 0;
@@ -2415,13 +2417,28 @@
const char * iface = nm_device_get_iface (NM_DEVICE (self));
gboolean success = FALSE;
inttries = 0;
+ const char * wpa_driver;
+ const char * kernel_driver;
if (!(ctrl = wpa_ctrl_open (WPA_SUPPLICANT_GLOBAL_SOCKET, NM_RUN_DIR)))
goto exit;
+ kernel_driver = nm_device_get_driver (NM_DEVICE (self));
+
+ /*
+ * We want to work with the generic wext wpa_supplicant driver, but some kernel drivers
+ * are just utter junk. For those losers, we use a specific wpa_supplicant driver.
+ */
+ if (!strcmp (kernel_driver, ath_pci))
+ wpa_driver = madwifi;
+ else if (!strcmp (kernel_driver, ndiswrapper))
+ wpa_driver = ndiswrapper;
+ else
+ wpa_driver = wext;
+
/* wpa_cli -g/var/run/wpa_supplicant-global interface_add eth1 wext /var/run/wpa_supplicant */
if (!nm_utils_supplicant_request_with_check (ctrl, OK, __func__, NULL,
- INTERFACE_ADD %s\t\twext\t WPA_SUPPLICANT_CONTROL_SOCKET \t, iface))
+ INTERFACE_ADD %s\t\t%s\t WPA_SUPPLICANT_CONTROL_SOCKET \t, iface, wpa_driver))
goto exit;
wpa_ctrl_close (ctrl);
@@ -2457,7 +2474,8 @@
struct wpa_ctrl * ctrl;
gboolean user_created;
char * hex_essid;
- char * ap_scan = AP_SCAN 1;
+ const char * ap_scan;
+ const char * kernel_driver;
g_return_val_if_fail (self != NULL, FALSE);
g_return_val_if_fail (req != NULL, FALSE);
@@ -2468,14 +2486,25 @@
ctrl = self-priv-supplicant.ctrl;
g_assert (ctrl);
- /* Ad-Hoc and non-broadcasting networks need AP_SCAN 2 */
user_created = nm_ap_get_user_created (ap);
- if (!nm_ap_get_broadcast (ap) || user_created)
+ kernel_driver = nm_device_get_driver (NM_DEVICE (self));
+
+ /*
+ * We want to use AP_SCAN 1, which tells wpa_supplicant to perform scanning. This seems
+ * to work better with some drivers. But we want AP_SCAN 2, telling wpa_supplicant that
+ * we will do our own scanning, if
+ *
+ * - The driver is orinoco_cs. It chokes on AP_SCAN 1.
+ * - The AP is non-broadcast or Ad-Hoc. Unless the driver is madwifi.
+ */
+ if (!strcmp (kernel_driver, orinoco_cs))
ap_scan = AP_SCAN 2;
+ else if ((!nm_ap_get_broadcast (ap) || user_created) strcmp (kernel_driver, ath_pci))
+ ap_scan = AP_SCAN 2;
+ else
+ ap_scan = AP_SCAN 1;
- /* Tell wpa_supplicant that we'll do the scanning */
- if (!nm_utils_supplicant_request_with_check (ctrl, OK, __func__, NULL,
- ap_scan))
+ if (!nm_utils_supplicant_request_with_check (ctrl, OK, __func__, NULL, ap_scan))
goto out;
/* Standard network setup info */
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: small patch for DBUS 0.60
On Fri, 2006-03-03 at 13:33 +, James Begley wrote: As I see it (as a very limited hacker) there are 2 ways round this. 1) Only allow DBUS = 0.60 2) Check the DBUS version, and use the appropriate DBUS function. The attached patch does this, and is sent on a strictly works-for-me basis. I actually would prefer to just require DBUS 0.60, although your patch is a viable option, too. By and by, I don't see where we require 0.50, though. Dan, opinions? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: small patch for DBUS 0.60
On Fri, 2006-03-03 at 13:31 -0500, Dan Williams wrote: Not particularly, but I think I'd rather require dbus 0.60 too. While the patch does preserve the old behavior, the old behavior was clearly broken. I bumped our requirement from 0.22 (!) to 0.60. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Subject Prefix...
On Thu, 2006-03-02 at 06:55 -0500, Robert Brown wrote: Could we turn on the Subject Prefix option for this list? Something like [NM] or [NetworkManager]? It's pretty easy to set up mail preprocessing, prefiling and so on based on this field. More important, it makes it easy for the eye to identify list traffic in a long list of email. I get several hundred mails a day and every little bit helps. Set up a mailing list filter! The subject prefix is ugly and annoying. Filter on ^X-BeenThere: networkmanager-list@gnome.org and you are gold. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Thu, 2006-03-02 at 10:39 -0500, Robert Love wrote: Bill said the committed patch worked for him, but that obviously doesn't make sense now. s/Bill/Brian/ sorry. Anyhow, this patch at least does not break anything for me. ndiswrapper users, does this fix your problems? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Thu, 2006-03-02 at 09:52 -0500, Dan Williams wrote: We've seen this around as well, but it seems to be fairly random. I have a bug report (Novell bug #153536) where it is happening pretty regularly. Very odd. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Thu, 2006-03-02 at 10:42 -0500, Robert Love wrote: On Thu, 2006-03-02 at 10:39 -0500, Robert Love wrote: Bill said the committed patch worked for him, but that obviously doesn't make sense now. s/Bill/Brian/ sorry. Anyhow, this patch at least does not break anything for me. ndiswrapper users, does this fix your problems? Got a confirmation from an internal user that this fixes the problem for ndiswrapper/broadcom and this patch makes more sense than the current set_mode() no-op, so I committed it. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Wed, 2006-03-01 at 19:38 -0500, Brian Magnuson wrote: Appears to be ok. Comments? Unfortunately, it won't work for everyone. There are only a handful of wpa_supplicant drivers. ndiswrapper just happens to be one of them. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Wed, 2006-03-01 at 19:31 -0500, Brian Magnuson wrote:
--- src/nm-device-802-11-wireless.c 2006-02-21 11:39:33.0 +0100
+++ src/nm-device-802-11-wireless.c 2006-03-01 19:06:34.0 +0100
@@ -1808,8 +1808,10 @@
/* Must be in infrastructure mode during scan,
otherwise we don't get a full
* list of scan results. Scanning doesn't work well in
Ad-Hoc mode :(
*/
- nm_device_802_11_wireless_set_mode (self,
IW_MODE_INFRA);
- nm_device_802_11_wireless_set_frequency (self, 0);
+ if (nm_device_802_11_wireless_get_mode (self) ==
IW_MODE_ADHOC) {
+ nm_device_802_11_wireless_set_mode (self,
IW_MODE_INFRA);
+ nm_device_802_11_wireless_set_frequency (self,
0);
+ }
Has anyone tested without this chunk, and with just the second hunk that
sets the wpa_supplicant driver?
Robert Love
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Wed, 2006-03-01 at 20:00 -0500, Brian Magnuson wrote: No, but it seemed pretty uncontroversial. Could be less so by switching that check to != IW_MODE_INFRA. I agree though that it's not obvious why this would be needed at all. The real thing that bothers me is putting the set_frequency() inside of the if statement. Only setting the mode if it actually needs to be set is one thing and makes sense (presumably it is expensive to set the mode on some cards, so why do it if not needed). Moving the set_frequency() in there, however, means that cards are no longer going to have their frequency zeroed out before each scan. And that is an actual change in behavior, whereas the set_mode() change is essentially a no-op. Should that matter? Not really. But this is wireless drivers we are talking about. Nothing is sensical. So I am curious if this hunk of the patch is even requisite, or if setting the driver is sufficient. Partly my curiosity stems from the fact that we do a set_mode() a few lines later ... and apparently that is okay. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Wed, 2006-03-01 at 20:10 -0500, Brian Magnuson wrote: Sorry I don't follow you here. My 2nd patch (I think) handles the cases for the other supplicant drivers. I admittedly don't really know anything about the control connect to wpa_supplicant that I'm messing with here but it does seem wrong that it was always sending wext before. wpa_supplicant drivers and kernel drivers are two different things. the get_driver() function returns the kernel driver. you are passing that in where we request the wpa_supplicant driver. it won't work for most drivers. wpa_supplicant defines a generic wext driver that handles the wireless extension API. it also defines a handful of custom drivers, because the kernel wireless drivers are such pieces of cat poop. madwifi and ndiswrapper are two of them. but, say, airo (a valid kernel driver) is not. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless silently disconnects?
On Wed, 2006-03-01 at 20:43 -0500, Brian Magnuson wrote: Ah, I see. Ok, so something like this might be more appropriate? Basically back to the original posters concept. More elses could be added as appropriate. Yes, this is exactly what I had in mind. Good work! Additionally I moved the set_freq outside the if() which still works for me. The set_mode really seems to be the thing causing the problem. Having that outside the if caused that same hang. In that case it's not even clear that the 2nd part of the patch is needed although it certainly seems like the right thing to do. So ... this works for you? Good. I would be curious if you needed the second hunk. The reason being is that Dan doesn't want to put these driver-specific hacks in NM (with good reason), but the first hunk makes more sense. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
