Forwarding traffic to a proxy server, full IPTABLES - Hero, G2 Touch Android Development

Hi Devs,
I'm trying to get my android to transparently forward certain domains/IPs to a proxy server automatically.
For this I am trying to use IPTABLES, however the compiled version I can find on the device is not compiled with glibc, but with a reduced version. When trying to use any commands that refers to a specific protocol (TCP) then I get a similar error to:
FIX ME! implement getnetbyaddr() bionic/libc/bionic/stubs.c:366
I been searching a lot for a binary of iptables, that doesn't have this problem but haven't been successful. However applications like wireless tether, droidwall, TOR client seem to work with the reduced iptables, looks like they are issuing simpler commands, I want to run something like:
iptables -t nat -A PREROUTING -i eth0 -s ! 192.168.10.16 -p tcp --dport 80 -j DNAT --to 192.168.10.16:8080
I am on a 2.1 ROM btw. Any suggestions on how to achieve selective transparent proxy forwarding o a full version of iptables for android?
Many thanks,
Edited:
BTW, I've just found out that the current iptables version works, it just prints the errors...

any one any clue?

fulanito108 said:
Hi Devs,
I'm trying to get my android to transparently forward certain domains/IPs to a proxy server automatically.
For this I am trying to use IPTABLES, however the compiled version I can find on the device is not compiled with glibc, but with a reduced version. When trying to use any commands that refers to a specific protocol (TCP) then I get a similar error to:
FIX ME! implement getnetbyaddr() bionic/libc/bionic/stubs.c:366
I been searching a lot for a binary of iptables, that doesn't have this problem but haven't been successful. However applications like wireless tether, droidwall, TOR client seem to work with the reduced iptables, looks like they are issuing simpler commands, I want to run something like:
iptables -t nat -A PREROUTING -i eth0 -s ! 192.168.10.16 -p tcp --dport 80 -j DNAT --to 192.168.10.16:8080
I am on a 2.1 ROM btw. Any suggestions on how to achieve selective transparent proxy forwarding o a full version of iptables for android?
Many thanks,
Click to expand...
Click to collapse
You tried VillainROM 10.2 with ninpo or kendon's kernel? I think they added iptables. Dunno any more than that

Thanks Pulser, I'm on VillainROM 5.5, I will update to 10 when I can, but is not the problem that I can't find iptables, the problem all the versions I find are not complete, they are compiled with bionic C library.

fulanito108 said:
Thanks Pulser, I'm on VillainROM 5.5, I will update to 10 when I can, but is not the problem that I can't find iptables, the problem all the versions I find are not complete, they are compiled with bionic C library.
Click to expand...
Click to collapse
Talk to ninpo about this, he can maybe help

The bionic library that iptables (and your android setup) was built against is missing getnetbyaddr, it hasn't been implemented yet, neither has getprotobyname, so iptables is very limited right now. I ran into this issue when enabling TOS for my build. It's in bionic/libc/include/netdb.h but needs a stub entry.

I guess that you can still compile iptables against glibc and link it statically. I am trying to find out if any one might have done this, or knows a workarround

Was there ever an update on this? I am working with someone on trying to get a "full" version of iptables going so we can try and implement qos....

spiicytuna said:
Was there ever an update on this? I am working with someone on trying to get a "full" version of iptables going so we can try and implement qos....
Click to expand...
Click to collapse
sorry haven't found it yet, and need it... if you get your hands around it please reply to this post

It's not the iptables full version you need, it's the underlying libc that is missing that particular resolver function, as kernelzilla already pointed out above.
Statically linking glibc would probably be an overkill - uclibc or dietlibc would probably be better choice. No idea if any of them implements these particular resolver functions, though.
EDIT: Shiny, after quick check of source code of both, they both *do* implement getnetbyaddr().

ticho said:
EDIT: Shiny, after quick check of source code of both, they both *do* implement getnetbyaddr().
Click to expand...
Click to collapse
Thanks Ticho, when I have some time I'll try to setup the dev enviroment to play compiling it...

fulanito108 said:
Thanks Ticho, when I have some time I'll try to setup the dev enviroment to play compiling it...
Click to expand...
Click to collapse
This would be awesome!!

BTW, I've just found out that the current iptables version works, it just prints the errors...

Related

openvpn anyone?

