piCore 5.0alpha4

[bmarkus]

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 md5

[meo]

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

[sbp]

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:

Code: [Select]

udhcpc (v1.21.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
Failed to connect.

Steen

[Gerrelt]

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:

Code: [Select]

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:

Code: [Select]

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...

[sbp]

Hi Gerrelt

Just started over again - changed the wifi.sh script within wifi.tzc.

And you are right now it gives this output:

Code: [Select]

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

[Gerrelt]

@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.

[sbp]

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.

[Gerrelt]

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.

[bmarkus]

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.

[sbp]

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:

Code: [Select]

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
 

[meo]

Hi bmarkus!

Problem solved. Thanks a lot I really appreciate that! 

Keep up the good work with piCore,
meo

[Gerrelt]

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:

Code: [Select]

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.

[sbp]

Resetting my router does nothing.

I noticed in the router log that it is being filled with:

Code: [Select]

[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

[Gerrelt]

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.

[sbp]

I have compared the wpa_supplicant conf file in version 4.7.7 where I have no problem connecting:

Code: [Select]

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:

Code: [Select]

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