| Summary: | Cannot make work my Broadcom BCM43228 wireless connection | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Juergen Harms <juergen.harms> |
| Component: | RPM Packages | Assignee: | Olivier Blin <mageia> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | ftg, jeff, mageia |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | drakx-net | CVE: | |
| Status comment: | |||
| Attachments: | snips from /var/log/syslog and various info described in the bug report | ||
Created attachment 3136 [details]
snips from /var/log/syslog and various info described in the bug report
Manuel Hiebel
2012-11-21 12:06:44 CET
Attachment 3136 mime type:
application/octet-stream =>
text/plain (not sure) Assignee:
bugsquad =>
mageia Are you trying to activate both wired and wireless interfaces at the same time ? If so, how does your DHCP server assign addresses ? I think the crux of the issue is why both interfaces are getting the same IP address. Yes, trying to use both interfaces at the same time (no problem with my old laptop). At first I strongly believed in the same-address theory - but things are more complicated - see below I did some more tests 1. ifdown on both interfaces 2. powercyle my router 3. boot 4. configure the wireless interface - no connection So, the problem also exists with a single connection Next 1. wit-T1h the wired connection still down 2. configure the wireless interface giving it a manual address (non-DHCP, well within the address pool) - still no connection That appears to indicate that the address conflict is only a secondary issue (but, yes, with 2 simultaneous connections there is the conflict) Running drakconnect on the wireless interface from a konsole, I get (after saying I want the connection now) the message Failed to create host name resolver: Invalid host name run-parts: /etc/sysconfig/network-scripts/hostname.d/avahi exited with return code 1 Is this significant? Some background on the router: My router is a Zyxel P-660-RU-T1 - no problems had so far (and - so far- perfectly handling the coexistance of wired and wireless connections for my old laptop - anyhow, the router creates connections and does probably not even know that request come from a single machine). And, I think that the test with the fixed address puts the router out of suspicion. Upon reflection, you're right. In fact, my DHCP server is set up to assign the same IP address to my laptop for both the wired and wireless interface. It's the METRIC that prevents confusion, since if both are active, wired will always trump wireless. I've seen something similar to this elsewhere, but I can't find the reference at the moment. First, check your syslog or dmesg for cfg80211 messages indicating that the driver is able to contact the access point. If it is, then I think the problem is that the "link beat not detected" comes out immediately, within the same second as the surrounding messages, without giving the device a chance to respond. This has been happening off and on for a while, but I think the latest round came in with a recent kernel which broke ifplugd wireless detection in this manner. You can refer to bug#2160 for instructions on actually getting NetworkManager to work, and then see if you can connect with NM controlling the interface. CC:
(none) =>
ftg > First, check your syslog or dmesg for cfg80211 messages
> indicating that the driver is able to contact the access point.
No cfg80211 messages whatever in my syslog (nor in dmesg) - does that mean that the driver does not talk to the access point? - I am out of my depth at this level
I had a look at bugzilla 2160. In my configuration (as it came out of sysconfig + updates + the packages loaded when I first configure the wireless interface) there is no networkmanager. Before potentially installing it, I would like to see clearer about the cfg80211 issue. Any suggestions?
I just compared with my old laptop which has a working wireless interface: that laptop contains a /sys/module/cfg80211/ directory - the new one (topic of this bug) does not. OK, check your syslog for any indication of an attempt to bring the wireless up during the boot sequence, e. g. search on the interface name being assigned to it, and see what happens when the driver gets loaded and tries to initialize the device. This will happen before ifplugd actually tries to activate the interface that uses the device. Basically, you want to separate the driver's ability to communicate with the device from the ability of ifplugd to activate the interface. After more looking around and googling, I gave up proceding by logical analysis (I had checked following your advice: practically nothing happens, I think the driver was not even loaded) and gave myself a single try at random "whatifs" (based on what I had seen looking at bug reports and googles): I installed networkmanager and knetworkmanagers, and now I have a perfectly working network interface - 2 minutes work. Several questions: (1) what about this bug: close it as resolved? the issue was: this specific broadcom device does not run if standard installation procedures applied; networkmanager makes the proof: a Mageia box contains the necessary ingredients - how make them ?eployed in the framework of standard installs? (2) any follow up? I am willing to contribute time to understand what did not work and how to make it work - but such follow-up must be driven by somebody who has much more knowledge then I have (3) info for "Mr. Anyuser" (Lieschen Müller in German): how give her/him the necessary info before he throws stones at his laptop and at Mageia? There needs to be some howto or whatever for non-specialists to get the wireless of their newly bought laptops working. The bug should remain open, at least until we can find the other bug (which may not exist, it may have been an ML thread) and mark it as a duplicate. The problem seems to be that recent kernel updates have broken the ability of ifplugd to detect the wireless state correctly. To summarize, if NM is not to be the default for MGA3, then somebody needs to fix ifplugd for newer kernels. But if NM is to be the default, there are other problems - unless you install and run GNOME and activate the wireless interface under GNOME, NM will not work for wireless under KDE (amd maybe other DEs) because it requires that the plasma-network-manager package be installed (it is not installed by default), added to the applet panel, and activated. The underlying requirement is that NM commands which parse the ifcfg-xxxx files have to be run on a one-time basis, and KDE does not do this by default, nor does drakconnect. For NM to work on an MGA install, *something* has to run this stuff. GNOME does this seamlessly, but nothing else appears to. Additional input to this summary: NM is not so dramatic with KDE. My desktop is KDE; I had originally (following what I had seen in Google) installed networkmanager along with knetworkmanager (plus some 10 modules it requires). Having achieved a working wireless interface, I made the experiment to remove the set of knetworkmanager modules again, just keeping NM: the interface still works, even after reboot. More: hotplugging the wifi also works perfectly(booting with the wireless switch off, and on demand switching it on). That had been a long-standing problem. You missed an important part of my comment: The underlying requirement is that NM commands which parse the ifcfg-xxxx files have to be run on a one-time basis The ifcfg files have to be "parsed" by NM in order to set up the NM equivalents. Otherwise, NM will fail to start any wireless interface and you will see messages in syslog about "parse of ifcfg-rh failed, SSID missing". Once that's been done (which it was by knetworkmanager), you're good to go whether you keep knetworkmanager or not. Actually, there are probably circumstances where you would still need those packages, e. g. a new access point (SSID) or deleting and redefining the interface, I can't be sure. The point is that if you have NM installed, which you will if you include GNOME in your selection of desktops, it will not work out-of-the-box in KDE unless you take the manual steps that you took. The current plan is that NM is not specified by default in drakconnect, and as long as ifplugd was working, that was fine. Now that ifplugd appears not to be working, NM may be the only choice unless ifplugd is fixed. If NM becaomes the default, then getting it to work out-of-the-box in KDE becomes critical. Hi, Ik have the same wireless card (BCM43228) in my HP Probook 6475b. It was default detected with the bcma module, but that one did not find the device in the "network manager". i switched to the broadcom-wl driver and that one was working. output from lspci: 03:00.0 Network controller: Broadcom Corporation BCM43228 802.11a/b/g/n I'm happy to do some testing for new patches if needed. Kind regards, Jeff CC:
(none) =>
jeff Seems to be duplicate *** This bug has been marked as a duplicate of bug 13976 *** Status:
NEW =>
RESOLVED |
Description of problem: I have a new Dell laptop (Latitude E6530). Using drakconnect to configure its wireless interface went well (installs 7 new packages), but when I try to start the connection, I get a failure message ("Problem occured during network connectivity test) - and that is solid, same thing when I try again, failure when I do ifdn / ifup. I am joining an attachment with snippets from /var/log/syslog, the konsole output of drakconnect, and copies of /var/lib/dhcp files (/etc/sysconfig/network-scripts/ifcfg-eth1 is identical to what I get on my old laptop - looks OK). Looking at syslog, I was struck by the message Nov 21 09:20:50 ltjuergen dhclient: Trying recorded lease 192.168.0.23 because 192.168.0.23 is the address used by my wired interface. I therefore looked at the dhcp lease files and saw that both interfaces used the same IP address. After erasing the lease files and than reconfiguring first the wireless and than the wired interface, I got both the wired and the wireless interface working. But this is not reproducible, after a reboot my wireless interface was dead again, and this time I did not manage to bring it up. One more observation: when I do ifup eth1, I get the message /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf . Recreating. But, in fact /etc/resolvconf is a directory that contains a link: run -> ../../run/resolvconf/ Sorry for this lengthy description,. My configuration: Mageia3 Alpha3 fully updated (x86_64), Broadcom BCM43228 (wireless), Intel 82579LM (wired). Both interfaces automatic (DHCP), with standard options. Version-Release number of selected component (if applicable): I do not know which component is at fault - I am using dhcp-client-4.2.4P2-1.mga3 resolvconf-1.68-1.mga3 How reproducible: Always (except the workaround erasing the release files) Steps to Reproduce: 1. drakconnect 2. configure wireless interface (see above) 3. start the connection now (or do ifdown eth1 followed by ifup eth1)