hi,
did anyone find a way to use openvpn on htc hero?
Catscrash said:
hi,
did anyone find a way to use openvpn on htc hero?
Click to expand...
Click to collapse
Not yet, but I am using the CyanogenMod 4.0.1 on my Dream and I have seen Donut on the HTC Click -- in both cases, Settings --> Wireless Controls is showing an option for VPN Settings, so I'm guessing that it would be a matter of time before this is available on the Hero and Magic firmware
Be patient, or wait for someone to cook a ROM with this feature
VPN wil be in Donut.
For now, it seems possible to implement it.
For the program GUI, it should good to extand that program to support openvpn and pptp vpn.
First of all tun driver is needed, you'll find it here.
Install and, as root, type:
# insmod /system/lib/modules/tun.ko
lsmod command should give you:
tun 11300 0 - Live 0xbf000000
That should load the tun kernel module.
I think we should then have to compile openvpn using android ndk.
A guy did it for the dream. Worth trying it. Maybe someone else could tell if binaries compiled for Dream can work on Hero
OpenVPN ist working on hero. I used the binaries for the G1. But the CIPHER is different: AES-256-CBC. I'm now testing it and if it's stable, perhaps I'm gonna compile openvpn with complete static openssl, so all functions should work.
If someone is interested, I can post my scripts and settings.
gogh57 said:
OpenVPN ist working on hero. I used the binaries for the G1. But the CIPHER is different: AES-256-CBC. I'm now testing it and if it's stable, perhaps I'm gonna compile openvpn with complete static openssl, so all functions should work.
If someone is interested, I can post my scripts and settings.
Click to expand...
Click to collapse
I am REALLY interested to now how you compiled it.
Hi!
I haven't compiled openvpn until now. I used this one:
https://www.digital-bit.ch/wiki/OpenVPN_auf_dem_G1
Just tried, may work. But i can't connect to my astaro because the key needs auth wit user and pw.
This Version hasnt been compiled with --auth-ask-pass. And reading from commandline doesn't work either..
I did compile it on my G1 with CyanogenMod ROM.
As far as I can see, it is working perfectly: I'm using it with certificates for 3 different VPNs.
Only issue: I wasn't able to complile a shared version of liblzo, so the binary is statically linked against liblzo.a (751 KB... )
Ah, yes, of course no GUI interface, shell only...
Hi!
Cool, could you post the binary? Could you give me a hint how you did it? I had several problems.
Would be perfect if someone could compile openvpn with " --enable-password-save"
Please post it, when a OpenVPN GUI for the HTC Hero / Magic is available.
Thans alot
wolfiedk said:
Please post it, when a OpenVPN GUI for the HTC Hero / Magic is available.
Thans alot
Click to expand...
Click to collapse
The great spam protection measures in this forum deny posting links for new users, so you have to manually follow them.
See: github.com/fries/android-external-openvpn
There is also an app and a statically linked openvpn binary at github.com/fries/android-external-openvpn/downloads
The openvpn binary has the following features:
* --enable-password-save
* statically linked against a blowfish enabled openssl
* statically linked against liblzo
Build:
* openvpn-static.bz2 was build on a donut-tree (1.6) for htc-magic
* openvpn-android-2.1.tar.bz2 was build on a cupcake (1.5) tree for htc-magic
* should run on a verity of (rooted) phones, please try it an give feedback.
A dynamically linked version is also available. The above git repo integrates seamless into the android build system. Some instructions may be found here: wiki.github.com/fries/android-external-openvpn/
Any feedback is welcome. Enjoy.
read this first -> http://sourceforge.net/projects/tunneldroid/files/README/download
First make sure kernel is compile with tun module
install tunneldroid from market
binary download -> http://sourceforge.net/projects/tunneldroid/files/openvpn-binary.zip/download
The newest version of my 'OpenVPN Settings' app is available at github.com/fries/android-external-openvpn/downloads

[HOWTO] tun.ko to run OpenVPN on Froyo xxJPK Galaxy S I9000

