1

I'm using Linux Mint 17.3 Rosa in a Dell Inspiron 1525 laptop. Wireless connection has been working for years in this laptop in different linux distros with proprietary Broadcom driver. I formated my computer 14 days ago, and wireless was working fine after that. I have been alternating between cabled and wireless connection. Yesterday, after disconnecting my cable connection, suddenly I could not use wireless anymore. The wifi networks are listed, but I cannot connect to them. I have confirmed (with other computer) that the network is working properly. I checked the packages that were installed or updated since last time wifi was working, and there were none. My kernel version is

$ uname -a
Linux mycomputer 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:37:25 UTC 2015 i686 i686 i686 GNU/Linux

Here is my wireless card:

$ lspci -knn | grep Net -A2
0b:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g LP-PHY [14e4:4315] (rev 01)
Subsystem: Dell Wireless 1395 WLAN Mini-Card [1028:000b]
Kernel driver in use: wl

Here is my dmesg output:

$ dmesg | grep wl
[   11.216767] wl: module license 'MIXED/Proprietary' taints kernel.
[   11.225409] wl: module verification failed: signature and/or  required key missing - tainting kernel
[   11.476882] wlan0: Broadcom BCM4315 802.11 Hybrid Wireless Controller 6.30.223.248 (r487574)

Here is the output of iwconfig:

$ iwconfig
wlan0     IEEE 802.11abg  ESSID:"housenet"  
      Mode:Managed  Frequency:2.462 GHz  Access Point: 20:CF:30:C6:32:A5   
      Retry short limit:7   RTS thr:off   Fragment thr:off
      Power Management:off

lo        no wireless extensions.

eth0      no wireless extensions.

Here is ip output (I don't know why it has state DORMANT and mode DORMANT):

$ ip link show wlan0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT mode DORMANT group default qlen 1000
link/ether 00:23:4d:a8:e4:77 brd ff:ff:ff:ff:ff:ff

Also, rfkill seems to show no problem.

$ rfkill list all
0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no
1: brcmwl-0: Wireless LAN
    Soft blocked: no
    Hard blocked: no

I've tried changing the driver from bcmwl-kernel-source to firmware-b43-installer, reboot the computer, but the problem persists. Strangely, the same problem is now happening in the USB-live version of LM 17.3.

10
  • Check what I posted half an hour ago: askubuntu.com/questions/791287/… Can you connect to any network with another distro?
    – user150867
    Jun 25, 2016 at 14:09
  • I don't have another distro on this machine, only Windows.
    – Jack Antares
    Jun 25, 2016 at 14:18
  • But does it work there? Because if it does that would indicate a non-hardware problem - if you read my own thread, I've tried using other distros, including a completely fresh, live USB and it still failed. For the life of me, I can't imagine how a non-hardware issue can appear like that in different distros, including one booting from a live USB
    – user150867
    Jun 25, 2016 at 14:24
  • @DigitalDracula it could also be a driver issue, not necessarily hardware.
    – nixpower
    Jun 25, 2016 at 14:26
  • @DigitalDracula I've tried in the live-USB of LM 17.3 and the problem is also happening there. Jun 25, 2016 at 14:43

1 Answer 1

1

I solved my similar issue, maybe this applies to you too.

It appears I had accidentally pressed Fn + F2, which in this Fujitsu Siemens turns off the wifi. And, surprise-surprise, it remembers the choice even after a shutdown.

Check to make sure there isn't a physical button or shortcut combo like mine which deactivates your wifi. Apparently this persists between reboots.

4
  • But in this case you shouldn't be seeing the networks, right? Jul 1, 2016 at 16:40
  • Good question. Apparently you can. Maybe the shortcut blocks the card from connecting, but allows scanning.
    – user150867
    Jul 2, 2016 at 14:27
  • On my version (v30 in Ubuntu 16.04) iwconfig also shows the TxPower. It says off when in airplane mode, and 13dBm when enabled.
    – xenoid
    Apr 8, 2018 at 20:59
  • It is usually a physical cut-off switch, so persisting across reboots is expected behaviour. Apr 8, 2019 at 17:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .