WPA3 SAE

SAE交换包含两个消息,发往对方的Commit Request和对方回应的Commit Confirm。进行消息交换前,需要产生PWE和两个随机数rand和mask。

发送方
构造SAE Commit Message,并发送到对方

commit-scalar = (rand + mask) mod r
COMMIT-ELEMENT = inverse(scalar-op(mask, PWE))

接收方
收到SAE Commit Message后,生成PMK和PMKID

首先生成一个shared secret element:
K = scalar-op(rand, (elem-op(scalar-op(peer-commit-scalar, PWE), PEER-COMMIT-ELEMENT)))
如果K是选择的group的identity element,则拒绝对方的authentication。(什么是identity element?)

再生成一个shared secret value:
k = F(K)
(K在ECC曲线上的投影,即x坐标)

最后生成PMK:
keyseed = H(<0>32, k)
kck_and_pmk = KDF-Hash-512(keyseed, “SAE KCK and PMK”, (commit-scalar + peer-commit-scalar) mod r)
KCK = L(kck_and_pmk, 0, 256)
PMK = L(kck_and_pmk, 256, 256)
PMKID = L((commit-scalar + peer-commit-scalar) mod r, 0, 128)

构造SAE Confirm Message并发送到对方:
confirm = CN(KCK, send-confirm, commit-scalar, COMMIT-ELEMENT, peer-commit-scalar, PEER-COMMIT-ELEMENT)
(CN函数见12.4.2)

接收方
收到SAE Confirm Message:
使用对方一样的方法来计算verifier:
verifier = CN(KCK, peer-send-confirm, peer-commit-scalar, PEER-COMMIT-ELEMENT, commit-scalar, COMMIT-ELEMENT)
如果verifier与对方发过来的confirm一样,则sta接受对方的authentication。

K的生成原理
假设双方分别是A和M,A是Authenticator。A收到M的Commit Request消息后,获取了scalar-M和element-M。它的K算式是:

((PE^(scalar-M) * element-M )^rnd-A) mod p ==

((PE^(scalar-M) * PE^(-mask-M) )^rnd-A) mod p ==

((PE^(rnd-M + mask-M) * PE^(-mask-M))^rnd-A) mod p ==

(PE^(rnd-M+rnd-A)) mod p

M收到A的Commit Confirm后,获取了scalar-A和element-A,它的K算式是

((PE^(scalar-A) * element-A )^rnd-M) mod p

通过演算也会得到(PE^(rnd-M+rnd-A)) mod p,与A算得的K相同。

 

一个示例SAE抓包

我将wireshark升级到最新的2.6.4才能正确查看该抓包。旧版本会导致Authentication的IE不能正确显示。

306 24.944721063 Epigram_12:d8:52 LewizCom_45:76:89 802.11 175 23 Authentication, SN=23, FN=0, Flags=........C
IEEE 802.11 wireless LAN
Fixed parameters (104 bytes)
Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)
Authentication SEQ: 0x0001
Status code: Successful (0x0000)
Group Id: 19
Scalar: 4330c8599fe71ba944d56c288b232b8158017ac335ece41a...
Finite Field Element: 72615832a4a47fafaa1a1559c916a2376b3e09b1c49ef71f...

309 25.104844242 LewizCom_45:76:89 Epigram_12:d8:52 802.11 175 569 Authentication, SN=569, FN=0, Flags=........C
IEEE 802.11 wireless LAN
Fixed parameters (104 bytes)
Authentication Algorithm: Simultaneous Authentication of Equals (SAE) (3)
Authentication SEQ: 0x0001
Status code: Successful (0x0000)
Group Id: 19
Scalar: 8495f978b4cba12af7dfd1c14b5c4847c95ef648bc444845...
Finite Field Element: 1f9d4f98d2c9c56b1a6a8fa60381691b157c672b4bd319e5...

SAE AP的beacon