NOTE: there is no guarantee this will work, because without access to the corresponding kernel source I can't be sure. It may wipe out your device if there's memory corruption! You're warned, use it only at your risk!!
Over the last weekend I wanted to familiarize with the arm assembly, buildsystem, SDK so I created a tun.ko module for kernel running in the JPK ROM. But lots of the time was also wasted trying to guess their config (things like disabled DMABOUNCE and removal of the dummy they added in 2.6.29 from struct net_device, I hope I got it all right).
I encourage to release the kernel source along with the ROM images in the future (it'd be much simpler if there was a git tree that they can just tag with the name of the ROM), and to include the tun device into the modules/tun/tun.c (as in the tarball) so that it is included by default in the future. I won't be doing this process again.
I had to install openvpn with the openvpn installer a second time with openvpn in xbin, busybox in xbin/bb and I created the bb directory and two symlinks from xbin/bb/{ifconfig,route} to xbin/busybox (after mounting /system rw). The DNS to change during VPN must be set by long pressing on the left of the openvpn config slot in the OpenVPN settings GUI.
The tun.ko I keep it in /sdcard/openvpn/tun.ko and the path has to be configured in the openvpn settings advanced settings menu and I choose to load it with insmod.
This JPK rom works great for me, so I'll likely keep using it for a long while now that I've got openvpn running fine.
252ae6e655fa08774f32f67dd76dad3a tun.ko
EDIT: the same tun.ko module works for JPM too
Great job!!!
I use vpnc daily, so I couldn't even think to upgrade to JPK without an available tun module.. now I can!
Would you share your .config, so other devs can use it? Maybe we can hope in a Froyo-voodoo in a short time..
I'm confirming that it works.
Here is how I did it (I garantee that THIS IS NOT THE MOST ELEGANT WAY to make it work)
Install Openvpn from Openvpn Installer
openvpn in /system/xbin
route and ifconfig in /system/bin
At this point, Openvpn could connect and create a tun device, but route are not pushed so it's not very usefull
So, I downloaded this version of Openvpn
http://github.com/downloads/fries/android-external-openvpn/openvpn-static-2.1.1.bz2
As superuser
Code:
su
I remounted in rw /system
Code:
mount -o remount,rw /system
I renamed /system/xbin/openvpn into openvpn_old
Code:
mv /system/xbin/openvpn /system/xbin/openvpn_old
I put that new openvpn binary in /system/xbin
I created symlinks from /system/bin/route and ifconfig to /system/xbin
Code:
ln -s /system/bin/route /system/xbin/route
ln -s /system/bin/ifconfig /system/xbin/ifconfig
I also created a symlink os /system/xbin to /system/xbin/bb, just in case
Code:
ln -s /system/xbin /system/xbin/bb
Here we go
captive said:
Would you share your .config, so other devs can use it?
Click to expand...
Click to collapse
+1
i tried to complie cifs.ko and tun.ko for the JPC kernel and couldnt get it to work. i ultimately went back to eclair because of this so would like to be able to compile modules and other filesystem support.
thanks.
kanemari said:
+1
i tried to complie cifs.ko and tun.ko for the JPC kernel and couldnt get it to work. i ultimately went back to eclair because of this so would like to be able to compile modules and other filesystem support.
thanks.
Click to expand...
Click to collapse
config attached, but the config is not enough and it may not be fully correct (it is enough as far as the data structures used by tun.ko are concerned, I checked them all against the zImage assembly). The diff of the v2.1 image, has to be applied too but with DMABOUNCE removed from Kconfig of the subarch of the galaxy as far as I can tell and the placeholder added to struct net_device in their v2.1 diff, has to be removed too. cifs.ko may be more complicated than tun, good luck. Unless you've personal interest to familiarize with the enviroment and the arm assmbly like I had, I would wait the source to released, it has to be released eventually to comply with the GPLv2.
Thankyou Newmail!!
I've tryed VPNC 0.99 and works great!!
You have only to type from terminal: insmod /system/folder/tun.ko
After that you can use VPNC...
I've found an issue with the FQDN of the VPN gateway... solved setting the IP address
Just a question:
when I'll update my JPK.. what I have to do to recompile the tun.ko?
Can you write here the procedure?
Cheers
Paolo
newmail said:
config attached, but the config is not enough and it may not be fully correct (it is enough as far as the data structures used by tun.ko are concerned, I checked them all against the zImage assembly). The diff of the v2.1 image, has to be applied too but with DMABOUNCE removed from Kconfig of the subarch of the galaxy as far as I can tell and the placeholder added to struct net_device in their v2.1 diff, has to be removed too. cifs.ko may be more complicated than tun, good luck. Unless you've personal interest to familiarize with the enviroment and the arm assmbly like I had, I would wait the source to released, it has to be released eventually to comply with the GPLv2.
Click to expand...
Click to collapse
OK, but is the placeholder field at the end of the net_device struct?
If so it shouldn't matter and a module cross compiled from the 2.6.29 source should be OK. The absence of DMABOUNCE shouldn't matter for tun.ko either.
In theory you should be able to clone the AOSP git kernel repo and use that kernel for building a module, as long as the module itself doesn't actually use changes that have been made by Samsung (unlikely).
The .config used probably does deserve some attention though, as you have done.
foloap said:
Thankyou Newmail!!
I've tryed VPNC 0.99 and works great!!
You have only to type from terminal: insmod /system/folder/tun.ko
After that you can use VPNC...
I've found an issue with the FQDN of the VPN gateway... solved setting the IP address
Just a question:
when I'll update my JPK.. what I have to do to recompile the tun.ko?
Can you write here the procedure?
Cheers
Paolo
Click to expand...
Click to collapse
Glad it works great for you too. So the tun.ko has to be recompiled if they alter .config. It may work but it's not guaranteed. The procedure is nasty and hard to document and I don't have enough time for that sorry. But I'm sure we'll get the source when there will be an official Froyo release that is shipped to all phones so I wouldn't worry.
raven-au said:
OK, but is the placeholder field at the end of the net_device struct?
If so it shouldn't matter and a module cross compiled from the 2.6.29 source should be OK. The absence of DMABOUNCE shouldn't matter for tun.ko either.
In theory you should be able to clone the AOSP git kernel repo and use that kernel for building a module, as long as the module itself doesn't actually use changes that have been made by Samsung (unlikely).
The .config used probably does deserve some attention though, as you have done.
Click to expand...
Click to collapse
The .config is the fundamental part, and it may be enough I'm not sure. There was a placeholder was a samsung customization done in the middle of net_device and that was removed in the Froyo ROM (initially I applied it). the DMABOUNCE removal affects the struct device that is part of net_device so a lot of stuff goes off by 4 bytes by tweaking that arch config option. That gets set in some Kconfig patched in by samsung. You're right that probably tun isn't affected by the DMABOUNCE but I tried to get the net_device size right (just in case) and it may affect other net modules.
Hi newmail, thanks so much for the tun.ko file, this is the first time I've managed to get VPNC working on my SGS!! One question though, I find I'm having to run insmod everytime I reboot the phone to make tun.ko available again, does anyone know if there's a way around this please so it stays permanently available? Many thanks!!
@bdl1969
I made a subdir in /system/lib called "modules" and placed my tun.ko there.
Now it's insmodded automagically..
newmail said:
The .config is the fundamental part, and it may be enough I'm not sure. There was a placeholder was a samsung customization done in the middle of net_device and that was removed in the Froyo ROM (initially I applied it). the DMABOUNCE removal affects the struct device that is part of net_device so a lot of stuff goes off by 4 bytes by tweaking that arch config option. That gets set in some Kconfig patched in by samsung. You're right that probably tun isn't affected by the DMABOUNCE but I tried to get the net_device size right (just in case) and it may affect other net modules.
Click to expand...
Click to collapse
Oh crap, that is bad news.
Then both the DMABOUNCE and the net_device are likely a problem.
That's a stupid way of doing things.
raven-au said:
Oh crap, that is bad news.
Then both the DMABOUNCE and the net_device are likely a problem.
That's a stupid way of doing things.
Click to expand...
Click to collapse
The smart way of doing things I already mentioned in the first post (public git tree tagged at every ROM release .
captive said:
@bdl1969
I made a subdir in /system/lib called "modules" and placed my tun.ko there.
Now it's insmodded automagically..
Click to expand...
Click to collapse
hmm I tried and it didn't work for me... are you sure? openvpn GUI runs insmod for me so it's no big deal.
That worked great for me, thanks for the suggestion! The only problem I found was that it caused my Good for Enterprise app to crash so I uninstalled and reinstalled it and then it was all fine. Only problem I'm left with now is when using VPNC, I make the VPN connection fine but I can't disconnect via the app, I have to bounce the network connection (eg. toggle WiFi) to drop the tunnel!
I compiled tun.ko using the 2.6.32 kernel from android git and your .config, but it won't load with dmesg saying "Unknown symbol mem_map". May I ask which kernel version did you use, and what arm toolchain are you using?
sztupy said:
I compiled tun.ko using the 2.6.32 kernel from android git and your .config, but it won't load with dmesg saying "Unknown symbol mem_map". May I ask which kernel version did you use, and what arm toolchain are you using?
Click to expand...
Click to collapse
Probably you have discontigmem off in the .config. The platform of the galaxy isn't in the android kernel, it's in arch/arm/plat-s5pc11x (it's the thing that sets DMABOUNCE in v2.1 roms and I guess it doesn't on the JPK kernel).
You need to make a diff between android 2.6.29 and their tree, and apply it to the 2.6.32 kernel, then you need to solve enough rejects so that it can build external module. I didn't port the whole diff of course, just enough so make can start with the headers and .config all right. Then I built the module externally (adding the tun/ directory to their modules/ directory) but it should also work with just make modules setting CONFIG_TUN=m if you want to build it in-tree.
It's a bit tricky.. If you really need I can give you the broken diff to apply to the 2.6.32.9 android kernel. That is enough to build some module including tun.ko
newmail said:
Probably you have discontigmem off in the .config. The platform of the galaxy isn't in the android kernel, it's in arch/arm/plat-s5pc11x (it's the thing that sets DMABOUNCE in v2.1 roms and I guess it doesn't on the JPK kernel).
You need to make a diff between android 2.6.29 and their tree, and apply it to the 2.6.32 kernel, then you need to solve enough rejects so that it can build external module. I didn't port the whole diff of course, just enough so make can start with the headers and .config all right. Then I built the module externally (adding the tun/ directory to their modules/ directory) but it should also work with just make modules setting CONFIG_TUN=m if you want to build it in-tree.
It's a bit tricky.. If you really need I can give you the broken diff to apply to the 2.6.32.9 android kernel. That is enough to build some module including tun.ko
Click to expand...
Click to collapse
It'd be great. I've already tried to do the patching. It compiles, but crashes the phone when loaded. Maybe your version is a bit better.
sztupy said:
It'd be great. I've already tried to do the patching. It compiles, but crashes the phone when loaded. Maybe your version is a bit better.
Click to expand...
Click to collapse
Did you find the source now that JPM has been released officially with Kies? I upgraded to JPM now, in the hope we get the source....
BTW, my tun.ko and my rfs_async.ko also works fine on JPM. I don't know about my ext4 build but I assume that will work too.
I used one CSC of this thread http://forum.xda-developers.com/showthread.php?t=802909 and I deleted the KOR /efs/nv_data* created by the JPK ROM (leaving the .nv_data.bak*). So with this combination of CSC from that thread, and MODEM and PDA from the JPM rar, I apparently restored the original product_id (SGSToolbox also says I'm back to the original product_id). Not that product_id matters but I thought I'd try that next time I flashed and apparently it worked fine...
newmail said:
Did you find the source now that JPM has been released officially with Kies? I upgraded to JPM now, in the hope we get the source....
BTW, my tun.ko and my rfs_async.ko also works fine on JPM. I don't know about my ext4 build but I assume that will work too.
I used one CSC of this thread http://forum.xda-developers.com/showthread.php?t=802909 and I deleted the KOR /efs/nv_data* created by the JPK ROM (leaving the .nv_data.bak*). So with this combination of CSC from that thread, and MODEM and PDA from the JPM rar, I apparently restored the original product_id (SGSToolbox also says I'm back to the original product_id). Not that product_id matters but I thought I'd try that next time I flashed and apparently it worked fine...
Click to expand...
Click to collapse
The JPM source was avialable for a few hours on the samsung's site, did grap it. You can find it on megaupload somewhere. I couldn't manage to compile a working module from that source either (it now loads fine, but does a kernel panic when I try to mount a loop device formatted with ext4), but I'm sure that's my fault.

FTDI kernel module unknown relocation

Hey guys,
I've spent a few days now researching and attempting to build the FTDI kernel module for my Archos 70b. After following this guide I managed to get a successful compilation. I uploaded it to my device (which was rooted via Paul's root and rebooted into sde). When I attempt to use insmod, I get the following error: insmod: cannot insert '/sdcard/ftdi_sio.ko': Invalid module format (-1): Exec format error. I ran 'dmesg -c' and got the following output: [ 684.472290] ftdi_sio: unknown relocation: 27. I have the usbserial module installed already as well. What is the problem here? I'm assuming by relocation it means it's loading the module into the wrong part of the address space? I could be very off I'm new to this process. I just want to thank everyone in advance for their help, this is my first post and I've used these forums extensively over the last few days. You have a great community here.
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules
whistlinwilly said:
Hey guys,
I've spent a few days now researching and attempting to build the FTDI kernel module for my Archos 70b. After following this guide I managed to get a successful compilation. I uploaded it to my device (which was rooted via Paul's root and rebooted into sde). When I attempt to use insmod, I get the following error: insmod: cannot insert '/sdcard/ftdi_sio.ko': Invalid module format (-1): Exec format error. I ran 'dmesg -c' and got the following output: [ 684.472290] ftdi_sio: unknown relocation: 27. I have the usbserial module installed already as well. What is the problem here? I'm assuming by relocation it means it's loading the module into the wrong part of the address space? I could be very off I'm new to this process. I just want to thank everyone in advance for their help, this is my first post and I've used these forums extensively over the last few days. You have a great community here.
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules
Click to expand...
Click to collapse
Hi !
First be sure that you have the same version kernel->module , run modinfo module.ko and vermagic need to be the same with kernel version !
- if it's ok you can try strings module.ko and than insmod module.ko !
( but can be many things wrong in your process of compiling module !!! ) Good luck ...
I can confirm that the versions are the same, I was using an incorrect version before and dmesg was complaining. I've since compiled the module for the right kernel version and now dmesg only gives me the "unknown relocation: 27" error.
I ran the strings command, it outputted over 4000 lines. I'm not quite sure what you could gain from the output but I can attached the text file I piped it to if that will be helpful.
whistlinwilly said:
I can confirm that the versions are the same, I was using an incorrect version before and dmesg was complaining. I've since compiled the module for the right kernel version and now dmesg only gives me the "unknown relocation: 27" error.
I ran the strings command, it outputted over 4000 lines. I'm not quite sure what you could gain from the output but I can attached the text file I piped it to if that will be helpful.
Click to expand...
Click to collapse
Ok!
May be you have a problem when your module "export symbols" -> take a look into Module.symvers ... and see if something export !
I looked around and couldn't find Module.symvers either in the source code or on the actual device. Do you know where I might be able to find it or how I can create the file myself? When the module is compiled, make throws a warning about not being able to find it. I think this is the problem.
whistlinwilly said:
I looked around and couldn't find Module.symvers either in the source code or on the actual device. Do you know where I might be able to find it or how I can create the file myself? When the module is compiled, make throws a warning about not being able to find it. I think this is the problem.
Click to expand...
Click to collapse
Hi !
...maybe it help you => http://tldp.org/LDP/lkmpg/2.6/html/lkmpg.html
( module.symvers is created after you run make ( for make module) in directory where you compile module )
I'm not quite sure I understand. I get a warning
WARNING: Symbol fakepath/kernel/Module.symvers
is missing; modules will have no dependencies and modversions.
when I run make in the modules folder. There IS a file created called Module.symvers after I run make, but it is empty; I'm assuming its just a copy of whatever Module.symvers file it is actually looking for.
Has anyone compiled the archos gen9 kernel that might have created this file and can pass it along to me?
whistlinwilly said:
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules
Click to expand...
Click to collapse
Hi whistlinwilly
Are you sure you've grabbed the right kernel source - your KDIR says gen9, if your compiling for the 70b you probably need the gen8 kernel source code as I think it's on the Gen8 product line
you can check which kernel version you have by running the following from a command prompt.
Code:
adb shell uname -a
Hope that helps
Hey whistlinwilly,
i don't know if you were successful in the meantime, but here's what i suggest for simple kernel module compilation...
You might refer to my custom kernel thread and check my toolchain, which is ready to rock (only 32bit linux right now):
http://forum.xda-developers.com/showthread.php?t=1328027
To compile custom kernel/modules only, look here as well:
http://forum.xda-developers.com/showpost.php?p=19134490&postcount=8
The archos specific toolchain uses uclibc and is used for kernel and userland.
So if you use stock kernel, but choose a different toolchain (e.g. libc based) to compile your modules, you might run into trouble at some point.
BTW, is it correct that you talk about this device:
http://www.archos.com/products/ta/archos_70b/index.html?country=de&lang=de
Not sure which family it exactly belongs to
If you're talking about this one:
http://www.archos.com/products/ta/archos_70it2/index.html?country=de&lang=de
...the kernel should be 2.6.35 then.
http://gitorious.org/archos/archos-gpl-gen9-kernel
I'm not aware of any config for the A70IT2 though.
Please refer to trevd's suggestion and find out your kernel release first...
Good luck!
scholbert
I had the same problem (Relocation error: 27) when trying to compile a custom kernel module for my Moto xoom running Honeycomb.
I was able to compile successfully by rolling back to Android NDK 5b. I also had to force the vermagic string to read ARMv7 so I know this isn't the right way to solve the problem, but when I compiled with the 5b toolchain, the relocation error goes away and I am able to insmod without error on the tablet.
I would love to know why this works and the right way to get NDK 7 to work with this, if anyone can shed some light??
EDIT:
On further digging and testing- I realize it is not necessarily NDK 5b, but rather the toolchain "arm-eabi-4.4.0" as opposed to using the "arm-linux-androideabi-4.4.3" toolchain, that makes the difference with the "unknown relocation 27" error. It just so happens that NDK 5b is the last NDK that shipped with both toolchains, AFAIK.
It still for some reason likes to compile under ARMv5 unless I force it to use ARMv7 but this issue is probably unrelated- I didn't mean to confuse things with the ARM v5/v7 versus NDKr5 /NDKr7 which don't correlate...
Anyway I hope this helps, or maybe someone else who knows more can help us both!
Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!
the_zuck said:
Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!
Click to expand...
Click to collapse
Thanks a million, finally got past the relocation 27 error now. Insmod doesn't complain anymore and the drivers load successfully, now to just figure out why I'm getting a backtrace on device insertion.
Thanks for solving my major headache tho
Exec format error
the_zuck said:
Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!
Click to expand...
Click to collapse
Ok, thanks for the answer. My first post here.
After this got solved. I still have "Exec format error". And! and no errors are display in dmesg. Are there any other places where the error might be displayed? I just created a simple printk("hello world") project.
If i remove the printk it doesn't show the error.
I don't know whether to laugh or cry. I dabbled my self to the brink of madness to solve this. I couldn't find a solution anywhere. Finally solved it after 6 weeks of my time. Probably my boss at work will not be happy if he finds I was working on this instead of working.
And I find the solution here 2 days after I solved it. WOW!!!:crying::crying:
But my saga still continues...

