Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: bmarkus on December 01, 2012, 11:41:38 AM
-
Added WIFi stack to piCore. Install wifi.tcz from the repo, itt will install all necessary tools and libs. I do not have an USB WiFi stick and can't test, but most priobably works :)
Let me know the result if you tried.
-
don't have Ethernet so i put on to SD using Ubuntu this it what it looks like
but i cant get it pull up the WI-FI scan and should it be a icon
-
You need the following packages (*tcz, *.md5.txt and *.dep if exists) int tce/optional:
(http://www.hasix.org/tc/wiifidep.jpg)
Add wifi,tcz to tce/onboot.lst to load it automatically at boot time. It will install all others automatically based on .dep files.
WIFI icon must appear in WBAR:
(http://www.hasix.org/tc/wifiwbar.jpg)
-
got it loaded but the wifi usb sticks i have must not be supported it is a linksys wireless G with speed booster it works in x86 version of tiny core i had in my think pad (with a pent2 at 384Mhz)
-
got it loaded but the wifi usb sticks i have must not be supported it is a linksys wireless G with speed booster it works in x86 version of tiny core i had in my think pad (with a pent2 at 384Mhz)
please provide details, like your dmesg, lsusb and lsmod output as well is ifconfig
-
got it loaded but the wifi usb sticks i have must not be supported it is a linksys wireless G with speed booster it works in x86 version of tiny core i had in my think pad (with a pent2 at 384Mhz)
please provide details, like your dmesg, lsusb and lsmod output as well is ifconfig
i dont know where to look for that info but i have the data plate on the back
model No. WUSB54GSC
serial MOG00HB02204
IC: 3839A-WUSBGSC
-
Hi Joeledmund
Enter the following commands:
dmesg > dmesg.txt
lsmod > lsmod.txtAttach the two text files to your next post.
If you can install usb-utils.tcz enter:
lsusb > lsusb.txtand attach that file too.
-
Updated wpa_supplicant.tcz, missing drivers added. Try and let me know the result.
-
SUCCESS 8) 8)
Thank you for the prompt update much appreciated, yes it works no problem from GUI. Though have to sometimes launch the WiFi tool a couple of times to retrieve a list of nearby Routers.
tinycorearm blogspot co uk
-
Hi Cloudcentric
Could you please tell me which wifi dongle you are using?
Thanks
Steen
-
Yes, it is a cheap Ebay Chinese no brand, with a Realtek RTL8188CUS Chipset, I bought this as the chipset is supported in Raspbian.
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x8176 RTL8188CUS 802.11n WLAN Adapter
I also have another cheap Ebay Chinese no brand, with a Ralink RT5370 Chipset, which is not recognised in piCore or Raspbian
idVendor 0x148f Ralink Technology, Corp.
idProduct 0x5370 RT5370 Wireless Adapter
-
Yes!!! Success here too! :)
Thank you very much bmarkus for your fast response!
I also added this line to bootlocal.sh to make it connect at startup:
/usr/local/bin/wifi.sh -a 2>&1 > /tmp/wifi.log
But that didn't work at first. I had to add the line again (so two of the same lines) to get it working.
I allready noticed when executing wifi.sh by hand it only worked the second time.
It feels like the first time it activates the wifi dongle, and the second time it's allready activated.
Any thoughts on that?
For completeness, I am using this dongle: LogiLink Wireless LAN USB 2.0 Nano Adapter
-
Gerrelt@
Thanks for the feedback. You may look around in the forum for possible similar issue with the x86 version and solution.
-
Hi bmarkus,
The iwlist command doesn't always execute succesfull on the first try.
Could we change this part of the wifi.sh script:
echo "Standby for scan of available networks..."
ifconfig "$WIFI" up 2>/dev/null
sleep 2
iwlist "$WIFI" scanning |
awk -v wifi="$WIFI" -v dbfile="$DB" -v mode="$MODE" -v ptmp="$PTMP" '
To this?:
echo "Standby for scan of available networks..."
ifconfig "$WIFI" up 2>/dev/null
# try for 5 times to get a succesfull iwlist
for i in $(seq 1 5)
do
sleep 1
iwlist "$WIFI" scanning >/dev/null
if [[ $? -eq 0 ]]
then
break
fi
done
iwlist "$WIFI" scanning |
awk -v wifi="$WIFI" -v dbfile="$DB" -v mode="$MODE" -v ptmp="$PTMP" '
This will do a maximum tries of 5 before continuing with the rest of the script.
The auto start option might be a bit more durable with this change.
Be aware, it's been awhile since I did some unix scripting, so I'm a bit rusty.. ;D
I didn't test it either..
-
Please read http://forum.tinycorelinux.net/index.php/topic,5287.msg28016.html#msg28016
bmarkus is not the extension maker. If your reading the extension's code then you should know and respect extension rules.
-
As it happens I was testing on wifi.sh for the allwinner port and therefore I added a couple of timimg loops for the slower arm devices. wifi.tcz updated and posted in the repo.
-
Hi Roberts,
Sorry, I'm new at this, I was trying to contribute to the good cause. I will check out the update. Thank you for your work!
Greetings,
Gerrelt.
-
Hi Roberts,
I've just installed piCore 4.7.4 and the new wifi.sh. It's working great! It now always finds the wifi access points on the first try.
The automatic connect with -a seems to work better too.
I've peeked in the wifi.sh file, and saw your loop. A lot nicer then mine! :)
Thank you for your work.
Greetings,
Gerrelt.
-
Hi Gerrelt
Glad to hear it is working. The pi is a bit slower than other devices that have been using wifi.sh.
I actually added two loops on for the device creation and one for scan results. Neither of these
loops should cost faster platforms. So it is an enhancement that is well worth the effort. I was actually
previewing wifi.sh for my recent Allwinner wifi README when you posted. In the end all is well.
-
Hi. Just undertook a fresh install of piCore4.7.4 and the Wireless Tool works as expected now, thank you
-
Hi I also got the WiFi to work on the raspberry.
However, I have the problem that the sound from the raspberry is breaking up after 30 - 60 sec. Sometimes it plays very slow, at other times it is just bad.
I have increased the clock from 700 to 850 MhZ, it has helped a little. But somehow it seem like the WiFi is too heavy for the Raspberry. If using a LAN cable, ther is no problem.
The sound is equally bad via the 3.5" audio jack and a extern USB DAC.
Is it possible to debug this problem?
The wifi adaptor is a Comfast 150 Mbps nano adaptor build on REALTEK RTL8188CUS chip. USB 2.0 Hi-Speed connector.
Thanks
Steen
-
Did you try it on Raspbian?
-
I always use a USB Mains Powered Hub for peripherals, the USB is known to be flakey if overloaded...............
-
The wifi adaptor is a Comfast 150 Mbps nano adaptor build on REALTEK RTL8188CUS chip. USB 2.0 Hi-Speed connector.
It is not listed as compatible device:
http://elinux.org/RPi_VerifiedPeripherals#USB_Wi-Fi_Adapters
Can be a power issue. Try one from the list.
-
Thanks I will try your suggestions.
I just noticed that there is a lot of dropped RX packages:
wlan0 Link encap:Ethernet HWaddr 00:0F:12:82:13:1F
inet addr:192.168.1.25 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:972254 errors:0 dropped:1159824 overruns:0 frame:0
TX packets:395648 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1465638498 (1.3 GiB) TX bytes:39812520 (37.9 MiB)
What can be the reason for that?
bmarcus: I think it is supported, from the page you linked to I found my card:
Comfast
WU710N: chipset RTL8188CUS. The rtl8192cu kernel driver is loaded automatically in the latest Raspian distribution.
-
I also use a RTL8188CUS based wifi dongle. It works pretty good on Raspbian Wheezy, not perfect, but pretty good.
But I still have problems with it on TinyCore. Connecting seems sometimes slow, ie it takes a while before it gets an IP address. And sometimes it will get an IP address, but I can't ping it from my PC. Strange.
And sometimes it just works fine, it's a bit intermittent.
@Roberts: I've been playing around with the udhcpc command. It seems that the -b command option works better then the -n option.
The -n option gives up after a few tries, and then quits, if it doesn't get a wifi connection. The -b option forks the udhcpc process and keeps on trying to connect in the background. This seems to work better on our "slow" raspberry devices.
Another thing I found usefull is the "-x hostname:" option. With that option I can set the hostname that will appear on the DHCP client list on my routers managament webpage.
-
I also use a RTL8188CUS based wifi dongle. It works pretty good on Raspbian Wheezy, not perfect, but pretty good.
But I still have problems with it on TinyCore. Connecting seems sometimes slow, ie it takes a while before it gets an IP address. And sometimes it will get an IP address, but I can't ping it from my PC. Strange.
And sometimes it just works fine, it's a bit intermittent.
Is it an open network or WPA? Just to identify wether it is a wpasupplicant error or not.
-
Hi. For me it is on a WPA protected network.
I could try remove the protection.
Steen
-
As long as you observe a high rate of dropped packages, it might be a good idea to leave protection out of the equation entirely.
-
Is it an open network or WPA? Just to identify wether it is a wpasupplicant error or not.
It's WPA. And I created a custom wpa_supplicant.conf file, this one:
tc@cherry:/opt$ cat wpa_supplicant.conf
network={
proto=RSN
scan_ssid=1
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
ssid="SeinfeldsHouse"
psk="youdontdoubledip"
}
And these are the commands I am executing:
wpa_supplicant -B -Dwext -i wlan0 -c /opt/wpa_supplicant.conf
/sbin/udhcpc -b -i wlan0 -x hostname:cherry
This morning I started the cherry raspberry and it worked in 1 one try again.. ???
Maybe my router is a bit buggy, I've got a hunch it's got something to do with IP lease times.
Resetting my router fixes the connection problem, normally.
edit: I've got some dropped packages too:
wlan0 Link encap:Ethernet HWaddr 00:9E:95:90:5A:75
inet addr:192.168.0.108 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:598 errors:0 dropped:617 overruns:0 frame:0
TX packets:303 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:109432 (106.8 KiB) TX bytes:46935 (45.8 KiB)
617 packages in about 10 minutes, is that a lot?
-
Yes, it is a lot :(
-
More dropped than received...
-
Gerrelt@
Can you try it without WPA?
-
Yes, but not at the moment. I think my family members will get angry when I fool around with the router now.. ;D
I have a second SD card, I will install Raspbian wheezy on it, and see if it also drops this much packages. If yes, it's something with my dongle or router.
-
OK, installed wheezy and squeezelite on the second SD card... And, also dropping packages like crazy... :(
wlan0 Link encap:Ethernet HWaddr 00:9e:85:9d:55:79
inet addr:192.168.0.109 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2411 errors:0 dropped:2433 overruns:0 frame:0
TX packets:1480 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2298483 (2.1 MiB) TX bytes:156045 (152.3 KiB)
The good news: there's nothing wrong with tinycore. The bad news: I have to find out what's going wrong.. :o
-
If you have a N 150 Router you should only use CCMP to connect at N speed, if you have a 54G Router just use TKIP
http://en.wikipedia.org/wiki/CCMP
Though it could be a power issue, maybe turn of the power management of the WiFi Dongle ? so it reads something like this
wlan0 IEEE 802.11bg ESSID:"acme" Nickname:"rtl_wifi"
Mode:Managed Frequency:2.447 GHz Access Point: 00:21:29:69:C2:D8
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:****-****-****-****-****-****-****-**** Security mode:open
Power Management:off
Link Quality=100/100 Signal level=100/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
-
I've checked, powermanagement is allready off :
wlan0 IEEE 802.11bgn ESSID:"SeinfeldsHouse" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.462 GHz Access Point: 00:9E:95:90:5A:75
Bit Rate:150 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=99/100 Signal level=76/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Apperently it's a common issue, see: raspberrypi.org thread (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=6256&start=1025#p181698)
They suspect it's nothing to worry about.. ???
-
One possible reason is a jamming from a neighbour station using the same channel. Check list of heard AP's.
Also would be good to see the result connecting WiFi dongle to an external powered USB hub.
-
I've checked the wifi channel, it's on a unique channel, not used by anybody else in the range.
The dongle is connected to an externally powered USB hub.
My dongle is 150 Mb/s, and my wifi router is 300 Mb/s. I could try setting the router to 150 Mb/s, to see if it makes any difference.
-
Do test on a "regular" box too, to see if it's the stick or the Pi.
-
It may happen that 150MBit/s is too high bitrate for the Pi and it can't handle. Switch back to 54 Mbit/s and check.
-
Hi bmarkus.
I Will report my findings lager tonight.
Is it possible to set the speed on the raspberry side? I mean how do i force the USB wifi to operate at 54 mbit instead of 150?
-
Hi sbp
The rate option of iwconfig should let you set that, see:
http://linux.die.net/man/8/iwconfig
-
Hi
Regarding the WiFi issue.
I'm using the Raspberry as a Squeezebox player (the PicoPlayer - I made). It is working really fine on a LAN cable.
The problem with the player on WiFi is that the sound is breaking up. It helps a bit to increase the buffer in the player but still I'm unable to listen for more than a few minutes it breaks up. It then buffers for some seconds before it starts again often stuttering. This is vi the audio jack. It seems OK if I use a USB-DAC, then it plays without problems.
I have noticed that if the I play music via the Wifi, the Raspberry seems pressed to its limits, if I write something via putty, there is considerable lag from a keypress and to it is written to the screen.
Now to my experiments:
If connected to my D-link 665 Router -N speed, it is connected with 150 Mbit/sec and react as described above (I haven't checked different protection schemes - see below).
If I connect to a Linksys WAP54G it only connects at 54 Mbit/sec, as shown below there is still a lot of dropped RX-packages, but the player is playing without any problems and there is no hic-ups.
This is without any protection:
iwconfig
lo no wireless extensions.
wlan0 IEEE 802.11bg ESSID:"linksys" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.462 GHz Access Point: 00:18:39:1A:CF:2F
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=100/100 Signal level=100/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
wlan0 Link encap:Ethernet HWaddr 00:0F:12:82:13:1F
inet addr:192.168.1.25 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:68313 errors:0 dropped:125046 overruns:0 frame:0
TX packets:32770 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:100723162 (96.0 MiB) TX bytes:2823088 (2.6 MiB)
With WPA2-Personel protection enabled - the audio is breaking up again (on the Linksys - which played fine without protection) However it still has a lot of dropped packages.
wlan0 Link encap:Ethernet HWaddr 00:0F:12:82:13:1F
inet addr:192.168.1.25 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5904 errors:0 dropped:5925 overruns:0 frame:0
TX packets:3705 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7968557 (7.5 MiB) TX bytes:374187 (365.4 KiB)
With WPA-Personel - the audio is fine (on the same Linksys)
wlan0 Link encap:Ethernet HWaddr 00:0F:12:82:13:1F
inet addr:192.168.1.25 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28876 errors:0 dropped:58810 overruns:0 frame:0
TX packets:14628 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:50879966 (48.5 MiB) TX bytes:1867817 (1.7 MiB)
In conclusion: there is a lot of dropped packages no matter what kind of protection, but the audio is playing fine without protection and with WAP-Personel protection - So I think that the problem is the WPA2-Personel protection which seems to bring the Raspberry to its knees.
So is there a setting in Microcore that could tell the WiFi USB dongle to use WPA (as my router accepts both WPA and WPA2 connections?)
Steen
-
It's a wpasupplicant config.
-
I have looked but this is the content:
cat /etc/wpa_supplicant.conf
# reading passphrase from stdin
network={
ssid="linksys"
#psk="smiley12"
psk=7b6cc12d581431c567a5dec33ca4c6e6fc85fb9e86fd0197774910932b0e9365
}
Steen
-
This config sets the minimum options to get connected. There are much more options to customize connection. read man page:
http://linux.die.net/man/5/wpa_supplicant.conf
-
It may happen that 150MBit/s is too high bitrate for the Pi and it can't handle. Switch back to 54 Mbit/s and check.
I tried this, I connected it to another old wifi router I had that's 54 Mbit/s. But it didn't matter still lots of dropped packets. It was a good idea though.
I've got exactly the same experience as sbp. Maybe the dropped packets are not an actual problem. It might be just a weird way this dongle reports dropped packets.
I am going to try switching to WPA too.
-
I've checked the wifi channel, it's on a unique channel, not used by anybody else in the range.
That doesn't mean much as channels may be overlapping, monitoring all traffic on a specific channel would mean more.
My dongle is 150 Mb/s, and my wifi router is 300 Mb/s. I could try setting the router to 150 Mb/s, to see if it makes any difference.
Changing max. speed of router doesn't seem to make much sense.
You can check for supported speeds with
iwlist s
-
With a lot of dropped packets, in order to troubleshoot I would try
iwconfig <interface> rate 1M fixed
It might be useful to know if the dropped packets originate mainly from tcp or udp traffic.
-
Referring to report saying WPA works fine while WPA2 isn't, just an idea below without tests, measurements.
Possibly the problem is WPA2 which requires more computation than WPA. There are certain instructions are missing in the Pi's ARMv6 CPU for example hw division so there are functions which are supprisingly slow. I have an interesting bencmark with different languages as C, Java, Perl, Python, LUA, LuaJIT, etc. Will submit later. C is slower than expected due to division and Lua is better. Investigating code found that Lua is using the hw floating point for integer arithmetics to gain speed while GCC is generating a conventional code.
-
Hi thanks for all your help, but I still have some questions:
1.
Where is the password for the wifi network stored ?
Because I have changed the password on my router, and now when microcore is scanning the network, it finds the router, but delivers the old password, and therefore connection is refused.
Also it continues to connect to a network it once was connected to, but now I don't wan't it to connect to that any more. But still it automatically connect
2.
I have tried to add
key_mgmt=WPA-PSK
group=CCMP TKIPto the /etc/wpa_supplicant.conf file in order to force it to use WPA instead of WPA2, but the /etc/wpa_supplicant.conf
file is overwritten with a new one after a reboot (even though I added etc/wpa_supplicant.conf to the filetool.lst file before a backup)
3.
I have tried to force the wlan card to use a lower speed by:
sudo iwconfig wlan0 rate 5Mthis command terminates without error, but the iwconfig still shows a bit rate of 150 Mb/s
The audio problem for me is a combination of speed and WPA2 protection:
If I use my D-link Router N-speed (where the USB Wifi is connected by 150 Mb/s), then the sound is breaking up:
without protection
with WPA
With WPA2
If I connect to my Linksys at 54 Mb/s, the sound is fine:
without protection
with WPA
But the sound is breaking with
WPA2
So if only I could force the wifi card to use 54Mb/s and WPA while connected to my D-link, everything would be fine.
-
If you are using wifi.sh then it is wifi.db in your home directory.
-
Hi sbp
I have tried to force the wlan card to use a lower speed by:
Code: [Select]
sudo iwconfig wlan0 rate 5M
this command terminates without error, but the iwconfig still shows a bit rate of 150 Mb/s
How about if you use:
sudo iwconfig wlan0 rate 5M fixed
-
5M does not sound like a valid bitrate.
Check your radio with
iwlist band your AP with
iwlist s
-
5M does not sound like a valid bitrate.
Check your radio with
iwlist band your AP with
iwlist s
Hi, this is the result of iwlist b:
tc@box:~$ iwlist b
lo no bit-rate information.
wlan0 4 available bit-rates :
1 Mb/s
2 Mb/s
5.5 Mb/s
11 Mb/s
Current Bit Rate:150 Mb/s
eth0 no bit-rate information.
and here is the output from iwlist s:
Cell 03 - Address: 00:24:01:79:93:33
ESSID:"Steens 2.4GHz"
Protocol:IEEE 802.11bgn
Mode:Master
Frequency:2.442 GHz (Channel 7)
Encryption key:on
Bit Rates:144 Mb/s
Extra:wpa_ie=dd1a0050f20101000050f20202000050f2020050f20401000050f202
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : TKIP CCMP
Authentication Suites (1) : PSK
Extra:rsn_ie=30180100000fac020200000fac02000fac040100000fac020000
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : TKIP CCMP
Authentication Suites (1) : PSK
IE: Unknown: DD180050F204104A00011010440001021057000120103C000102
Quality=42/100 Signal level=43/100
If I try to manually set the speed by:
tc@box:~$ sudo iwconfig wlan0 rate 5.5M fixedIt terminates without problem, but it is still connected at 150Mb/s
So two questions remains:
1. How do I force the card to connect at a lower speed?
2. How do I force it to connect using WPA and not WPA2?
-
So two questions remains:
1. How do I force the card to connect at a lower speed?
2. How do I force it to connect using WPA and not WPA2?
-
For WPA, see config example:
http://www.thinkwiki.org/wiki/How_to_install_wpa_supplicant
Did not test, not sure it works for this purpuse.
-
Hi, this is the result of iwlist b:
tc@box:~$ iwlist b
lo no bit-rate information.
wlan0 4 available bit-rates :
1 Mb/s
2 Mb/s
5.5 Mb/s
11 Mb/s
Current Bit Rate:150 Mb/s
eth0 no bit-rate information.
Hrm, it appears to show b rates only as available, and an n rate as current... ::)
and here is the output from iwlist s:
Cell 03 - Address: 00:24:01:79:93:33
ESSID:"Steens 2.4GHz"
Protocol:IEEE 802.11bgn
Mode:Master
Frequency:2.442 GHz (Channel 7)
Encryption key:on
Bit Rates:144 Mb/s
Extra:wpa_ie=dd1a0050f20101000050f20202000050f2020050f20401000050f202
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : TKIP CCMP
Authentication Suites (1) : PSK
Extra:rsn_ie=30180100000fac020200000fac02000fac040100000fac020000
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : TKIP CCMP
Authentication Suites (1) : PSK
IE: Unknown: DD180050F204104A00011010440001021057000120103C000102
Quality=42/100 Signal level=43/100
I've never before seen an AP showing only one single bitrate, but then... A: I've never seen a n router at all and B: output of iwlist may differ between drivers.
Note that your AP seems to broadcast at 144Mb/s while your client radio appears to be set to 150Mb/s.
Channel 7 might potentially be more vulnerable to interference, you could try 1, 6, 11+
If I try to manually set the speed by:
tc@box:~$ sudo iwconfig wlan0 rate 5.5M fixedIt terminates without problem, but it is still connected at 150Mb/s
So two questions remains:
1. How do I force the card to connect at a lower speed?
This may again be driver dependent (which driver is it?)...
Try following sequence:
sudo ifconfig wlan0 down
sudo iwconfig wlan0 essid "my essid" rate 1M fixed"
sudo iwconfig wlan0 commit
sudo ifconfig wlan0 up
sudo iwconfig wlan0 essid "my essid" rate 1M fixed"
sudo iwconfig wlan0 commit
Also, best to boot with code "syslog" (though you could always run 'syslogd' manually') and in an aterm do:
tail -f /var/log/messagesso with whatever you doif you are lucky you might get some real time feedback hopefully giving some hints ;)
-
I've noticed my wifi problem dissapear when I boot the raspberry with an ethernet cable attached. Then, on my router's maintanance webpage, I can see two IP adresses assigned to the raspberry. When I ssh into the raspberry using the Wifi IP address (identified by the Mac address), everything works perfectly.
But, am I then really connecting through wifi? Or am I routed through he wired ethernet connection?
-
Check sent/received frames with ifconfig to see where the traffic goes.
iptraf.tcz can provide details on traffic.
And 'route' command displays rules how traffic is routed actually.
Planty of ways to find out :)
-
Hi Gerrelt
What is your problem without the LAN cable connected?
PS: Thanks for you alternative wifi-script, however, I don't have succes with it. Everytime I start with it I get this error:
ioctl[SIOCSIWAP]: Operation not permitted.
And the Raspberry is not seen on my LAN (Using an IP-scanner), so I can't connect via Putty. but I can ping fine from the Raspberry???
EDIT: Gerrelt - you could simply pull the LAN cable, then you will soon discover if you are connected via WiFi or via LAN
-
Hi sbp
Everytime I start with it I get this error:
ioctl[SIOCSIWAP]: Operation not permitted.
That sounds like it needs to be run as root.
-
Check sent/received frames with ifconfig to see where the traffic goes.
iptraf.tcz can provide details on traffic.
And 'route' command displays rules how traffic is routed actually.
Planty of ways to find out :)
Thanx! I will try that.
What is your problem without the LAN cable connected?
Exactly the same problems as yours! ;D
PS: Thanks for you alternative wifi-script, however, I don't have succes with it. Everytime I start with it I get this error:
ioctl[SIOCSIWAP]: Operation not permitted.
Yes, I get that too, but I think it's just a warning. Sometimes it just works fine allthough I had the "error".
And the Raspberry is not seen on my LAN (Using an IP-scanner), so I can't connect via Putty. but I can ping fine from the Raspberry???
Reset your router, and then try again. That usually makes my raspberry reconnect again.
EDIT: Gerrelt - you could simply pull the LAN cable, then you will soon discover if you are connected via WiFi or via LAN
I think it all just stops working. But that test could also prove the wireless just needs the wired.
Hi sbp
Everytime I start with it I get this error:
ioctl[SIOCSIWAP]: Operation not permitted.
That sounds like it needs to be run as root.
I start my script from bootlocal.sh. Then it's automatically started as root?
-
Hi Gerrelt
I start my script from bootlocal.sh. Then it's automatically started as root?
Yes it is.
-
What is your problem without the LAN cable connected?
Exactly the same problems as yours! ;D
My problem is the following:
1. The sound is breaking up when connected to a Wireless-N router (at 150 Mb/s).
and
2. The sound is perfect when connected to 54 Mb/sec using WPA or no protection, whereas WPA2 breaks the sound.
However, I don't have any problems connecting without a LAN cable.
-
Well, OK, my problem started just like yours. The sound breaks up after a little while when using wifi.
-
Hi generelt.
Is it possible for you to confirm that using WPA and reducing the speed of the router to 54 Mb/s Will solve the sound problem?
It would be good to know if we Could solve the problem by going this route.
-
Hi.
I'm now absolutely sure that my problem with the sound breaking up after app 30-60 sec when playing music via WiFi, is caused by the raspberry struggling to deliver/decode the packages fast enough.
I have now connected with my D-Link N-type router, connected at 150 Mb/sec and using WPA2 (which for sure will break the music after a short period of time) - and I have never been able to play music from this connection
BUT it is now playing nicely, I just needed to overclock the raspberry, and now everything is working.
I added this to the config.txt file:
arm_freq=900
core_freq=333
sdram_freq=450
Luckily, my raspberry booted fine, and I did not need any overvolting.
(I'm not sure if overvolting via the config.txt (without using force_turbo=1) will void your warranty.) If you did it in rasbian I think it would be OK, but doing it in microcore, I'm not sure. http://www.raspberrypi.org/archives/2008 here it says something about.
Therefore I did not overvolt it, but for me it is booting fine even without overvolting.
So in order to fix our problem we have three opportunities:
1. Force the raspberry to connect at max 54 Mb/sec and using WPA (or no protection)
2. Increase the speed of our raspberry (by overclocking)
3. Increase the efficiency of the WiFi driver (or the WPA2 decoding) - I don't have a clue whether this is possible?
Steen
-
BUT it is now playing nicely, I just needed to overclock the raspberry, and now everything is working.
WHhch model, 256 or 512MB RAM?
-
It is a Model B with 256 RAM
-
It sounds reasonable and confirms that it is a performance issue with WPA2.
wpa_supplicant issue can be reported to upstream vendor but for sure would require significant rewrite. Also, compiler optimization may help but requires lot of time. Anybody welcome to play with it. Build script available in the repositoy, so you can try different options, or previous versions, etc.
:)
-
Hi gerrelt.
Is it possible for you to confirm that using WPA and reducing the speed of the router to 54 Mb/s Will solve the sound problem?
It would be good to know if we Could solve the problem by going this route.
I think I am using WPA. And I think my problem is not exactly the same as yours, see below.
But I can do some tests with my old 54 Mb/s router. But I will have to figure out how to reach the nas first, where the LMS server is. That's connected to the new router.
Hi.
I'm now absolutely sure that my problem with the sound breaking up after app 30-60 sec when playing music via WiFi, is caused by the raspberry struggling to deliver/decode the packages fast enough.
OK, I think my problem is totally different from your problem. I did have that behaviour a couple of times, but now my problem is different.
Yesterday I could connect and play (through Squeezelite) music without problems. Even synced with the two other raspberries. I let it play for an hour or so, and it didn't break up.
But then, after being disconnected for half an hour or something, it wouldn't connect anymore. Sometimes I see it gets an IP address, but I still cannot connect to it. I can't even ping it.
I even had a situation when I could not ssh to it from my PC, but I could ssh into it when I first ssh'd into my NAS and then ssh to the raspberry from withing this ssh session. So it must be some routing problem, or intialisation.
After trying several things, I rebooted my router, and it reconnected again. ???
-
Just a quick question.
The firmware.tzc can that be used directly in the picore, or does it need to be compiled for ARM?
Or is there a better way to add support for more wifi devices?
-
Hi sbp
To the best of my knowledge, that firmware executes in the hardware on the wireless card and does not need
to be recompiled for ARM. Assuming that the tcz formats between ARM and X86 are the same, you should be
able to use it.
-
Hi sbp
To the best of my knowledge, that firmware executes in the hardware on the wireless card and does not need
to be recompiled for ARM. Assuming that the tcz formats between ARM and X86 are the same, you should be
able to use it.
.tcz as a container is the same and portable. One example is mirrors.tcz
-
Check sent/received frames with ifconfig to see where the traffic goes.
iptraf.tcz can provide details on traffic.
Thanks! That's a brilliant programme. 8)
Hi gerrelt.
Is it possible for you to confirm that using WPA and reducing the speed of the router to 54 Mb/s Will solve the sound problem?
It would be good to know if we Could solve the problem by going this route.
I think I am using WPA. And I think my problem is not exactly the same as yours, see below.
But I can do some tests with my old 54 Mb/s router. But I will have to figure out how to reach the nas first, where the LMS server is. That's connected to the new router.
Offtopic.....
So, I've forwarded some ports (9001 and 3483) to the LMS server to be able to access the LMS server from the other router. And I had to tell squeezelite to use the routers IP address as the LMS server's address. And then I could connect to the LMS server. And I got squeezelite working.
Ontopic...
The old router is a 54 Mb/s router that supports WPA and WPA2. At first I connected it through WPA2, which worked pretty good. But after about an hour the music started to break up.
Then I switched the router to WPA. And it played without faults for hours! That supports your findings, sbp!
Even better, the next day, the raspberry could still connect to wifi. Even switching it on and off (pulling the plug) didn't matter, it connected everytime.
Today I plugged it back in, and it still works without problems.
So, it works a lot better with 54 Mb/s and WPA.
The strange thing is, that I have had raspberries running through wifi on 150 Mb/s and WPA2 without problem. But then I used the raspbian wheezy os. Is it because tinycore is run entirely in memory that the processor of the raspberry has to work harder?
-
The strange thing is, that I have had raspberries running through wifi on 150 Mb/s and WPA2 without problem. But then I used the raspbian wheezy os. Is it because tinycore is run entirely in memory that the processor of the raspberry has to work harder?
piCore base system is running in RAM, but .tcz extensions are mounted. You can load all tcz's or selected one's copy to RAM instead of loop mounting. You can try to copy everything to RAM and check WiFi, but I do not expect difference. However interested in the result :)
-
So, it works a lot better with 54 Mb/s and WPA.
So if only we could find a way to force microcore wifi to connect at max 54Mb/s and WPA we could be back in business.
Steen
-
So if only we could find a way to force microcore wifi to connect at max 54Mb/s
Have you tried to follow suggested instructions in #Reply 58 in detail?
-
wpa_supplicant is using /etc/wpa_supplicant.conf created by wifi.sh It is always recreated when wifi.sh started. For testing, start wifi manually.
1) Stop wifi (disconnect than quit in wifi.sh)
2) Edit /etc/wpa_supplicant.conf
3) Start wpa_supplicant in a teminal:
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
It will run in foreground and you will see messages
4) In a new terminal start dhcp client
udhcpc -b -i wlan0 -x hostname box -p /var/run/udhcpc.wlan0.pid
It will run in background. You will see messages on leased IP and DNS.
Now you have a WiFi connection using /etc/wpa_supplicant.conf settings and you can test it. For settings see
http://linux.die.net/man/5/wpa_supplicant.conf
or Google
To set rate:
sudo iwconfig wlan0 rate 1M
(or any supported value)
-
BTW what is the CPU load of wpa_supplicant using WPA2 and 150 Mbit/s?
-
BTW what is the CPU load of wpa_supplicant using WPA2 and 150 Mbit/s?
Not very high, max 2 percent, if I remember correctly. In fact, the raspberry wasn't very busy at all, according to the "top" command.
Which is strange, isn't it?
It must be some kind of IO problem then?
-
Another thing to consider.
When I'm connected to my router at 150 Mb/s, the music is breaking up even when connected without any WPA protection (so I guess that WPA_supplicant is not used?)
Steen
-
Hi,
I've upgrade my Pi with the piCore-20130521 image (the one with the 4.7.7 base and 3.8.13 kernel), and now I don't have any problems with wifi anymore! :)
I can now even connect to my 150 Mb/s router using WPA2 without problems, it connects everytime and the music does not break up. I am very happy with it!
I wanted to mention this here, just to be complete.
Greetings,
Gerrelt.
-
Thanks a lot for reporting. Glad to hear it works fine. This 3.8.13 kernel solved many problems, I like it.
-
Hello,
I've trying to make my Wifi usb dongle work reading this tutorial. My usb dongle is a TPLink TL-WN721N that shows "Atheros Communications, Inc. AR 9271 802.11n" when I type lsusb into console terminal.
When I connect the Wifi usb dongle I got the message into dmesg - Failed to load firmware htc_9271.fw.
So, after a research, I've found this file into the Linux Wireless site. So I've downloaded this file and put it into the /usr/local/firmware folder.
I've disconnected and connected the wifi usb dongle again, and I've got the wireless working.
But when I reboot, all my changes go away. I've tried to install the wireless*.tcz packages, but no success.
So, Have I make an extension to keep this file into /usr/local/firmware persistent?
Thanks
-
Install firmware.tcz.
-
Sorry, I missed that it was an ARM forum.
I wish we could unsubscribe to specific fora.
-
No problem. I'm actually trying to enable WiFi access into my RPi with this brand of wifi usb dongle. But into the tce app I couldn't find the firmware package.
-
I will add firmwares in a short time.