305	24.883601576	LewizCom_45:76:89	Broadcast	802.11	345	566	Beacon frame, SN=566, FN=0, Flags=........C, BI=100, SSID=test_sae
IEEE 802.11 wireless LAN
    Fixed parameters (12 bytes)
    Tagged parameters (262 bytes)
        Tag: SSID parameter set: test_sae
        Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 18, 24, 36, 54, [Mbit/sec]
        Tag: DS Parameter set: Current Channel: 11
        Tag: Traffic Indication Map (TIM): DTIM 2 of 0 bitmap
        Tag: Country Information: Country Code US, Environment Any
        Tag: Power Constraint: 0
        Tag: TPC Report Transmit Power: 15, Link Margin: 0
        Tag: ERP Information
        Tag: Extended Supported Rates 6, 9, 12, 48, [Mbit/sec]
        Tag: RSN Information
            Tag Number: RSN Information (48)
            Tag length: 24
            RSN Version: 1
            Group Cipher Suite: 00:0f:ac (Ieee 802.11) AES (CCM)
            Pairwise Cipher Suite Count: 1
            Pairwise Cipher Suite List 00:0f:ac (Ieee 802.11) AES (CCM)
            Auth Key Management (AKM) Suite Count: 2
            Auth Key Management (AKM) List 00:0f:ac (Ieee 802.11) PSK 00:0f:ac (Ieee 802.11) Unknown 8
                Auth Key Management (AKM) Suite: 00:0f:ac (Ieee 802.11) PSK
                Auth Key Management (AKM) Suite: 00:0f:ac (Ieee 802.11) Unknown 8
                    Auth Key Management (AKM) OUI: 00:0f:ac (Ieee 802.11)
                    Auth Key Management (AKM) type: Unknown (8)
            RSN Capabilities: 0x008c
        Tag: HT Capabilities (802.11n D1.10)
        Tag: HT Information (802.11n D1.10)
        Tag: Extended Capabilities (8 octets)
        Ext Tag: HE Capabilities (IEEE Std 802.11ax/D2.0)
        Ext Tag: HE Operation (IEEE Std 802.11ax/D2.0)
        Ext Tag: MU EDCA Parameter Set
        Tag: Vendor Specific: Epigram, Inc.
        Tag: Vendor Specific: Broadcom
        Tag: Vendor Specific: Microsoft Corp.: WMM/WME: Parameter Element

上面的AKM type 8表示SAE,2表示PSK,详见Table 9-133—AKM suite selectors。(OWE规范定义了18表示OWE,802.11 2016中并未定义)

5203595817

最近看书需要查阅地图,百度地图高德地图完全不管用,因为无法查询国外地点。google上找到两个较好的pdf版本,一是CIA版的phisical world map,可以看到世界地形,还有重要城市。

下载地址:/www.cia.gov/library/publications/the-world-factbook/attachments/docs/original/world.pdf

另一个是英国卫报(The Guardians)版本,信息丰富,很漂亮。下载地址:/image.guardian.co.uk/sys-files/Guardian/documents/2011/07/11/New.world5.pdf

 

WPA3 OWE(Opportunistic Wireless Encryption)

(详见/tools.ietf.org/pdf/rfc8110.pdf)

在传统方法中,station需要经过两个步骤来连接到ap。第一个为authentication,目前采用的是open方式,station告诉ap,我是来加入该网络的。ap回应,好的,你通过了。第二个为association,station发送association request到ap,ap回应response。

如果采用的是open方式,station现在就可以访问网络了。如果采用的是psk认证方式,还需要通过四次握手过程来进行认证且产生加密用的key。

owe就是在authentication过程中通过dh交换来生成key,然后用该key来保护后续的数据。

ap在beacon和probe response的rsn ie中加入以下akm(authentication and key management)选项。

如果希望使用owe,station需要在assoc request中携带owe akm,并携带dh parameter ie,即自己的public key。
ap需要在response中携带owen akm。如果ap没有使用pmk caching,则也需要携带dh parameter ie,即自己的pub key。
如果没有使用pmk caching,则station需要丢弃携带了owe akm且不包含dh parameter ie的assoc response。

收到对方的pub key后,sta和ap就可以独立产生pmk和pmk id
z = F(DH(x, Y)) / x: 自己的private key,Y:对方的pub key
prk = HKDF-extract(C | A | group, z) / C: client的pub key,A:AP的pub key
PMK = HKDF-expand(prk, “OWE Key Generation”, n)
PMKID = Truncate-128(Hash(C | A))

association完成后,使用前面产生的pmk来进行四次握手。四次握手的结果是产生ptk(ptk分为三部分:kek,kck,tk。tk用于数据加密)

(715) 415-2062

有关FBT详见spec 12.7.1.7 FT key hierarchy

fbt的初衷是避免漫游到别的ap下时需要再进行四次握手。为了省去四次握手,fbt在reassociation req/response中携带了nonce,以便用较少的信令来生成ptk。

fbt的key包含三个层次:PMK-R0, PMK-R1, PTK。它们的计算方法如下:

R0-Key-Data = KDF-Hash-Length(XXKey, “FT-R0”, SSIDlength || SSID || MDID || R0KHlength || R0KH-ID || S0KH-ID)
PMK-R0 = L(R0-Key-Data, 0, Q)
PMK-R0Name-Salt = L(R0-Key-Data, Q, 128)
Length = Q + 128

PMK-R1 = KDF-Hash-Length(PMK-R0, “FT-R1”, R1KH-ID || S1KH-ID)

PTK = KDF-Hash-Length(PMK-R1, “FT-PTK”, SNonce || ANonce || BSSID || STA-ADDR)

XXKey和Q与选择的akm有关,详见12.7.1.7.3。XXKey有可能是psk,或者sae中生成的的mpmk。
S0KH-ID和S1KH-ID均为supplicant的mac地址。

四次握手中携带的信息:

R1KH –> S1KH: EAPOL-Key(0, 0, 1, 0, P, 0, 0, ANonce, 0)
S1KH –> R1KH: EAPOL-Key(0, 1, 0, 0, P, 0, 0, SNonce, MIC, RSNE[PMKR1Name], MDE, FTE)
R1KH –> S1KH: EAPOL-Key(1, 1, 1, 1, P, 0, 0, ANonce, MIC, RSNE[PMKR1Name], MDE,GTK[N], IGTK[M], FTE, TIE[ReassociationDeadline], TIE[KeyLifetime])
S1KH –> 1KH: EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC)

一次fbt抓包(fbt over air)

376 11.653387000 SamsungE_56:08:02 Broadcom_a9:84:1f 802.11 45 Authentication, SN=1532, FN=0, Flags=.........
378 11.653732000 Broadcom_a9:84:1f SamsungE_56:08:02 802.11 45 Authentication, SN=1305, FN=0, Flags=.........

383 11.654866000 SamsungE_56:08:02 Broadcom_a9:84:1f 802.11 199 Association Request, SN=1533, FN=0, Flags=........., SSID=FBT5G
Tag: Mobility Domain
Tag Number: Mobility Domain (54)
Tag length: 3
Mobility Domain Identifier: 0x0000
FT Capability and Policy: 0x00
.... ...0 = Fast BSS Transition over DS: 0x0
.... ..0. = Resource Request Protocol Capability: 0x0
385 11.657725000 Broadcom_a9:84:1f SamsungE_56:08:02 802.11 294 Association Response, SN=1306, FN=0, Flags=.........
Tag: Fast BSS Transition
Tag Number: Fast BSS Transition (55)
Tag length: 97
MIC Control: 0x0000
0000 0000 .... .... = Element Count: 0
MIC: 00000000000000000000000000000000
ANonce: 000000000000000000000000000000000000000000000000...
SNonce: 000000000000000000000000000000000000000000000000...
Subelement ID: PMK-R1 key holder identifier (R1KH-ID) (1)
Length: 6
PMK-R1 key holder identifier (R1KH-ID): 020405060708
Subelement ID: PMK-R0 key holder identifier (R0KH-ID) (3)
Length: 5
PMK-R0 key holder identifier (R0KH-ID): 23456
到这一步生成了PMK-R1.

391 11.666490000 Broadcom_a9:84:1f SamsungE_56:08:02 EAPOL 159 Key (Message 1 of 4)
398 11.683213000 SamsungE_56:08:02 Broadcom_a9:84:1f EAPOL 281 Key (Message 2 of 4)
404 11.686811000 Broadcom_a9:84:1f SamsungE_56:08:02 EAPOL 337 Key (Message 3 of 4)
406 11.696471000 SamsungE_56:08:02 Broadcom_a9:84:1f EAPOL 137 Key (Message 4 of 4)
到这一步生成了PTK.

