Re: nm-edit (was: Re: [3/3] Do something with trusted networks)
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.I think could be a usefull characteristic, becouse is just another way to do the same. 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.What about to have the oportunity to disable the DHCP of each connection, then you can allow the user to store static IP's for each network and save this data to a gconf key. -- Trabajar, la mejor arma para tu superaciónde grano en grano, se hace la arena (R) (entrámite, pero para los cuates: LIBRE) ___ 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: [3/3] Do something with trusted networks
On Thursday 08 June 2006 03:33, Robert Love wrote: We definitely need a wireless properties editor. I don't like the idea of having nm-applet provide UI for editing the entries, but we should have a separate (launchable from the applet, to be sure) utility for editing the stored networks. If nothing else, we need a way to let users remove networks. Have a look at the Manage Networks... dialog in KNetworkManager - it's a simple drag and drop based network list to change the trusted (-fallback) status of networks and delete unwanted networks. Thanks for implementing the trusted flag, now our UI has something to do. Will -- Will Stephenson IRC: Bille ___ 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 Wed, 7 Jun 2006, Robert Love wrote: If nothing else, we need a way to let users remove networks. I've got a glade/gtk project going that will (I hope) let one do at least this -- this is just remove the essid-named directory stored in .gconf/system/networking/wireless/networks/whatever, right? It might form the basis of something more at some point, if I have time to figure out gconf in more detail. rgb -- Robert G. Brownhttp://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED] ___ 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 Wed, 2006-06-07 at 21:33 -0400, Robert Love wrote: Jens Lautenbacher wrote: I think it's problematic that whenever the need may arise to reenter network information, the information that is on disk somewhere can't be accessed, but must be given by hand again. Suppose I just need to change the key (because of a typo or so) - I always have to reenter everything again. If I had a list where I can select one of the known networks, this would fill out the UI to the current values - which in turn could be changed before clicking on connect. (A UI could be a drop down select menu with the default entry New network, and all the UI in it's pristine state. Selecting another known network from the drop down menu would then fill in the values) This could also help with another problem I have at work: They change essid and key every month, forcing me to enter a new network and loosing all the collected AP bssids from anywhere around the house... We definitely need a wireless properties editor. I don't like the idea of having nm-applet provide UI for editing the entries, but we should have a separate (launchable from the applet, to be sure) utility for editing the stored networks. If nothing else, we need a way to let users remove networks. Absolutely. Dan ___ 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 Wed, 2006-06-07 at 18:53 -0400, Robert Love wrote: 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? This is horrid. 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. I'd rather not actively aid abet this practice by separating out every MAC, but that doesn't mean we can't try to make life easier for those people who's network admins make the WRONG decisions :) The reason NM chokes on it is that we have logic to merge two AP objects into one if they share the same BSSID. So here's a thought (started out as two different options, but this one is clearly better): Do finer-grained coalescing of access points. Still do limited BSSID-ESSID fill-in, but after that, start matching AP capabilities too. There's no way to distinguish between 40/64/104/128-bit WEP, but we can stuff the APs into categories like unencrypted, WEP, WPA1, WPA2. If the user has pre-configured settings for them, we can use those to further differentiate them. We must be careful to not do too-aggressive differentiation, but it's pretty clear that an AP that's unencrypted shouldn't be coalesced with an AP that's encrypted, even if they share the same SSID. The point is that we accommodate users who's networks suck, but don't make pointless distinctions for people who never are, or never will be, in that situation. Given Jens' situation, with a few others thrown in: a. SSID: foo, BSSID: xx:0a, hidden, WEP b. SSID: bar, BSSID: xx:0a, broadcast, unencrypted c. SSID: linksys, BSSID: xx:bf, broadcast, WPA1 d. SSID: linksys, BSSID: xx:ac, broadcast, WPA1 e. SSID: linksys, BSSID: xx:9f, broadcast, Ad-Hoc, WEP f. SSID: stupid, BSSID: xx:12, broadcast, WPA1 g. SSID: stupid, BSSID: xx:66, broadcast, WEP The NM applet would show the following list of logical networks: .--. | O Wired Network | | | Wireless Networks| | | | O foo | | O barE ==.. | | O linksysE =... | | O linksys AE =... | | O stupid (WEP) E ===. | | O stupid (WPA1) E | |--| | VPN Connections| |--| | Connect to Other Wireless...| | Create Wireless Network... | `--' A few notes; first, you'll see that 'linksys' doesn't have its encryption type shown, because all access points in the area are homogeneous. There's no point to the extra information, except to know that the AP is encrypted, if you care. 'foo' and 'bar' are differentiated, because they have different SSIDs. This _does_ mean a bunch of extra logic in NM to make sure we don't do the hidden network BSSID-SSID matching too soon if more than two or more GConf entries share the the same BSSID. Since the 'last connected' timestamp is kept per-SSID, which I think is 100% correct, NM should only connect to 'bar' for Jens, and ignore 'foo'. For him, the latency for connection will be slightly higher, but that's the price he pays for working at a company that doesn't want to shell out for a better AP. Bad Jens :) If we differentiate APs this way, we can't keep using dbus object paths or GConf paths like we have until this point, ie keyed off SSID. After a long and futile struggle, I hereby capitulate to pragmatism. I propose to not use the SSID in the dbus object path, and not to use it in GConf paths either. I guess we'll just use some sort of UID instead. This also means we don't have to escape SSIDs for dbus or gconf, which proved to be a PITA. This should all be 0.7 material. Thoughts? I'd also like some bclark interaction input here, but we'll get that in a minute after we make sure I'm not smoking the heavy technical/situational crack at all. Dan ___ 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: [3/3] Do something with trusted networks
Robert Love [EMAIL PROTECTED] writes: 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? Yes! I do too: Cell 03 - Address: 00:0F:3D:EE:5C:DC ESSID:mynet Mode:Master Frequency:2.412 GHz (Channel 1) Quality=47/94 Signal level=-48 dBm Noise level=-95 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s 48 Mb/s; 54 Mb/s Extra:bcn_int=100 Cell 05 - Address: 00:0F:3D:EE:5C:DC ESSID:mynet-a Mode:Master Frequency:5.32 GHz (Channel 64) Quality=32/94 Signal level=-63 dBm Noise level=-95 dBm Encryption key:on Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s 36 Mb/s; 48 Mb/s; 54 Mb/s Extra:bcn_int=100 That violates the wireless spec, I am 99% sure. Who makes the access point? D-Link.DWL-7100AP In my case one network is on (a) and another is (b/g). It works for me MOSTLY... But NM doesn't always connect properly on first-login after a reboot.. I think it might depend on whether it sees the ihtfp or ihtfp-a network first in its scanning. The reason NM chokes on it is that we have logic to merge two AP objects into one if they share the same BSSID. Yeah, I've always considered that a bug. Another (similar but different) issue I've seen is where you can't specify a particular a or b/g network. When I go to the IETF meetings they have both (a) and (b/g) networks all with the same ESSID, and there's no way in NM to specify I want the (a) network. Robert Love -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [3/3] Do something with trusted networks
Dan Williams [EMAIL PROTECTED] writes: [snip] So here's a thought (started out as two different options, but this one is clearly better): Do finer-grained coalescing of access points. Still do limited BSSID-ESSID fill-in, but after that, start matching AP capabilities too. There's no way to distinguish between 40/64/104/128-bit WEP, but we can stuff the APs into categories like unencrypted, WEP, WPA1, WPA2. If the user has pre-configured settings for them, we can use those to further differentiate them. We must be careful to not do too-aggressive differentiation, but it's pretty clear that an AP that's unencrypted shouldn't be coalesced with an AP that's encrypted, even if they share the same SSID. The point is that we accommodate users who's networks suck, but don't make pointless distinctions for people who never are, or never will be, in that situation. Given Jens' situation, with a few others thrown in: a. SSID: foo, BSSID: xx:0a, hidden, WEP b. SSID: bar, BSSID: xx:0a, broadcast, unencrypted c. SSID: linksys, BSSID: xx:bf, broadcast, WPA1 d. SSID: linksys, BSSID: xx:ac, broadcast, WPA1 e. SSID: linksys, BSSID: xx:9f, broadcast, Ad-Hoc, WEP f. SSID: stupid, BSSID: xx:12, broadcast, WPA1 g. SSID: stupid, BSSID: xx:66, broadcast, WEP 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. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ 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: [3/3] Do something with trusted networks
Quoting Robert Love [EMAIL PROTECTED]: 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. Your fist will get awful tired! As I pointed out in my previous email, my D-Link does this. :-/ How hard do you think it would be to not only keep (a) and (b/g) networks separate, but also provide a clue in the UI which is the (a) and which is the (b/g)? In a similar note, how hard would it be to add ordering preferences in lieu of most-recently-used? My reasoning: I'd like to connect to the ietf (a) network instead of the ietf (b/g) network when there's an (a) AP in range.. But when there isn't an (a) network I do want it to fallback to (b/g)... Thanks for all your hard work! Robert Love -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ 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:57 -0400, Robert Love wrote: 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? No, the spec mentions nothing about this possibility AFAICS, but random comments and other documents I've found via Google describe how to do it and the particular limitations of doing it. It seems to be a manufacturer driven thing where they simply decided to charge into areas that weren't fully spec-ed out by the 802.11 spec and make up their own interpretation. I have a multiple-SSID-in-single-box AP, but it gives different BSSID's to each network. Seems easy enough. Yeah, same for some of our test equipment at the office. It provides up to 64 BSSIDs and won't let you do more than one SSID on a single BSSID. 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? Yes. 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. Yes, that code would go away because most of it would be rewritten. 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. We'd probably want to roll that code into the merging code, since in Jens' situation we would normally coalesce 'foo' to 'bar' because they share the same BSSID and 'foo' is hidden. (Well, 'foo' just wouldn't show up in the scan list really, so we'd have to pull 'foo' out of GConf and merge it into the scan list artificially). But the point here is that we can't seem to rely on the merge logic the way it is now. 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. ;-) Yes, the UI will obviously have to escape bits of the ESSID, and we'll have do lookups to find ESSIDs in our networks list rather than just constructing the object path itself. But I think that's somewhat cleaner in the long run than having to jump through hoops to stuff random character sets through dbus and GConf. 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. Correct; even if we use (ESSID, BSSID) pairs, we still need the concept of a network, which is exactly what the ESSID was supposed to provide. We're still going to combine APs to form networks, but the combination process should take into account more than just ESSID; it should also account for mode (adhoc/infra) and encryption settings. We have somewhat of an M:N mapping here, but I think it's quite doable and not too messy. In the end, we're not going to be perfect, but I assert that is OK. We're making a trade-off between ease of advanced configuration and easy of daily use. Everyone makes that tradeoff, and we're no different. Where we make the difference is how far to either side we go. And obviously I'm on the record for more easy-of-daily-use. If somebody relies daily on an access point that has the same security type and ESSID as another, but not the same WEP key, that's just dumb.
Re: [3/3] Do something with trusted networks
On Thu, 2006-06-08 at 13:30 -0400, Derek Atkins wrote: Dan Williams [EMAIL PROTECTED] writes: [snip] So here's a thought (started out as two different options, but this one is clearly better): Do finer-grained coalescing of access points. Still do limited BSSID-ESSID fill-in, but after that, start matching AP capabilities too. There's no way to distinguish between 40/64/104/128-bit WEP, but we can stuff the APs into categories like unencrypted, WEP, WPA1, WPA2. If the user has pre-configured settings for them, we can use those to further differentiate them. We must be careful to not do too-aggressive differentiation, but it's pretty clear that an AP that's unencrypted shouldn't be coalesced with an AP that's encrypted, even if they share the same SSID. The point is that we accommodate users who's networks suck, but don't make pointless distinctions for people who never are, or never will be, in that situation. Given Jens' situation, with a few others thrown in: a. SSID: foo, BSSID: xx:0a, hidden, WEP b. SSID: bar, BSSID: xx:0a, broadcast, unencrypted c. SSID: linksys, BSSID: xx:bf, broadcast, WPA1 d. SSID: linksys, BSSID: xx:ac, broadcast, WPA1 e. SSID: linksys, BSSID: xx:9f, broadcast, Ad-Hoc, WEP f. SSID: stupid, BSSID: xx:12, broadcast, WPA1 g. SSID: stupid, BSSID: xx:66, broadcast, WEP 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. Ah yes, I haven't forgotten you and your network :) Quite correct. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [3/3] Do something with trusted networks
Great work! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [3/3] Do something with trusted networks
Robert Love wrote: 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. It might be worth remembering a flag along with the trusted network data that says whether or not the network was hidden. Since the network interface is presumably reasonably stable, you could skip testing the ones that previously weren't hidden, and just provide the user with a way to say try this one again if the network had become hidden after having been visible. Otherwise you could spend a noticeable amount of time hunting through a list of networks if it's long. ___ 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 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
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
On Wed, 2006-06-07 at 18:53 -0400, Robert Love wrote: 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. 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. Are you saying you have two wireless networks, with two different ESSID's, but sharing one BSSID? yes. And I have no control over this, unfortunately. That violates the wireless spec, I am 99% sure. Who makes the access point? Sorry, can't tell for sure. From the bssid it looks as if it's from SMC The reason NM chokes on it is that we have logic to merge two AP objects into one if they share the same BSSID. 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? jtl ___ 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: [3/3] Do something with trusted networks
On Wed, 2006-06-07 at 19:19 -0400, Robert Love wrote: 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. ;-) Yes, sure - I didn't meant to sound like a PITA.. :-) 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. I see. 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. I think it's problematic that whenever the need may arise to reenter network information, the information that is on disk somewhere can't be accessed, but must be given by hand again. Suppose I just need to change the key (because of a typo or so) - I always have to reenter everything again. If I had a list where I can select one of the known networks, this would fill out the UI to the current values - which in turn could be changed before clicking on connect. (A UI could be a drop down select menu with the default entry New network, and all the UI in it's pristine state. Selecting another known network from the drop down menu would then fill in the values) This could also help with another problem I have at work: They change essid and key every month, forcing me to enter a new network and loosing all the collected AP bssids from anywhere around the house... If I could just select the previous network, change the relevant values and connect, these adjustments would then be saved on a successful connect (and wiping out the old invalid network the same time) Thanks for all your hard work, jtl ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
