mmohanraj91 / droidwall

Automatically exported from code.google.com/p/droidwall
0 stars 0 forks source link

Error applying iptables rules. Exit code: -1 #51

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Before a recent update, droidwall worked on my motorola droid.

Now, I get "Error applying iptables rules.  Exit code: -1" when I try to apply 
rules.  Show log reports, "Log is empty"

Show rules gives just a blank dialog.

Trying to disable the firewall, I see "Working... Deleting iptables rules" 
followed by "error purging iptables, exit code: -1"

Any ideas?

Droidwall is great, and I'd like to get it working again.  Thanks.

motorola droid, sapphire 1.1.0 
(http://sapphire.ccroms.net/wiki/releases/sapphire-1.1.0)

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by davecohe...@gmail.com on 18 Oct 2010 at 5:27

GoogleCodeExporter commented 9 years ago
Same here. Exactly the same as above.

Error began when I installed Tweetdeck 1.0 (without removing Tweetdeck beta, so 
I had two Tweetdecks installed). Even after uninstalling both, my Droid Wall 
applications list still showed one of them.

Even after uninstalling Droid Wall, clearing the cache, reinstalling, it gives 
the above error.

Original comment by chris.de...@googlemail.com on 18 Oct 2010 at 11:52

GoogleCodeExporter commented 9 years ago
If I have a corrupt file lying around, I'm familiar enough with adb that I 
could probably delete it or clean it up.  Can anyone tell me what to look for?

Thanks.

Original comment by davecohe...@gmail.com on 18 Oct 2010 at 5:10

GoogleCodeExporter commented 9 years ago
You could try to clear the cache using the "manage applications" and try again. 
Please let me know the results.

Original comment by rodrigo...@gmail.com on 18 Oct 2010 at 8:36

GoogleCodeExporter commented 9 years ago
That seems to fix it.  Thanks!

I had tried clearing the data.  That did not help.  Clearing the cache does.

Original comment by davecohe...@gmail.com on 18 Oct 2010 at 10:16

GoogleCodeExporter commented 9 years ago
Great :)
@chris.delaforce, can you confirm if this works for you too? Thanks

Original comment by rodrigo...@gmail.com on 19 Oct 2010 at 12:45

GoogleCodeExporter commented 9 years ago
Didn't work for me either. As I stated in my original post, I had cleared my 
cache.

Original comment by chris.de...@googlemail.com on 19 Oct 2010 at 7:48

GoogleCodeExporter commented 9 years ago
Just tried again with no success, but after a reboot it's fine.

Original comment by chris.de...@googlemail.com on 19 Oct 2010 at 8:56

GoogleCodeExporter commented 9 years ago

Original comment by rodrigo...@gmail.com on 19 Oct 2010 at 5:35

GoogleCodeExporter commented 9 years ago
The problem is back.  I've rebooted, I've cleared the application cache.  I've 
tried over and over.

Today I always get the exit code -1 error whenever I try to enable or apply 
rules.  Nothing I've tried will fix it.

Original comment by davecohe...@gmail.com on 20 Oct 2010 at 8:16

GoogleCodeExporter commented 9 years ago
Okay.. try the following:
1. Try to enable the firewall
2. After getting the error, open and ADB shell (or use the Terminal Emulator)
3. Make sure you are root (type "su")
4. cd /data/data/com.googlecode.droidwall/cache
5. ls -l droidwall.sh
(This file should exist and have execution permissions)
Try to run it manually and let me know the results:
./droidwall.sh

Original comment by rodrigo...@gmail.com on 20 Oct 2010 at 8:34

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
i use droidwall on my i9000 with android 2.2...
the problem is the "iptables_g1" file in 
/data/data/com.googlecode.droidwall/cache/
it hangs and return no errorcode, so the droidwall.sh scrip hangs to.
the iptables_n1 file work fine.

1. cd /data/data/com.googlecode.droidwall/cache
2. ./iptables_g1 --version

dirty fix:
cp iptables_g1 iptables_g1_old
cp iptables_n1 iptables_g1
./droidwall.sh

Original comment by alexande...@googlemail.com on 21 Oct 2010 at 9:39

GoogleCodeExporter commented 9 years ago
Well the dirty fix works perfectly, I had the same issue with my i9000 and 
thanks to you no more hangs :D

Can you please detail your dirty fix? 
What exactly does happen?
Any cpu/ram/blocking type impact?

Original comment by vadimpe...@gmail.com on 21 Oct 2010 at 5:27

GoogleCodeExporter commented 9 years ago
It seems that the "iptables_g1" binary is simply hanging forever on those 
devices.

DroidWall is currently shipping with two different iptables binaries - each one 
was compiled for one processor architecture.
There is no "easy" way to determine which one works on each phone, so basically 
it first attempts to use "iptables_g1", and if that one fails it tries the 
"iptables_n1".

