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 (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.

  • 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


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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.