I finally figured it out, and it was more complicated than what it should
have been. The short story is: apparently the apps run in a chrooted
environment, all of them but the shell scripts. I don't think that there
was any chroot on older devices, but this is what I found on my PB360+.
Now to the longer story. All the following applies to my PB360+, firmware
version 15.4. Most probably it doesn't apply to any older device. Anyway,
I am somewhat curious: have all PB360+ devices the same configuration?
First I tried to run a script as rkomar suggested, and it worked, but just
partially. The script successfully connects to the network, but then it
fails to run my own app (which I called in the "... do stuff here"
section). Inserting ls commands in the script I could verify that the
application was there, permissions were correct, etc. Nevertheless it
always failed to run with a cryptic "not found" error.
So I decided that I could just try to run /ebrmain/bin/netagent from my
app (in C). Tried using system(), which invokes the shell, tried execve(),
which doesn't, to no avail. And again I got the mysterious "not found"
all the time.
Finally, I resolved to just call rkomar's script from my C app. And
surprisingly it didn't work. By an obscure reason, the script works
correctly when called from the applications menu, and also when called
from another shell script (yes, I tried this as well), but, if I call it
from a binary application, it fails to launch netagent with the usual "not
found".
Out of sheer exhaustion, I listed the root directory using a script and
using a binary application, and I compared the results. Here they are:
Code:
--- trough a shell script ---
drwxr-xr-x 2 root root 2048 Oct 17 14:12 bin
lrwxrwxrwx 1 root root 17 Oct 17 14:12 dev -> /oabiroot/var/dev
drwxr-xr-x 12 root root 1024 Oct 17 14:14 ebrmain
drwxr-xr-x 5 root root 1024 Oct 17 14:12 etc
drwxr-xr-x 4 root root 2048 Oct 17 14:12 lib
drwx------ 2 root root 12288 Oct 17 14:12 lost+found
drwxr-xr-x 6 root root 1024 Oct 17 14:12 mnt
drwxr-xr-x 11 root root 1024 Oct 17 14:12 oabiroot
dr-xr-xr-x 46 root root 0 Jan 1 1970 proc
drwxr-xr-x 2 root root 1024 Oct 17 14:12 sbin
drwxr-xr-x 12 root root 0 Jan 1 1970 sys
lrwxrwxrwx 1 root root 17 Oct 17 14:12 tmp -> /oabiroot/var/tmp
drwxr-xr-x 2 root root 1024 Oct 17 14:12 usr
lrwxrwxrwx 1 root root 13 Oct 17 14:12 var -> /oabiroot/var
Code:
--- through a binary ---
drwxr-xr-x 2 root root 1024 Oct 17 14:12 bin
lrwxrwxrwx 1 root root 7 Oct 17 14:12 dev -> var/dev
drwxr-xr-x 12 root root 1024 Oct 17 14:14 ebrmain
drwxr-xr-x 2 root root 1024 Oct 17 14:12 etc
drwxr-xr-x 2 root root 1024 Oct 17 14:12 lib
drwxr-xr-x 5 root root 1024 Oct 17 14:12 mnt
dr-xr-xr-x 46 root root 0 Jan 1 1970 proc
drwxr-xr-x 2 root root 1024 Oct 17 14:12 sys
lrwxrwxrwx 1 root root 7 Oct 17 14:12 tmp -> var/tmp
drwxr-xr-x 2 root root 1024 Oct 17 14:12 usr
drwxrwxrwt 8 root root 160 Mar 29 00:47 var
Did you notice?
Code:
drwxr-xr-x 11 root root 1024 Oct 17 14:12 oabiroot
This is the chroot. The "oabi" part of "oabiroot" means Old ABI, i.e. the
ARM ABI as it used to be before the introduction of the newer EABI. I am
completely novice to ARM stuff, but what google told me is that the same
kernel can handle OABI and EABI binaries, however the two ABI are not
compatible, and, in particular, OABI binaries must link to OABI libraries
and EABI binaries to EABI libraries. The binaries in the main filesystem
are EABI, except for the chroot /oabiroot which contains an OABI
environment.
Suddenly this explained all the silly behaviour noted above. First of all,
by some reason (possibly connected with the fact that they want some of
their own scripts in /mnt/ext1/applications to be able to run programs
outside of the chroot) the controller of the application menu runs shell
scripts outside of the chroot, and runs binaries chrooted to /oabiroot.
When a shell script tries to run a binary compiled for the OABI
environment in the EABI environment, of course, the linking phase fails,
hence the "not found" errors. Also, netagent has been built for the EABI
environment, so, when an application tries to run it inside the chroot,
link fails, bye bye. (By the way, if you paid attention, there is no
/oabiroot/sbin, i.e. no ifconfig and company).
How to solve the impasse? Compile the application with the correct linking
options, so that it links even if run outside the chroot, and run it
through a shell script (static linking is not an option because we don't
have the inkview static library). Of course, a binary compiled like that
will not link and run unless it is called through a shell script. The option
to give to gcc (through Makefile or whatever mechanism) is the following
Code:
-Wl,--dynamic-linker="/oabiroot/lib/ld-linux.so.2",-rpath="/oabiroot/lib",-rpath="/oabiroot/usr/lib"
As I expected, now the NetConnect() library call works perfectly well (in
an app compiled with this workaround). Most probably it failed inside the
chroot just because it couldn't run netagent.
Finally, I show you my /proc/mounts, just in case.
Code:
bash-4.1$ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext2 ro,errors=continue 0 0
none /proc proc rw 0 0
none /oabiroot/proc proc rw 0 0
none /oabiroot/var tmpfs rw,size=49152k 0 0
none /sys sysfs rw 0 0
none /oabiroot/var/dev/pts devpts rw,mode=622 0 0
tmpfs /oabiroot/var/dev/shm tmpfs rw 0 0
/dev/mmcblk0p2 /ebrmain ext2 ro,errors=continue 0 0
/dev/mmcblk0p2 /oabiroot/ebrmain ext2 ro,errors=continue 0 0
/dev/mmcblk0p3 /mnt/secure ext3 rw,errors=continue,data=ordered 0 0
/dev/mmcblk0p4 /mnt/ext1 vfat rw,dirsync,nosuid,nodev,noatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8 0 0
/dev/mmcblk0p4 /oabiroot/mnt/ext1 vfat rw,dirsync,nosuid,nodev,noatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8 0 0
Enjoy, A.