Right now, I am out of ideas about how to fix this... but I will try to work 
out something  for the next release.

Original comment by rodrigo...@gmail.com on 21 Oct 2010 at 7:07

GoogleCodeExporter commented 9 years ago
Why not simply add a galaxy S fix item in the settings menu that implements the 
"dirty fix"?

Original comment by vadimpe...@gmail.com on 21 Oct 2010 at 7:10

GoogleCodeExporter commented 9 years ago
I am still researching the best solution for this issue.

I would really like to get rid of the two different iptables binaries. I am 
sure that it is possible to compile one that runs on all ARM architectures, 
like I did with busybox (which I compiled myself).

The binary shipped with "Wireless Tether for root users" for example runs fine 
on all devices, but that version is unfortunately too old for DroidWall.

As a last resource I will check the processor architecture and determine which 
binary to use automatically.

Original comment by rodrigo...@gmail.com on 21 Oct 2010 at 11:34

GoogleCodeExporter commented 9 years ago
Samsung I9000, 2.1, exit - error when applying rules.............please help

Original comment by tna...@gmail.com on 22 Oct 2010 at 12:29

GoogleCodeExporter commented 9 years ago
@tnajju, does the dirty fix posted by alexander.seener works for you?

Original comment by rodrigo...@gmail.com on 22 Oct 2010 at 12:38

GoogleCodeExporter commented 9 years ago

@rodrigo.zr, Thanks dude for the support dear. its working now after a reboot. 
Thanks again.........you guys rock!!! :)

Original comment by tna...@gmail.com on 22 Oct 2010 at 1:07

GoogleCodeExporter commented 9 years ago
@rodrigo.zr
i played a little bit... and had a idea...

start iptables in backround, wait 3 sec and check it with "ps".

here is a part of iptables check in my droidwall.sh...

# Try to find iptables
$BUSYBOX killall "iptables_g1" >/dev/null 2>/dev/null
/data/data/com.googlecode.droidwall/cache/iptables_g1 --version >/dev/null 
2>/dev/null &
sleep 3
IPTABLES_G1=$(ps | $BUSYBOX grep iptables_g1)         
$BUSYBOX killall "iptables_g1" >/dev/null 2>/dev/null
if [ -z "$IPTABLES_G1" ]; then
        if /data/data/com.googlecode.droidwall/cache/iptables_g1 --version >/dev/null 2>/dev/null ; then
                IPTABLES=/data/data/com.googlecode.droidwall/cache/iptables_g1
        fi
elif [ "$IPTABLES" = "iptables" ]; then
        $BUSYBOX killall "iptables_n1" >/dev/null 2>/dev/null
        /data/data/com.googlecode.droidwall/cache/iptables_n1 --version >/dev/null 2>/dev/null &
        sleep 3
        IPTABLES_N1=$(ps | $BUSYBOX grep iptables_N1)         
        $BUSYBOX killall "iptables_N1" >/dev/null 2>/dev/null
        if [ -z "$IPTABLES_N1" ]; then
                if /data/data/com.googlecode.droidwall/cache/iptables_n1 --version >/dev/null 2>/dev/null ; then
                        IPTABLES=/data/data/com.googlecode.droidwall/cache/iptables_n1
                fi
        fi
fi

$IPTABLES --version || exit 1

Original comment by alexande...@googlemail.com on 23 Oct 2010 at 5:47

GoogleCodeExporter commented 9 years ago
Won't this cause an unpleasant delay? With the dirty fix it's quite fast.

Original comment by vadimpe...@gmail.com on 23 Oct 2010 at 6:06

GoogleCodeExporter commented 9 years ago
Yes... I don't like the idea of having to sleep for a few seconds just to 
detect which binary to use.

I was trying to compile iptables myself using Android NDK and got pretty close 
from success. I am still facing some problems with the dynamic linker, but I'll 
keep trying. ;)

Original comment by rodrigo...@gmail.com on 24 Oct 2010 at 1:12

GoogleCodeExporter commented 9 years ago
So what does the dirty fix actually do (that is not right)?
It really seems easy to implement

Original comment by vadimpe...@gmail.com on 24 Oct 2010 at 4:29

GoogleCodeExporter commented 9 years ago
The problem is how to determine which devices need the "dirty fix". DroidWall 
will stop working on MANY devices if you do this "fix".

Original comment by rodrigo...@gmail.com on 25 Oct 2010 at 11:33

GoogleCodeExporter commented 9 years ago
I suggest to leave the program as it is and add a menu option:

"▢ Enable alternative iptables fix"

A short explanation in the change log and help menu, like "tick this if you 
have an error" should be much more practical than circumventing this issue by 
hardcoding.

