联想thinkpad x220,X220t,x220i,x220s windows 7 x64 专业版恢复盘下载地址

FRU:04X0006
只对本机自带slic2.1能激活
Type:(NEW)!
4286,4287,4289,4290,4291,
4294,4296,4297,4298,4299.

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

【译】在各种OS下更改 ACK timeout的方法

通过改变ACK/CTS timeout和Slottime可以提升长距离链路的吞吐性能,见http://www.air-stream.org/ACK_Timeouts

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。

举例

athctrl  -d 1000

设置wifi0的最大距离为1000米

athctrl  -i wifi1 -d 5000

设置wifi1的最大距离为5000米

OpenWrt + Madwifi

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

OpenWrt:~# sysctl dev.wifi0.acktimeout
dev.wifi0.acktimeout = 22

举例

我想设置我的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。

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

OpenWrt:~# sysctl -w dev.wifi0.acktimeout=74
dev.wifi0.acktimeout = 74
OpenWrt:~# sysctl -w dev.wifi0.ctstimeout=74
dev.wifi0.ctstimeout = 74
OpenWrt:~# sysctl -w dev.wifi0.slottime=35
dev.wifi0.slottime = 35

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

dev.wifi0.ctstimeout=74
dev.wifi0.acktimeout=74
dev.wifi0.slottime=35

BSD

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

举例

以修改网卡wl1为例:

~# sysctl -w dev.wl.1.acktimeout=74
dev.wl.1.acktimeout: 22 -> 74
~# sysctl -w dev.wl.1.ctstimeout=74
dev.wl.1.ctstimeout: 22 -> 74
~# sysctl -w dev.wl.1.slottime=35
dev.wl.1.slottime: 9 -> 35

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

dev.wl.1.acktimeout=74
dev.wl.1.ctstimeout=74
dev.wl.1.slottime=35

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设置保持不变。

OpenWrt:~# ./sdistshm: 0x9reg 684: 0×207
OpenWrt:~# nvram set wl0_distance=20000
OpenWrt:~# /sbin/wifi
OpenWrt:~# ./sdist
shm: 0x8f
reg 684: 0x28d
OpenWrt:~# nvram commit

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实现。

【译】ACK Timeouts及其对远程链路的影响

所有的802.11a/b/g无线设备使用IEEE规范定义的计时常量来侦听其他使用无线媒介的载波并避免冲突(802.3只侦听冲突),也用来重传丢失的帧。需重点考虑的常量有slottime,CTS timeout和ACK timeout。在多站(multiple stations)互联环境中的冲突避免或其中一个站尝试模拟全双工通信时,slottime显得更为重要;而ACK timeouts对点对点通信更为重要。其他的可抑制最大链路距离的参数有SIFS (Short Inter Frame Spacing,短帧间隔), DIFS (Distributed IFS,分布式协调功能帧间隔) 和PIFS (Point Coordination IFS,点协调功能帧间隔)。DIFS是stations在开始新的传输序列前,用来检测射频空闲状态的时间。SIFS是station在发送或接收一个RTS,CTS或ACK帧前必须等待的时长。PIFS是AP的一种称为点协调功能(point coordination function)的特殊访问模式下的DIFS。这些计时常量在定义时,赋予了RTS,CTS和ACK帧更高的优先级(例如,一旦包传输序列开始了,station将一直把持信道,直到传输完成)

在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的默认值因厂家设定而异。

Continue reading →

【译】802.11中的time out值是多少?

在802.11a/b/g中,所有的数据传输都要求接收机(the receiving radio)确认;如果发射机没有收到接收机发来的ACK,发射机就会发起若干重传尝试(注:有一些方法使用多播或多媒体特性发送无确认数据包)。因为发射机在等待一段有限的时间(ack timeout)后,就会尝试重传,因此确认(acknowledgments)会对长距离链路有影响。如果确认超时时间(ack timeout)设置得太短,发射机就可能在接收到接收机传来的ACK之前开始发起重传,而且这个重传还会干扰到正在空中传输(“on it’s way”)的ACK。(注:重传会发生在一个随机的random backoff后)。最终导致的结果就是实际的吞吐量很低,而重传次数很高。如果,相反的,ACK timeout设置得过长,接收机因收不到ACK而确实需要重传数据时,就会先等待一段不必要的长ACK timeout,这就带来了时间上的损失,从而降低链路的吞吐量。

除了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

 

hanewin或TFTP32+binlsrv.exe搭建windows 远程安装环境

我的远程计算机系统是32bit windows 7 pro中文版,待安装的系统为windows xp sp2 中文专业版。

参考的资料有:

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,一定要设置为 “无密码共享”,否则客户端无法读取安装文件。

“CCNP Switch (642-813)学习指南”中DHCP操作过程描述前后不一致的疑惑

CCNP Switch (642-813)学习指南 ,关于DHCP操作过程的描述

中文译本第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 多家公司有望受益

日前,全球最大的WiFi(一种将多种智能或非智能终端以无线方式连接的技术)服务提供商Boingo开始首次全球公开募股,进一步引发了全球范围内的WiFi热潮。

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

【RFC5415】【CAPWAP】2.3 CAPWAP状态机定义

以下状态图表代表了一个WTP-AC会话的生命周期;CAPWAP协议对DTLS的使用。致使两名义上并列独立的状态机制紧密地联系在一起。DTLS状态机制和CAPWAP状态机制是以Commands和notification组成的API实现关联的。一些DTLS状态机制里状态的切换由CAPWAP状态机制里的一些指令触发。类似的,一些CAPWAP状态机制里的切换是由DTLS状态机制下的通告消息触发的。

Continue reading →

【RFC5415】【CAPWAP】2.2 CAPWAP会话建立概览(CAPWAP Session Establishment Overview)

以下假定使用证书进行DTLS认证。DTLS允许将多条特定消息汇聚成一个单帧。 Continue reading →

【RFC5415】【CAPWAP】2.1 Wireless Binding Definition

CAPWAP协议是独立于特定WTP Radio技术和与之关联的无线链路层协议的。CAPWAP协议的元素定义,为的是以一种标准的方式去适应/满足任何一种特定的无线技术。为特定无线技术实施CAPWAP协议,必须以满足该无线技术的相关要求为前提。

当定义无线技术的Binding时,作者必须包含任何该无线技术特定的消息定义和这些技术特定的消息的消息元素定义。至少,一个binding必须提供:

  1. 定义binding-specific统计消息元素,该信息将被WTP Event Request 消息承载。
  2. 一个由station configuration request 消息承载的消息元素,用以配置WTP下的station信息。
  3. 一个WTP Radio information message element,由Discovery,primary Discovery,Join Request和Response消息承载,以标示WTP和AC支持的binding-specific radio type。