[Q] Working & stable SSHD/sftpd for ZE55xML ?

Apologize for possible OT, but I can't find an always working (and stable) SSH daemon app for the Zenfone2's Lollipop
This is what I tried, any of them PAID apps:
QuickSSHd - too old, not even starts
SSHDroid Pro - sometime starts, only first time after reboot, but only without root and higher ports (>1024)
RRooted SSH/SFTP Daemon - always refusing connections
Ssh Server Pro (olive tree) - seems promising, but very poor of binaries
The Dropbear service hanging issue seems the root of this problem
Thanks for any hint
I can't even find a proper ssh binary. I just tried sshd from an x86 cyanogen port (RAZRi, I think). Got this after loading appropriate library in lib (same as client)
1|[email protected]:/ # sshd
CANNOT LINK EXECUTABLE: could not load library "libssh.so" needed by "sshd"; caused by cannot locate symbol "EVP_ripemd160" referenced by "libssh.so"...
Good luck sir
Blades said:
I can't even find a proper ssh binary. I just tried sshd from an x86 cyanogen port (RAZRi, I think). Got this after loading appropriate library in lib (same as client)
1|[email protected]:/ # sshd
CANNOT LINK EXECUTABLE: could not load library "libssh.so" needed by "sshd"; caused by cannot locate symbol "EVP_ripemd160" referenced by "libssh.so"...
Good luck sir
Click to expand...
Click to collapse
Hi,
I followed the following guide which you can get from googling "Compiling-Dropbear-for-a-Nexus-7-tablet". Sorry, I can't post any links yet as my post counts are still below 10
The difference with the info from the website above is that we don't need to cross compile if you're compiling in a Linux x86-64 system. Just need to make a static binary.
Let me know if you have any questions and I'll try to help out.
Cheers.
wolfdude said:
The difference with the info from the website above is that we don't need to cross compile if you're compiling in a Linux x86-64 system. Just need to make a static binary.
Let me know if you have any questions and I'll try to help out.
Click to expand...
Click to collapse
Thanks for your answer.
Sorry but I can't get the exact entry-point, bypassing all the NDK / X-compiling stuff, as we're on a x86_64 architecture
Referring to the "simplified" version of your link (here: https://nerdoftheherd.com/articles/cross-compiling-dropbear-rsync-android/ ),
how should I compile the Dropbear source ?
Something like this ?
Code:
./configure \
--disable-zlib --disable-largefile --disable-loginfunc --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog \
CFLAGS='-Os -W -Wall -fPIE' LDFLAGS='[COLOR="Red"]-static[/COLOR] -fPIE -pie'
... right before make-ing ?
Thanks for any further hint in the right direction
Hi,
I didn't refer to that site you have posted BUT that site does have a link at the bottom to the site where I followed.
From that site, what I did was :-
1) Download dropbear v58 (dropbear-2013.58.tar.bz2). I know this is older but the patch available is based on this version.
2) Download patch (dropbear-patch2) from that site.
3) Apply patch to the original dropbear (v58) source.
4) Run configure :-
./configure --disable-zlib --disable-largefile --disable-loginfunc \
--disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog
5) Run make :-
STATIC=1 MULTI=1 SCPPROGRESS=0 PROGRAMS="dropbear dropbearkey scp dbclient" make strip
6) You should end up with "dropbearmulti" which is a static binary that you can then copy over the the phone & go on from there.
There are some issues with that version of the code (v58+patch). Namely the "scp" doesn't work (but I have found the offending code in scp.c and found a workaround).
Let me know if you need more details. If I have some time, I might look at getting the latest dropbear version & working out a patch for it to get it to work on android x86.
Cheers.
wolfdude said:
Hi,
I didn't refer to that site you have posted BUT that site does have a link at the bottom to the site where I followed.
[...]
There are some issues with that version of the code (v58+patch). Namely the "scp" doesn't work (but I have found the offending code in scp.c and found a workaround).
Let me know if you need more details. If I have some time, I might look at getting the latest dropbear version & working out a patch for it to get it to work on android x86.
Cheers.
Click to expand...
Click to collapse
Yes of course. The main link you weren't able to post is:
http://blog.xulforum.org/index.php?post/2013/12/19/Compiling-Dropbear-for-a-Nexus-7-tablet
Actually that procedure seemed too complex as mostly dealing with the cross-compiling issue, which didn't apply to x86 case.
So I named the derivative one
Thanks for pointing out the static compiling is done within MAKE and not CONFIGURE phase... I'm quite newbie in those flags so I do appreciate any of your words
About issues, what about using the latest v67 for Dropbear sources ? (see here)
If the patch doesn't work for such different version, I guessed commenting out the interactive password line would be enough
I'm trying to compile it this way and - for instance - replace the binaries in one of the SSHD packages I named in the OP...
Thank you again for your time
Val3r10 said:
About issues, what about using the latest v67 for Dropbear sources ? (see here)
If the patch doesn't work for such different version, I guessed commenting out the interactive password line would be enough
I'm trying to compile it this way and - for instance - replace the binaries in one of the SSHD packages I named in the OP...
Thank you again for your time
Click to expand...
Click to collapse
Hi,
Yes, the patch for v58 does not work for v67. I think one just have to go through the patch and "adjust" it slightly for the newer v67. Hopefully there isn't much changes from v58 to v67. There may be more than just commenting out the password prompt as there are certain functions that don't work in Android as in *NIX. When I have some time, I will attempt to patch v67 meanwhile, I'm running v58 fine on my ZE550ML so no complains there.
Cheers.
Hi,
I've created a guide on compiling the latest dropbear (2015.67) :-
http://forum.xda-developers.com/zenfone2/general/compiling-dropbear-2015-67-zenfone-2-t3142222
Hope it helps.
Cheers.
wolfdude said:
I've created a guide on compiling the latest dropbear (2015.67)
Click to expand...
Click to collapse
Thanks a lot.
Do you think the same process (STATIC build, of course, not patching) could be likely used for other small binaries too ?
Val3r10 said:
Thanks a lot.
Do you think the same process (STATIC build, of course, not patching) could be likely used for other small binaries too ?
Click to expand...
Click to collapse
Of course. I've managed to compile tcpdump, iperf, gdbserver, etc... successfully and working fine on the Zenfone 2.
Cheers.
I found that "Servers Ultimate" SSH/SFTP modules work on the Zenfone2 once properly configured. Its not working 100% but its already more then most solutions out there.