Original comment by vadimpe...@gmail.com on 25 Oct 2010 at 12:43

GoogleCodeExporter commented 9 years ago
hi,
a other idea is to detect iptables settings on the first startup or after 
update of the app. you can save the result in a config file.
the delay is only executed once.

Original comment by alexande...@googlemail.com on 26 Oct 2010 at 9:01

GoogleCodeExporter commented 9 years ago
I just stumbled upon the changelog and saw the planed features:

"Log output now displays the number of packets blocked per destination IP 
address."

I hope this doesn't mean that the UID/name of the app sending data won't be 
shown anymore?

Original comment by vadimpe...@gmail.com on 26 Oct 2010 at 3:40

GoogleCodeExporter commented 9 years ago
@vadimpelau no, this information is still there ;)

Original comment by rodrigo...@gmail.com on 26 Oct 2010 at 4:53

GoogleCodeExporter commented 9 years ago
Just an idea: to detect these phones you could use:

"cat /system/build.prop | busybox grep ro.product.model"

which returns:

ro.product.model=GT-I9000

Original comment by adrian.pasvante on 27 Oct 2010 at 3:04

GoogleCodeExporter commented 9 years ago
I Cleared the Cache and userdata, uninstalled, restarted phone and installed 
from market .
Now it works again

Original comment by tonymont...@gmail.com on 3 Nov 2010 at 1:21

GoogleCodeExporter commented 9 years ago
I followed the advise given by comment #12, and it worked.

However, sometimes later it rolled back to what it was.  I notice this because 
I get the same error code again.  I then check the cache directory and found 
the iptables_g1_old (came from iptables_g1) was gone and everything was the 
same as before, as if I didn't make any change to it.

Just let you know ... it would be nice to have a permanent solution to it.  By 
the way, it didn't seem to be able to block "News and Weather" because I still 
get the update (temperature) while the log says it did block it.  I am confused.

Thanks.

Original comment by jjyu2...@gmail.com on 5 Nov 2010 at 7:58

GoogleCodeExporter commented 9 years ago
Here is the update: the cache directory was wiped out after I ran app 
CacheCleaner.
That is why I said in the previous note that things were as if I didn't replace 
iptables_g1 with iptables_n1.

Original comment by jjyu2...@gmail.com on 5 Nov 2010 at 8:07

GoogleCodeExporter commented 9 years ago
can this work:

Using uname -a  or uname -m to determine what hardware architecture before 
deciding which binary to use?

I have no idea how this would work on G1.  Just a thought.  

Original comment by jjyu2...@gmail.com on 5 Nov 2010 at 8:49

GoogleCodeExporter commented 9 years ago
I flashed several times JM8, JP6, JPA (galaxy S firmwares) after I did the fix 
from comment #12.

Finally, having installed JPA, I also installed droid wall anew and is seems to 
work perfectly...

Is it possible the issue was solved by the new JPA firmware or has the #12 fix 
somehow survived the multiple flash and factory reset(did that too + format 
data, system, cache, dalvik cache etc)?

Original comment by vadimpe...@gmail.com on 5 Nov 2010 at 9:46

GoogleCodeExporter commented 9 years ago
Strangely enough, it is working without giving out the -1 error code.

I did not do anything in particular at all, except applying all the market 
updates whenever I see them, which I do not know they are in anyway related to 
this app.

This is really puzzling.  I am glad it works.  But I do not know what made it 
failed in the beginning.

Original comment by jjyu2...@gmail.com on 8 Nov 2010 at 1:42

GoogleCodeExporter commented 9 years ago
I think I finally fixed this. I was able to compile iptables using the android 
NDK, but that still didn't work :(
So I had to detect the CPU architecture and choose the binary using that 
information.

The attached APK is a development version of DroidWall which should have this 
fixed.
I would appreciate if someone could test it for me (clear the cache before 
installing).
Thanks

Original comment by rodrigo...@gmail.com on 9 Nov 2010 at 11:47

Attachments:

GoogleCodeExporter commented 9 years ago
I checked it and it works great - no hangs, error messages, the rules are 
applied and work as intended.

Thanks for your effort!

(SGS-I9000 international version; Froyo (JPM/JP6) firmware). I cleared the 
cache, data, then uninstalled the old version then installed this dev.apk.

Original comment by adrian.pasvante on 9 Nov 2010 at 3:06

GoogleCodeExporter commented 9 years ago
Still have the error on my wildfire (firmware: 2.1)
I noticed that the error ocurs just on 3g rules; no error on wifi.

Original comment by cristi.m...@gmail.com on 10 Nov 2010 at 9:17

GoogleCodeExporter commented 9 years ago
@adrian.pasvante, Thanks for the testing.

