Closed GoogleCodeExporter closed 9 years ago
I've got a log from LogCollector also. Maybe it will be useful... there is some
exception, which concerns superuser rights as it seems... I just looked at it,
didn't deeply analyzed.
Original comment by jpro....@gmail.com
on 16 Nov 2010 at 4:18
Attachments:
The "SIM Toolkit" probably does not communicate directly, it must be using
another system service (with another UID) to perform this connection.
You can check which UID it uses by doing the following:
1. Select "White list (allow selected)" mode.
2. Leave ALL check-boxes unmarked.
3. Enable the log.
4. Enable the firewall.
5. Clear the log.
6. Go in TrafficStats program and refresh it. (should fail)
7. Return to DroidWall and click on "Show Log".
This will display all connection attempts from all UIDs - now you can track
which UID
it uses for networking.
PS: The exception on this log is not related to this issue.
Original comment by rodrigo...@gmail.com
on 19 Nov 2010 at 5:39
I noticed too that Sim Toolkit leaks data. I really wonder what the heck it
could be...
Very suspicious anyway.
Original comment by vadimpe...@gmail.com
on 19 Nov 2010 at 9:32
Rodrigo, I made as you wrote. Traffic stats showed that two programs still
sent/recieved data: SIMToolkit and Droidwall. So Droidwall doesn't block
simtoolkit at all...
Original comment by jpro....@gmail.com
on 23 Nov 2010 at 5:45
On this case, there must be something wrong with Traffic stats.
I can say that for sure since DroidWall does not send/receive any data (not
even a single byte).
The traffic you see for SIMToolkit, if that is just a few bytes, then it is
possible that it is related to DNS lookups, not real data transfers.
When the log is enabled, DNS lookups are allowed by DroidWall - otherwise it
wouldn't be possible to log the destination of connection attempts.
You can confirm that by disabling the DroidWall log, while keeping "black-list"
and nothing selected. On this mode, not even DNS will be allowed.
Original comment by rodrigo...@gmail.com
on 23 Nov 2010 at 11:11
Sorry, I meant "white-list", not "black-list" on my last statement.
Original comment by rodrigo...@gmail.com
on 23 Nov 2010 at 12:21
[deleted comment]
I'm not worrying about DroidWall's traffic, it's really very small and I don't
think that you connect anywhere.
But SIMToolkit's traffic can be 10kb or 40kb per one session. I doubt that it's
simple DNS lookup or TrafficStats error...
Anyway, strange...
Original comment by jpro....@gmail.com
on 23 Nov 2010 at 12:57
40kb does not seem DNS lookups, really (unless the SIMToolkit app behaves
really bad).
If even after blocking everything (white-list, no apps marked, log disabled) it
still leaks data, the only reasonable explanation I can find is that this
application communicates locally (using the loopback interface) with another
service, and this data is being displayed by TrafficStats.
Original comment by rodrigo...@gmail.com
on 23 Nov 2010 at 1:18
Thanks, rodrigo, very clear explanation! I'll go and find TrafficStats project
issues and start flood there ;)
Original comment by jpro....@gmail.com
on 23 Nov 2010 at 1:39
Original comment by rodrigo...@gmail.com
on 23 Nov 2010 at 1:46
I consider the major traffic shown by trafficstats is the local communication.
But there is still a bit data maybe produced by "sim toolkit" and can't be
stopped, because i found there's still some traffic data when i select all
applications in blacklist or none in whitelist and then apply the rule
successfully(droidwall work fine with all the other apps!thank you!).The data
is shown only produced by "sim toolkit"not only in trafficstats but also other
traffic counter softwares such as 3g wath dog.Most importantly, the sign "H" on
the top of the screen still appear sometimes with "↑""↓", which means that
there must be uploading/downloading. It is so strange.
Original comment by mwcodeno...@gmail.com
on 26 Apr 2011 at 9:40
o sorry,the first sentence i mean the majoy traffic of "sim toolkit"shown by
trafficstats...
Original comment by mwcodeno...@gmail.com
on 26 Apr 2011 at 2:46
Original issue reported on code.google.com by
jpro....@gmail.com
on 16 Nov 2010 at 4:13