Automatic setup for RTL8188CUS based wifi adapters

[MrEngman]

This is working pretty good. The issue being headless is there a way to allow for multiple networks?
Currently in /etc/network/interfaces I have an entry like:

Code: Select all

auto wlan0
iface wlan0 inet dhcp
wpa-ssid "myssi"
wpa-psk "mypass"

Is there a format that I can use which would allow the device on its own to see and use a known network when I am in range? For example, at work I know the WiFi there but since it is headless, it would be hard to do without having to hookup a keyboard and monitor.

Or do I need more scripts to do this?

You can use wpa_supplicant. There's a load of stuff on the forums and internet on how to set it up.

Try this for a start http://www.raspberrypi.org/phpBB3/viewt ... 56#p150556

[Dweeber]

Will look into that. That would make the headless part work in known locations which would not be very many. 2 at home, Portal via my phone and the full set at work (uses the same ssid and password for all 30 AP's).

Been around Unix for a long time, but have never done any wireless with it. Always fixed Ethernet.

[mattura]

My version is:

Linux raspberrypi 3.1.9-cutdown-aufs #23 PREEMPT Mon Aug 13 15:20:21 CEST 2012 armv6l GNU/Linux

Due to this, the script fails. Is there a driver file for this distro? If not, how would I go about compiling it?
Thanks

Where can I find this image?

Sorry for the delay, work tends to get in the way of raspberry pi fun!
The image from Berryboot should be here:
http://178.63.95.79/dl/Debian_Wheezy_Raspbian.img192
Thanks

[bluesman13]

Hello,
My Raspbian set-up with an "Edimax EW-7811UN" dongle was working fine, but warning messages at boot-up disturbs me. Here are the messages :
==================================================
Configuring network interfaces ...
ioctl[SIOCSIWAP]: Operation not permitted
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/80:1f:02:4b:7d:70
Sending on LPF/wlan0/80:1f:02:4b:7d:70
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.0.254
DHCPACK from 192.168.0.254
bound to 192.168.0.22 -- renewal in 18248 seconds.
==================================================
Is it possible to remove these messages : ioctl[xxx] ?
Thank you.

[MrEngman]

Hello,
My Raspbian set-up with an "Edimax EW-7811UN" dongle was working fine, but warning messages at boot-up disturbs me. Here are the messages :
==================================================
Configuring network interfaces ...
ioctl[SIOCSIWAP]: Operation not permitted
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/80:1f:02:4b:7d:70
Sending on LPF/wlan0/80:1f:02:4b:7d:70
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.0.254
DHCPACK from 192.168.0.254
bound to 192.168.0.22 -- renewal in 18248 seconds.
==================================================
Is it possible to remove these messages : ioctl[xxx] ?
Thank you.

Possibly. It's something to do with wpa_supplicant. Loads on the internet about it.

I see them but don't appear to have any problems with my wifi.

[Jim Ford]

Hello,
My Raspbian set-up with an "Edimax EW-7811UN" dongle was working fine, but warning messages at boot-up disturbs me. Here are the messages :
==================================================
Configuring network interfaces ...
ioctl[SIOCSIWAP]: Operation not permitted
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/80:1f:02:4b:7d:70
Sending on LPF/wlan0/80:1f:02:4b:7d:70
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 17
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.0.254
DHCPACK from 192.168.0.254
bound to 192.168.0.22 -- renewal in 18248 seconds.
==================================================
Is it possible to remove these messages : ioctl[xxx] ?
Thank you.

Looks normal to me and I wouldn't worry about it.

Jim

[wallarug]

Is there an update for the latest raspbian image?

[Dweeber]

Is there an update for the latest raspbian image?

The update script that I just grabbed appears to have as the newest entry:

#41 PREEMPT Tue Aug 21 15:51:24 BST 2012
Latest Driver: 8192cu-20120819.tar.gz

I thought there was a new driver for each kernel release but perhaps not.

I planned on setting up a daily grab which would allow me to diff the differences to quickly tell what versions it currently supported and auto post the info to a info web page. But I've not yet gotten to it.

Since the device files are in a dropbox instead of a ftp like directory, it is hard to easily see what new files might be there without parsing the install script to find them.

**Added** also, I'm sure there is a way to tell what the current version of Rasperian is before doing the update to make sure that an updated driver is already available before doing the update, but I am not real familiar with the apt-get update process to know if there is a info only test run to get the info. I'm sure there is (might be available on a website as well).

With all the collected info you could.

o Know that if you do an update you will end up with XXX version
o The wifi update script current supports version XXX
o and the driver for that is filename XXX

[wallarug]

Is there an update for the latest raspbian image?

The update script that I just grabbed appears to have as the newest entry:

#41 PREEMPT Tue Aug 21 15:51:24 BST 2012
Latest Driver: 8192cu-20120819.tar.gz

I thought there was a new driver for each kernel release but perhaps not.

I planned on setting up a daily grab which would allow me to diff the differences to quickly tell what versions it currently supported and auto post the info to a info web page. But I've not yet gotten to it.

Since the device files are in a dropbox instead of a ftp like directory, it is hard to easily see what new files might be there without parsing the install script to find them.

**Added** also, I'm sure there is a way to tell what the current version of Rasperian is before doing the update to make sure that an updated driver is already available before doing the update, but I am not real familiar with the apt-get update process to know if there is a info only test run to get the info. I'm sure there is (might be available on a website as well).

With all the collected info you could.

o Know that if you do an update you will end up with XXX version
o The wifi update script current supports version XXX
o and the driver for that is filename XXX

Just installed all fine.

[MrEngman]

Is there an update for the latest raspbian image?

The update script that I just grabbed appears to have as the newest entry:

#41 PREEMPT Tue Aug 21 15:51:24 BST 2012
Latest Driver: 8192cu-20120819.tar.gz

I thought there was a new driver for each kernel release but perhaps not.

I planned on setting up a daily grab which would allow me to diff the differences to quickly tell what versions it currently supported and auto post the info to a info web page. But I've not yet gotten to it.

Since the device files are in a dropbox instead of a ftp like directory, it is hard to easily see what new files might be there without parsing the install script to find them.

**Added** also, I'm sure there is a way to tell what the current version of Rasperian is before doing the update to make sure that an updated driver is already available before doing the update, but I am not real familiar with the apt-get update process to know if there is a info only test run to get the info. I'm sure there is (might be available on a website as well).

With all the collected info you could.

o Know that if you do an update you will end up with XXX version
o The wifi update script current supports version XXX
o and the driver for that is filename XXX

There is a document with the list of available drivers and compatible llinux versions at http://dl.dropbox.com/u/80256631/install-rtl8188cus.txt

Trying to find the version of a new install is something I'm also trying to work out. Without this info it is possible that a driver can be installed in the wrong place or the wrong driver version may be used and after a reboot the wifi will not work. The script then has to be re-run to install the driver in the right place.

This is a particular problem when the version running is 3.1.9+ and the new version installed changes to 3.2.27+. The script will install in /etc/modules/3.1.9+/.... but when the new install is rebooted the driver is expected to be in /etc/modules/3.2.27+/.... The script then has to be run again to install the driver in /etc/modules/3.2.27+/.... to get it back working.

This is also a problem when using apt-get update which now installs RPi firmware updates as well. The updates do not update to the latest available version but to some intermediate point so trying to determine the driver version required is a real problem.

As an example I made an image of 2012-07-15-wheezy-raspbian and then ran the script to install the wifi. Wifi was installed ok but then when apt-get update ran it changed the RPi firmware etc. to an unknown version. So rebooted and the wifi stopped working. Ran the script again and updated the wifi and it started working again but then rpi-update ran and changed the linux version from 3.1.9+ to 3.2.27+. After rebooting the wifi stopped working again as the script had installed the driver in 3.1.9+, not 3.2.27+ as it does not know how to determine the version of a new install. So ran the script again and finally ended with a working wifi. So had to run the script 3 times in succession to get the wifi up and running with the latest code.

One way round this may be to run rpi-update or apt-get update and reboot to get the latest firmware/software installed running and then run the script.

If you find out how to identify the version of linux that the RPi will end up with after apt-get update or rpi-update can you let me know how? Would be really, really useful.

MrEngman

[Max]

[This is also a problem when using apt-get update which now installs RPi firmware updates as well. The updates do not update to the latest available version but to some intermediate point so trying to determine the driver version required is a real problem.

As an example I made an image of 2012-07-15-wheezy-raspbian and then ran the script to install the wifi. Wifi was installed ok but then when apt-get update ran it changed the RPi firmware etc. to an unknown version. So rebooted and the wifi stopped working. Ran the script again and updated the wifi and it started working again but then rpi-update ran and changed the linux version from 3.1.9+ to 3.2.27+. After rebooting the wifi stopped working again as the script had installed the driver in 3.1.9+, not 3.2.27+ as it does not know how to determine the version of a new install. So ran the script again and finally ended with a working wifi. So had to run the script 3 times in succession to get the wifi up and running with the latest code.

One way round this may be to run rpi-update or apt-get update and reboot to get the latest firmware/software installed running and then run the script.

Sounds overly complicated.

Was wondering if any attempt has been made into either fixing the non-working kernel module that is part of the main kernel, or getting this alternative module added to the raspberrypi kernel git?
So that it gets build and shipped automatically with all distributions.

[piglet]

That gets my vote. Having wifi broken after every update is a right royal pain!

[MrEngman]

[This is also a problem when using apt-get update which now installs RPi firmware updates as well. The updates do not update to the latest available version but to some intermediate point so trying to determine the driver version required is a real problem.

As an example I made an image of 2012-07-15-wheezy-raspbian and then ran the script to install the wifi. Wifi was installed ok but then when apt-get update ran it changed the RPi firmware etc. to an unknown version. So rebooted and the wifi stopped working. Ran the script again and updated the wifi and it started working again but then rpi-update ran and changed the linux version from 3.1.9+ to 3.2.27+. After rebooting the wifi stopped working again as the script had installed the driver in 3.1.9+, not 3.2.27+ as it does not know how to determine the version of a new install. So ran the script again and finally ended with a working wifi. So had to run the script 3 times in succession to get the wifi up and running with the latest code.

One way round this may be to run rpi-update or apt-get update and reboot to get the latest firmware/software installed running and then run the script.

Sounds overly complicated.

Was wondering if any attempt has been made into either fixing the non-working kernel module that is part of the main kernel, or getting this alternative module added to the raspberrypi kernel git?
So that it gets build and shipped automatically with all distributions.

Just making change from 3.1.9+ to 3.2.27+. Normally its not too bad.

I have no idea about anyone trying to fix the built in driver. Would be useful. I've taken a brief look at it but don't have much of a clue as to what to look for.

As for including the alternative look here https://github.com/Hexxeh/rpi-firmware/issues/1

MrEngman

[Max]

As for including the alternative look here https://github.com/Hexxeh/rpi-firmware/issues/1

If someone is willing to create a pull request that adds 8192cu support, and to be responsible for fixing it up if a kernel update breaks it, then we might make an exception.

So that would be an option.


(cannot help with that, as I do not have a 8192cu device myself.
Reason for asking, is that I maintain Berryboot which uses a custom kernel with aufs patch, and some users complained that they weren't able to use your script with that.
While I could add the module to my own build, it would be easier if it was part of upstream. Also in regard to testing with each release. I can only "test" that it compiles).

[pwillard]

(Sad face)

Using NETGEAR G54/N150 ()
Tested "latest" script on SQUEEZE and WEEZY debian releases. I have only tried debian releases.

Seems to build stuff OK.
lsusb says: "NetGear, Inc. WNA1000M 802.11bgn [Realtek RTL8188cus]"
wlan0 gets created and configured (/etc/network/interfaces looks right and has good WPA settings) , .

In both cases, dongle flashes at the right time but the script hangs at waiting for adapter to connect.

On reboot, it never succeeds in getting DHCP response.

I have seen other people do the same thing in blogs and say they had no issues with this device.

[Dweeber]

I finally hooked up to eth0, but it is very flakey. I can seem to only get a connection if the WiFi card is attached. Even then, sometimes I can't get it to work.

I decided to do an update to see if that fixed the problem... well...

Linux raspberrypi 3.2.27+ #60 PREEMPT Thu Aug 23 15:33:51 BST 2012 armv6l GNU/Linux

Turns out to be very new, newer than the script (of course).

Now I can still get to WiFi locally, and even Eth0, but no longer can get to the Internet which is weird...

route -n (when both connected):

Code: Select all

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

route -n (when only WiFi is connectect):

Code: Select all

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

I'm pretty sure that is what it was before.

In either case, I can ping local, but can't get remote. It is not a DNS issue as it finds the IP correctly...

Code: Select all

root@raspberrypi:~# ping www.google.com
connect: Network is unreachable

traceroute to www.google.com (74.125.224.209), 30 hops max, 60 byte packets
connect: Network is unreachable

but I can ping local

Code: Select all

root@raspberrypi:~# ping 192.168.1.12
PING 192.168.1.12 (192.168.1.12) 56(84) bytes of data.
64 bytes from 192.168.1.12: icmp_req=1 ttl=128 time=14.3 ms
64 bytes from 192.168.1.12: icmp_req=2 ttl=128 time=8.27 ms
64 bytes from 192.168.1.12: icmp_req=3 ttl=128 time=8.18 ms
^C

Current /etc/network/interfaces file:

Code: Select all

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.51
netmask 255.255.255.0
gateway 192.168.1.1
network 192.168.1.0
broadcast 192.168.1.255

allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

When running the current install script I get:

Code: Select all

Press any key to continue...

An RTL8188CUS driver module is installed and loaded.

You have 1 wifi adapter configured.
wlan0 is configured, installed, and has a network connection.

The Pi has no Internet connection.

[MrEngman]

I finally hooked up to eth0, but it is very flakey. I can seem to only get a connection if the WiFi card is attached. Even then, sometimes I can't get it to work.

I decided to do an update to see if that fixed the problem... well...

Linux raspberrypi 3.2.27+ #60 PREEMPT Thu Aug 23 15:33:51 BST 2012 armv6l GNU/Linux

Turns out to be very new, newer than the script (of course).

Script was updated a couple of hours ago. You just beat me to it. So many changes in the last few days what on earth is going on?

Anyway I'm not sure about the rest of your post but I'll take a look at my Pi and see if I can see anything.

As you say things are a bit flaky even with eth0 is your power OK? And how about your router. I had mine go down a while back - aluminium capacitors burst their cases giving power issues in the router which caused some wierd behaviour - replaced them and all was well again.

MrEngman

[Dweeber]

I am loading up another SDcard with the current Wheezy from the main download page (MicroUSB in a SDcard adapter).... I will setup a basic Eth0 and see if that works okay. If so, I will work from there.

If not, I will go back to the one I was using and try to update the drivers manually again.

Funny I had postponed updating but had some time and wanted to get current to see if that would fix the Eth0 issues I was having.

[MrEngman]

I am loading up another SDcard with the current Wheezy from the main download page (MicroUSB in a SDcard adapter).... I will setup a basic Eth0 and see if that works okay. If so, I will work from there.

If not, I will go back to the one I was using and try to update the drivers manually again.

Funny I had postponed updating but had some time and wanted to get current to see if that would fix the Eth0 issues I was having.

You will have to run the script several times (maybe x3) in succession to get it working unless you update to the current version before installing the wifi. I'm in the process of checking a further update to reduce this problem but it will take a while.

Regarding your route -n outputs. I see the same as you do.

MrEngman

[Dweeber]

Interesting experience... I started with the current Wheezy Rasberian in the Download directory.
By default, that sets up an entry for dhcp eth0. Regardless what I tried, no go. Will deal with that later with another router (I have 5 to play with).

Next, I preloaded an SDCard with the latest script, and I copied the
8192cu-20120819.tar.gz
install-rtl8188cus-latest.sh

But it never occured to me it would need the older 8192cu-20120726.tar.gz driver file...

So the first try at loading the WiFi stuff failed, because I didn't have the driver file for the version of Kernel the download gave me. Copied it to an USB Drive, but failed to see the WiFi device... So I rebooted without the USBDrive and Wifi and tried it again and this time it saw it okay.

I then let it do the big update.....

After it was done, I found that the driver I had preloaded was gone. Apparently the script removes them all when it does its thing... So I had to unplug the WiFi, reinsert the USBdrive, copy the driver over again (made copies in other locations just in case) and tried it again.... works.

So I am now almost back to where I was (still have to load a few packages and setup some config stuff) but now with the current kernel..

Linux raspberrypi 3.2.27+ #60 PREEMPT Thu Aug 23 15:33:51 BST 2012 armv6l GNU/Linux

Will play with the eth0 stuff some time later. Will setup one of my test routers on a different network.

Oh and now I have an SDCard with 16GB instead of the original 8GB I started with which was another goal.

[MotoBlue]

When both LAN and WLAN are connected, the default route (there's only one - that's why it is default) is via the lowest cost route ie the LAN. Disconnect the LAN and one would only be able to access the local network.

Rebooting with just the WLAN connected and the default route (0.0.0.0) will be via the WLAN. Reconnect the LAN and the default route will remain via the WLAN.

[swizzard]

Hi,
General problem: my MicroNext dongle used to work fine. Now it can't seem to find my wifi network.
Specifics: I just upgraded to the latest version of wheezy. The script seems to work fine (I don't have long enough cords to plug both my ethernet and my tv into my RasPi, so I have to do the put-the-tar-on-the-sd trick), but when it gets to the part where you enter you wifi info, the script claims my network isn't visible. I know the network is broadcasting its SSID, because I can see it from the computer I'm posting this from. I tried plugging the dongle into my powered hub as well as directly into one of the Pi's onboard USB slots; neither worked. There is an apostrophe in my network SSID but a)I can't change that (it's an airport and my Mac is in the shop), and b)the script didn't have a problem with it before. Suffice it to say, I has a sad.


(Slightly off-topic: assuming this all gets fixed, how would I ever be able to use a different network than the one I picked when running the script? The script says wlan0 doesn't support scanning. I'd like to be able to take my pi places and use wireless networks beyond my home network. Would I have to remember their SSIDs and then manually enter them into some config file? That seems cumbersome.)

[MrEngman]

Hi,
General problem: my MicroNext dongle used to work fine. Now it can't seem to find my wifi network.
Specifics: I just upgraded to the latest version of wheezy. The script seems to work fine (I don't have long enough cords to plug both my ethernet and my tv into my RasPi, so I have to do the put-the-tar-on-the-sd trick), but when it gets to the part where you enter you wifi info, the script claims my network isn't visible. I know the network is broadcasting its SSID, because I can see it from the computer I'm posting this from. I tried plugging the dongle into my powered hub as well as directly into one of the Pi's onboard USB slots; neither worked. There is an apostrophe in my network SSID but a)I can't change that (it's an airport and my Mac is in the shop), and b)the script didn't have a problem with it before. Suffice it to say, I has a sad.


