养文有世定，

昌荣啟胜芳，

思德吉天永，

安国照忠良。

以上辈分都是单字的，不排除同音错别字的可能，毕竟传下来那么长时间了。

内部网络主机的DNS配置成10.1.1.254
命令解释：
（1）：启用路由器DNS服务功能
（2）：启用DNS的外部查询功能，一般来说，该功能路由器缺省启用
（3）：指定所查找的上级DNS服务器地址（根据本地情况确定）
（4）：手工配置DNS本地条目

发布时间：2011.6.30日
恢复介质:4DVD
disc 1 0A25253 3.37GB
disc 2 0A40447 4.25GB
disc 3 0A40473 814MB
additional software disc 89Y6527 1.14GB
前三张盘为系统恢复盘，第四张为额外软件盘

disc1:

http://lenovohdq:lenovohy@kbdl.lenovo.com.cn/Think/ThinkPad/X_Series/X220%20X220T%20Win7Pro%2064SC%2004X0006/disc1%200A25253.iso

disc2:

http://lenovohdq:lenovohy@kbdl.lenovo.com.cn/Think/ThinkPad/X_Series/X220%20X220T%20Win7Pro%2064SC%2004X0006/disc2%200A40447.iso

disc3:

http://lenovohdq:lenovohy@kbdl.lenovo.com.cn/Think/ThinkPad/X_Series/X220%20X220T%20Win7Pro%2064SC%2004X0006/disc3%200A40473.iso

文件校验码：

文件: disc1 0A25253.iso
大小: 3624833024 字节
MD5: AAEE47EB5C585DC7E8CE47151B11892D
SHA1: C5D9D8636C8516AF52865FAF8B568965884EB40A
CRC32: 990A909B

文件:disc2 0A40447.iso
大小: 4572178432 字节
MD5: 13049C428C9D5A4C1B83FBEFE2C0A1CC
SHA1: 47EEDE9403467CE7A72EDB38CA476AD60AC0CE7A
CRC32: 12D0785A

文件: disc3 0A40473.iso
大小: 854091776 字节
MD5: 50DDEA0438E8138859A2FE7C91D1EF4E
SHA1: BDEAD38033537D6B5F6123C85E3250500FE12185
CRC32: B52E80E2

RouterOS

ACK Timeout选项可在Winbox GUI网卡接口设置的“Advanced”标签中找到—-须确保“Advanced Mode”被勾选。RouterOS有一个特性，可以自动计算ACK Timeout，这是默认选项并且在大多数情况下都工作得很好。若要手动设置ACK Timeout，直接输入以微秒为单位的数字，然后点击apply即可。

使用athctrl修改Atheros网卡

athctrl是一个Linux下基于指定的以米为单位的最大距离更改ACK Timeout，CTS Timeout和Slottime的小工具。它的使用方法是：

athctrl  [-h] [-i device] [-d distance]

目前基于atheros的网卡的acktimeout/ctstimeout的可能的最大值是409µs，可以工作的最大距离约为53-57km。

举例

设置wifi0的最大距离为1000米

设置wifi1的最大距离为5000米

OpenWrt + Madwifi

物理层参数存储在/proc/sys/dev/wifiX中。查看参数，比如wifi0的acktimeout

举例

我想设置我的802.11a网卡wifi0，使其工作于8km的链路上。默认的slottime是9µs，默认的acktimeout就是上面的命令所得到的22µs。在原始的300米基础上，距离每增加300米，我都必须将slottime加1，acktimeout加2。这意味着，我必须为slottime添加额外的(8000-300)/300=25.7µs。保险起见，向上取26。因此，我的slottime就是9+26=35，acktimeout和ctstimeout都将是22+26*2=74。

这些设置可通过如下方式完成：

为使设置的参数在系统启动时不变，我们需要将以下内容添加到/etc/sysctl.conf中：

BSD

可以在基于BSD的系统中使用sysctl访问和修改参数，格式是相似的。

举例

以修改网卡wl1为例：

为使设置的参数在系统启动时不变，我们需要将以下内容添加到/etc/sysctl.conf中：

OpenWrt Whiterussian + Broadcom

使用工具dctrl修改Whiterussian中的nbd或nvram设置，可以指定station之间的最大距离。dctrl的使用方法是：

dctrl  [以米为单位的最大距离]

在Whiterussian RC5或更高版本中，nvram中的wl0_distance能用来控制以米为单位的最大距离。一个称为sdist的小工具，可以用来验证是否正确修改了寄存器。在更改nvram后，记得运行/sbin/wifi重新加载wifi设置。