2418 55.741217000 Broadcom_a9:84:1f SamsungE_56:08:02 802.11 50 BSS Transition Management Request / AP发起了transition请求
Fixed parameters
Category code: WNM (10)
Action code: BSS Transition Management Request (7)
Dialog token: 0x01
.... ...1 = Preferred Candidate List Included: 1
.... ..0. = Abridged: 0
.... .0.. = Disassociation Imminent: 0
.... 0... = BSS Termination Included: 0
...0 .... = ESS Disassociation Imminent: 0
Disassociation Timer: 0
Validity Interval: 0
BSS Transition Candidate List Entries: 340d001018e2e36200000000012400
2420 55.741468000 SamsungE_56:08:02 Broadcom_a9:84:1f 802.11 39 BSS Transition Management Response
2426 55.750471000 SamsungE_56:08:02 Broadcom_e2:e3:62 802.11 181 Authentication, SN=1969, FN=0, Flags=.........
Tag: Fast BSS Transition
Tag Number: Fast BSS Transition (55)
Tag length: 89
MIC Control: 0x0000
0000 0000 .... .... = Element Count: 0
MIC: 00000000000000000000000000000000
ANonce: 000000000000000000000000000000000000000000000000...
SNonce: 8eae251828c38c323cd119749749ba48a487243ebc111f76...
Subelement ID: PMK-R0 key holder identifier (R0KH-ID) (3)
Length: 5
PMK-R0 key holder identifier (R0KH-ID): 23456
2428 55.753855000 Broadcom_e2:e3:62 SamsungE_56:08:02 802.11 189 Authentication, SN=174, FN=0, Flags=.........
Tag: Fast BSS Transition
Tag Number: Fast BSS Transition (55)
Tag length: 97
MIC Control: 0x0000
0000 0000 .... .... = Element Count: 0
MIC: 00000000000000000000000000000000
ANonce: 3018473324e1634ac05bbb09e67d661b7d3e515e637ccc20...
SNonce: 8eae251828c38c323cd119749749ba48a487243ebc111f76...
Subelement ID: PMK-R1 key holder identifier (R1KH-ID) (1)
Length: 6
PMK-R1 key holder identifier (R1KH-ID): 020304050607
Subelement ID: PMK-R0 key holder identifier (R0KH-ID) (3)
Length: 5
PMK-R0 key holder identifier (R0KH-ID): 23456
收到了新的R1KH-ID,计算出新的PMK-R1。PMK-R0与之前保持一样。
2430 55.754980000 SamsungE_56:08:02 Broadcom_e2:e3:62 802.11 322 Reassociation Request, SN=1970, FN=0, Flags=........., SSID=FBT5G
Tag: Fast BSS Transition
Tag Number: Fast BSS Transition (55)
Tag length: 97
MIC Control: 0x0300
0000 0011 .... .... = Element Count: 3
MIC: 76aa9372f70a2b57207f96d001855af5
ANonce: 3018473324e1634ac05bbb09e67d661b7d3e515e637ccc20...
SNonce: 8eae251828c38c323cd119749749ba48a487243ebc111f76...
Subelement ID: PMK-R1 key holder identifier (R1KH-ID) (1)
Length: 6
PMK-R1 key holder identifier (R1KH-ID): 020304050607
Subelement ID: PMK-R0 key holder identifier (R0KH-ID) (3)
Length: 5
PMK-R0 key holder identifier (R0KH-ID): 23456
AP收到reassoc request后,获取了ANonce和SNonce,这样就算出了新的PTK.

2432 55.757005000 Broadcom_e2:e3:62 SamsungE_56:08:02 802.11 371 Reassociation Response, SN=175, FN=0, Flags=.........
Tag: Fast BSS Transition
Tag Number: Fast BSS Transition (55)
Tag length: 134
MIC Control: 0x0300
0000 0011 .... .... = Element Count: 3
MIC: e0961bf92451ad0bf99cf3441f49dfaf
ANonce: 3018473324e1634ac05bbb09e67d661b7d3e515e637ccc20...
SNonce: 8eae251828c38c323cd119749749ba48a487243ebc111f76...
Subelement ID: PMK-R1 key holder identifier (R1KH-ID) (1)
Length: 6
PMK-R1 key holder identifier (R1KH-ID): 020304050607
Subelement ID: PMK-R0 key holder identifier (R0KH-ID) (3)
Length: 5
PMK-R0 key holder identifier (R0KH-ID): 12345
Subelement ID: GTK subelement (2)
Length: 35
Key Info: 0x0001
.... .... .... ..01 = Key ID: 1
Key Length: 0x10
RSC: 9a02000000000000
GTK: c857262cb18e513d8349bb01c6f75eb1eb64bc2e3c7ce2e8
STA算出了新的PTK.

DLNA和Wi-Fi Display

在家有时想把手机上的视频投射到电视机上,这时有两种方式。打开小米盒子的“无线投屏”,里面能看到Miracast和影音投屏。

