03-26-2012, 06:36 PM | #1 |
Junior Member
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. |
03-26-2012, 08:52 PM | #2 |
Wizard
Posts: 2,987
Karma: 18343081
Join Date: Oct 2010
Location: Sudbury, ON, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633
|
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 |
03-29-2012, 09:05 PM | #3 |
Junior Member
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 Code:
drwxr-xr-x 11 root root 1024 Oct 17 14:12 oabiroot 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" 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 Last edited by alcuin; 03-29-2012 at 09:26 PM. |
03-29-2012, 09:58 PM | #4 |
Wizard
Posts: 2,987
Karma: 18343081
Join Date: Oct 2010
Location: Sudbury, ON, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633
|
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.
|
03-30-2012, 06:05 PM | #5 |
Junior Member
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. |
03-30-2012, 06:30 PM | #6 | |
Wizard
Posts: 2,987
Karma: 18343081
Join Date: Oct 2010
Location: Sudbury, ON, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633
|
Quote:
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. |
|
03-30-2012, 07:17 PM | #7 |
Junior Member
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. |
03-30-2012, 08:04 PM | #8 | |
Wizard
Posts: 2,987
Karma: 18343081
Join Date: Oct 2010
Location: Sudbury, ON, Canada
Device: PRS-505, PB 902, PRS-T1, PB 623, PB 840, PB 633
|
Quote:
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 08:07 PM. |
|