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 <[email protected]>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 <[email protected]>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 <[email protected]>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 >>> <[email protected]>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 <[email protected]>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 >>>>> <[email protected]>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 <[email protected]>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 < >>>>>>> [email protected]> 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 >>>>>>>> [email protected] >>>>>>>> To unsubscribe from this group, send email to >>>>>>>> [email protected] >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected] >>>>>> 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 >>>>> [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> 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 [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> 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 [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
