MTK平台 数据问题分析

2019独角兽企业重金招聘Python工程师标准>>>

一、Framework层的相关类

ConnectivityService

Dctracker

二、RILD的相关AT命令

AT+CGACT

三、modem侧的相关实现

Log实例：

一、确认数据连接的状态

  Line 3611: 05-09 10:34:15.554347 916 916 D ConnectivityService: getActiveNetworkInfo networkInfo = [type: MOBILE[EDGE], state: CONNECTED/CONNECTED, reason: connected, extra: cmnet, failover: false, available: true, roaming: false, metered: true]
    Line 3612: 05-09 10:34:15.554360 916 966 D ConnectivityService: getActiveNetworkInfo networkInfo = [type: MOBILE[EDGE], state: CONNECTED/CONNECTED, reason: connected, extra: cmnet, failover: false, available: true, roaming: false, metered: true]
    Line 3617: 05-09 10:34:15.554641 916 2080 D ConnectivityService: getActiveNetworkInfo networkInfo = [type: MOBILE[EDGE], state: CONNECTED/CONNECTED, reason: connected, extra: cmnet, failover: false, available: true, roaming: false, metered: true]
    Line 3618: 05-09 10:34:15.554695 916 1153 D ConnectivityService: getActiveNetworkInfo networkInfo = [type: MOBILE[EDGE], state: CONNECTED/CONNECTED, reason: connected, extra: cmnet, failover: false, available: true, roaming: false, metered: true]
    Line 3624: 05-09 10:34:15.557682 916 2080 D ConnectivityService: getActiveNetworkInfo networkInfo = [type: MOBILE[EDGE], state: CONNECTED/CONNECTED, reason: connected, extra: cmnet, failover: false, available: true, roaming: false, metered: true]
    Line 3636: 05-09 10:34:15.561940 916 1640 D ConnectivityService: getActiveNetworkInfo networkInfo = [type: MOBILE[EDGE], state: CONNECTED/CONNECTED, reason: connected, extra: cmnet, failover: false, available: true, roaming: false, metered: true]

二、发包无返回会触发Android重连机制

这个机制的实现在/vendor/mediatek/proprietary/frameworks/opt/tedongle/src/java/com/android/internal/tedongle/dataconnection/DcTrackerBase.java

方法名字里会带recovery，

从log分析是因为trigger了recovery机制，一般为网络异常导致的．Recovery是android原生的feature,并非MTK feature，当前现象为正常的网络异常处理现象，

以下为详细log:
//进入第一个状态:GET_DATA_CALL_LIST, 原因是：在这1分钟内发送出去的数据包没有返回超过或达到10个包,这里是10个
//所以进入recovery机制，并发送EVENT_DO_RECOVERY. key log: doRecovery() get data call list
05-05 16:13:57.379044 1625 1625 D DCT : [0]updateDataStallInfo: OUT sent=10 mSentSinceLastRecv=10
05-05 16:13:57.392584 1625 1625 D DCT : [0]doRecovery() get data call list

//一分钟后并进入第二个状态:CLEANUP ： reactivate pdp context(reason=PDP_RESET)此时会看到数据连接有短暂的断开,
//原因是：在这1分钟内发送出去的数据包没有返回超过或达到10个包,这里是31个
05-05 16:14:57.393972 1625 1625 D DCT : [0]updateDataStallInfo: OUT sent=31 mSentSinceLastRecv=31
05-05 16:14:57.417809 1625 1625 D DCT : [0]doRecovery() cleanup all connections
05-05 16:14:57.421114 1625 1625 D DCT : [0]cleanUpAllConnections: tearDown=true reason=pdpReset

三、dup ack

netlog可以看到16:09有出现重传，其时间达到300ms+，但为什么出现重传需要检查底层链接收发包是否正常。

11792    2017-07-05 16:09:05.405084    10.62.249.122    120.204.9.103    TCP    124    [TCP Retransmission] 59358→31196 [PSH, ACK] Seq=22025 Ack=52025 Win=3198 Len=56 TSval=1133316 TSecr=304277205
11812    2017-07-05 16:09:05.637603    120.204.9.103    10.62.249.122    TCP    124    31196→59358 [PSH, ACK] Seq=52025 Ack=22081 Win=65535 Len=56 TSval=304277521 TSecr=1133235
11816    2017-07-05 16:09:05.637741    10.62.249.122    120.204.9.103    TCP    68    59358→31196 [ACK] Seq=22081 Ack=52081 Win=3198 Len=0 TSval=1133374 TSecr=304277521
11822    2017-07-05 16:09:05.974715    120.204.9.103    10.62.249.122    TCP    124    [TCP Retransmission] 31196→59358 [PSH, ACK] Seq=52025 Ack=22081 Win=65535 Len=56 TSval=304277542 TSecr=1133235
11826    2017-07-05 16:09:05.974886    10.62.249.122    120.204.9.103    TCP    80    [TCP Dup ACK 11816#1] 59358→31196 [ACK] Seq=22081 Ack=52081 Win=3198 Len=0 TSval=1133458 TSecr=304277542 SLE=52025 SRE=52081
11831    2017-07-05 16:09:05.975844    120.204.9.103    10.62.249.122    TCP    80    [TCP Dup ACK 11812#1] 31196→59358 [ACK] Seq=52081 Ack=22081 Win=65535 Len=0 TSval=304277558 TSecr=1133235 SLE=22025 SRE=22081

四、dns返回慢

此问题从log来看，应该是dns server的问题，在16:57其dns query都要一分多钟才回，直到17:00:42才恢复正常
但是其它tcp连接没有问题，很快就会回包，所以手机没有问题，因为手机不会区分其tcp和dns query包的发送,主要原因在于dns server端。
请知悉，感谢！
//这里一分多才回response
86162    2017-07-07 16:57:45.716113    10.59.48.13    221.179.38.7    DNS    80    Standard query 0xa57c A apilocate.amap.com\
88023    2017-07-07 16:57:55.721451    10.59.48.13    221.179.38.7    DNS    80    Standard query 0xa57c A apilocate.amap.com
296843    2017-07-07 16:58:57.842842    221.179.38.7    10.59.48.13    DNS    244    Standard query response 0xa57c CNAME apilocate.amap.com.gds.alibabadns.com A 106.11.13.1
296844    2017-07-07 16:58:57.843125    10.59.48.13    221.179.38.7    ICMP    272    Destination unreachable (Port unreachable)
296910    2017-07-07 16:58:57.993855    221.179.38.7    10.59.48.13    DNS    244    Standard query response 0xa57c CNAME apilocate.amap.com.gds.alibabadns.com A 106.11.13.1
//17:00开始很快恢复正常
390717    2017-07-07 17:00:42.756815    10.59.48.13    120.196.165.7    DNS    79    Standard query 0x7b8a A s.click.tmall.com
390738    2017-07-07 17:00:42.830768    120.196.165.7    10.59.48.13    DNS    300    Standard query response 0x7b8a CNAME adsh.wagbridge.tmall.alimama.com CNAME adsh.wagbridge.tmall.alimama.com.gds.alibabadns.com A 140.205.140.52

1.main log中查看其getaddrinfo对应log的pid号
2.event log中确认其对应pid的packagename，从而确定其是哪个APP在发起dns query

转载于:https://my.oschina.net/u/2829875/blog/834869