Bug 132661
Summary: | different wireless configurations must be manually activated | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jon Nettleton <jon.nettleton> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | redhat-bugs2eran, rvokal |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-30 21:55:30 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Jon Nettleton
2004-09-15 17:07:44 UTC
Created attachment 103871 [details]
first attempt at a function to return wireless ap's
This function uses iwlist to get a list of available ESSID's and the quality of
their signal. It then sorts the ESSID's by signal. It returns all the essid's
found ignoring any ap's with hidden essid's or essid's made up of entirely
spaces. All essid's are then manipulated so spaces and -'s are changed to _'s.
Created attachment 103872 [details]
when initializing wireless we should scan to see if any ap's are preconfigured
This changes the default behaviour of what is done when a card returns
is_wireless_device = true. It brings up the link on the wireless device then
calls the scan_wireless_ap function to get an ordered list of available ap's.
It then checks if a configuration file exists with a name of
ifcfg-DEVICE_ESSID. ESSID has all space's and -'s changed to _'s as needed by
the system_network_config utility. The behaviour is setting the main
ifcfg-DEVICE with onboot=YES or hotplug=yes, this initializes the device scan's
and then ifup's any configurations it finds.
Created attachment 103878 [details]
nicely formatted patch for network-functions
I accidentally uploaded my ugly all in one line function. This patch has a
more readable formatting.
Interesting, but you might as well look for a HWADDR that matches that has ESSID for the appropriate value in it, as opposed to doing it by filename. You may also want to look at NetworkManager. The reason that I am not looking only for a HWADDR to ESSID relationship is that it leaves the problem that two profiles with the same HWADDR and ESSID have been created. The only guarantee of not running into duplicates are filenames on the filesystem. I am trying to approach this from a systems administrator viewpoint if they were solely using the system-config-network-gui utility. They could very easily create a default profile and then copy that wireless profile customizing it per location. This allows you to setup static wireless configurations that any user on the machine can use, but not change. It also allows static ip addresses to be used if so desired. I have tried NetworkManager and I think it will be great for a per user coffee shop quick setup. However it doesn't read the ifcfg files for ESSID information of pre-configured ESSID's. This means every user needs the KEY for an AP in their gnome-keyring. NetworkManager also can't start until after dbus and hal are setup, which is well after the point in the init process where the rest of the Networking is setup so things like ntp will always fail. I do see that in the ifup portion of my patches I need to check to see if USERCTL is set and whether HWADDR matches before deciding that the specified file is actually the one that should be ifup'd. I really just think that this approach gives a greater flexibility in the boot process, using already existing information. Why would anyone have two profiles with the same HWADDR and ESSID? Seriously, I'm not sure I see the usage case for that. You can also just scan for the essid in the file instead of hwaddr+essid; it accomplishes the same thing. Currently you can only add one KEY per profile so it is plausible that an administrator that has a single ESSID, but different key's per location would create multiple profiles. I wouldn't do it, my patches don't take it into account, but they prevent it from incorrectly choosing a profile. This is the same reason I don't just scan for an ESSID. There is nothing that is stopping an admin from creating multiple profiles with the same ESSID, one configured with dhcp, the other with a static ip address. I am not claiming that my solution is the most elegant, I am just trying to provide a solution that has the least amount of gotchas, without doing a major overhaul to the network admin gui. It is very true that there might not be use cases to do something, but the gui lets you do it. That inevitably means that people using the gui will do it and it can lead to problems. My only claim is if a wireless card has scanning enabled, and profiles are setup as ifcfg-DEVICE_essid, that the correct profile will be chosen on ifup of the main device. This is caveated with the fact I need to do some more checking in ifup for USERCTL and HWADDR. With the continuing use of NetworkManager, I'm not going to change this in this way; eventually most of the networking stuff will get replaced with calls into NetworkManager. |