OK, got it to reproduce when running with the -tcpdump flag. I've attached the resulting pcap file to the bug report (actually just the DNS records since the entire 15MB compressed file wouldn't upload). Here's an excerpt of the DNS traffic from where it turned bad (starting at 79853):
76915 20:59:10.741125 10.0.2.15 10.0.2.3 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 76916 20:59:10.850500 10.0.2.3 10.0.2.15 DNS Standard query response A 174.129.233.190 77045 20:59:20.475500 10.0.2.15 10.0.2.3 DNS Standard query A data.flurry.com 77046 20:59:20.725500 10.0.2.3 10.0.2.15 DNS Standard query response A 63.150.3.198 77469 21:01:39.225500 10.0.2.15 10.0.2.3 DNS Standard query A imap.gmail.com 77470 21:01:39.272375 10.0.2.3 10.0.2.15 DNS Standard query response CNAME gmail-imap.l.google.com A 72.14.247.111 A 72.14.247.109 79853 21:02:44.334875 10.0.2.15 10.0.2.3 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 79937 21:02:49.366125 10.0.2.15 10.0.2.4 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 79942 21:02:54.350500 10.0.2.15 10.0.2.3 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 79947 21:02:59.350500 10.0.2.15 10.0.2.4 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 79948 21:03:04.350500 10.0.2.15 10.0.2.3 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 79949 21:03:09.350500 10.0.2.15 10.0.2.4 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 79950 21:03:14.350500 10.0.2.15 10.0.2.3 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 79953 21:03:19.350500 10.0.2.15 10.0.2.4 DNS Standard query A ec2-174-129-233-190.compute-1.amazonaws.com 79960 21:03:24.772375 10.0.2.15 10.0.2.3 DNS Standard query A data.flurry.com 79977 21:03:29.772375 10.0.2.15 10.0.2.4 DNS Standard query A data.flurry.com 79978 21:03:34.772375 10.0.2.15 10.0.2.3 DNS Standard query A data.flurry.com 79979 21:03:39.772375 10.0.2.15 10.0.2.4 DNS Standard query A data.flurry.com 79980 21:03:44.772375 10.0.2.15 10.0.2.3 DNS Standard query A data.flurry.com.\033 79983 21:03:49.772375 10.0.2.15 10.0.2.4 DNS Standard query A data.flurry.com.\033 79986 21:03:54.772375 10.0.2.15 10.0.2.3 DNS Standard query A data.flurry.com.\033 79987 21:03:59.772375 10.0.2.15 10.0.2.4 DNS Standard query A data.flurry.com.\033 Hope this helps! An unrelated concern: it seems like it's querying the server every time an application tries to resolve an address--doesn't the resolver cache at all? I'm looking at records that have 2-hour TTLs but it's querying them every few minutes. Seems to me this wastes battery and bandwidth and greatly increases application-level latency. -- Peter --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