@cristi.moga, are you sure you are getting "Exit code: -1"? Please give more 
details of your issue. The bug reported here causes DroidWall to fail on both 
wifi and 3g, so you might be facing a different issue.

Original comment by rodrigo...@gmail.com on 10 Nov 2010 at 8:18

GoogleCodeExporter commented 9 years ago

Original comment by rodrigo...@gmail.com on 10 Nov 2010 at 8:19

GoogleCodeExporter commented 9 years ago
My error is " error applying iptables rules. Exit code: 1 
Iptables  v1.4.7
Iptables: no chain/ target/match by that name."

Original comment by cristi.m...@gmail.com on 10 Nov 2010 at 9:56

GoogleCodeExporter commented 9 years ago
@cristi.moga, sorry but this error means that your kernel does not support the 
"iptables owner match" kernel module - DroidWall will unfortunately not work on 
your ROM.

This is not related to the "Exit code: -1" error from this issue.

Original comment by rodrigo...@gmail.com on 11 Nov 2010 at 11:05

GoogleCodeExporter commented 9 years ago
Good afternoon!

I didn't want to start a new thread for that, so I write here.
I have the same error, but I have it from the very start, just after I 
installed it. I think it's HTC Desire issue, but it's only an assumption.

I've "rooted" my phone, then installed this app and opened it. After I tried to 
turn firewall on, it gave me a window saying:
-------------------------------------------------------
Error applying iptables rules.

Exit code: 1

[: not found
[: not found
[: not found
[: not found
-- version: not found
-------------------------------------------------------

I've checked the Log Collector ans here is what I found for DroidWall:

-------------------------------------------------------
11-16 15:18:13.873 I/ActivityManager(   92): Starting activity: Intent { 
act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] 
flg=0x10200000 cmp=com.googlecode.droidwall/.MainActivity 
bnds=[245,410][355,528] }
...
11-16 15:18:14.164 I/ActivityManager(   92): Displayed activity 
com.googlecode.droidwall/.MainActivity: 185 ms (total 185 ms)
...
11-16 15:18:20.193 W/Parcel  (   92): Attempt to read object from Parcel 
0x4847dde0 at offset 740 that is not in the object list
11-16 15:18:20.193 I/ActivityManager(   92): Starting activity: Intent { 
act=android.intent.action.MAIN flg=0x58000000 pkg=com.noshufou.android.su 
cmp=com.noshufou.android.su/.SuRequest (has extras) }
11-16 15:18:20.553 D/MailRequestHandler(  455): 06021143 onUpdateProgressStatus 
is not implemented for message.what:13
11-16 15:18:20.734 W/ActivityManager(   92): Activity pause timeout for 
HistoryRecord{4668fd50 com.googlecode.droidwall/.MainActivity}
11-16 15:18:20.834 D/SuRequest(  569): Sending result: ALLOW
11-16 15:18:20.834 D/su      ( 3055): 10071 com.googlecode.droidwall executing 
0 /data/data/com.googlecode.droidwall/cache/droidwall.sh
11-16 15:18:20.873 E/DroidWall(  559): [: not found
11-16 15:18:20.873 E/DroidWall(  559): [: not found
11-16 15:18:20.873 E/DroidWall(  559): [: not found
11-16 15:18:20.873 E/DroidWall(  559): [: not found
11-16 15:18:20.873 E/DroidWall(  559): --version: not found
...
11-16 15:18:59.493 W/ActivityManager(   92): Activity pause timeout for 
HistoryRecord{4668fd50 com.googlecode.droidwall/.MainActivity}
11-16 15:18:59.574 D/SuRequest(  569): Sending result: ALLOW
11-16 15:18:59.574 D/su      ( 3059): 10071 com.googlecode.droidwall executing 
0 /data/data/com.googlecode.droidwall/cache/droidwall.sh
-------------------------------------------------------

Please tell me if I can run this great program on my Desire? What should I do 
for that? I have HTC Desire with Android 2.2 on it.

Thanks in advance!

Original comment by jpro....@gmail.com on 16 Nov 2010 at 1:47

GoogleCodeExporter commented 9 years ago
@jpro.swt, this is an old bug (issue 41) that has been fixed on the v1.4.2 - it 
is not related to the issue described here.
You can try either the official 1.4.2 version or the latest development version 
attached on Comment 36 of this thread.

Original comment by rodrigo...@gmail.com on 16 Nov 2010 at 1:55

GoogleCodeExporter commented 9 years ago
Thank you very much, rodrigo.zr! I've downloaded new version from downloads and 
it really works for my Desire!

Thanks again, pal!

Original comment by jpro....@gmail.com on 16 Nov 2010 at 2:26

GoogleCodeExporter commented 9 years ago
Great! :)

Original comment by rodrigo...@gmail.com on 19 Nov 2010 at 7:37