第1章 主动拨号流程分析

第1章 主动拨号流程分析

Java Application应用层《--------》Dialer拨号盘和Phone应用;

Java Frameworks 框架层《--------》Telephony Frameworks层

User Libraries系统运行库层《--------》RIL层

拨打电话的大致流程是:DialerTeleComServiceTeleComFrameworkTeleponyServiceTelephonyFrameworkRIL

总结:

DialpadFragment.onClick()

DialpadFragment.handleDialButtonPressed()

CallIntentProcessor.processIntent()

CallsManager. startOutgoingCall()

CallsManager.java的placeOutgoingCall()

ConnectionService. createConnection()

TelephonyConnectionService.onCreateOutgoingConnection()

GsmCdmaPhone.dial()--》dialInternal()

RIL.dial()

拨号流程总体时序图分析:

拨号流程时序图1

拨号流程时序图图2

 

1.1 拨号界面DialtactsActivity的onClick

ActivityManager启动DialtactsActivity的Actiivity拨号盘界面,DialtactsActivity中的onClick方法便是进入拨号盘的代码入口。

在onClick方法中会调用mDialpadFragment.dialButtonPressed()和mDialpadFragment.showDialpadFragment

1.2 DialpadFragment拨号盘表单

目录是:/packages/apps/Dialer/java/com/android/dialer/dialpadview/DialpadFragment.java

如果我们按了拨打电话的按钮就会调用dialButtonPressed();---handleDialButtonPressed();

1)handleDialButtonPressed():的作用是判断是不是空号,是不是禁播号码;创建intent,并调用DialerUtils. startActivityWithErrorToast()方法。

判断是不是空号,是不是禁播号码

else{正常拨号中创建intent

 

//调用DialerUtils. startActivityWithErrorToast

 

图1创建intent,调用DialerUtils的方法

2)CallUtil中

CallUtil.getCallIntent(String number, PhoneAccountHandle accountHandle)--》getCallIntent(number, null, accountHandle)---》getCallIntent(getCallUri(number), callOrigin, accountHandle);--》……--》最终会调用getCallIntent( Uri uri, String callOrigin, PhoneAccountHandle accountHandle, int videoState)

我们看一下getCallUri(),它是将号码封装成uri;且会判断是普通电话流程还是网络电话流程。

图2它是将号码封装成uri

接着看一下最后调用的getCallIntent(),这里intent就创建完了,intent创建完了就会传入CallUtils里面的startActivityWithErrorToast()方法【N4手机】

图3最终的getCallIntent(),在过程中会将号码封装成uri

3)DialerUtils. startActivityWithErrorToast()

 

图4会用到CallUtil的startActivityWithErrorToast()

CallUtil的startActivityWithErrorToast()

 

图5会调用TelecomManager.placeCall()

【getTelecomManager是TelecomManager类型的】

