《深入了解Android：Wi-Fi、NFC和GPS音量》勘误表

资源下载更新（我不知道为什么被115网盘屏蔽）

深入了解android它wifi-nfc-gps 
115网盘礼包码：5lbee5qn4g5g
http://115.com/lb/5lbee5qn4g5g

和115沟通后，

http://115.com/lb/5lbdugrdt4r   恢复使用

段昌志兄认真阅读了几遍。还把全部的反馈给集中整理了下。很感谢，一本真正的好书是须要作者和读者一起努力打造才干够创造的！感谢段兄，感谢全部兄弟

感谢段昌志兄的细心反馈。不论前期怎样仔细，书写过程还是有一些错误。

此处整理下段兄所反馈的错误。

时间稍紧，以后再针对此处的bug进行回复。

P21

倒数第4行

“然后查看下网络内部是否有其它主机再用”

这里出现错别字”再”

P43

页面中部介绍伪终端的时候出现拼写错误.

“伪终端(psuedo terminal)”

应该是pseudo terminal

psuedo这个单词从有道词典中仅能查到网络释义,我又百度了下UNIX伪终端,发现拼写确实错了,应该是pseudo terminal

P65

在讲802.11c和802.11d的时候对LLC的翻译不太准确.

这里把LLC翻译为链路连接控制

协议上LLC的全称是logical link control,一般都翻译为逻辑链路控制

P69

在图3-3以下的第5行中说”在RTS帧中会说明要发送的数据帧的长度”,在以下一行中说”在CTS帧中也附上站A欲发送的数据帧的长度(从RTS中将次数据拷贝到CTS中)”

可是我在详细的RTS和CTS帧中都没有知道这里说的数据帧的长度.

RTS帧例如以下:

CTS帧例如以下:

依据协议(IEEE Std 802.11 - 2007)来看,在RTS的帧格式中也没有发现数据传输长度的表示字段,倒是发现了一个Duration字段,可是这个字段表示的是时间,也就是说这个RTS预约了多少时间用于传输兴许的数据或者管理帧,加上CTS帧和ACK以及SIFS的时间.

详细协议是这么描写叙述的(在协议的72页):

For all RTS frames sent by non-QoS STAs, the duration value is the time, in microseconds, required to transmit the pending data or management frame, plus one CTS frame, plus one ACK frame, plus three SIFS intervals.

CTS也是同理,也没有发现数据传输的帧长度这个字段,同样存在Duration字段,也是表示时间.

我翻译的不好,详细协议是这样描写叙述的(协议73页):

For all CTS frames sent in response to RTS frames, the duration value is the value obtained from the Duration field of the immediately previous RTS frame, minus the time, in microseconds, required to

transmit the CTS frame and its SIFS interval. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer.

另外发现,在本书的P91上你也描写叙述了RTS,这里的描写叙述就是依据协议描写叙述的了.

P83

第6行

“非QoS情况下,很明显那些UP较高的数据见得到优先处理.”

这里是错别字.应该是”就”

P87

在(3)Address域以下的第4行:

“0~23位是厂商向IETF等机构申请用来表示厂商的代码”,查了下资料,发现MAC中的OUI应该是向IEEE申请的吧.

我找了协议和百度百科的资料例如以下:

在IEEE Std802.11 – 2007的P128页上有这么一句:

在百度百科的例如以下地址:

http://baike.baidu.com/link?

url=uag8NiziyQTNjzYpMrDGQrSSLl00nMQMHKYZWs73g3EMy7ibaNOLUw7NEfANsf4K

中说到:组织唯一标志符(OUI)是由电器和电子project师协会(IEEE)分配给单位组织的，它包括了24位(3字节)。各个单位组织依次被分配一个全局管理地址(24位，或3个字节)。对于厂家生产的每一块网卡来说，这个地址是唯一的。

P105

在页面最下方的”提示”的后半行”由于Wi-Fi以空气为传输媒介”

这里表达不严谨.

Wi-Fi是採用射频传输,也就是电磁波.电磁波能够穿过空气,真空,水泥等物体传播,仅仅是这些物体对电磁波造成的衰减不一样.

比方卫星通信,也是採用电磁波,可是太空中已经是真空了;再比方火星探測器在火星上向地球传输信号.

P106

在1.WEP介绍中说到"WEP是802.11规范的元老,在1999年规范诞生..."

规范是1997年出来的.

P107

本页文字的第10行

“XOR操作后的数据即图3-29所看到的的Encrypted部分”

引用错误,从上下文理解以及核对图3-29,发现这里引用的应该是图3-31.

P109

在"规范阅读提示"以下的第三行中,"WPA採用了新的MIC算法"