举例：

使用sdist检查初始值，然后将wl0_distance改为20km，重新加载wifi设置。检查wifi卡的寄存器是否正确修改了，然后执行nvram commit (committing the nvram)，以便系统重启后wl0_distance设置保持不变。

HostAP+Prism?

Do we care?

Note about Atheros：如果使用802.11g，将station的工作模式锁定为11g是一个很好的主意，这可以防止当有11b客户端尝试连接时，slottime发生重置。这可以通过在Linux/Madwifi下使用iwpriv <interface> mode 11g，在BSD下使用 ifconfig <interface> mode 11g实现。

在802.11b中，IEEE硬性规定了以下值：

• slottime=20µs
• SIFS=10µs
• PIFS=SIFS+Slottime=30µs
• DIFS=SIFS+2×Slottime=50µs

在802.11g中：

• Slottime=9µs
• SIFS=10µs
• DIFS=SIFS+2×Slottime=28µs

在802.11a中：

• Slottime=9µs
• SIFS=16µs
• DIFS=SIFS+2×Slottime=34µs

在2.4G 802.11n中：

• slottime=9µs（纯ERP环境）或20µs（若有NoERP STA）
• RIFS=2µs
• SIFS=10µs
• DIFS= SIFS+2×Slottime=28µs或50µs

在5G 802.11n中：

• slottime=9µs
• RIFS=2µs
• SIFS=16µs
• DIFS= SIFS+2×Slottime=34µs

注：DIFS/SIFS/PIFS被用作物理层载波侦听，而MAC层使用CTS和ACK timeouts实施冲突检测。CTS和ACK timeouts的默认值因厂家设定而异。

无RTS/CTS握手的普通传输流程

发送方：等待DIFS，发送数据，等待SIFS，侦听并接收ACK（直到最大的ACK timeout），重复

接收方：侦听并接收数据，等待SIFS，发送ACK，等待DIFS

802.11b中的距离限制

最佳的ACK Timeout，Slottime和DIFS有些依赖于空中传播的时间。IEEE标准定义空中传播时间为1µs±（10% SIFS）。无线电波的传播速度约为300m/µs。

ACK Timeout：显然，如果ACK timeout小于最后一个数据包（+SIFS）传递到接收端的时间+对应包的ACK包回传到发送端的时间，那么发送端的MAC就会认为包已经丢失，并发起不必要的（多余的）数据包重传。重传的包最终将会与正在传播（on its way）的ACK碰撞，加上协议的back-off部分，因此会降低吞吐量。如果，相反地，ACK timeout设置得过长，发射机（transmitter）在重传任何丢包之前必须等待一段不必要的时间（直到ACK timeout超时），因此会降低链路的吞吐量(更重要的是，环境中bit error会增加)。在CTS timeout上，也可以得出同样的结论，然而RTS/CTS只是用来降低有隐藏节点的环境中的冲突，在大多数情况下，可以将其（RTS/CTS）关闭。大多数实现都假定IEEE推荐的是单向空中传播时间为1µs，因此将设备的ACK timeout调整为300米。这是802.11b兼容设备能达到高吞吐量的最大距离。当距离更远时，链路仍然可以工作，但吞吐量会随着距离的增加而降低。

举例：当电波以300m/µs的速度传播时，3000m的链路需要的传播时间为10µs（比平常多9µs）。ACK timeout必须是双向传播的时间，因此一条3000m的链路要达到最大的吞吐量，必须在标准的ACK timeout上额外加18µs。这个最大吞吐量会比近距离时能达到的最大吞吐量略小，但会比不更改ACK timeout时的吞吐量大很多。

Slottime：station只被允许在slottime的开始发送数据，因此这个时间（slottime）在电波到达接收端前不能停止(超时)。这给出了一个最大的距离 20µs×300m/µs=6000 m。假定ACK timeout也作了相应的增加，这就是在点对多点环境中（假定无隐藏节点）不蒙受严重的指数级backoff下的最大距离。

DIFS：station在发起新的传输前，必须等待一个DIFS时长，换句话说，802.11b中，station有50µs的时间侦听信道以避免远端节点发来的帧引起冲突。这意味着远端节点的最大距离可达到300m/µs×50µs=15000 m。假定ACK timeout作了相应的增加，这就是点对点环境中不更改slottime(DIFS是基于slottime得来的)，吞吐量显著降低前能达到的最大距离。

