Bug 485477
Summary: | Incorrect nm-applet menu signal strength with multiple APs | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Dan Williams <dcbw> |
Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
Status: | CLOSED ERRATA | QA Contact: | desktop-bugs <desktop-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 5.3 | CC: | cmeadors, rlerch, zcerza |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Due to faulty logic in the code, nm-applet would choose the lowest signal strength of all APs of the same SSID in the area and display this strength in the menu to represent the signal strength for that SSID. Any SSID with more than one AP would therefore appear to have a weaker signal than it really did. The logic srror is corrected, and NetworkManager now correctly calculates wireless signal strength when multiple access points with the same SSID are present.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2009-09-02 11:54:16 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: |
Description
Dan Williams
2009-02-13 17:47:54 UTC
How does one discern that the best signal strenght calulation was incorrect from an end user point of view? In an area with multiple APs, buggy nm-applet would always show the lowest signal strength of all APs of the same SSID in the menu. Updated NM should show much higher signal strength for a laptop in the same location. Would be sufficient to: 1) Find an area with multiple APs using the same SSID and security-settings (RH Westford will work fine for this) 2) Set up machine with updated/fixed NM; copy /usr/bin/nm-applet to a temp directory 3) Install old NM on the machine, reboot 4) On login, take a screenshot of the applet menu (use 'gnome-screenshot --delay=10' from a terminal, then open the applet menu, and wait for the screenshot) 5) killall -TERM nm-applet 6) /path/to/temp/nm-applet 7) take a screenshot of the menu again comparing the two screenshots should show greatly increased signal strength for the SSID in question (ie, rh-wireless). The key is to try to make steps 4 - 7 fairly quick; they should be able to be done in less than 15 seconds. The reason to do the temp nm-applet dance is to ensure that the new applet (where the change actually is) is using the same dbus data as the old nm-applet, but presenting it correctly. The test could also be done by taking screenshots of the old applet a few times over 15 minutes, then installing the new NetworkManager RPMs, rebooting, and then taking screenshots of the new nm-applet over a period of 15 minutes, and comparing the old and new screenshots. You should see substantially better "signal strength" in the menu of the new applet. nm-applet-0.7-ap-menu-strength-rh485477.patch Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Due to faulty logic in the code, nm-applet would choose the lowest signal strength of all APs of the same SSID in the area and display this strength in the menu to represent the signal strength for that SSID. Any SSID with more than one AP would therefore appear to have a weaker signal than it really did. The logic srror is corrected, and NetworkManager now correctly calculates wireless signal strength when multiple access points with the same SSID are present. Verified on NetworkManager-0.7.0-7.el5.{i386,x86_64}. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1389.html |