Automatic setup for RTL8188CUS based wifi adapters

[Dweeber]

the hidden SSID can be easily found (inssider, for example), but does offer an extra barrier.

I have tried the scan_ssid=<various numbers> with no success. The wpa_supplicant code works fine when the SSID is broadcast. I presume this is a driver issue, as iwlist scan finds the hidden access point easily.

From everything that I've seen on this before, when this does not work it is because the driver is not configured to allow for it. I see a number of posts on Google where it doesn't work for one device, but when they try the exact same config with a device that uses a different driver... it works.

The ONLY barrier your hidden SSID is providing right now is blocking you from making your connections. Many WiFi devices won't work with that configuration, and any perceived barrier you think it is providing to the security of your network is an illusion. Simply not worth the effort.

[MrEngman]

Thanks MrEngman,

the hidden SSID can be easily found (inssider, for example), but does offer an extra barrier.

I have tried the scan_ssid=<various numbers> with no success. The wpa_supplicant code works fine when the SSID is broadcast. I presume this is a driver issue, as iwlist scan finds the hidden access point easily.

Regards, Joe

OK, I tried it here and it works using both an EW-7811Un and a Micronet SP907n both using the rtl8188cus driver.

My /etc/network/intefaces wpa_supplicant set up is different. wpa_supplicant.conf has one additional line but is otherwise the same.

/etc/network/interfaces

Code: Select all

auto lo

iface lo inet loopback
iface eth0 inet dhcp

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

wpa_supplicant.conf

Code: Select all

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
ap_scan=1

network={
ssid="my-ssid"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
psk="my network password"
}

iwlist behaves a little strangely. With the interface taken down, e.g. ifdown wlan0, iwlist wlan0 scan shows the network with no ssid. If I bring up wlan0, ifup wlan0, then iwlist shows the access point twice. First entry is with no ssid displayed but the second entry shows the network with the ssid displayed, but as the wifi is working so be it.

[wallarug]

Are you going to update the script for the latest Raspbain image?

[simplesi]

Due to corrupt SD card I just had to download the latest Raspbian and all I've had to do was plug my Edimax nano dongle in and use the WiFi Config program and its up and running without any further action needed

I'm sure that if it hadn't been due to your efforts, we wouldn't be here now

regards
Simon
PS Plus I've used your code/script process to make up my own easy-peasy install script to install Samba so I'm doubly grateful

[atzensepp]

Could be some power supply issues as described here:
http://himeshp.blogspot.de/2012/07/rasp ... imate.html

[Dweeber]

Finally got to test my idea and except for a few script errors (not a big bash fan)... it worked!

Basically, I created a "package" of files that I place on a new image while it is still mounted in Windows into what is /root/rpi

I then wrote a script to automate the process but basically it does...

Code: Select all

Copying config files from /boot/rpi/config to /boot
 - Copying /boot/rpi/config/70-persistent-net.rules
 - Copying /boot/rpi/config/interfaces
 - Copying /boot/rpi/config/wpa_supplicant.conf
 
Processing 70-persistent-net.rules
 - Making copy of /etc/udev/rules.d/70-persistent-net.rules
ERROR file does not exist. No copy made...
 - Creating symbolic link to /boot/70-persistent-net.rules
 
Processing interfaces
 - Making copy of /etc/network/interfaces
 - Creating symbolic link to /boot/interfaces

Processing wpa_supplicant.conf
 - Making copy of /etc/wpa_supplicant/wpa_supplicant.conf
 - Creating symbolic link to /boot/wpa_supplicant.conf
 
Appending addons to .bashrc for root 
 - Appending to /root/.bashrc

Appending addons to .bashrc for pi user
 - Appending to /home/pi/.bashrc

Copying Common Utilities 
 - Copying files to /usr/local/bin/

Appending decode license to /root/config.txt
 - Appending to /boot/config.txt

Script complete... rebooting will startup Wifi0
Need to expand filesystem and go from there after Reboot

So when the script runs (if it works right), the WiFi files are setup with my access points already in it, interfaces, 70-persistent-net.rules and wpa_supplicant.conf are symbolically mounted to /boot so I can access them from windows if I need to

All my common utilities are there along with my weird aliases I'm used to and use for both root and pi.

o I reboot, and WiFi finds the access point and links.
o I then modify /etc/hosts and /etc/hostname so that It see's the proper hostname
o I expand the filesystem
o and then do an update.

All can be done with just the keyboard (no mouse) and no GUI. In this particular case, I used a serial console cable... but the same would be if I was sitting in front of the TV with just a keyboard.

No drivers needed to be loaded, just a simple reboot to get the WiFi to use the config files I put into place.

[iZero]