802.11g/a长距离链路

原理是一样的，但数字不一样。默认的计时（timings）更为严格，因此任何适当距离的链路，其ACK timeout和slottime十之八九（可能）需要更改，即使是点对点链路。很多以太网网桥/网关设备提供很少或是没有方法修改这些，然而一些特定的miniPCI适配器，比如CM9，Senao和SuperRange卡在BSD或Linux下有驱动支持修改这些设置。适当调整后能达到的吞吐量（虽然不是完全的理论速率），比802.11b在相同距离下能达到的值高很多，值得努力。 

修改ACK timeout和Slottime

在300m的基础上每额外增加300m的距离，设备的Slottime增加1µs，ACK timeout和CTS timeout各增加2µs。

在同一信道上相连的所有station都需要设置相同的计时常量。

使用各节点间（任何两节点之间）的距离的最大值作为计算依据。

常用操作系统和驱动下的案例，可参考http://www.air-stream.org/Change_ACK

 定义

ACK Timeout = Air Propagation Time (max) + SIFS + Time to transmit 14 byte ACK frame [14 * 8 / bitrate in Mbps] + Air Propagation Time (max)

Slottime = MAC and PHY delays + Air Propagation Time (max)

DIFS = SIFS + 2 * Slottime

总结

适当的长距离802.11b链路，因不太严格的计时（timings）及一些厂商更宽松的MAC实现，可以工作得很好。使用正确的无线网卡并做一些调整，802.11b在非常长的链路上几乎能维持最大的理论吞吐量，因此是距离王。

然而802.11a仍然是吞吐量王，但是在远距离链路上需要使用允许调整的特别网卡。调整802.11g需要一块能锁定工作模式为11g的网卡，以防每次有11b客户端尝试连接时，slottime（自动）回调回去。802.11a胜过802.11g,因为在5.8G频谱上有更多的非重叠信道，意味着大多数11a链路将更可能维持其高吞吐量。

原文地址：http://www.air-stream.org.au/ACK_Timeouts

除了ACK timeout，一些其他的计时常数也需要做出调整以适应长距离链路。这些计时常量用于协议的冲突侦听和避免部分。

设置的底线是，确定两无线端站的距离（或者移动环境下的最大距离），计算以微秒为单位的包传送时间，并将ACK timeout设置为比CTS timeout(一个来回传输的时间)稍高一点的值，并将slot time设置为单向传输时间值。这些设置在/proc/sys/dev/athX中表现为slottime,ctstimeout,acktimeout。最简单的方式是使用驱动所带的athctrl工具来更改设置。例如，athctrl –d 15000表示为相距约15000米（约9.4英里）的设备设置相关合理参数。有一点很重要，所有互相通信的设备需使用相同的参数值。因此，在点对多点环境中，其中一台client距离AP 10000米，另一台距离AP 15000米，则需在每台设备上都执行athctrl –d 15000(即按照最远的那台设备与AP的距离做参数调整)。

英文原文见：http://forums.wi-fiplanet.com/showpost.php?s=346e8ea4a7346fae75108b7f68ec0909&p=26917&postcount=2

参考的资料有：

http://blog.csdn.net/magicbreaker/article/details/3373728

—–说实在的，实际上不用那么复杂。

http://bbs.znpc.net/viewthread.php?tid=4192

——描述得比较简单，不过够清楚，可以作为配置的主干

用到的软件：

http://www.hanewin.net/dhcp-e.htm

——这款软件的稳定性不错，但是在客户端电脑读取winnt.sif的时候，经常会抽风，使得客户端无法获取winnt.sif。

http://tftpd32.jounin.net/tftpd32_download.html

——我下载的是tftpd32 standard edition (zip)，这款软件的问题是，快速传送文件的时候，TFTP服务端经常会崩溃。

http://diddy.boot-land.net/pxe/files/binl.htm

——主要用到里面的binlsrv.exe，infparser.exe（用于生成nics.txt和devlist.cache），用法可以参考以上提到的参考资料。参考资料里面说devlist.cache在windows的环境下用不到，不过我用的这个版本的binlsrv.exe程序提示必须有devlist.cache这个文件与binlsrv.exe在同一个目录下，否则程序无法启动。

简要步骤提炼：

1、准备好TFTP/DHCP服务器，比如tftp32或者hanewin

2、设定好DHCP/TFTP服务器，指定TFTP根目录和启动文件名(startrom.n12或其他)。

3、建立tftp server的根目录，比如tftpboot

