MTK平臺 數據問題分析

1、Framework層的相關類

ConnectivityService

Dctracker

2、RILD的相關AT命令

AT+CGACT

3、modem側的相關實現

Log實例：

1、確認數據鏈接的狀態

  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]

2、發包無返回會觸發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

3、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

4、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