Tiny Core Linux
Tiny Core Base => Raspberry Pi => piCore Test Releases => Topic started by: bmarkus on October 05, 2013, 05:22:00 AM
-
I'm pleased to announce piCore 5.0.alpha4 for the Raspberry Pi.
5.0.alpha4 changelog:
- kernel updated to 3.11.2+
- Broadcom firmware updated
- e2fsprogs and util-linux base components rebuilt
- tc-functions and tc-config synced to 5.0.1 common script base
5.0.alpha3 changelog:
- kernel updated to 3.11.1
- udev/udevadm updated
- fixed USB hotplug issues
- zram/zcache enabled
5.0.alpha2 changelog:
- busybox, zlib, e2fsprogs, util-linux, bcrypt, zsync rebuilt with GCC 4.8.1
- libgcc_s.so.1 and libstdc++.so updated to GCC 4.8.1 libs
- removed visudo which was an x86 binary
5.0.alpha1 changelog:
- common TC 5 script base
- eglibc 2.18
- kernel 3.10.10
- busybox 1.21.1
- zlib 1.2.8
- e2fsprogs 1.42.8
- util-linux 2.23.2
- added bcrypt to base
- dropped scm type extension support
- cleanup, unneded files removed
- file reorganization
- updated Broadcom firmware
Download link: piCore-5.0.alpha4.img.gz (http://www.tinycorelinux.net/5.x/armv6/piCore-5.0.alpha4.img.gz) md5 (http://www.tinycorelinux.net/5.x/armv6/piCore-5.0.alpha4.img.gz.md5.txt)
-
Hi bmarkus!
Tried it out and issued following command "tce-load -wi TC" after which I gave the command, startx, after which I got the error message: "failed waitforX". Is something missing or am I doing something wrong?
Have fun with piCore,
meo
-
Hi version4 working fine.
Still I have the problem with wifi, no change.
As Gerrelt wrote:
It could be because I use -b with the udhcpc command instead of -n, which the wifi.tcz script uses.
Therefore I tried to change the wifi.sh so all the "udhcpc -n" was changed to "udhcpc -b" .
EDITED:
However, it did not solve the problem - Now I get this:
udhcpc (v1.21.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
Failed to connect.
Steen
-
This output:
Therefore I tried to change the wifi.sh so all the "udhcpc -n" was changed to "udhcpc -b" .
However, it did not solve the problem - Still:
udhcpc (v1.21.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
Failed to connect.
is the result of calling udhcpc with the -n option. Are you sure you changed all the udhcpc calls? And did you change the correct script?
With the -b option, this should have been the output:
udhcpc (v1.21.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
It tells us that it's forked to the background and continuus to obtain a lease.
Just as a test, try my script...
-
Hi Gerrelt
Just started over again - changed the wifi.sh script within wifi.tzc.
And you are right now it gives this output:
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
Failed to connect.
tc@box:$
But still it ends with "Failed to connect"
Next I will try your script.
Steen
-
@bmarkus:
I've tested Alpha 4, and everything works. I've tested it with two wifi adapters, one with the RTL8188CUS chipset, and one with the RT5370. That last one needed the ralink drivers.
-
I tested it with gerrelts script, and I was able to connect.
So somehow the automatic wifi script is not working. Hopefully, we can get it to work.
If you have an idea to test, please say so and I will try.
-
Yes, I have an idea you can test. I tried to test it, but I just discovered wifi.sh works on my raspberry.. But it will probably not work all the time. But testing will be difficult for me this way.
OK, here it goes: the script uses -n, which means the udhcpc command exits if it can not get a lease after a short period of waiting.
The -b option forks to te background after that period of time and keeps on trying to obtain a lease. This means the wifi.sh script continuus after that period of time with the rest of the script while the udhcpc command is trying to obtain a lease in a different process thread.
Now, I am curious what happens if we don't use either. So no "-n" and no "-b".
I am hoping the udhcpc command keeps the script thread waiting until it obtains a lease. That way the script can execute in it's normal fashion after udhcpc is finished and obtained a lease.
The downside to this would be it will wait forever if it cannot get a lease... But hey, if the only network connection is Wifi, the raspberry is useless anyway without a connection.
So could you remove all the "-n" options from the udhcpc command in the wifi.sh script and try again?
I believe we are breaking some rules concerning extension management... Maybe we should get in contact with the wifi extension manager?
edit: Just tested my own script without the -b or -n option, and it seems to work! It takes a little longer to complete the script, but it is connected afterwards.
-
Hi bmarkus!
Tried it out and issued following command "tce-load -wi TC" after which I gave the command, startx, after which I got the error message: "failed waitforX". Is something missing or am I doing something wrong?
Have fun with piCore,
meo
There was a missing dep. Fixed, now it works.
-
OK
As suggested by Gerrelt I tried to remove all the "-n" options from the udhcpc command in the wifi.sh script.
Now it continues with:
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Until I kill the process.
So there must be something else wrong with how the connection is made - I never had these problems with version 4.7.7 and it is the same wifi adaptors and the same router.
Steen
-
Hi bmarkus!
Problem solved. Thanks a lot I really appreciate that! :)
Keep up the good work with piCore,
meo
-
OK
As suggested by Gerrelt I tried to remove all the "-n" options from the udhcpc command in the wifi.sh script.
Now it continues with:
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Until I kill the process.
So there must be something else wrong with how the connection is made - I never had these problems with version 4.7.7 and it is the same wifi adaptors and the same router.
Steen
Reset your router, and try again.
-
Resetting my router does nothing.
I noticed in the router log that it is being filled with:
[INFO] Mon Oct 07 12:52:42 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F disconnected for reason: Received Deauthentication
[INFO] Mon Oct 07 12:52:42 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F secured and linked
[INFO] Mon Oct 07 12:52:42 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F associated
[INFO] Mon Oct 07 12:52:42 2013 Above message repeated 1 times
[INFO] Mon Oct 07 12:52:36 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F disconnected for reason: Received Deauthentication
[INFO] Mon Oct 07 12:52:36 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F secured and linked
[INFO] Mon Oct 07 12:52:36 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F associated
[INFO] Mon Oct 07 12:52:36 2013 Above message repeated 1 times
[INFO] Mon Oct 07 12:52:29 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F disconnected for reason: Received Deauthentication
[INFO] Mon Oct 07 12:52:29 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F secured and linked
[INFO] Mon Oct 07 12:52:29 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F associated
[INFO] Mon Oct 07 12:52:29 2013 Above message repeated 1 times
[INFO] Mon Oct 07 12:52:22 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F disconnected for reason: Received Deauthentication
[INFO] Mon Oct 07 12:52:22 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F secured and linked
[INFO] Mon Oct 07 12:52:22 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F associated
[INFO] Mon Oct 07 12:52:22 2013 Above message repeated 1 times
[INFO] Mon Oct 07 12:52:16 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F disconnected for reason: Received Deauthentication
[INFO] Mon Oct 07 12:52:16 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F secured and linked
[INFO] Mon Oct 07 12:52:16 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F associated
[INFO] Mon Oct 07 12:52:16 2013 Above message repeated 1 times
[INFO] Mon Oct 07 12:52:09 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F disconnected for reason: Received Deauthentication
[INFO] Mon Oct 07 12:52:09 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F secured and linked
[INFO] Mon Oct 07 12:52:09 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F associated
[INFO] Mon Oct 07 12:52:09 2013 Above message repeated 1 times
[INFO] Mon Oct 07 12:52:03 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F disconnected for reason: Received Deauthentication
[INFO] Mon Oct 07 12:52:03 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F secured and linked
[INFO] Mon Oct 07 12:52:03 2013 2.4GHz Band Steens 2.4GHz: Wireless system with MAC address 008732341D0F associated
And the MAC 008732341D0F is the MAC associated with the wlan of the raspberry. So the router and the raspberry disconnects all the time because of "Received Deauthentication"
Steen
-
Hmm.... >:(
I think we will have to compare the udhcpc command line options of my script and the one of wifi.sh.
Also we could compare my wpa_supplicant.conf file with the one generated by wifi.sh.
-
I have compared the wpa_supplicant conf file in version 4.7.7 where I have no problem connecting:
tc@box:~$ cat /etc/wpa_supplicant.conf
# reading passphrase from stdin
network={
ssid="Steens 2.4GHz"
#psk="s*****"
psk=fa081226891************83ea4dce716aef
}
tc@box:~$
And in version 5 - where I'm unable to connect:
tc@box:~$ cat /etc/wpa_supplicant.conf
# reading passphrase from stdin
network={
ssid="Steens 2.4GHz"
#psk="s*****"
psk=fa081226891*********37c959a32e83ea4dce716aef
}
tc@box:~$
So they are exactly the same.
NB, I added the *** to hide my password
Steen
-
wifi.tcz is the same in 4.x and 5.x repo so it is expected.
-
We're misunderstanding each other, I meant comparing it with my wpa_supplicant.conf and the udhcpc call in my script.
-
OK, I've tried several things, including replicating all the commands + options of the wifi.sh script into my script, but it keeps working....
The raspberry connects to my Wifi network every time.
-
Do the original wifi script also connect now if you start from scratch?
From your previous post you indicated that it didn't connect.
-
Yes, the original wifi.sh script works also. Sometimes, because of the "-n", it quits to early. But with the -n removed it connects every time.
And in your situation, the wifi.sh script works in 4.7.7, but not in 5?
But my script works in 5?
-
Hi bmarkus and Gerrelt
Sorry for my absence. I have been trying many different things the last couple of days, but I still have these strange wifi problems with version 5, whereas version 4.7.7 continue to be working fine with both my wifi adaptors.
On the other hand seems that Gerrelt is doing fine wit the wifi script in version 5, whereas he has trouble in version 4.7.7. (as far as I understand).
I have been tempted to give up on version 5 and continue updating version 4.7.7 with linux kernel 3.11.2. However, I seem to be having all kind of problems with this path.
I can build the kernel image, but somehow I can't get the module-gz to work. I don't know what the problem is, as I'm still able to build working versions based on the 3.9.y kernel.
On the other hand I would prefer to update my piCorePlayer so it is build on bmarkus piCore version 5, but there I have the wifi problem.
So right now i'm stuck, just hoping that somebody (probably bmarkus) can solve the wifi issue.
Steen
-
update.
It seems like the wifi problem is caused by a combination of picore version5 and my router a D-link 855.
I just tried to make a mobile Ap point using my android phone, and here the picore version 5 was able to connect fine.
PiCore version 4.7.7 can connect fine to both my D-link router and the mobile Ap point.
Can it be a timing issue?
Steen