目录结构如下：

tftpboot
│ ntdetect.com
│ ntldr
│ startrom.n12
│ winnt.sif
│
└─boot
    └─I386

并将tftpboot共享出去（无密码共享），否则客户端无法读取i386目录下的文件。

以上各文件的来历：

①ntdetect.com，直接来源于i386目录下的同名文件，复制一份即可

②ntldr， 取i386目录下的SETUPLDR.EX_，文件解压、更名而来，解压出来的文件名叫做setupldr.exe，直接改名为ntldr即可

③startrom.n12，取i386目录下的STARTROM.N1_，文件解压而来，解压出来的文件名即叫做startrom.n12

④winnt.sif，此文件为系统安装配置指导文件，内容可参考如下：

[Data]
    AutoPartition=0
    floppyless = "1"
    msdosinitiated = "1"
    ; Needed for second stage
    OriSrc = "\\192.168.0.1\tftpboot\boot\i386"
    OriTyp = "4"
    LocalSourceOnCD = 1
    DisableAdminAccountOnDomainJoin = 1
    UnattendedInstall = "No"
[SetupData]
    OsLoadOptions = "/fastdetect"
    ; Needed for first stage
    SetupSourceDevice = "\Device\LanmanRedirector\192.168.0.1\tftpboot\boot"

[UserData]
    ComputerName=MTH
    ; if needed
    ProductID=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

[RemoteInstall]
    Repartition = No
    UseWholeDisk = No

⑤i386目录即为XP光盘里面的i386目录（完整目录及目录下文件）

4、将客户端网卡驱动程序.sys文件放入i386目录下

5、将由infparser.exe生成的网卡信息文件nics.txt和devlist.cache放在binlsrv.exe相同的文件夹下，启动binlsrv.exe

6、启动tftp/dhcp服务器

7、远端客户机可以开始网络安装系统了。

遇到的问题：

1、网卡驱动：一定要用正确的网卡驱动，可以直接用“infparser.exe  网卡驱动.inf” 生成 nics.txt。最好将“网卡驱动.inf”中的无用驱动信息都删除。

2、安装开始时，windows XP一直卡在滚动条那里不动，原因是TFTP根目录没有被正确的共享。如：http://www.renren.it/a/caozuoxitong/Windows/20101005/32838.html     ，win7下的共享设置方法见：http://wenku.baidu.com/view/0b0ad619964bcf84b9d57b4d.html，一定要设置为 “无密码共享”，否则客户端无法读取安装文件。

中文译本第188页提到：

①Client —–DHCP Discovery(广播)—–> Server

②Client<—-DHCP Offer(单播)————   Server

③Client——DHCP Request(广播)——–>Server

④Client<—-DHCP ACK(单播)————-   Server

中文译本第318页提到 DHCP使用下列4个消息来向客户端提供IP地址

• 客户端发送的DHCP发现广播
• 发往客户端的DHCP Offer广播
• 客户端发送的DHCP单播请求
• 发往客户端的DHCP单播确认

我对比了一下中文版与英文原版，发现英文原版也是同样的描述。以上两处对应英文原版PDF文档的第147页及245页。

由此，我用wireshark做了一个抓包测试，结果又有了新的发现，如下图：

DHCP的四个过程都是以广播的形式进行的，不过这里的网络设备不是CISCO的。。。不同厂家在对待DHCP的实现上，看来有些差异。

众多业内专家分析认为，WiFi的爆炸式增长以及通信运营商之间的WLAN（无线局域网）之争势必会引发新一轮的WiFi建设与投资热潮，产业链上不少企业或因此受益。

WiFi国内跑马圈地

继2月发布“光网城市”计划之后，中国电信日前在京又发布“无线中国”计划，吹响了大范围部署WiFi热点（通过WiFi连接互联网的访问点，多分布于公共场所）的“集结号”。不久前，中国移动董事长王建宙在阐述中国移动今年的三大战略时，也格外强调了“扩大WLAN覆盖，建立大量热点”的战略。

工信部电信研究院副总工程师陈金桥在接受证券时报记者采访时表示，用户需求旺盛和网络“减负”的迫切心情是运营商加快发展WLAN，增加WiFi热点覆盖的主要推动力。慧聪邓白氏研究员何倩莹也表示，三大运营商在3G市场中角力，用户逐渐增加，一旦使用流量大的数据业务，容易引起阻塞，WiFi热点上网能很好地缓解流量引起的网络压力。

