Guess I need a rooted device for that... ------ QTAGUID STATS INFO (su root cat /proc/net/xt_qtaguid/stats) ------
*** exec(su): Permission denied On 17 December 2012 16:33, Robert Greenwalt <rgreenw...@google.com> wrote: > Interesting. > > If you run a test and take a bugreport you whould be able to look at > "QTAGUID STATS INFO" in the bugreport. It shows the packets/bytes sent per > app. Take a bugreport first, let your device sit for 10 minutes and take > another. The 4th column is the UID of the app and you should be able to > figure our who is responsible for the data. > > R > > > On Mon, Dec 17, 2012 at 7:00 AM, Goncalo Oliveira <gonc...@minkan.net>wrote: > >> Robert, some more information that might be relevant. >> As I told you, I was using a sim card that connects through our own APN, >> that restricts access to our servers. >> Today I decided to try the same scenario with a different SIM, so I >> plugged a "generic" 3G sim card, without the APN restrictions. The result >> was that I no longer had the stall problem... Could any Android background >> service be failing to connect and giving this outcome? >> Also, browsing the web I found this issue: >> http://code.google.com/p/android/issues/detail?id=35856 might it be >> related? >> >> Cheers >> >> >> >> On 17 December 2012 12:22, Goncalo Oliveira <gonc...@minkan.net> wrote: >> >>> Robert, isn't there any way to override the data stall detector >>> behavior? or at least change the default value? >>> >>> >>> On 17 December 2012 12:02, Goncalo Oliveira <gonc...@minkan.net> wrote: >>> >>>> Thanks again for the feedback Robert. >>>> >>>> I'm sending a heartbeat package but an answer is given. Though, I'm >>>> only sending the heartbeat every 30 minutes. Well, currently I'm doing less >>>> than that, but only as a workaround for this problem. For the test in case, >>>> I'm not even sending data. I'm just connecting and listening. >>>> More information that might be relevant - I ran the test again, but >>>> this time I'm not even making a connection. I'm just listening to the >>>> connectivity changes - I was suspecting someone else was causing this. >>>> Turns out that the same behavior occurs, so someone else is causing this? >>>> >>>> 12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection: >>>> tearDown=true reason=pdpReset >>>> 12-17 11:50:27.951 374 374 D GSM : [GsmDCT] cleanUpConnection: >>>> tearing down >>>> 12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] DcActiveState >>>> msg.what=EVENT_DISCONNECT RefCount=0 >>>> 12-17 11:50:27.951 374 1486 D GSM : [GsmDC-1] tearDownData radio >>>> is on, call deactivateDataCall >>>> 12-17 11:50:27.951 374 1486 D RILJ : [1903]> DEACTIVATE_DATA_CALL >>>> 1 2 >>>> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: >>>> DISCONNECTING for type default, previous state:CONNECTED >>>> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as >>>> pdpReset, for type mms,current state IDLE >>>> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection: >>>> tearDown=true reason=pdpReset >>>> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE >>>> for type mms, previous state:IDLE >>>> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] >>>> isDataPossible(mms): possible=true isDataAllowed=true apnTypePossible=true >>>> apnContextisEnabled=false apnContextState()=IDLE >>>> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn >>>> string for type:mms >>>> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] set reason as >>>> pdpReset, for type cbs,current state IDLE >>>> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] cleanUpConnection: >>>> tearDown=true reason=pdpReset >>>> 12-17 11:50:27.959 374 374 D GSM : [ApnContext] setState: IDLE >>>> for type cbs, previous state:IDLE >>>> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] >>>> isDataPossible(cbs): possible=true isDataAllowed=true apnTypePossible=true >>>> apnContextisEnabled=false apnContextState()=IDLE >>>> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] get active apn >>>> string for type:cbs >>>> 12-17 11:50:27.959 374 374 D GSM : [GsmDCT] stopNetStatPoll >>>> 12-17 11:50:28.006 374 374 D GSM : [GsmDCT] handleMessage msg={ >>>> what=270368 when=-1ms arg1=1 } >>>> 12-17 11:50:28.576 111 209 D RILClient: processUnsolicited(): >>>> resp_id (11010), len(59) >>>> 12-17 11:50:28.576 115 194 D RILClient: processUnsolicited(): >>>> resp_id (11010), len(59) >>>> 12-17 11:50:28.576 756 784 D RILS : Executing Am broadcast -a >>>> android.intent.action.PROXIMITY_CP --es cmd on >>>> 12-17 11:50:30.576 374 496 D RILJ : [1903]< DEACTIVATE_DATA_CALL >>>> >>>> Cheers >>>> >>>> >>>> On 14 December 2012 19:58, Robert Greenwalt <rgreenw...@google.com>wrote: >>>> >>>>> oops.. I truncated a sentence.. >>>>> >>>>> updateDataStallInfo logs show what's going on when a stall is >>>>> detected. In your log you can see that 21 packets have been sent since >>>>> you >>>>> last received a packet. >>>>> >>>>> >>>>> On Fri, Dec 14, 2012 at 11:49 AM, Robert Greenwalt < >>>>> rgreenw...@google.com> wrote: >>>>> >>>>>> The data stall detector is watching for outgoing packets with no >>>>>> corresponding return. If it sees this for X (6 minute default) it tries >>>>>> a >>>>>> bunch of things and one of those steps is to tear down and rebuild the >>>>>> connection. That's what you're seeing. I believe UDP packets may get >>>>>> ignored, thus my tcp/udp question. You can see some log lines in the >>>>>> radio >>>>>> log like "updateDataStallInfo: OUT send=..." that show what' >>>>>> >>>>>> What are you doing in your keepalive pings? Sending a char with no >>>>>> response, or echoing a response back? That could cause the problem >>>>>> because >>>>>> there'd be outgoing traffic but no incoming traffic. If there were NO >>>>>> outgoing the data stall detector shouldn't fire. If you change your >>>>>> keep-alive to send both ways you should be fine. >>>>>> >>>>>> This makes me wonder what your other test device is doing - the one >>>>>> that doesn't show this problem. Are you using rooted devices? They >>>>>> would >>>>>> allow you to use tcpdump and look at the network traffic.. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Dec 14, 2012 at 11:28 AM, Robert Greenwalt < >>>>>> rgreenw...@google.com> wrote: >>>>>> >>>>>>> Interesting. >>>>>>> >>>>>>> Maybe it is an android bug! >>>>>>> >>>>>>> What kind of traffic are you sending? tcp? udp? >>>>>>> >>>>>>> >>>>>>> On Fri, Dec 14, 2012 at 11:23 AM, Goncalo Oliveira < >>>>>>> gonc...@minkan.net> wrote: >>>>>>> >>>>>>>> Got the radio logs... >>>>>>>> >>>>>>>> http://pastebin.com/754wJ2jd >>>>>>>> >>>>>>>> This seems to be it >>>>>>>> GSM : [GsmDCT] onReceive: >>>>>>>> action=com.android.internal.telephony.gprs-data-stall >>>>>>>> >>>>>>>> >>>>>>>> On 14 December 2012 18:25, Robert Greenwalt >>>>>>>> <rgreenw...@google.com>wrote: >>>>>>>> >>>>>>>>> 3319 is fine. It's just the tethering code noting an interface is >>>>>>>>> going away. >>>>>>>>> >>>>>>>>> Can you get radio logs? This is the system log - there are >>>>>>>>> several log buffers. A bugreport (adb bugreport > mybug.txt) would >>>>>>>>> get >>>>>>>>> them all. Then you can match the connectivityservice dropout with >>>>>>>>> what >>>>>>>>> happened in the radio. >>>>>>>>> >>>>>>>>> I don't think you should open a bug: this is not an android issue, >>>>>>>>> but rather it's a samsung issue. >>>>>>>>> >>>>>>>>> I have opened an internal issue to expand CTS to check for this - >>>>>>>>> any device wanting to claim to be an android device would not be >>>>>>>>> allowed to >>>>>>>>> do such a thing in the future. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Dec 14, 2012 at 10:08 AM, Goncalo Oliveira < >>>>>>>>> gonc...@minkan.net> wrote: >>>>>>>>> >>>>>>>>>> Robert, >>>>>>>>>> >>>>>>>>>> Thanks again for the feedback. I traced the logs from samsung >>>>>>>>>> with a simple app to reproduce this behavior. Same thing, 6/7 >>>>>>>>>> minutes and >>>>>>>>>> it drops. >>>>>>>>>> I posted the logs here: http://pastebin.com/FcPPbq3V >>>>>>>>>> On line 3323 you can see ConnectivityService disconnecting. What >>>>>>>>>> I can't understand is what's causing it. Line 3319 is suspicious as >>>>>>>>>> I don't >>>>>>>>>> have tethering on, but other than that I can't really determine what >>>>>>>>>> causes >>>>>>>>>> this. Should I open a bug for this? >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14 December 2012 16:50, Robert Greenwalt < >>>>>>>>>> rgreenw...@google.com> wrote: >>>>>>>>>> >>>>>>>>>>> Is it possible something else on the device is occasionally >>>>>>>>>>> sending data and reseting your window? >>>>>>>>>>> >>>>>>>>>>> I would look in the log for the timestamp of the >>>>>>>>>>> ConnectivityChanged broadcast and then check the radio log and see >>>>>>>>>>> what's >>>>>>>>>>> going on. >>>>>>>>>>> >>>>>>>>>>> I suspect there is an unsolicited data call list notification >>>>>>>>>>> coming from the radio showing that the data call has gone away. >>>>>>>>>>> Perhaps >>>>>>>>>>> just before that there may be something explaining why. >>>>>>>>>>> >>>>>>>>>>> You may have to contact samsung if you're sure that other >>>>>>>>>>> devices have longer connection times on the same carrier. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Dec 14, 2012 at 8:30 AM, Goncalo Oliveira < >>>>>>>>>>> gonc...@minkan.net> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Robert, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the reply. If I send a packet every 5/6 minutes the >>>>>>>>>>>> connectivity is maintained yes. Only if connection is idle for >>>>>>>>>>>> longer than >>>>>>>>>>>> that. The weird thing is that it's not an exact timer, even though >>>>>>>>>>>> the >>>>>>>>>>>> average is very close. Sometimes it lasts 7 minutes, sometimes 8 >>>>>>>>>>>> or 9. I >>>>>>>>>>>> even saw this happening with a 4 minute interval, though very >>>>>>>>>>>> rarely. On >>>>>>>>>>>> the other device, I can most of the times maintain higher idle >>>>>>>>>>>> times. >>>>>>>>>>>> I'll try to look at the logs more carefully to see if there's >>>>>>>>>>>> something else. Is there anything in particular that I should look >>>>>>>>>>>> for? >>>>>>>>>>>> >>>>>>>>>>>> Cheers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 14 December 2012 16:16, Robert Greenwalt < >>>>>>>>>>>> rgreenw...@google.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Android is not supposed to do this, though there is no >>>>>>>>>>>>> guarantee of connectivity. It sounds like something samsung is >>>>>>>>>>>>> doing, >>>>>>>>>>>>> either accidentally or on purpose. >>>>>>>>>>>>> >>>>>>>>>>>>> If you send a packet every 6 minutes does that keep the device >>>>>>>>>>>>> from pulsing connectivity? >>>>>>>>>>>>> >>>>>>>>>>>>> Can you take a bugreport - the radio log may have some >>>>>>>>>>>>> indication of why it's happening. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Dec 14, 2012 at 2:24 AM, Goncalo Oliveira < >>>>>>>>>>>>> gonc...@minkan.net> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Seems that Android is dropping idle sockets when under a >>>>>>>>>>>>>> mobile network. Usually, no socket is kept alive for more than 7 >>>>>>>>>>>>>> minutes of >>>>>>>>>>>>>> inactivity. I am using a SIM card with a particular APN, that >>>>>>>>>>>>>> allows idle >>>>>>>>>>>>>> sockets for at least 30 minutes - this was tested using another >>>>>>>>>>>>>> kind of >>>>>>>>>>>>>> device, also communicating with GSM, and there are no drops, so >>>>>>>>>>>>>> problem >>>>>>>>>>>>>> isn't the SIM card. >>>>>>>>>>>>>> >>>>>>>>>>>>>> After a few searches in the web, I tried a few approaches to >>>>>>>>>>>>>> work around this, but until now, no success. I tried using a >>>>>>>>>>>>>> partial wake >>>>>>>>>>>>>> lock after connecting, releasing only when disconnected - didn't >>>>>>>>>>>>>> work. Also >>>>>>>>>>>>>> tried using only a 2G network, as some said that changing from >>>>>>>>>>>>>> network type >>>>>>>>>>>>>> could impact on this - same outcome. >>>>>>>>>>>>>> >>>>>>>>>>>>>> After digging a bit more and by analyzing logcat, I watched >>>>>>>>>>>>>> that a CONNECTIVITY_CHANGE is sent after some idle time, >>>>>>>>>>>>>> disabling the data transfer availability (active network is >>>>>>>>>>>>>> mobile, no >>>>>>>>>>>>>> connectivity) and another one is sent enabling it again (active >>>>>>>>>>>>>> network is >>>>>>>>>>>>>> mobile, connectivity). This cuts off all live socket connections. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Investigating a little bit more, I also observed that this >>>>>>>>>>>>>> behavior is not consistent through all Android versions, or >>>>>>>>>>>>>> maybe (even >>>>>>>>>>>>>> worse) through different hardware. Connectivity break is >>>>>>>>>>>>>> occurring in a Galaxy Tab 7 with Android 4.0.4. The same isn't >>>>>>>>>>>>>> occurring in >>>>>>>>>>>>>> an Unitech TB 100 with Android 3.2. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does anyone know where I can get more information and/or I >>>>>>>>>>>>>> can work around this? I would really like to avoid sending >>>>>>>>>>>>>> heartbeats every >>>>>>>>>>>>>> 6/7 minutes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>>> Google >>>>>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>>>>> For more options, visit this group at >>>>>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>> Google >>>>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>>>> For more options, visit this group at >>>>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Gonçalo Oliveira >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>> Google >>>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>>> To post to this group, send email to >>>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>>> For more options, visit this group at >>>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google >>>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>>> To post to this group, send email to >>>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>>> For more options, visit this group at >>>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Gonçalo Oliveira >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>>> Groups "Android Developers" group. >>>>>>>>>> To post to this group, send email to >>>>>>>>>> android-developers@googlegroups.com >>>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>>> For more options, visit this group at >>>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "Android Developers" group. >>>>>>>>> To post to this group, send email to >>>>>>>>> android-developers@googlegroups.com >>>>>>>>> To unsubscribe from this group, send email to >>>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>>> For more options, visit this group at >>>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Gonçalo Oliveira >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Android Developers" group. >>>>>>>> To post to this group, send email to >>>>>>>> android-developers@googlegroups.com >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> android-developers+unsubscr...@googlegroups.com >>>>>>>> For more options, visit this group at >>>>>>>> http://groups.google.com/group/android-developers?hl=en >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Android Developers" group. >>>>> To post to this group, send email to >>>>> android-developers@googlegroups.com >>>>> To unsubscribe from this group, send email to >>>>> android-developers+unsubscr...@googlegroups.com >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/android-developers?hl=en >>>>> >>>> >>>> >>>> >>>> -- >>>> Gonçalo Oliveira >>>> >>> >>> >>> >>> -- >>> Gonçalo Oliveira >>> >> >> >> >> -- >> Gonçalo Oliveira >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to android-developers@googlegroups.com >> To unsubscribe from this group, send email to >> android-developers+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Gonçalo Oliveira -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
