Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book Readers > PocketBook > PocketBook Developer's Corner

Notices

Reply
 
Thread Tools Search this Thread
Old 03-26-2012, 07:36 PM   #1
alcuin
Junior Member
alcuin began at the beginning.
 
Posts: 5
Karma: 10
Join Date: Mar 2012
Device: PB360+
NetConnect

Hi all, this is my first post here.

I can not make the NetConnect() library function work properly on my device (PB360+ with firmware version 15.4). I tried both NetConnect(connection_name) and NetConnect(NULL). In both cases the call fails returning -127, which is strange because -127 is not among the error codes listed in inkview.h. In fact, NetErrorMessage(-127) pops up an "Unknown error" message.

For example, the application telnet_starter.app (after a little modification to let it work without the stylus) starts the telnet server properly, but it is unable to activate the network. This is not a show-stopper because I can always use the browser to let the device connect to the network, and then I quit the browser and launch telnet, however it is annoying. Also, the only way I know to shut the network down is to power cycle the device: the NetDisconnect() function doesn't seem to work.

Has someone else experienced the same problem? Any idea of the solution?

Thank you all,
A.
alcuin is offline   Reply With Quote
Old 03-26-2012, 09:52 PM   #2
rkomar
Wizard
rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.
 
Posts: 1,769
Karma: 4368476
Join Date: Oct 2010
Location: Vancouver, BC, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840
I'm not sure about the problems with NetConnect, but you could kludge a solution by calling your program from a shell script, and wrapping it in calls to netagent connect/disconnect. Here's how I do it in my sshd start and stop scripts:

Code:
# Connect to the net first if necessary.
ifconfig eth0 1> /dev/null 2> /dev/null
if [ $? -ne 0 ]; then
  touch /tmp/sshd-connected-to-wifi
  /ebrmain/bin/netagent connect
fi

... do stuff here

if [ -f /tmp/sshd-connected-to-wifi ]; then
  rm -f /tmp/sshd-connected-to-wifi
  /ebrmain/bin/netagent disconnect
fi
The code connects to the net if required, and disconnects later if it had been originally disconnected.
rkomar is offline   Reply With Quote
Old 03-29-2012, 10:05 PM   #3
alcuin
Junior Member
alcuin began at the beginning.
 
Posts: 5
Karma: 10
Join Date: Mar 2012
Device: PB360+
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.

Last edited by alcuin; 03-29-2012 at 10:26 PM.
alcuin is offline   Reply With Quote
Old 03-29-2012, 10:58 PM   #4
rkomar
Wizard
rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.
 
Posts: 1,769
Karma: 4368476
Join Date: Oct 2010
Location: Vancouver, BC, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840
Wow! I don't see anything like this on my 902. Maybe that's because the Pro series switched to EABI binaries almost immediately, so there isn't any problem with compatibility with OABI binaries. Are you building your applications for OABI? I build for EABI (arm-none-linux-gnueabi), and everything runs without surprizes.
rkomar is offline   Reply With Quote
Old 03-30-2012, 07:05 PM   #5
alcuin
Junior Member
alcuin began at the beginning.
 
Posts: 5
Karma: 10
Join Date: Mar 2012
Device: PB360+
Well, the official SDK is OABI, and I think that the pro has a different SDK. In fact, what I suspect is that they did this chroot kludge to keep binary compatibility with the older models, and to include some EABI software at the same time. Anyway, probably, they just forgot that this breaks the functionality provided by netagent to custom apps. I don't think that any other model is affected except PB360+, and possibly not all of them. This is a minor issue, but I may send them a bug report, just in case. Thank you for the info, anyway!

A.
alcuin is offline   Reply With Quote
Old 03-30-2012, 07:30 PM   #6
rkomar
Wizard
rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.
 
Posts: 1,769
Karma: 4368476
Join Date: Oct 2010
Location: Vancouver, BC, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840
Quote:
Originally Posted by alcuin View Post
Well, the official SDK is OABI, and I think that the pro has a different SDK. In fact, what I suspect is that they did this chroot kludge to keep binary compatibility with the older models, and to include some EABI software at the same time. Anyway, probably, they just forgot that this breaks the functionality provided by netagent to custom apps. I don't think that any other model is affected except PB360+, and possibly not all of them. This is a minor issue, but I may send them a bug report, just in case. Thank you for the info, anyway!

A.
I've been building EABI executables for the 360+ and hadn't heard of any problems from anyone. Which SDK are you using? I suspect it is out of date.

I don't own a 360 or 360+, but my understanding is that they switched to EABI from OABI when they released the 360+ (the Pro models had already made the change to EABI). So, you build OABI for the older models (301, 302, 360), and EABI for the newer ones (Pro series, 360+, Touch). Try building for EABI using PB's sdkrelease_1_1 (or better yet, Sergey Vlasov's pbsdk-linux-1.1.0 if you use Linux) and see if you still have problems.
rkomar is offline   Reply With Quote
Old 03-30-2012, 08:17 PM   #7
alcuin
Junior Member
alcuin began at the beginning.
 
Posts: 5
Karma: 10
Join Date: Mar 2012
Device: PB360+
You are right, if I build EABI, my application runs outside of the chroot, and everything works. On the other hand, my SDK was not outdated: I was just using the latest version found on the official site (http://pocketbook-free.sourceforge.net/en/sdk.shtml) of the non-pro SDK. So the solution is: for 360+ use the pro SDK!

It is finally clear that the chroot is a buggy backward-compatibility trick for binaries produced using the non-pro SDK. The monitor application (or whatever menages the applications menu) runs shell scripts and EABI binaries outside the chroot, and OABI binaries chrooted.

Thank you for your help,
A.
alcuin is offline   Reply With Quote
Old 03-30-2012, 09:04 PM   #8
rkomar
Wizard
rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.rkomar ought to be getting tired of karma fortunes by now.
 
Posts: 1,769
Karma: 4368476
Join Date: Oct 2010
Location: Vancouver, BC, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840
Quote:
Originally Posted by alcuin View Post
You are right, if I build EABI, my application runs outside of the chroot, and everything works. On the other hand, my SDK was not outdated: I was just using the latest version found on the official site (http://pocketbook-free.sourceforge.net/en/sdk.shtml) of the non-pro SDK. So the solution is: for 360+ use the pro SDK!
That site looks to be out of date. Look here: http://sourceforge.net/projects/pocketbook-free/. You will also see the dates on when the files were uploaded. The non-Pro SDK is over two years old.

It is also a misnomer to label the latest SDKs as being for Pro devices only. You can build for both EABI and OABi using the new SDKs. The newer devices use the Freescale part of the SDK (arm-none-linux-gnueabi), and the older ones use the PBSDK part (arm-linux; OABI). So do yourself a favour and forget about the old SDK version; it will only give you headaches.

Edit: Oh and welcome to MobileRead! I hope you will contribute to the PocketBook software projects found here.

Last edited by rkomar; 03-30-2012 at 09:07 PM.
rkomar is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump


All times are GMT -4. The time now is 09:00 AM.


MobileRead.com is a privately owned, operated and funded community.