Miracast就是Wi-Fi Display。手机侧抓取屏幕,编码打包再送到小米盒子上。这种方式的特点是,建立投屏后,手机上的任何动态都可以在电视机上显示。它也有明显缺点,因为手机一直开着,而且编码需要占用大量资源,且手机通过Wi-Fi Direct持续发送大量数据产生很高的功耗,导致手机发热现象很严重。另外,如果无线路由器只支持2.4G的话,手机的投射通道(Wi-Fi Direct)和网络访问通道都处于2.4G,造成拥塞和时延,马赛克现象严重。

如果选择影音投屏方式,效果则好很多。很多视屏播放器或者浏览器播放插件都有“视频投射”的选项

投射到小米盒子后,手机端可以把播放器关掉,盒子播放不受影响。

通过抓包分析,发现这种方式用的是DLNA技术。盒子通过UPNP让周围知道它启用了DLNA。手机抓到包含UPNP的组播报文后,会将播放链接发给盒子,盒子就可以直接打开这个链接播放了。

一次DLNA抓包:/pan.baidu.com/s/1dtfv3o

#82 192.168.1.19 -> 239.255.255.250 盒子组播upnp ssdp
#2392 192.168.1.4 -> 192.168.1.19 手机将视频url发往盒子/hls-3954.liveplay.myqcloud.com/live/3954_313712128_900.m3u8?bizid=3954&txSecret=543e9751c4d6ce41cf96a890502d9862&txTime=5a861a54
#3109 192.168.1.19 -> 211.162.78.1 查询域名hls-3954.liveplay.myqcloud.com: type A, class IN
#3117 211.162.78.1 -> 192.168.1.19 l3.tcdnlive.com: type A, class IN, addr 220.112.25.187
#3191 192.168.1.19 -> 220.112.25.187 盒子播放视频GET /live/3954_313712128_900.m3u8?bizid=3954&txSecret=543e9751c4d6ce41cf96a890502d9862&txTime=5a861a54 HTTP/1.1

hostapd搭建wpa-eap热点

用hostapd搭建wpa-eap终于成功了,碰到了几个问题:

1. 产生certificate时报错:

Certificate is to be certified until Mar 16 09:04:00 2019 GMT (365 days)
Sign the certificate? [y/n]:y
failed to update database
TXT_DB error number 2
unable to load certificates
140648634365600:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:150:
unable to load certificate

原因:之前用该脚本生成过同名的cert,再生成就有问题了。好比一个CA下面有两个同名的证书。改一下common name即可。

 

2. hostapd报“bad certificate”

W/hostapd (15134): TLS: Certificate verification failed, error 9 (certificate is not yet valid) depth 1 for ‘/C=FI/ST=ES/L=Espoo/O=rinta-aho.org/OU=Home/CN=teemu1/emailAddress=teemu@rinta-aho.org’

D/hostapd (15134): SSL: (where=0x4008 ret=0x22a)

I/hostapd (15134): SSL: SSL3 alert: write (local SSL3 detected an error):fatal:bad certificate

原因:我在手机上运行hostapd,凭证是在Ubuntu PC上生成的,push到手机。手机时间没有校正,依然是1970。hostapd检测到凭证是一个未来日期,于是报错。将手机连上网络同步时间即可解决。

 

3. wpa_supplicant报self signed certificate in certificate chain

W/wpa_supplicant( 4681): TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 1 for ‘/C=FI/ST=ES/L=Espoo/O=rinta-aho.org/OU=Home/CN=teemu1/emailAddress=teemu@rinta-aho.org’

大概是认为cert是由一个未知的CA签名的。将supplicant.conf中ca_cert这一行引掉即可。

4. 四次握手停在3/4 msg处

eap过程已经完成,但四次握手有问题:

D/wpa_supplicant( 2855): wlan0: State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
D/wpa_supplicant( 2855): wlan0: WPA: RX message 3 of 4-Way Handshake from 02:1a:11:f5:0e:7b (ver=1)
D/wpa_supplicant( 2855): WPA: IE KeyData – hexdump(len=62): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 02 01 00 00 0f ac 01 0c 00 dd 26 00 0f ac 01 01 00 88 04 …
D/wpa_supplicant( 2855): WPA: RSN IE in EAPOL-Key – hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 02 01 00 00 0f ac 01 0c 00
D/wpa_supplicant( 2855): WPA: GTK in EAPOL-Key – hexdump(len=40): [REMOVED]
W/wpa_supplicant( 2855): wlan0: WPA: IE in 3/4 msg does not match with IE in Beacon/ProbeResp (src=02:1a:11:f5:0e:7b)
I/wpa_supplicant( 2855): WPA: RSN IE in Beacon/ProbeResp – hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 02 01 00 00 0f ac 01 0d 00
I/wpa_supplicant( 2855): WPA: RSN IE in 3/4 msg – hexdump(len=22): 30 14 01 00 00 0f ac 02 01 00 00 0f ac 02 01 00 00 0f ac 01 0c 00