Just works, I've been hacking around with this for ages.

Many thanks for some excellent work

[MrEngman]

Are you going to update the script for the latest Raspbain image?

Do you have anything particular in mind or just don't use startx?

[wallarug]

Are you going to update the script for the latest Raspbain image?

Do you have anything particular in mind or just don't use startx?

Going through the gui is very time consuming and your script is brilliant! I just think that it is easier to run your script (which grabs the required software) than mess around with gui.

Does the current image of Raspbian include all the software? ... and therefore I would not need your script and I can just do it manually in /etc/network/interfaces. Correct?

[NerdUno]

With an N 150, we're seeing thousands of RX errors with the current Raspbian driver. It works, but...

Here's what we see with a restart of wlan0:

Code: Select all

ifup wlan0
ioctl[SIOCSIWAP]: Operation not permitted
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument
dhcpcd.sh: interface wlan0 has been configured with new IP=192.168.0.100

Any ideas??

[Dweeber]

Errors or drops?

Code: Select all

wlan0     Link encap:Ethernet  HWaddr 80:1f:02:70:9f:be  
          inet addr:192.168.1.146  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:544674 errors:0 dropped:601711 overruns:0 frame:0
          TX packets:242358 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:754457111 (719.5 MiB)  TX bytes:56365629 (53.7 MiB)

I don't see any errors normally, but on RX I see a lot of drops. Doesn't seem to be affecting anything though.

[NerdUno]

Sorry. Ours are drops as well. Well over half the packets received.

[dom]

Sorry. Ours are drops as well. Well over half the packets received.

Anyone with the packet loss issue, can you do a sanity check.
Plug the dongle into different linux system, and report what the packet loss is.
Ideally it should be as close as possible to Raspberry Pi version. Ideally a debian/Ubuntu system with the same out-of-tree kernel module.

Gordon did have a look at this, but felt the packets were not being lost in the USB driver.
Possibly it's just a foible of how that driver reports packet loss (or a bug in the WiFi driver).

[Dweeber]

Sorry. Ours are drops as well. Well over half the packets received.

Anyone with the packet loss issue, can you do a sanity check.
Plug the dongle into different linux system, and report what the packet loss is.
Ideally it should be as close as possible to Raspberry Pi version. Ideally a debian/Ubuntu system with the same out-of-tree kernel module.

Gordon did have a look at this, but felt the packets were not being lost in the USB driver.
Possibly it's just a foible of how that driver reports packet loss (or a bug in the WiFi driver).

Packet loss = Drops ?? Is that what drops are supposed to represent?

When I do any kind of ping tests I see no packet loss at all to any inside addresses which is about all that is being connected to right now.

[dom]

Packet loss = Drops ?? Is that what drops are supposed to represent?

No idea. I just know that RTL8188CUS wifi dongles seem to report ~50% of packets dropped.
Other dongles report 0% packets dropped.
I don't know the reason for the dropped packets.

[Dweeber]

Was curious...

I sent the output to my WWAN guy and his response was:

look at your recvd versus xmit bytes:
way lopsided. Not alarming but I would expect to see different numbers.
Looks like the interface just can’t handle the download speed and is dropping packets.
I assume most of the traffic is tcp based so it will just retransmit it which is why your’e dropped packets exceeds your Rx packets.

I guess I would have to test another type of WiFi adapter (different driver) and then to some tests side by side.

[NerdUno]

Never saw this in previous builds using standard Debian Squeeze and Wheezy.

[stuii]

I too am having really serious packet dropping problems with the RTL8188CUS, well over half, sometimes as many as two thirds are being dropped. A test of transferring a 128Mb file from my desktop to the Pi using scp gives an average transfer rate of 32KB/s and takes well over an hour. This sort of bandwidth is fine just for SSH but useless for anything else.

I've tried all the /boot/cmdline.txt tricks (mine is below) but they've not made a jot of difference.

Code: Select all

dwc_otg.microframe_schedule=1 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 dwc_otg.speed=1 console=tty1 root=/dev/mmcblk0p3 rootfstype=ext4 elevator=deadline rootwait

Anybody have any more ideas?

[henryd]

BRILLIANT worked 1st time on my 9 pound dongle from Tescos

[Dweeber]

I too am having really serious packet dropping problems with the RTL8188CUS, well over half, sometimes as many as two thirds are being dropped. A test of transferring a 128Mb file from my desktop to the Pi using scp gives an average transfer rate of 32KB/s and takes well over an hour. This sort of bandwidth is fine just for SSH but useless for anything else.

Anybody have any more ideas?

Strange... with the "drops" ... I just transferred a 542mb file to my RPi:

542MB 1.1MB/s 08:32