(Slightly off-topic: assuming this all gets fixed, how would I ever be able to use a different network than the one I picked when running the script? The script says wlan0 doesn't support scanning. I'd like to be able to take my pi places and use wireless networks beyond my home network. Would I have to remember their SSIDs and then manually enter them into some config file? That seems cumbersome.)

As you say the script says "wlan0 doesn't support scanning" this may be an issue with the file /etc/udev/rules.d/70-persistent-net.rules. Seems a favourite at the moment. Check the file doesn't contain more than one line referencing wlanx - x=0,1,2 etc. There is some issue with wifi adapters and this file. I don't know why but it can contain spurious connections to invalid devices causing your wifi to be given a name other than wlan0. This is also the case if you plug in more than one different wifi adapter. Each will be given a different name even when not configured. Delete all lines in this file containing references to wlanx. Or if it only contains references to wlanx devices you can just delete the whole file.

Code: Select all

sudo rm /etc/udev/rules.d/70-persistent.net.rules

no need for sudo if logged in as root user.

To access a variety of networks without needing to edit /etc/network/interfaces every time you change to a different network you need to use wpa_supplicant. You can then setup the wpa_supplicant configuration to point to all the networks you are intersted in connecting to. My knowledge of wpa_supplicant is very limited but there's a load of stuff in the forums and on the internet. There are some posts back in this thread about it.

MrEngman

[Dweeber]

Now it can't seem to find my wifi network.
...
The script says wlan0 doesn't support scanning.

I had the both of the issue during my recent upgrade that was resolved by rebooting the RPi. I think the fact that I had an USBDrive in the same spot I ended up plugging in the WiFi adapter messed it up.

After the reboot, and redoing the script it both saw the network and stopped saying that scanning was not supported.

I'd like to be able to take my pi places and use wireless networks beyond my home network. Would I have to remember their SSIDs and then manually enter them into some config file? That seems cumbersome.)

Before I did the update, I had wpa_supplicant working with two WiFi networks. I had it working with three SSID's, one of which was my phone so that I could use my tablet to access the RPi where ever I was to add/change another if need be.

I need to reset it up (because I created a new SDcard), but I took notes on what I did so I should be able to do it quickly. I will be trying that again tonight after work.

[rayfranco]

Yea, I had the same problem as swezzard on the same day with the latest scrip claiming my network was not visible. Also, sometimes had the other same problem as swezzard with script stating my WiFi adapter did not support scanning. Is this a bug in the latest script?

Ray Frano