据统计，截至去年底，中国电信的WiFi热点就已达到10万个，到今年4月底，突破30万个，短短5个月内增幅超过2倍，并计划今年年底前突破70万个，明年年底前突破100万个。与此同时，中国移动宣布，3年内在全国部署100万个WiFi热点。中国联通有关负责人也对记者表示，将在大力发展3G扩网的同时，利用WCDMA网络的技术和终端优势积极发展WiFi战略。

目前中国电信与中国联通分别在南方和北方占据相对优势，而中国移动WiFi热点几乎遍布全国各地。分析人士认为，三大运营商的WiFi布局未来相互渗透的趋势将更加明显，WiFi跑马圈地进程将加快。

多家公司有望受益

“WLAN之争势必会引发WiFi产业的投资与建设高潮。”陈金桥说，“运营商将加大WiFi的投入，购买相关的设备，同时开发相应的数据卡业务，这都会带动整个产业链的迅速反应，加快投融资的步伐。”

数据显示，去年10月以来，中国移动开启了38万台WLAN设备的招标采购，中国联通开启了20万台WLAN设备的招标采购。到今年2月，中国电信也开始大规模WLAN设备采购。平安证券预计，WiFi建设将带动250亿元至300亿元的电信设备新市场。

陈金桥介绍，WiFi设备的价格仅相当于3G设备的十分之一，运营商投入的成本相对偏低，这无形之中降低了准入门槛，设备商在该领域的竞争将变得非常激烈。此前，在中国联通的一次WLAN设备采购招标中，华为、中兴、上海贝尔等终端厂商参与了招标，最终因价格因素，上海贝尔夺魁。不过后来在中国电信的5万台WiFi定单争夺中，华为成功中标。有分析指出，在WiFi设备的争夺中还没有出现强者通吃的局面，产业链条上其他中小型设备商，如三元达、星网锐捷、三维通信等都会有自己的定位和斩获。

记者在采访中发现，国内WiFi产业链条上的服务商、内容商、技术商早已“蠢蠢欲动”。长电科技去年就与中国电信合作开发即插即用手机WiFi卡的系统封装，并一跃成为该领域的龙头企业。摩托罗拉等也为中国电信量身打造了多款“3G互联网四通道手机”。

业内人士认为，上述企业都有机会在本次WiFi热潮中直接受益。此外，受累于WiFi的安全隐患，运营商急需保护用户的上网隐私，英特尔、思科等提供安全解决方案的企业也有机会。

文章引用来源：http://tech.163.com/11/0513/10/73U86CKL000915BE.html

Figure 4: CAPWAP Integrated State Machine

上图所示的CAPWAP状态机，AC和WTP都采用了。为防状态未被共享（比如，未在AC或WTP中的某一个中实施），以下状态转换描述中队此进行了明确的声明。所定义的每一种单一状态，都只允许收发特定的消息。CAPWAP控制消息定义指定了消息在什么状态下有效（或者可以说，定义了特定状态下的有效消息）。

因为一个WTP只与一台AC通信，因此单台WTP只有一个CAPWAP状态机实例。AC上的状态机的运行与WTP不同，因为一台AC会与很多WTP通讯。AC使用了“三线程”的概念。注意：这里的“线程”这个词并非表示AC实现时必须使用线程技术，但这是一种实施AC state machine 的可能/可行方式。

Listener thread： AC的listener thread通过DTLSListen指令处理入站DTLS会话建立请求。一旦建立，listener thread就在DTLS  Setup state启动。一旦一个DTLS会话被确认生效（这发生在state machine 进入authorize状态），listener thread就会创建一个与特定WTP会话相关的服务进程和状态相关信息（state context）。Figure 4中的state machine转换以数字表示。AC保护自身以防来自no-authenticated帧中存在的各种攻击很有必要。

Discovery thread：AC的Discovery thread负责接收、响应Discovery request消息。Figure 4中的state machine转换以数字表示。注意：Discovery thread不会单独为每一个WTP维护独立的context 信息，而只整体上维护一个state context。AC保护自身以防来自no-authenticated帧中存在的各种攻击很有必要。

Service Thread：AC的Service Thread负责处理每个WTP的状态并且每个WTP连接都存在这样一个线程。当到达（进入）授权状态后，Service Thread将会被listener thread创建。当被创建后，Service thread会从listener thread继承一份state machine context的一份信息拷贝。一旦与WTP的通信完成，service thread就会被终结。所有与其相关的资源都会被释放。Figure 4中的state machine transitions以字母和标点符号表示。