How To Guide Get BCM4389 into monitor mode for WIFI sniffing

Hey all,
I was trying to watch beacon frames transmitted by my access point, but had no capable hardware in my house to sniff it. Or did I?
Turns out, Pixel 6 / Pixel 6 Pro can do it. Here's my howto.
Getting the BCM4389 in Pixel 6 into monitor mode for tcpdump/Wireshark WIFI sniffing
A little side project to debug a WIFI 6E TP-Link mesh network in my house, went from "This sounds easy!" to "This is impossible!" to "It can...
chrisf4.blogspot.com
Short answer: Flash an aosp_raven-userdebug build from Google, then use wifi_sniffer and some related system properties to configure frequency and bandwidth, and enable monitor mode using a special firmware that is shipped in the userdebug build. Then, use tcpdump on the newly created radiotap0 interface.
Enjoy,
Chris
Is there any real difference from doing it this way?
GitHub - kimocoder/qualcomm_android_monitor_mode: Qualcomm QCACLD WiFi monitor mode for Android
Qualcomm QCACLD WiFi monitor mode for Android. Contribute to kimocoder/qualcomm_android_monitor_mode development by creating an account on GitHub.
github.com
x56x said:
Is there any real difference from doing it this way?
GitHub - kimocoder/qualcomm_android_monitor_mode: Qualcomm QCACLD WiFi monitor mode for Android
Qualcomm QCACLD WiFi monitor mode for Android. Contribute to kimocoder/qualcomm_android_monitor_mode development by creating an account on GitHub.
github.com
Click to expand...
Click to collapse
Hi x56x, a dependency for that is "3. WiFi chipset that actually uses the QCACLD driver/firmware."
Since Pixel 6 uses a Broadcom WIFI chip and not Qualcomm, you would need my directions for Pixel 6 and 6 Pro.
-Chris
ccfries said:
Hi x56x, a dependency for that is "3. WiFi chipset that actually uses the QCACLD driver/firmware."
Since Pixel 6 uses a Broadcom WIFI chip and not Qualcomm, you would need my directions for Pixel 6 and 6 Pro.
-Chris
Click to expand...
Click to collapse
I actually used these commands for qualcomm on a rooted stock A12 P6P and it worked flawlessly. Never got a chance to mess around with packet sniffing. I am curious as to how you found this? Maybe someone can take a deeper look at the firmware and start working on packet injection.
x56x said:
I actually used these commands for qualcomm on a rooted stock A12 P6P and it worked flawlessly. Never got a chance to mess around with packet sniffing. I am curious as to how you found this? Maybe someone can take a deeper look at the firmware and start working on packet injection.
Click to expand...
Click to collapse
I don't think it could work
raven:/ # ls -l /sys/module/wlan/parameters/con_mode
ls: /sys/module/wlan/parameters/con_mode: No such file or directory
Are you on Android 12, 12.1, or 13? I got it to work on 12 when the phone first came out, so something had to have changed.
I worked on Pixel 6 kernel software and this didn't change..
Just to be sure, you can sniff WIFI packets that the kernel sees, without any changes and just root, using tcpdump. If you want to see other traffic that the WIFI chip would normally filter out, you need monitor mode and you need to load this separate firmware to get into monitor mode.
I pulled the wifi sniffer binary, firmware and .rc files needed to get monitor mode working and packed them into a magisk module. you can find it here on my github
GitHub - Biohazardousrom/nh-magisk-wifi-firmware-gs101-gs201: This Magisk module adds the required firmware for external wireless adapters to be used with NetHunter.
This Magisk module adds the required firmware for external wireless adapters to be used with NetHunter. - GitHub - Biohazardousrom/nh-magisk-wifi-firmware-gs101-gs201: This Magisk module adds the r...
github.com
Duhjoker said:
I pulled the wifi sniffer binary, firmware and .rc files needed to get monitor mode working and packed them into a magisk module. you can find it here on my github
GitHub - Biohazardousrom/nh-magisk-wifi-firmware-gs101-gs201: This Magisk module adds the required firmware for external wireless adapters to be used with NetHunter.
This Magisk module adds the required firmware for external wireless adapters to be used with NetHunter. - GitHub - Biohazardousrom/nh-magisk-wifi-firmware-gs101-gs201: This Magisk module adds the r...
github.com
Click to expand...
Click to collapse
Tried to install today, Didnt see a Release on the Github page, tried to manually compile the magisk module and just get error "Failed to unzip" in magisk. Any ideas? Thanks regardless, been searching up and down for the Wifi_Sniffer binary
try this zip. github is weird sometimes with magisk modules source when you download it.
as for the binaries and the firmware they are located in the system/vendor folder in the zip
Duhjoker said:
try this zip. github is weird sometimes with magisk modules source when you download it.
as for the binaries and the firmware they are located in the system/vendor folder in the zip
Click to expand...
Click to collapse
WORKS PERFECT, THANKS A MILLION!!!!
raven(bear)claws said:
WORKS PERFECT, THANKS A MILLION!!!!
Click to expand...
Click to collapse
on a side note, i am getting "permission denied" while trying to run "wifi_sniffer start". on a rooted pixel 6 pro, factory image but have ro.userdebugging enabled. adb sees the process just does not have access to view it. Could be my goof since i am not using userdebug build
go to data/adb/modules look for the module and go to system/vendor/bin and change the permissions with
chmod a+x wifi_sniffer
chmod a+x wifi_perf_diag
i guess i need to fix that somehow
Duhjoker said:
go to data/adb/modules look for the module and go to system/vendor/bin and change the permissions with
chmod a+x wifi_sniffer
chmod a+x wifi_perf_diag
i guess i need to fix that somehow
Click to expand...
Click to collapse
It starts now!! time for me to fiddle with this "Unable to open /sys/wifi/firmware_path, Failed to up radiotap0" error, surely i made a mistake.
i havent had much time to play with it. i was really hoping someone could figure it out and recount thier steps here.
i noticed some sepolicy stuff reguarding wifi_sniffer while building a few roms for pixel 7, theres an incomplete package to build it. right now adding the package to the device trees to build enables the sepolicy for it but thats it. we may not be able to use them with out using a beta preview until android 14 is released. thats speculation though, cause i dont know.
but please anyone that gets this working please share your steps
Duhjoker said:
i havent had much time to play with it. i was really hoping someone could figure it out and recount thier steps here.
i noticed some sepolicy stuff reguarding wifi_sniffer while building a few roms for pixel 7, theres an incomplete package to build it. right now adding the package to the device trees to build enables the sepolicy for it but thats it. we may not be able to use them with out using a beta preview until android 14 is released. thats speculation though, cause i dont know.
but please anyone that gets this working please share your steps
Click to expand...
Click to collapse
I actually got useful help from ChatGPT. dmesg has an output of [wlan] wl_cfg80211_alert ←[0m: In : error alert eventing, reason=0x6, which indicated firmware corruption. Will start looking at the firmware file its self momentarily.
This is how i get wifi_sniffer to work. first download and install the nethunter firmware magisk module. check permissions of the binaries.
next reboot your device and disable wifi and data. This must be done in order to restart the wlan in monitor mode
now open terminal emulator and either type or copy and paste the commands below
in su shell
Code:
su
# Set bandwidth to 160 MHz for sniffing on 2.4 GHz
Code:
setprop persist.vendor.wifi.sniffer.bandwidth 160
# Set 2.4GHz band
Code:
setprop persist.vendor.wifi.sniffer.freq 2412
# start wifi sniffer
Code:
wifi_sniffer start
#tcp dump to .pcap file
Code:
tcpdump -i radiotap0 type mgt subtype beacon -w /data/beacon-capture.pcap

Categories

Resources