4

I have been using my Raspberry Pi 1 for over a year as a wireless bridge. I purchased a Pi2 and wanted to move the SD card across, but the first thing I had to do was upgrade the distro to support the new processor on the new Pi2:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

This is where things started to go wrong as the WiFi stopped working from this point, so I think it is something related to the dist-upgrade.

My config looks like so:

lsusb 
Bus 001 Device 005: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]


/etc/network/interfaces:
allow-hotplug wlan0
allow-hotplug eth0
iface wlan0 inet dhcp
iface eth0 inet dhcp
wpa-iface wlan0
wpa-bridge br0
wpa-driver wext
wpa-conf /etc/wpa_supplicant/WPA.conf
auto br0
iface br0 inet dhcp
      bridge_ports wlan0 eth0
      bridge_stp off
      bridge_maxwait 5

/etc/wpa_supplicant/WPA.conf:
network={
    ssid="<removed>"
    psk=<removed>
}

On troubleshooting I edited the WPA.conf file as follows:

network={
    ssid="<removed>"
    proto=WPA RSN
    scan_ssid=1
    key_mgmt=WPA-PSK
    pairwise=CCMP TKIP
    group=CCMP TKIP
    #psk="<removed>"
    psk=<removed>
}

It made no difference. Here was some further troubleshooting I did and I checked the Pi can see the SSID

#sudo wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant/WPA.conf
rfkill: Cannot open RFKILL control device
ioctl[SIOCSIWAP]: Operation not permitted
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument

$iwconfig
wlan0     unassociated  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency=2.412 GHz  Access Point: Not-Associated   
          Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

wlan0     Scan completed :
          Cell 01 - Address: <removed>
                   ESSID:"<removed>"
                   Protocol:IEEE 802.11bgn
                   Mode:Master
                   Frequency:2.412 GHz (Channel 1)
                   Encryption key:on
                   Bit Rates:144 Mb/s
                   Extra:rsn_ie=30140100000fac040100000fac040100000fac020c00
                   IE: IEEE 802.11i/WPA2 Version 1
                       Group Cipher : CCMP
                       Pairwise Ciphers (1) : CCMP
                       Authentication Suites (1) : PSK
                   IE: Unknown: DDAE0050F204104A0001101044000102103B00010310470010FC5B2561C3AEE1C761E442CA1B754>D50102100154153555354654B20436F6D707574657220496E632E1023001C57692D46692050726F>74656374656420536574757020526F757465721024000852542D41433638551042001165303A336>63A34393A39343A64373A65301054000800060050F20400011011000852542D4143363855100800>022008103C0001011049000600372A000120
                   Quality=86/100  Signal level=62/100

$ ethtool -i wlan0
driver: rtl8192cu
version: 
firmware-version: 
bus-info: 1-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

What can I do to get this working again?

fileinsert
  • 193
  • 8
  • Try [my suggestion here](http://raspberrypi.stackexchange.com/q/37594/5538) for testing a simple WPA connection. The three commands suggested for `rc.local` in subshell notation (parantheses) after *"If you are using a wifi adapter...try...`iplink`...`wpa_supplicant`...`dhclient`"* can be run as is from the command line with `sudo` **after** you disable everything properly. This is just to check that it's not a driver or other fundamental issue; it should only take a few minutes... – goldilocks Nov 21 '15 at 19:27
  • ...Note that `wpa_supplicant` usually throws a few `rfkill` and `ioctl` warnings in my experience. The litmus test is `dhclient`, which may take a few dozen seconds but will report (if you use `-v`), then background itself. – goldilocks Nov 21 '15 at 19:27
  • thanks for your comments. Unfortunately that is exactly what I have been doing with no success. It has been working for over a year every day and it seems to be the dist-upgrade that killed it. I should also note that I have disabled the bridge and gone back to normal interfaces for troubleshooting and it has also made no difference. Is there something specific in the new distro that could affect this? – fileinsert Nov 21 '15 at 22:06
  • 1
    If that is "exactly what you have been trying" and it does not work, then somewhere in step 1 (`ip link ...`), step 2 (`wpa_supplicant ...`), or step 3 (`dhclient -v ...`), there would be explicit errors (other than the superflous rfkill, etc. warnings). **If this is the case, then you need to describe exactly what those errors are.** If there are no such errors, then dhclient will *very clearly* indicate it has a lease and go into the background. At that point, you are connected and the output of `ip addr` will show this. – goldilocks Nov 21 '15 at 22:40

1 Answers1

2

As I thought that is was the dist-upgrade was the cause of the issue I decided to start afresh and downloaded a fresh copy of Jessie and image the card. No sooner had I done this (and set up the AP settings again) than it worked. Interestingly enough the behaviour had changed as well. As Goldilocks correctly pointed out "there would be explicit errors" but they were not showing. In the new build errors were showing such as "Authentication/Association or connect commands not supported" when using the nl80211 driver. Another error I got was when I typed the wrong key when first setting up the system status and dmesg showed errors specifically stating that the key was wrong. These errors were not present on the upgraded build. I was in the fortunate position that a new install didn't cause me much pain as I had documented everything I had done to set up the Pi initially. Unfortunately I'm not sure the source of the issue, I don't know if dist-upgrade is broken or it was a single faulty upgrade.

fileinsert
  • 193
  • 8
  • Further information: I found out that it was due to an upgrade of the wpa_supplicant package the broke everything. When I held this package at an older revision it was OK. Unfortunately I cannot remember the version numbers of the version that worked and the version that didn't. – fileinsert Apr 14 '16 at 08:39