<think>我们首先需要理解用户的需求:用户想要构造一个DHCP动态拨号续约的场景,并进行抓包分析,以验证其是否符合DHCP协议规范。 根据之前对DHCP协议的介绍,我们知道DHCP租期续约的过程如下: - 在租期过半(T1时间)时,客户端会向原服务器发送单播的DHCP REQUEST请求续约。 - 如果此时续约失败(例如服务器没有响应),客户端会在租期达到87.5%(T2时间)时,向网络中的任意DHCP服务器广播DHCP REQUEST请求续约。 - 如果租期到期仍未续约成功,客户端将停止使用该IP地址,并重新开始DHCP发现过程(DORA)。 因此,要构造续约场景,我们需要: 1. 搭建一个DHCP服务器,并设置一个较短的租期(例如5分钟),这样我们可以快速观察到续约过程。 2. 配置客户端(例如一台Linux机器)通过DHCP获取IP地址。 3. 在租期过半时(即2.5分钟后),客户端应该会发送单播的REQUEST报文进行续约。 4. 使用抓包工具(如Wireshark或tcpdump)在客户端或服务器端捕获DHCP报文。 具体步骤: ### 步骤1:搭建DHCP服务器(以Linux为例) - 安装DHCP服务器软件(如isc-dhcp-server)。 - 配置DHCP服务器,设置地址池和租期(lease time)。例如,在`/etc/dhcp/dhcpd.conf`中设置: default-lease-time 300; # 租期300秒(5分钟) max-lease-time 600; # 最大租期600秒 subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.200; option routers 192.168.1.1; option domain-name-servers 8.8.8.8; } - 启动DHCP服务器。 ### 步骤2:配置客户端使用DHCP - 将客户端网络接口配置为DHCP模式(通常默认就是),并重启网络接口或重启客户端机器以触发初始的DHCP过程(DORA)。 ### 步骤3:抓包准备 - 在客户端或服务器端启动抓包工具,过滤DHCP报文(UDP端口67和68)。例如,使用tcpdump: tcpdump -i eth0 -w dhcp.pcap port 67 or port 68 - 或者使用Wireshark,设置过滤条件:`udp.port == 67 or udp.port == 68` ### 步骤4:等待续约发生 - 由于租期设置为5分钟,续约会在2.5分钟(T1)时发生。因此,我们需要捕获至少3分钟以上的数据包(确保覆盖T1时刻)。 - 在租期达到87.5%(即约4分22秒)时,如果第一次续约失败,客户端会广播REQUEST。 ### 步骤5:分析抓包文件 - 使用Wireshark打开抓包文件,分析DHCP报文序列。 - 验证在租期过半时,客户端是否发送了单播的DHCP REQUEST(目标IP为DHCP服务器IP,目标端口67)。 - 服务器应该回复一个DHCP ACK(单播或广播,取决于客户端设置),其中包含新的租期时间(从当前时间重新计算租期)。 ### 协议规范验证点: 1. 初始分配过程(DORA)是否完整。 2. 续约请求(REQUEST)是否在租期过半时发送,且为单播。 3. 服务器的ACK响应是否及时,并更新租期。 4. 如果服务器没有响应,客户端是否在T2时间(87.5%)发送广播REQUEST。 5. 租期到期后,客户端是否停止使用IP并重新开始DORA过程。 注意:为了快速测试,我们可以将租期设置得更短(如1分钟),这样T1为30秒,T2为52.5秒,我们可以在1分钟内完成测试。 ### 构造续约失败的场景: 为了观察T2时刻的广播续约请求,我们可以: - 在T1时刻之前(例如租期开始后20秒)关闭DHCP服务器,这样客户端在T1时刻发送的REQUEST将得不到响应。 - 然后观察在T2时刻(租期开始后52.5秒)客户端是否发送广播的REQUEST。 ### 抓包分析示例(预期): 1. 初始DORA过程(4个报文): DISCOVER -> OFFER -> REQUEST -> ACK 2. 在T1时刻(租期过半): REQUEST(单播) -> [无ACK] (因为服务器已关闭) 3. 在T2时刻(租期87.5%): REQUEST(广播) -> [仍然无ACK] 4. 租期到期后(1分钟),客户端释放IP,并重新发送DISCOVER。 通过以上步骤,我们可以验证DHCP续约过程是否符合RFC2131规范。 ### 注意事项: - 确保网络中没有其他DHCP服务器干扰。 - 如果客户端在租期到期前成功续约,租期会从续约时刻重新计算(即延长租期)。 - 在测试过程中,可能需要清除客户端上的租期缓存(例如,在Linux客户端上可以释放并重新获取:`dhclient -r`然后`dhclient`)。 通过抓包分析,我们可以清晰地看到续约报文的类型、发送时间、单播/广播方式以及事务ID(xid)的连续性,从而验证是否符合协议规范。 ### 相关RFC引用: - 续约过程定义在RFC2131的4.4.5节(Renewing a Lease)[^2]。 §§相关问题§§ 1. 如何通过Wireshark过滤分析DHCP报文? 2. DHCP租期时间设置对网络性能有何影响? 3. DHCP中继代理如何跨网段工作? 4. DHCP Snooping如何防止非法DHCP服务器攻击?</think>### 构造DHCP续约场景抓包及协议验证指南 要构造DHCP动态拨号续约场景并验证协议规范,需完成以下步骤: --- #### 一、环境搭建(Linux示例) ```bash # 1. 配置DHCP服务器(租期设为5分钟便于观察) sudo vim /etc/dhcp/dhcpd.conf # 添加关键配置: default-lease-time 300; # 租期300秒 max-lease-time 600; # 最大租期600秒 subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.100 192.168.1.200; option routers 192.168.1.1; } # 2. 重启服务 sudo systemctl restart dhcpd # 3. 客户端主动释放IP(触发续约流程) sudo dhclient -r eth0 && sudo dhclient eth0 ``` --- #### 二、抓包操作(Wireshark/tcpdump) ```bash # 1. 在DHCP服务器抓包(过滤端口67/68) sudo tcpdump -i eth0 -w dhcp.pcap 'udp port 67 or port 68' # 2. 关键时间点监控(租期过半时续约) 等待150秒(租期300秒的50%)后观察报文 ``` --- #### 三、协议规范验证点 通过分析抓包文件(如Wireshark),验证以下RFC2131[^2]核心规范: 1. **续约时机** - 租期过半(T1=150秒)时客户端应发送**单播REQUEST**(目标IP=服务器IP) ```mermaid timeline title 租期时间线 0s : ACK分配IP 150s : 单播REQUEST(T1) 262.5s : 广播REQUEST(T2) 300s : IP失效 ``` 2. **报文结构** - REQUEST中必须包含: - `Option 53=REQUEST(3)` - `Client IP`字段(当前使用的IP) - `Server Identifier`(指定续约服务器) - ACK响应中需包含`IP Address Lease Time`字段 3. **端口规范** - 客户端源端口必须为`68`,服务器源端口必须为`67`(UDP) 4. **失败处理** - 若T1未收到ACK,T2时间(租期87.5%)应转为**广播REQUEST** --- #### 四、验证示例(Wireshark分析1. **过滤续约请求** ```bash dhcp.option.dhcp == 3 # REQUEST类型 ``` 2. **检查关键字段** - 事务ID(xid)与初始ACK一致 - 租期时间戳符合`$T1=\frac{1}{2}LeaseTime$`计算 - 无非法Option(RFC2132[^2]定义的标准选项) 3. **异常场景测试** - 手动阻塞服务器端口,验证客户端是否在T2时间转为广播请求 --- #### 五、常见问题排查 | 现象 | 可能原因 | 解决方案 | |------|----------|----------| | 无T1续约请求 | 客户端租期计时错误 | 检查客户端`dhclient`日志 | | REQUEST被忽略 | 服务器未识别事务ID | 验证xid连续性 | | ACK未更新租期 | 服务器配置错误 | 检查`/var/lib/dhcpd/dhcpd.leases`文件 | > 📌 **协议符合性报告**:若抓包显示单播REQUEST(150s)→单播ACK(151s)的交互流程,且字段符合RFC2131第4.4.5节[^2]描述,即表明续约行为规范。 --- ### 相关工具推荐 1. **Wireshark过滤器** - `bootp.option.type==53`(查看DHCP消息类型) - `bootp.id==0xabcd123`(跟踪特定事务ID) 2. **Linux调试命令** ```bash journalctl -u dhcpd -f # 实时DHCP服务器日志 dhclient -v eth0 # 客户端详细调试模式 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值