Since the European genuine HTC ROM
Code:
# uname -a
Linux localhost 2.6.35.10-g60b2609 #1 PREEMPT Sun Apr 17 01:15:33 CST 2011 armv6l GNU/Linux
has tun support disabled according to the /proc/config.gz I got with scp from my marvel,
Code:
# CONFIG_TUN is not set
I just build one
using the wildfire S kernel source code from htcdev
and
http://marakana.com/forums/android/examples/111.html
http://wiki.cyanogenmod.com/wiki/Building_Kernel_from_source
but with arm toolchain from http://www.emdebian.org/crosstools.html
Code:
$ gunzip config.gz
$ cp -vp config .config
$ make xconfig -> enable tun, set CONFIG_CROSS_COMPILE="arm-linux-gnueabi-"
or use the patch in zipfile.
Code:
$ make modules_prepare
$ make modules
$ make modules_install INSTALL_MOD_PATH='../install'
Module Binary is attached, please test. Copyright is GPL >= V. 2,
md5sum
10fd212186ee8506d72d14b00aa15bf5 tun.ko.zip
a8f6e2bd1f7bab19f02371955b9eda0d tun.ko
I got problems dependency checking without building the whole kernel:
Code:
$ /sbin/depmod -ae -b ../install/modules -E ./Module.symvers 2.6.35.10
WARNING: ../install/modules/lib/modules/2.6.35.10/kernel/drivers/net/tun.ko needs unknown symbol register_netdevice
... dozens more...
$ /sbin/depmod -n /usr/local/src/htc-kernel/install/modules/lib/modules/2.6.35.10/kernel/drivers/net/tun.ko
/usr/local/src/htc-kernel/install/modules/lib/modules/2.6.35.10/kernel/drivers/net/tun.ko:
# Aliases extracted from modules themselves.
alias devname:net/tun tun
alias char-major-10-200 tun
# Soft dependencies extracted from modules themselves.
# Copy, with a .conf extension, to /etc/modprobe.d to use it with modprobe.
# Aliases for symbols, used by symbol_request().
alias symbol:tun_get_socket tun
# Device nodes to trigger on-demand module loading.
tun net/tun c10:200
No questions or Support par PM or E-Mail. Report and ask here, pls.
Or tell me an IRC channel where android devs meet.
Thanks, but I suggest preference of stability and integrity before performance at experimental state kernels
Well, I start my Android world with smaller steps.
And as a conservative engineer I wouldn't overclock.
Ok, thanks.
BTW: Noone has been chasing me with an axe yet, so I assume the tun.ko module works?
Thank you for your work.
I try to load this tun.ko on Wildfire S, but module don't load.
Code:
insmod: init_module '/system/lib/modules/tun.ko' failed (Exec format error)
When I check magic number of module, here is only '2.6.35.10', but maybe right is '2.6.35.10-g60b2609'.
Please, is it possible to fix it?
(I need tun.ko because openvpn...)
Thx
Hmm, thx, I've expected the emdebian gcc is not compatible with armv6l.
You need to use the toolchain from the android sdk or the one from the CM guys site.
Yesterday, I cross-compiled DropBear for the 2nd Gen Fire TV, but I am receiving a linkage error that points to it being compiled with an incorrect toolchain.
I downloaded and extracted the "android-ndk-r10e-linux-x86_64.bin" and used the following command to make the standalone toolchain:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=arm-linux-androideabi-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
What are the correct platform and toolchain for the AFTV2 on 5.0.4? I tried to look this up, but I was unable to find it posted in any of the expected places. If I don't hear back, I suppose I'll give it a try with aarch64-linux-android-4.9, because the error I'm receiving when I try to connect to server complains about the bitness of "libc.so" (is 32-bit instead of 64-bit), but I can't even seem to find confirmation that the AFTV2 uses a 64-bit arm processor.
Thanks,
William
fecaleagle said:
Yesterday, I cross-compiled DropBear for the 2nd Gen Fire TV, but I am receiving a linkage error that points to it being compiled with an incorrect toolchain.
I downloaded and extracted the "android-ndk-r10e-linux-x86_64.bin" and used the following command to make the standalone toolchain:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=arm-linux-androideabi-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
What are the correct platform and toolchain for the AFTV2 on 5.0.4? I tried to look this up, but I was unable to find it posted in any of the expected places. If I don't hear back, I suppose I'll give it a try with aarch64-linux-android-4.9, because the error I'm receiving when I try to connect to server complains about the bitness of "libc.so" (is 32-bit instead of 64-bit), but I can't even seem to find confirmation that the AFTV2 uses a 64-bit arm processor.
Thanks,
William
Click to expand...
Click to collapse
Yes, you need aarch64. I've used both the NDK and the aarch64 compiler straight from AOSP. Both work.
rbox said:
Yes, you need aarch64. I've used both the NDK and the aarch64 compiler straight from AOSP. Both work.
Click to expand...
Click to collapse
Thanks, I actually just rebuilt the toolchain with aarch64 and re-compiled. I'll follow-up, because I'm assuming that was the only thing preventing the server from functioning properly. Thanks for all your assistance.
fecaleagle said:
Thanks, I actually just rebuilt the toolchain with aarch64 and re-compiled. I'll follow-up, because I'm assuming that was the only thing preventing the server from functioning properly. Thanks for all your assistance.
Click to expand...
Click to collapse
Well, I'm obviously still doing something wrong. The file command on my build-system reports:
Code:
./dropbearmulti: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
, which looks correct.
But clients are still receiving the following error when I try to connect to the server:
Code:
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
I'll keep digging, but basically, I am building the toolchain like so:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=aarch64-linux-android-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
Then running configure:
Code:
./configure --build=x86_64-unknown-linux-gnu --host=aarch64-linux-android --prefix=/home/william/aftv2-toolchain --disable-zlib --disable-largefile --disable-loginfunc --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp --disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog
Then, I am setting CC and PATH to the following:
Code:
CC=aarch64-none-linux-gnueabi-gcc
PATH=/home/william/aftv2-toolchain/bin:$PATH
Then, I am building as such:
Code:
STATIC=1 MULTI=1 SCPPROGRESS=0 PROGRAMS="dropbear dropbearkey scp dbclient" make strip
No complaints during the build or from the file command, but the issue persists. Surely I am missing something.
Interesting. So when I poke around my toolchain, all of the copies of libc.so are 64-bit, according to the linux file command.
However, just to see if it would tell me anything, I compiled the binary dynamically-linked rather than statically linked and used the ndk-depends tool, and it reports the following:
Code:
Building dependency graph...
dropbearmulti depends on: libc.so libdl.so
Android system library: libc.so
Android system library: libdl.so
Building sorted list of binaries:
dropbearmulti -> ./dropbearmulti
libdl.so -> $ /system/lib/libdl.so
libc.so -> $ /system/lib/libc.so
This obviously indicates that when I build dynamic, it is attempting to link with the 32-bit libraries and not the 64-bit libraries. How can I correct this so that when I do any build, the linkages are correct?
fecaleagle said:
Interesting. So when I poke around my toolchain, all of the copies of libc.so are 64-bit, according to the linux file command.
However, just to see if it would tell me anything, I compiled the binary dynamically-linked rather than statically linked and used the ndk-depends tool, and it reports the following:
Code:
Building dependency graph...
dropbearmulti depends on: libc.so libdl.so
Android system library: libc.so
Android system library: libdl.so
Building sorted list of binaries:
dropbearmulti -> ./dropbearmulti
libdl.so -> $ /system/lib/libdl.so
libc.so -> $ /system/lib/libc.so
This obviously indicates that when I build dynamic, it is attempting to link with the 32-bit libraries and not the 64-bit libraries. How can I correct this so that when I do any build, the linkages are correct?
Click to expand...
Click to collapse
I was compiling kexec dynamically by setting CC and it was working. And I've compiled other things with Android.mk files using the NDK and compiling them static and it worked. Why are you compiling dropbear static to begin with? You say CLIENTS are receiving that message. It almost sounds like dropbear is trying to fork a 32bit shell for them. Since you are running dropbear as the server fine, itself is compiled correctly...
rbox said:
I was compiling kexec dynamically by setting CC and it was working. And I've compiled other things with Android.mk files using the NDK and compiling them static and it worked. Why are you compiling dropbear static to begin with? You say CLIENTS are receiving that message. It almost sounds like dropbear is trying to fork a 32bit shell for them. Since you are running dropbear as the server fine, itself is compiled correctly...
Click to expand...
Click to collapse
I'm compiling static because I'm following the guide posted here:
http://forum.xda-developers.com/nexus-7-2013/general/guide-compiling-dropbear-2015-67-t3142412
Running the dynamically-linked version on the fire tv reports:
Code:
error: only position independent executables (PIE) are supported.
I suppose I should be reaching out to @jocala at this point, since I'd guess he's managed to compile it successfully for the 2nd gen fire tv.
fecaleagle said:
I'm compiling static because I'm following the guide posted here:
http://forum.xda-developers.com/nexus-7-2013/general/guide-compiling-dropbear-2015-67-t3142412
Running the dynamically-linked version on the fire tv reports:
Code:
error: only position independent executables (PIE) are supported.
Click to expand...
Click to collapse
http://stackoverflow.com/questions/...id-l-error-only-position-independent-executab
You need to enable PIE in CFLAGS and LDFLAGS:
CFLAGS = -fPIE
LDFLAGS = -fPIE -pie
fecaleagle said:
I suppose I should be reaching out to @jocala at this point, since I'd guess he's managed to compile it successfully for the 2nd gen fire tv.
Click to expand...
Click to collapse
I'm working on the adbFire update for AFTV2 root; ssh is on the list, but I'm not there yet.
rbox said:
http://stackoverflow.com/questions/...id-l-error-only-position-independent-executab
You need to enable PIE in CFLAGS and LDFLAGS:
CFLAGS = -fPIE
LDFLAGS = -fPIE -pie
Click to expand...
Click to collapse
Doing this allows it startup correctly dynamically linked, but clients still fail to connect. Debian reports the most useful information:
Code:
dispatch_protocol_error: type 51 seq 6
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
As usual, dropbear reports:
Code:
[6329] Jan 04 13:48:35 Child connection from 192.168.1.210:53425
void endusershell()(3) is not implemented on Android
void endusershell()(3) is not implemented on Android
[6329] Jan 04 13:48:42 password auth succeeded for 'root' from 192.168.1.210:53425
[6329] Jan 04 13:48:43 Exit (root): Disconnect received
To me, it appears that the server is throwing up the error to the client, but I still suspected that I am linking the 32-bit version of libc.so when I build dropbear, and I am still at a loss for how to correct that.
Thanks for all of your help. I'll get there eventually.
fecaleagle said:
Doing this allows it startup correctly dynamically linked, but clients still fail to connect. Debian reports the most useful information:
Code:
dispatch_protocol_error: type 51 seq 6
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
As usual, dropbear reports:
Code:
[6329] Jan 04 13:48:35 Child connection from 192.168.1.210:53425
void endusershell()(3) is not implemented on Android
void endusershell()(3) is not implemented on Android
[6329] Jan 04 13:48:42 password auth succeeded for 'root' from 192.168.1.210:53425
[6329] Jan 04 13:48:43 Exit (root): Disconnect received
To me, it appears that the server is throwing up the error to the client, but I still suspected that I am linking the 32-bit version of libc.so when I build dropbear, and I am still at a loss for how to correct that.
Thanks for all of your help. I'll get there eventually.
Click to expand...
Click to collapse
Dropbear itself is 64-bit, because you are actually running it fine. If you could turn up the logging on dropbear, maybe you can get it to tell you what it's doing between password succeeded and disconnect received. Or you could just add a ton of logging to the code. My guess is it's forked the connection and trying to start a secondary program, and that program isn't 64bit. My guess would be the shell, but it should just be using the system shell, so unsure.
jocala said:
I'm working on the adbFire update for AFTV2 root; ssh is on the list, but I'm not there yet.
Click to expand...
Click to collapse
Thanks for your work on adbFire. I'll report back if I'm ever able to get this resolved.
rbox said:
Dropbear itself is 64-bit, because you are actually running it fine. If you could turn up the logging on dropbear, maybe you can get it to tell you what it's doing between password succeeded and disconnect received. Or you could just add a ton of logging to the code. My guess is it's forked the connection and trying to start a secondary program, and that program isn't 64bit. My guess would be the shell, but it should just be using the system shell, so unsure.
Click to expand...
Click to collapse
This suggestion is making more and more sense. I'll take a look at the source and start thinking about my own patchset for the latest source version. I'm annoyed that the verbose flag is not included in the source version of dropbear that the patch was created for, so I think I will end up going that route eventually. I'll take your advice and focus adding debug messages when dropbear initializes the shell, since the authentication goes of without a hitch and it's at that point that the process breaks down. I really appreciate all of your suggestions!
@rbox,
This is rather helpful, and the post from July 31st, 2015 all but confirms your suspicion about forking the shell and points me in the right direction:
http://www.kevinboone.net/kbox3_diary.html
I will start by modifying the patches to use: /bin/sh rather than /system/bin/sh when launching the shell and see if that resolves my issue, then get started on the long slog.
The blog post above seems to have shed some light on the issue. Updating the patches to refer to /bin/sh rather than /system/bin/sh seems to have resolved the "CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit" error. As @rbox suspected, dropbear seems to be creating the appropriate shell upon connect now on a 64-bit system (aftv2).
Unfortunately, I'm still receiving the "dispatch_protocol_error":
Code:
dispatch_protocol_error: type 51 seq 6
[5761] Jan 04 19:47:46 Exit (root): Child failed
Connection to 192.168.1.213 closed.
Any thoughts on this one @jocala? Googling dispatch_protocol_error type 51 returns zilch.
My Note II has:
Code:
Model number: SAMSUNG-SGH-I317
Android version: 4.4.2
Baseband version: I317UCUCNJ2
Kernel: 3.0.31-1728680 [email protected] #1 Wed Aug 5 22:21:45 KST 2015
Build number: KOT49H.I317UCUCNJ2
SE for Android status: Enforcing SEPF_SAMSUNG-SGH-I317_4.4.2_0016 Wed Aug 05 22:30:54 2015
When I run OpenVPN Client v2.15.15, it opens VPN tunnel. Apps using UDP protocol work trough the tunnel fine all the time. But apps using TCP may start to work for first couple of minutes and then all TCP connections stop... It looks like there is some bug in TCP stack preventing all apps from using TCP in VPN tunnel
How to fix it?
Is TCP stack part of kernel? If it is, what kernel would you recommend to install? If it's not, what and how should be replaced.to fix that problem?
Thank you in advance.