This was not just from a local network to local network connection, but rather from my VPS server in California to RPi (Arizona) over the Internet.

I would think that there must be something else involved with your slow transfer.

Code: Select all

wlan0     Link encap:Ethernet  HWaddr 80:1f:02:70:9f:be  
          inet addr:192.168.1.146  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:437220 errors:0 dropped:442148 overruns:0 frame:0
          TX packets:123802 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:621545336 (592.7 MiB)  TX bytes:11933534 (11.3 MiB)

Ping test to the same site:
500 packets transmitted, 500 received, 0% packet loss, time 499673ms
rtt min/avg/max/mdev = 38.236/44.063/64.946/2.593 ms

BTW.. my smartphone blows this out of the water, but we are not talking about the same class of computer there (HTC Rezound - Qualcomm MSM8660 - Dual Core, 1500MHz - GPU Qualcomm Adreno 220 - System Memory: 1024MB - Built-in Storage: 16GB)

[jbeale]

I tried transferring a 26 MB file back and forth between two R-Pis, one using the RTL8188CUS WiFi and one wired ethernet, both running the current Raspbian release. I got 2.1MB/s (00:14) going to the wireless system, and 581.2KB/s (00:51) coming from the wireless system. It does look like the wireless system is dropping about 50% of RX packets.

Wireless:

Code: Select all

Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l GNU/Linux

Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

/boot/cmdline.txt:  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=noop rootwait

wlan0     Link encap:Ethernet  HWaddr 00:13:ef:b0:2c:e1
          inet addr:192.168.10.142  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:109511 errors:0 dropped:118499 overruns:0 frame:0
          TX packets:43898 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:58881200 (56.1 MiB)  TX bytes:36471884 (34.7 MiB)

Wired:

Code: Select all

Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l GNU/Linux

eth0      Link encap:Ethernet  HWaddr b8:27:eb:de:1d:9f
          inet addr:192.168.10.106  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29990 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32173 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:33060814 (31.5 MiB)  TX bytes:35835370 (34.1 MiB)

UPDATE: tried it again sending the file from the wireless Pi, and got only 264.7KB/s. My WiFi dongle is direct into the Pi without a powered hub, and this is an "original" Pi with the USB fuses. I measured 0.6 V drop across the USB fuse during the file transfer! Ok, that's a problem. Then I tried a third time holding metal tweezers across the fuse to short it out, and got 630.7KB/s transfer. So the USB power supply is clearly a factor. Note that the faster the WiFi dongle works, the more current it draws.

[jbeale]

Update 2: I soldered a wire across that USB fuse and now I get 898.2KB/s (29 MB in 00:33) coming from the wireless pi. However, ifconfig shows that 50% of all RX packets are still being dropped, so that is likely a USB driver and/or R-Pi slow CPU issue, since my USB power supply is now solid at 5.09 V during the transfer.

Code: Select all

wlan0     Link encap:Ethernet  HWaddr 00:13:ef:b0:2c:e1
          inet addr:192.168.10.142  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8457 errors:0 dropped:9043 overruns:0 frame:0
          TX packets:23499 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:914482 (893.0 KiB)  TX bytes:35921382 (34.2 MiB)

In /boot/setup.txt I have

Code: Select all

arm_freq=900
core_freq=333
sdram_freq=450
over_voltage=2

Added note: removing the wireless dongle and connecting the formerly wireless R-Pi to wired ethernet, I get 2.4MB/s (29 MB in 00:12) using scp to transfer a file from that device to another R-Pi.

[dom]

Never saw this in previous builds using standard Debian Squeeze and Wheezy.

Are you saying you got no packets dropped with the same wifi dongle on an older image? Did you get a higher throughput (e.g. measured with iperf)?
Can you identify the most recent image that has no packets dropped?
I'd imagine it is only the kernel.img and /lib/modules that matters, rather than the distribution, so it should be possibly to transplant those files from an older image to the latest raspbian/wheezy, and see if that works.

[NerdUno]

Correct. Debian Wheezy stock build had no dropped Rx packets. But we want the overclocking. Doesn't that rule out replacing the kernel.img??

[dom]

Correct. Debian Wheezy stock build had no dropped Rx packets. But we want the overclocking. Doesn't that rule out replacing the kernel.img??

You should be able to transplant kernel.img and /lib/kernel onto a new image. You won't have the overclock, but it would be a useful experiment.
Can you point to the Wheezy image? Is it the soft float (armel) or hard float (raspbian) one?

Older images didn't support RTL8188CUS, so this was after running MrEngman's script and installing his driver?
Are you sure you are remembering a RTL8188CUS based wifi dongle? I have other dongles that show 0 droppped packets.