这里的MIC的解释应该是Message Integrity Code,

见协议(802.11-2012)第21页上有MIC的解释:message integrity code

一般会译为"消息完整性验证码"

建议还是依照协议.

P112

图3-36以下第一行的括号里:

"EAP Over LAN, 基于LAN的扩展EAP协议"

本身EAP中的E就是扩展的意思,P就是协议的意思.

这里应该解释为”基于LAN的EAP”吧.这样感觉拗口,还不如说”基于LAN的扩展认证协议”呢

P117

倒数第6行首次出现”RSNE”,前文中没有对此做出解释.

依据802.11-2012协议来看RSNE是robust security network element

P162

图4-11时,解释struct wpa_supplicant时:

a).解释l2时,说L2是Link Layer的缩写.这么说没错.可是对于刚開始学习的人可能不理解为什么l2是Link Layer.我认为解释l2 是Layer 2,也就是”层2”更好一些.然后再说明一下层2是数据链路层,层3是网络层.

b).解释own_addr时,说ETH_ALEN个数为16. 可是ETH_ALEN表示MAC地址长度,是6字节,48bit.

c).在解释第9个成员变量bssid时,有错别字吧.说”元素各位为ETH_ALEN”,应该是”元素个数”吧.

d).在解释第12个成员变量disconnected时,有错别字”链接”,应该是”连接”.

P163

第5行解释countermeasures的时候引用了MIC,括号说是(Message Integrity Check),在<<802.11-2012>>第21页中有解释:

我们通常把MIC称之为消息完整性校验码,这里的C应该是Code的意思.

建议还是參考上面协议的说明.

P188

图4-19中解释成员变量own_addr的时候说”ETH_ALEN,值16”:

ETH_ALEN是MAC地址的长度,是6个字节,48bit.

P199

在[àstate_machine.h]以下的第一个凝视部分,把EAP SM写成了EAP SSM,例如以下:

“而STATE_MACHINE_DATA也是一个宏.对与EAP SSM来说”.

P225

第7行最后几个字:

“全部,直接来看”

这里应该是”所以”

P242

中间部分的wpa_supplicant_set_state()这句后面的主是中”设置wpa_sm装为WPA_ASSOCIATED”

这里出现错别字

P244

第二行凝视的后半部分:

“将状态机一系列动作”

这里感觉语句不顺,猜了半天也没明确什么意思.

P244

倒数第11行,分析eapol_sm_notify_portEnabled的时候,函数原型少了左边括号.应该是

void eapol_sm_notify_portEnabled(struct eapol_sm *sm, Boolean enabled)

P248

第一行

“的IE信息对于nl80211来说…………..”

这里感觉不通,应该在”的IE信息”后有逗号.你从个前面一页的最后一行開始读一下感觉感觉.

P264

在4.6.1本章总结中的第6行

“该流程实际上包括的代码远比书中给多”

这里语句不通顺,应该是”远比书中给的多”.

P276

倒数第10行,在块凝视中解释RSSI的时候少了个顿号

“WPAS支持的RSSI信息包括:接受信号强度、连接速度(link speed)噪声强度(noise)和频率”

在连接速度(link speed)后面少了顿号

P278

第19行,讲WifiApConfigStore的时候

“配置信息存储于/data//misc/wifi/softap.conf”

这里在/data后出现了2个/

P279

在wifi_start_supplicant()中的第12行

“//P2P _PROP_NAME值为….”

这里在P2P后多了个空格

P286

第2行

最后缺少句号.

我对照了其它地方,这里确实须要一个句号.

P303

第18行

在5)的地方以下一行

“初始化WPS相关的信息、设置WifiState”

我感觉这里WPS拼错了.由于我研究了下这个函数,没发现有WPS相关的代码,应该是WPAS.

P323

第三行

“并为  该WLAN加入无线设备”

这里多了个空格.

P336

倒数第7行中间:

“这个流程讲涉及M1~M8相关的知识.”

这里有错别字,应该是将

P355

第7行最后:

“wpas_wps_ssid_wildcard_ok”

这里函数被加粗,可是第一个字母w没有被加粗.

格式上不一致.

P362

第19行

在case EAP_CODE_REQUEST以下的第5行后半句

“ESC_Start属于扩展EAP协议”

这个问题在前面一章提出过,就是EAP本身就是扩展认证协议的意思,

这里再说是扩展EAP协议有点反复了.

P366

中间部分介绍wps_get_msg以下的那句话中把WPAS拼错了.我当初也常常拼错.

“我们在前面已经介绍过M1~M8的内容.在WAPS的代码中….”

P627

