Description of problem: When using the broadcom closed wireless driver with BCM4313, the mageia network tool detects the interface as wired network. The problem is mostly cosmetic since it still works just fine. However, some information is lost because of this. For example, wireless signal stength and access point encryption aren't shown. I wonder if this isn't why drakx-net typically fails to complete the configuration if it's expecting to find a wired connection instead of a wireless connection. The notification area shows the connection a wired while opening the configuration tool shows a wireless connection. See attachment. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install broadcom-wl driver 2. Attempt to configure network with mageia's tool 3. Reproducible: Steps to Reproduce:
Created attachment 3735 [details] Screenshot showing inconsistent interface
Priority: Normal => LowCC: (none) => thierry.vignaudAssignee: bugsquad => mageiaSeverity: normal => minor
Summary: Broadcom wireless connection detected as wired connection by drakx-net => Broadcom wireless connection detected as wired connection by net_center (but as wireless in draknetcenter)
Created attachment 3907 [details] detect wireless devics using phy80211 sysfs dir too Does this patch on /usr/lib/libDrakX/detect_devices.pm help?
Status: NEW => ASSIGNED
Unfortunately, the bug is still present after patching detect_devices.pm.
Thanks for testing. What is the content of your /sys/class/net/eth1 directory? (replace eth1 with your BCM4313 interface name if needed)
[root@localhost eth1]# pwd && ls -l /sys/class/net/eth1 total 0 -r--r--r-- 1 root root 4096 mai 9 07:52 addr_assign_type -r--r--r-- 1 root root 4096 mai 9 07:38 address -r--r--r-- 1 root root 4096 mai 9 07:52 addr_len -r--r--r-- 1 root root 4096 mai 9 07:52 broadcast -r--r--r-- 1 root root 4096 mai 9 07:40 carrier lrwxrwxrwx 1 root root 0 mai 9 07:38 device -> ../../../0000:02:00.0/ -r--r--r-- 1 root root 4096 mai 9 07:38 dev_id -r--r--r-- 1 root root 4096 mai 9 07:52 dormant -r--r--r-- 1 root root 4096 mai 9 07:52 duplex -rw-r--r-- 1 root root 4096 mai 9 07:52 flags -rw-r--r-- 1 root root 4096 mai 9 07:52 ifalias -r--r--r-- 1 root root 4096 mai 9 07:39 ifindex -r--r--r-- 1 root root 4096 mai 9 07:52 iflink -r--r--r-- 1 root root 4096 mai 9 07:52 link_mode -rw-r--r-- 1 root root 4096 mai 9 07:52 mtu -rw-r--r-- 1 root root 4096 mai 9 07:52 netdev_group -r--r--r-- 1 root root 4096 mai 9 07:52 operstate drwxr-xr-x 2 root root 0 mai 9 07:52 power/ drwxr-xr-x 4 root root 0 mai 9 07:52 queues/ -r--r--r-- 1 root root 4096 mai 9 07:52 speed drwxr-xr-x 2 root root 0 mai 9 07:52 statistics/ lrwxrwxrwx 1 root root 0 mai 9 07:39 subsystem -> ../../../../../../class/net/ -rw-r--r-- 1 root root 4096 mai 9 07:52 tx_queue_len -r--r--r-- 1 root root 4096 mai 9 07:38 type -rw-r--r-- 1 root root 4096 mai 9 07:38 uevent drwxr-xr-x 2 root root 0 mai 9 07:39 wireless/
If you right-click on net_applet and go in the "Wireless networks" menu, do you see a list of wireless networks? There should be a least the connected one.
I'm currently connected wirelessly, however the list in the applet's menu is empty. Even the AP I'm connected to doesn't appear.
It's strange because after patching the file as you suggested trying, I removed the interface and reconfigured it from scratch in MCC. At that point, after selecting the broadcom closed driver, I was presented with a list of access points. So at least during the configuration, it knowns that it's a wireless connection and not a wired connection. However, the configuration tool always fails to establish a connection once everything is setup. Rebooting the system is the only way to succesfully establish a connection. I'm wondering if this isn't what's causing the connection to fail at the end of the configuration. You start out with a wireless connection, but somewhere along the line, something goes wonky and the tools suddently thinks it's a wired connection. Here's the usual methodology 1) Configure interface for wireless and select access point with correct parameters. 2) Attempt connection once configured. 3) Connection attempt fails. 4) Reboot. 5) System boots up with active connection. 6) Change location and/or access point (say if you go from your house to school) 7) Attempt connection to new AP. 8) Connection attempt fails. 9) Reboot. 10) System boots up with active connection to new AP. 11) Cycle repeats every time I change location. I'm wondering if this current bug isn't responsible for the wonkyness of the wireless connection. My interface is having an identity crisis.
But at least the patch did help detecting it at wireless instead of wire? So I think we should close the original bug. Please open a new one if you still has connection issues with mga4 or cauldron.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED