MTK Android 9.0双网共存实战：策略路由与默认网络固定

1. 双网共存这件事到底在解决什么问题搞嵌入式安卓的兄弟对MTK平台应该都不陌生尤其是Android 9.0这个版本段大量行业设备、手持终端、车载后装、工业平板还跑在这个底包上。项目标题里说的“双网共存”说白了就是让设备同时挂两套网络通道——一套走Wi-Fi一套走以太网或者两套不同制式的有线/无线组合并且两套网络各自能通、互不打架、按需分流。听起来简单真上手调过的人都知道MTK的连通性框架在Android 9.0上有一套自己的私货逻辑跟原生AOSP的行为不完全一致坑基本都埋在框架层和网络评分策略里。这个内容适合谁看一类是做行业定制机的系统工程师客户要求“内网走网线、外网走Wi-Fi”或者“双网卡各接一个专网”另一类是刚接手MTK方案、被双网路由问题折腾得睡不着的应用/系统开发。我先把结论摆前面双网共存的核心不是“把两个网卡都点亮”而是让系统在路由选择、默认网络判定、DNS解析这三条线上都做出符合预期的决策。网卡起来只是第一步后面网络评分NetworkScore、默认网络Default Network切换、策略路由Policy Routing才是真正决定成败的地方。我在几个基于MTK Android 9.0的定制项目里反复调过这套东西从最初的“两个网卡都up但只有一个能上网”到后来能做到按应用分流、按目标网段分流中间踩的坑足够写满一页纸。下面按我实际的调试顺序拆开讲尽量把每一步“为什么这么做”说清楚你照着抄作业也能少走弯路。2. 整体方案设计与选型思路拆解2.1 先搞清楚MTK在Android 9.0上的网络框架底子Android 9.0Pie在网络管理上已经引入了ConnectivityService集中调度、NetworkAgent上报网络状态、NetworkScore打分的机制。MTK在这个基础上做了厂商定制主要体现在ConnectivityService的评分策略、NetworkFactory的注册顺序以及Ethernet服务与Wifi服务的优先级处理上。原生AOSP里以太网和Wi-Fi共存时系统默认倾向于“有网就选评分高的”但评分高低受信号强度、链路速率、是否计费网络等因素影响实际表现就是默认网络会飘——一会儿走Wi-Fi一会儿走有线应用侧感知到的就是网络时通时断。所以方案设计的第一原则不要指望系统自动帮你选对要主动干预默认网络和路由策略。我一般把方案分成三层来设计链路层确保两个网卡都能正常up、拿到IP、链路状态稳定这是地基。框架层控制ConnectivityService对两个网络的评分与默认网络绑定避免默认网络乱跳。路由层用策略路由ip rule ip route table把不同目标网段的流量钉死到指定网卡绕开默认网络的不确定性。这三层里链路层是“能不能通”框架层是“系统认为谁通”路由层是“实际数据从哪走”。很多教程只讲第一层结果读者照着配完发现还是单网能用问题就出在后两层没动。2.2 为什么选策略路由而不是只改默认网络有人会问直接把默认网络固定成某一个另一个网卡只做特定访问不就行了理论上可以但实际会撞上两个问题。第一Android的默认网络是全局的应用发起连接时如果不做绑定全部走默认网络你没法让A应用走Wi-Fi、B应用走有线。第二MTK底包里ConnectivityService在某些场景比如Wi-Fi断开重连会重新评估默认网络你手动设的绑定可能被覆盖。策略路由的好处是它在内核层面生效不依赖框架层的默认网络判定。具体做法是给每个网卡分配独立的路由表用ip rule按源地址或目标网段匹配命中后查对应路由表。这样即使框架层默认网络在飘只要策略规则在指定流量依然走指定网卡。代价是需要root权限、需要处理规则持久化重启后规则会丢以及要小心别把系统自身的连通性检测流量也带偏。我最终采用的组合是框架层固定默认网络 路由层做目标网段分流。默认网络固定保证大部分应用行为可预期策略路由负责“例外流量”的精确投递。这个组合在多个项目上验证过稳定性最好。2.3 双网共存的三种典型拓扑实际项目里双网共存不是一种形态我梳理了三种最常见的拓扑配置思路差别不小拓扑类型网络组合典型需求配置重点内外网分离以太网接内网、Wi-Fi接外网内网业务走网线公网访问走无线目标网段分流内网网段钉到以太网双专网并行双以太网口各接一个专网两套业务系统互不干扰源地址绑定 独立路由表主备冗余有线为主、Wi-Fi为备有线断了自动切无线默认网络优先级 链路检测第一种拓扑在行业终端里最常见也是我下面实操部分主要围绕的场景。第二种需要设备有两个物理以太网口MTK部分方案支持双MAC配置上要给两个口分别建路由表。第三种本质是故障切换重点在链路监测和默认网络切换的及时性跟“共存”略有区别但配置手法相通。3. 核心细节解析与实操前的准备3.1 确认硬件与驱动层是否支持双网卡并行动手之前先确认一件事你的设备两个网络接口在驱动层是不是都能独立工作。MTK平台常见的组合是“Wi-Fi模组 一路以太网MAC”部分方案支持USB转以太网做第二路。检查方法很直接设备起来后执行ip link show看输出里是否有wlan0和eth0或eth1两个接口且状态不是DOWN。如果以太网口没起来先查驱动加载和PHY初始化这一步不通后面全是空谈。我遇到过以太网PHY时钟配置错误导致link一直down的情况日志里dmesg | grep eth能看到PHY协商失败的记录这种属于驱动层问题得找硬件和驱动同事一起看不是改配置能解决的。另外要注意MTK某些底包里以太网服务是可选编译的frameworks/opt/net/ethernet这个模块如果没编进系统EthernetService根本不存在ifconfig eth0 up能起来但框架层不认ConnectivityService里看不到以太网网络。确认方法adb shell dumpsys connectivity | grep -i ethernet有输出说明以太网服务在跑没输出就得先补编译配置。3.2 网络评分机制的干预点在哪Android 9.0里每个网络通过NetworkAgent上报时带一个NetworkScoreConnectivityService据此决定默认网络。MTK底包里Wi-Fi的初始评分通常高于以太网因为Wi-Fi被认为是“主连接”这就导致双网都在时默认网络偏向Wi-Fi。如果你的需求是以太网做默认就得干预评分。干预方式有两种一是改NetworkFactory里的评分逻辑二是在ConnectivityService的rematchNetworkAndRequests流程里加厂商判断。前者改动小但影响面窄后者更彻底但要小心别把正常切换逻辑搞坏。我一般优先选前者在以太网NetworkFactory里把初始评分调高或者在Wi-Fi评分计算里加一个“存在以太网时降权”的判断。具体代码位置在MTK底包的frameworks/base/services/core/java/com/android/server/ConnectivityService.java和frameworks/opt/net/ethernet/java/com/android/server/ethernet/EthernetNetworkFactory.java不同底包版本行号有差异按方法名搜更靠谱。注意改评分逻辑属于框架层改动编译后要整包刷机验证不能只push单个jar否则容易和odex校验冲突导致起不来。3.3 策略路由需要的前置条件策略路由依赖ip rule和自定义路由表需要满足几个条件内核编译时开启了CONFIG_IP_MULTIPLE_TABLESMTK默认内核一般都有系统有root权限userdebug或eng版本以及ip命令可用toybox自带。验证内核支持adb shell cat /proc/net/ip_tables_names adb shell ip rule showip rule show能列出规则至少有默认的local、main、default三条就说明多路由表可用。如果报错“RTNETLINK answers: Operation not permitted”那是权限问题换userdebug版本再试。还有一个容易被忽略的点Android的netd自己会管理一部分路由规则你手动加的ip rule如果优先级pref跟netd的规则冲突可能被覆盖或行为异常。netd默认规则一般在pref 10000以上我手动加的规则用pref 1000~9000之间确保优先级高于netd的默认规则同时不跟系统保留段冲突。4. 实操过程与核心环节落地4.1 第一步让两个网卡都稳定拿到地址先不管路由把两个接口的地址配好。Wi-Fi走正常的wpa_supplicant连接流程连上后DHCP拿地址。以太网如果走DHCP确认EthernetService的DHCP客户端正常工作如果是静态IP用ifconfig或ip addr配adb shell su ip addr add 192.168.10.100/24 dev eth0 ip link set eth0 up配完用ip addr show eth0确认地址生效ping一下同网段网关验证链路通。这一步的坑在于MTK底包里以太网有时会被EthernetService接管后重新下发DHCP你手动配的静态地址可能被冲掉。解决办法是在EthernetService的配置里把该接口设为静态模式或者干脆停掉以太网的DHCP客户端再手动配。我倾向后者调试阶段手动控制更清晰。两个网卡都拿到地址后先分别验证单网连通性断开Wi-Fi确认以太网能通断开以太网确认Wi-Fi能通。这一步是基线基线不通就别往下走。4.2 第二步固定默认网络止住“网络乱飘”双网都通之后观察默认网络行为adb shell dumpsys connectivity | grep -A5 Default network连续看几次如果默认网络在wlan0和eth0之间跳说明评分机制在打架。我的处理是在框架层把以太网评分调高并固定让默认网络稳定在以太网假设业务主通道是有线。改完刷机后再看dumpsys默认网络应该稳定不变。如果不想动框架代码也有个取巧办法在Wi-Fi连接后手动把Wi-Fi网络的NetworkScore通过ConnectivityManager接口降权但这需要应用层有系统权限且重启后失效只适合临时验证。长期方案还是改框架。默认网络固定后验证方法ping外网地址同时用ip route get看实际出口ip route get 8.8.8.8输出里dev eth0说明走有线符合预期。如果还是走wlan0说明默认网络没固定住回头查评分改动是否生效。4.3 第三步建独立路由表做目标网段分流这是双网共存的核心操作。假设需求是内网网段10.0.0.0/8走以太网eth0网关192.168.10.1其余流量走Wi-Fi。操作序列如下# 1. 新建路由表表号用100避开系统保留段 echo 100 intranet /data/misc/net/rt_tables # 部分系统路径为 /etc/iproute2/rt_tables # 2. 给表100加默认路由指向以太网网关 ip route add default via 192.168.10.1 dev eth0 table 100 # 3. 加策略规则目标为内网网段的流量查表100 ip rule add to 10.0.0.0/8 table 100 pref 2000 # 4. 验证规则和路由 ip rule show ip route show table 100这里几个参数的选择逻辑要说清楚。表号选100是因为Android netd用的表号集中在1000以上如main表254、local表255netd自定义表在1000100在低位不冲突。pref 2000确保这条规则优先于netd的默认规则netd规则pref通常从10000起但低于系统最优先的local规则pref 0这样本地流量和系统流量不受影响。验证分流效果# 目标内网地址应走eth0 ip route get 10.1.2.3 # 目标公网地址应走wlan0 ip route get 114.114.114.114两条命令的输出分别显示dev eth0和dev wlan0就对了。如果内网地址还是走Wi-Fi检查ip rule show里规则是否在、pref是否被更高优先级的规则截胡。4.4 第四步处理DNS解析的双网归属路由分流做完还有个隐蔽的坑DNS。Android的DNS解析走netd的DnsResolver默认用当前默认网络的DNS服务器。如果你的内网域名需要内网DNS解析而默认网络是Wi-Fi外网DNS内网域名就解析不出来。处理方式有两种。一是给内网网段配独立的DNS通过netd的resolver接口按网络绑定二是在应用层做DNS指定连接内网时用内网DNS服务器地址。前者更彻底但改动大后者简单但要求应用配合。我在项目里用的是折中方案在ConnectivityService里给以太网网络单独配置DNS服务器列表并确保内网域名的解析请求能命中以太网网络的DNS。具体是在以太网NetworkAgent上报时把内网DNS塞进LinkProperties同时确认DnsResolver的多网络解析逻辑能按目标域名选对网络。验证方法adb shell nslookup intranet.example.com如果解析失败或返回错误地址用dumpsys connectivity看以太网网络的LinkProperties里DNS列表是否正确。这一步经常被忽略结果就是“网通了但业务域名解析不了”排查半天以为是路由问题。4.5 第五步规则持久化扛住重启手动加的ip rule和路由表重启就没了。持久化有两个思路一是在init.rc里加on boot阶段执行脚本二是写一个系统服务在ConnectivityService初始化后触发配置。前者简单直接后者更可控能等网络就绪再配。我一般用init脚本方案在/vendor/etc/init/下加一个.rc文件on property:sys.boot_completed1 exec - -- /system/bin/sh /vendor/bin/setup_dualnet.sh脚本里就是前面那套ip rule和ip route命令加上判断网卡是否就绪的循环等待。注意脚本要设可执行权限且init执行的上下文要有网络配置权限一般root或system上下文可以。实测下来这个方案在MTK底包上稳定重启后规则自动恢复。提示脚本里加日志输出到/data/local/tmp/dualnet.log出问题时能快速定位是哪一步没执行成功比盲猜强得多。5. 常见问题与排查技巧实录5.1 双网都up但只有一个能上网这是最高频的问题。排查顺序我固定成三步先看默认网络是谁再看路由表出口对不对最后看DNS。具体命令前面都给了这里强调一个容易漏的点检查iptables的NAT规则。Android的netd会给每个网络配SNAT规则如果以太网网络的NAT规则没建好包出去了但回不来表现就是“能ping通网关但上不了外网”。用iptables -t nat -L -n看POSTROUTING链里有没有对应网段的MASQUERADE规则没有就说明netd没给这个网络配NAT得查EthernetService的网络注册流程。5.2 默认网络频繁切换导致应用断流应用侧感知是“网络时断时续”日志里能看到ConnectivityService反复rematch。根因通常是两个网络评分接近链路状态微小波动就触发重新评估。解决办法是拉开评分差距或者在ConnectivityService里加防抖逻辑比如切换前要求新网络稳定N秒。我倾向拉开评分差距简单可靠。另外检查Wi-Fi是否开了“始终扫描”扫描导致的信号波动也会影响评分调试阶段可以先关掉。5.3 策略路由规则加了但不生效先确认规则优先级没被截胡ip rule show按pref从小到大执行如果有一条pref更小的规则匹配了同样的流量你的规则就不会命中。常见的是netd的main表规则pref比你的小导致流量先查了main表。解决办法是把你的规则pref调到比netd规则更小但大于0或者把目标网段从main表里排除。我一般直接调pref直观。5.4 重启后规则丢失或部分丢失如果用了init脚本但重启后规则只恢复了一部分大概率是脚本执行时网卡还没就绪ip route add失败但脚本继续往下跑。脚本里每个命令后加返回值判断失败就重试或等待。另外确认脚本执行时机sys.boot_completed1时网络服务一般已起来但个别底包上以太网初始化较慢可以加个循环等eth0出现再配。5.5 常见问题速查表现象可能原因排查命令处理方向双网up仅一个通NAT规则缺失iptables -t nat -L -n查netd网络注册默认网络乱跳评分接近/信号波动dumpsys connectivity拉开评分差距分流规则不生效规则优先级被截胡ip rule show调pref或排除main表内网域名解析失败DNS归属错误nslookupdumpsys配独立DNS到以太网重启规则丢失脚本执行时机/失败看脚本日志加就绪等待和重试以太网框架不认服务未编译dumpsys connectivity补编译ethernet模块5.6 几个踩过坑才明白的经验第一个经验调试顺序不能乱。先链路、再默认网络、再路由、最后DNS跳步调试会让你在错误的方向上浪费大量时间。我早期图快链路还没稳就去调路由结果路由规则没问题但网卡本身在闪断排查了一整天才发现是PHY问题。第二个经验改框架层之前先备份原镜像。MTK底包编译一次时间不短改评分逻辑如果引入新问题没有备份回滚会很被动。我习惯每次改框架前dd一份完整镜像存着出问题直接刷回。第三个经验策略路由的规则数量要控制。有人图省事给每个目标网段加一条规则规则多了之后ip rule匹配开销上升且维护困难。正确做法是网段聚合能合并的合并规则控制在十条以内。第四个经验验证要用真实业务流量不能只ping。ping走的是ICMP跟TCP/UDP的路由行为在个别场景下不一致比如某些策略只对TCP生效。验证时用curl或业务应用实际跑一遍才能确认分流真的对业务生效。6. 收尾前再聊两句实操体会这套双网共存配置我在几个MTK Android 9.0的定制项目上反复用过从最初的手忙脚乱到后来能半小时配完并验证通过最大的感受是MTK底包的连通性框架“聪明”得有点过头你得学会在它自作主张之前把规则定死。评分机制、默认网络切换、netd的自动路由管理每一项单独看都合理叠在一起就是双网场景下的混乱源头。策略路由之所以可靠恰恰是因为它绕开了框架层的“智能判断”用内核规则做确定性投递。还有一个后续可以扩展的方向如果设备支持双Wi-Fi比如2.4G和5G各连一个AP配置思路跟有线无线类似但Wi-Fi的评分波动更大默认网络固定的难度更高可能需要更激进的评分干预。另外Android 10之后网络管理框架有调整NetworkScore的机制变了这套配置迁移到更高版本时要重新验证评分干预点不能直接照搬。这些等后面有机会再单独整理。