图6-7以下第一段

“尽管EAP-WSC终于以EAP-Fail帧结束,可是…”

这里一整段,我说下自己的理解.

规范中说,最后的EAP-Fail帧是有益发出来的,目的是终止EAP的交互,也通知上层已经结束了EAP交互.Station在收到此帧后须要主动断开与AP的连接.然后用拿到的password等又一次開始普通的连接和四步握手.

以下是规范的节选:

P31 (WPS规范2.02版)

P58

P62页

P365

倒数第7行

“if (data->state == WAIT_FRAG_ACK) {……//MF标志位的处理}”

这里凝视的不太对,应该是处理处理WAIT_FRAG_ACK的东西.

P383

表7-4 OUI SubType取值

在表右边第2列的Type中又列出来一遍4 P2P Invitation Response这个字段的介绍,由于在左边那列最后已经列出来了.这是反复了.

我看到这里的时候还仔细看了下这2个有何不同呢.

P384

第3行

在讲GO Intent的时候说

“该字段长1字节,眼下使用的仅是该字节的前八位”

这里,一字节不就8位吗,所以这里描写叙述为”使用的是该字节的前八位”感觉不妥.

依据协议来看,这一个字节确实没实用满,用最低位的一个bit表示Tie Breaker,用4bit表示Intent,由于最大值是15,由于4bit也就够了.

下图是我的GO Intent,这个字节的值是0C,所以GO Intent是6,Tie Breaker是0

P384

倒数第3行

“Tie Breaker为随机值,所以两个设备的Tie Breaker取值同样的几率很低”

我感觉取值同样的几率不是太低啊.

Tie Breaker仅仅是1bit,取值仅仅能是0和1,那么就存在以下4种取值情况

00    01    10    11

从上面看,这个Device都取0和都取1的情况就是50%的概率了.

P407

倒数第6行

后半部分”它在P2pEnabeldState中被处理,wpas_supplicant将发起P2P Device Discovery流程…..”

这里把wpa_supplicant拼错了.

P412

图7-29中的p2p_config描写叙述中提到了dev_addr的类型和长度

dev_addr就是一个MAC地址,所以类型肯定是char,代码中显示是u8,也就是unsigned char,长度是6字节.

所以书中描写叙述是int数组和长度是8字节是不正确的.

P424

在wpas_start_llisten的解说中第3行

“调用deriver_nl80211.c的wpa_driver_set_ap_wps_p2p_ie函数,它用于将Probe Response帧信息和Association Response帧信息.”

上面这句话不通,说了一半就没了.所以看不懂什么意思.

P388

在这一页的”提示”那一栏中提到接收PD Request的P2P Device不支持发送者设置的WSC Config Methods时,为什么不在PD Response帧中设置Config Methods为自己所支持的WSC方法呢.

经过分析代码和研究,我发现是例如以下的原因,他这样设计是合理的.

首先,在P2P Device发送PD Request的时候把自己所支持的全部的WSC Config Methods都列出来,也就是说都放在这个帧中发出去了.这个属性在PD Request帧中的P2P Device Info中,例如以下图:

build这个P2P Device Info的代码例如以下:

p2p_buf_add_device_info()

从这里看出,正好和上面的空口信令中抓到的Config Methods是一致的,也就是说,发出PD Request的一方把自己支持的全部方法都给出了.

那么在接收这个PD Request的P2P Device是怎么处理的呢.

看例如以下的函数:

p2p_process_prov_disc_req()

在这个函数中,接收PD Request的P2P Device的设备在process这个PD Request的时候,把Request中的config_methods和自己所支持的全部的方法匹配一下看看是否有一种方法能匹配上.

假设一种都匹配不上,那么这里就走goto out了.再来看goto out:

上图中,假设接收PD Request的Device自己全部的方法都无法与发送者匹配,那么这里在build PD Resp的时候就会把config_methods填0.

由于自己全部的方法都不匹配了,也就不用给出自己支持的方法了.

从机制上来说,发送者给出了自己全部的支持的方法,那么接收者用自己全部的方法去匹配,发现匹配不上,所以这里直接给出0就结束了.再给出自己支持的方法,发送者也解决不了问题.

P433

在7.4.4这个标题上面的那行有错别字

“如今来看本章关于P2P的最后一到工序”

感谢博客上的好友...

p450页的图8-6上面TNF应该是3bits而不是2bits。
p453页的表8-5status的说明，第7位为0。表示的是utf-8编码。好像书中写反了吧。
p453页的图8-8中的text的那个字符串应该是“Hello,World!”吧，假设是“Hello Word”的话。好像PayLoad Length字段不正确。