原来sta端检测到beacon中的rsn ie与3/4 msg中的rsn IE不一样,差在倒数第二个字节,beacon是0d,3/4 msg中是0c。检查hostapd的日志,发现设到驱动中的的确为0c,可是抓包发现空包中是0d,为啥?原来broadcom驱动没有将ie正确设置到芯片中,芯片中生效的是0d。怎么办呢?只能迁就芯片了。我将hostapd.conf中

wpa=1

改为

wpa=3

,这样hostapd往3/4 msg中设置的就是0d,也尝试往chip中设置0d(虽然没有设下去)。另外,sta端的supplicant.conf中将

proto=WPA

改为

proto=WPA RSN

,不这样改的话,supplicant不会尝试连接hostapd热点,报错“rsn ie proto mismatch”

 

附上配置文件hostapd.conf:

root@hammerhead:/data/misc/wifi/eap # cat hostapd.conf
interface=wlan0
driver=nl80211
ctrl_interface=/data/misc/wifi/eap/wlan0
ssid=n5
channel=6
ieee80211n=1
hw_mode=g
ignore_broadcast_ssid=0
wpa=3
wpa_key_mgmt=WPA-EAP
rsn_preauth=0

ieee8021x=1
eapol_version=1
eap_server=1
ca_cert=/data/misc/wifi/eap/ca.pem
dh_file=/data/misc/wifi/eap/hostapd.dh.pem
server_cert=/data/misc/wifi/eap/server.pem
private_key=/data/misc/wifi/eap/server.key
private_key_passwd=pw4server
eap_user_file=/data/misc/wifi/eap/hostapd.eap_users

 

root@hammerhead:/data/misc/wifi/eap # cat hostapd.eap_users                    

#

# Cleaned up example, see original users file for comments.

#

“testuser” TLS

 

supplicant.conf文件内容:

disable_scan_offload=1
update_config=1
device_name=aosp_flounder
manufacturer=HTC
model_name=AOSP on Flounder
model_number=AOSP on Flounder
serial_number=HT4B6JT05113
device_type=10-0050F204-5
config_methods=physical_display virtual_push_button
p2p_no_go_freq=5170-5740
pmf=1
external_sim=1
wowlan_triggers=any
p2p_search_delay=0

network={
ssid=”n5″
proto=WPA
key_mgmt=WPA-EAP
pairwise=CCMP TKIP
eap=TLS
identity=”testuser”
client_cert=”/data/misc/wifi/eap/client.pem”
private_key=”/data/misc/wifi/eap/client.key”
private_key_passwd=”pw4client”
priority=1
}

东萍ubb格式

客户端编程指南

棋谱局面和行棋着法均采用坐标纪录,棋盘左上角为(0,0),右下角为(8,9),比如“炮二平五”,纪录为“7747”,是最简单的程序纪录格式。局面格式为“车马相士帅士相马车炮炮兵兵兵兵兵车马象士将士象马车炮炮卒卒卒卒卒”的顺序,纪录的都为棋子坐标,没有的棋子用99代替。这个项目用来支持残局显示
注解:[DhtmlXQ_comment1_2]+注解文本+[/DhtmlXQ_comment1_2],其中comment是注解的特征字符串,第1个数字为当前变着序号,第2个数字为起始着法对应的数字序号,主着法变着序号为0,可以省略掉
例如:[DhtmlXQ_comment0]这是棋谱刚打开时看到的注解[/DhtmlXQ_comment0],程序内部可以按照DhtmlXQ_comment0_0来解释
变着:主着法用movelist,实际相当于变着0_1_0,代码为[DhtmlXQ_movelist]7747…5545[/DhtmlXQ_movelist],程序内部可以按照DhtmlXQ_move_0_1_0]来解释
子变着格式为[DhtmlXQ_move_0_2_1]xxxx[DhtmlXQ_move_0_2_1],其中move是变着的特征字符串,第1个数字为父变着序号,第2个数字为本变着序号,第3个数字为起始着法对应的数字序号