* IBSS timeouts
@ 2018-07-16 19:31 James Prestwood
2018-07-17 7:57 ` Nicolas Cavallari
0 siblings, 1 reply; 8+ messages in thread
From: James Prestwood @ 2018-07-16 19:31 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
Hello,
I am a developer for IWD and trying to implement IBSS networks. The
initial IBSS_JOIN, 4-way, and setting the keys all works and I am able
to connect two stations. The problem is that I am hitting a timeout in
the kernel once the connection has succeeded and there are no more
frames flowing between stations. I dug around in the kernel and saw
there is a 60 second inactivity timeout which is precicely what is
happening. After setting the keys 60 seconds go by and I recieve a
DEL_STATION (log attached).
My question is: is this timeout expected after the station has been
added and the keys are set? If so how does one reset this timeout so
the connection can remain alive even if no data is being sent?
heartbeat of some kind?
The log attached was obtained with iwmon, which is a utility included
in IWD that monitors NL traffic.
Thanks,
James
[-- Attachment #2: log.txt --]
[-- Type: text/plain, Size: 32668 bytes --]
< Request: Set Interface (0x06) len 16 [ack] 1531765291.397958
Interface Index: 2 (0x00000002)
Interface Type: 1 (0x00000001)
> Response: Set Interface (0x06) len 4 [0x100] 1531765291.397968
Status: Success (0)
< Request: Join IBSS (0x2b) len 80 [ack] 1531765291.420343
Interface Index: 2 (0x00000002)
SSID: len 6
6d 79 73 73 69 64 myssid
Wiphy Frequency: 2437 (0x00000985)
Wiphy Channel Type: 0 (0x00000000)
Control Port: true
Privacy: true
Interface Socket Owner: true
Information Elements: len 20
RSN:
Group Data Cipher Suite: len 4
Group traffic not allowed (00:0f:ac) suite 07
Pairwise Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
AKM Suite: len 4
PSK; RSNA PSK (00:0f:ac) suite 02
01 00 00 0f ac 07 01 00 00 0f ac 04 01 00 00 0f ................
ac 02 ..
Beacon Interval: 100 (0x00000064)
> Response: Join IBSS (0x2b) len 4 [0x100] 1531765291.420363
Status: Success (0)
< Request: Get Scan (0x20) len 8 [ack,0x300] 1531765293.386648
Interface Index: 2 (0x00000002)
> Complete: Get Scan (0x20) len 4 [multi] 1531765293.390015
Status: 0
> Event: Join IBSS (0x2b) len 28 1531765299.243604
Wiphy: 0 (0x00000000)
Interface Index: 2 (0x00000002)
MAC Address 52:1A:93:B9:3E:D4
> Event: New Station (0x13) len 32 1531765299.593053
Interface Index: 2 (0x00000002)
MAC Address 6C:71:D9:0D:6E:4B
Generation: 5 (0x00000005)
Station Info: len 0
> Event: Join IBSS (0x2b) len 28 1531765299.593167
Wiphy: 0 (0x00000000)
Interface Index: 2 (0x00000002)
MAC Address C6:4B:95:D4:B4:42
< PAE: len 121 0.593374
Interface Index: 2
EAPoL: len 121
02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 ...u............
01 7c 23 78 f9 41 20 1e 3c b6 65 29 77 71 d6 a5 .|#x.A .<.e)wq..
29 97 6e 88 a1 9c 90 55 b9 c3 a6 94 8f 89 27 cb ).n....U......'.
d6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 16 dd 14 00 0f ac 04 84 74 54 87 67 e0 7c ..........tT.g.|
e0 03 17 77 ed e4 b4 e1 32 ...w....2
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 117
Descriptor Type: 2
Key MIC: false
Secure: false
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: true
Key Length: 16
Key Replay Counter: 1
Key NONCE
7c 23 78 f9 41 20 1e 3c b6 65 29 77 71 d6 a5 29 |#x.A .<.e)wq..)
97 6e 88 a1 9c 90 55 b9 c3 a6 94 8f 89 27 cb d6 .n....U......'..
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key Data: len 22
Vendor specific: len 20
IEEE 802.11 (00:0f:ac) type: 04
00 0f ac 04 84 74 54 87 67 e0 7c e0 03 17 77 ed .....tT.g.|...w.
e4 b4 e1 32 ...2
> PAE: len 121 0.613642
Interface Index: 2
EAPoL: len 121
02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 ...u............
01 33 2b b2 1f 7e 42 78 73 83 ae 9e 5c 4d 49 20 .3+..~Bxs...\MI
c7 32 87 87 a0 60 90 6a 96 6a d3 ba 16 d5 c3 bf .2...`.j.j......
89 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 16 dd 14 00 0f ac 04 6c d5 47 28 c7 fa de .........l.G(...
05 27 d1 bf 01 be d1 41 b2 .'.....A.
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 117
Descriptor Type: 2
Key MIC: false
Secure: false
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: true
Key Length: 16
Key Replay Counter: 1
Key NONCE
33 2b b2 1f 7e 42 78 73 83 ae 9e 5c 4d 49 20 c7 3+..~Bxs...\MI .
32 87 87 a0 60 90 6a 96 6a d3 ba 16 d5 c3 bf 89 2...`.j.j.......
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key Data: len 22
Vendor specific: len 20
IEEE 802.11 (00:0f:ac) type: 04
00 0f ac 04 6c d5 47 28 c7 fa de 05 27 d1 bf 01 ....l.G(....'...
be d1 41 b2 ..A.
< PAE: len 119 0.614028
Interface Index: 2
EAPoL: len 119
02 03 00 73 02 01 0a 00 00 00 00 00 00 00 00 00 ...s............
01 25 25 1c e7 44 97 89 56 cc 6f 01 3a 1f 2f ca .%%..D..V.o.:./.
99 d9 3c 34 98 f6 5c da c9 5c a5 28 ce 24 e6 fa ..<4..\..\.(.$..
45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 57 c2 4f 46 94 5f 10 5d ac 86 12 46 1d e0 8d .W.OF._.]...F...
cd 00 14 30 12 01 00 00 0f ac 07 01 00 00 0f ac ...0............
04 01 00 00 0f ac 02 .......
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 115
Descriptor Type: 2
Key MIC: true
Secure: false
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: false
Key Length: 0
Key Replay Counter: 1
Key NONCE
25 25 1c e7 44 97 89 56 cc 6f 01 3a 1f 2f ca 99 %%..D..V.o.:./..
d9 3c 34 98 f6 5c da c9 5c a5 28 ce 24 e6 fa 45 .<4..\..\.(.$..E
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
57 c2 4f 46 94 5f 10 5d ac 86 12 46 1d e0 8d cd W.OF._.]...F....
Key Data: len 20
RSN:
Group Data Cipher Suite: len 4
Group traffic not allowed (00:0f:ac) suite 07
Pairwise Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
AKM Suite: len 4
PSK; RSNA PSK (00:0f:ac) suite 02
01 00 00 0f ac 07 01 00 00 0f ac 04 01 00 00 0f ................
ac 02 ..
> PAE: len 119 0.623958
Interface Index: 2
EAPoL: len 119
02 03 00 73 02 01 0a 00 00 00 00 00 00 00 00 00 ...s............
01 72 ce ff 06 31 cd a3 f0 6f 44 76 80 09 eb 57 .r...1...oDv...W
b5 9f f2 8e 1a 15 02 2b 61 41 1b b8 90 1d 4a 59 .......+aA....JY
1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 2f 3f ce 3e e3 42 a2 06 49 b5 c9 a8 9b 24 ce ./?.>.B..I....$.
76 00 14 30 12 01 00 00 0f ac 07 01 00 00 0f ac v..0............
04 01 00 00 0f ac 02 .......
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 115
Descriptor Type: 2
Key MIC: true
Secure: false
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: false
Key Length: 0
Key Replay Counter: 1
Key NONCE
72 ce ff 06 31 cd a3 f0 6f 44 76 80 09 eb 57 b5 r...1...oDv...W.
9f f2 8e 1a 15 02 2b 61 41 1b b8 90 1d 4a 59 1b ......+aA....JY.
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
2f 3f ce 3e e3 42 a2 06 49 b5 c9 a8 9b 24 ce 76 /?.>.B..I....$.v
Key Data: len 20
RSN:
Group Data Cipher Suite: len 4
Group traffic not allowed (00:0f:ac) suite 07
Pairwise Cipher Suite: len 4
CCMP (00:0f:ac) suite 04
AKM Suite: len 4
PSK; RSNA PSK (00:0f:ac) suite 02
01 00 00 0f ac 07 01 00 00 0f ac 04 01 00 00 0f ................
ac 02 ..
< PAE: len 131 0.624501
Interface Index: 2
EAPoL: len 131
02 03 00 7f 02 13 ca 00 10 00 00 00 00 00 00 00 ................
02 7c 23 78 f9 41 20 1e 3c b6 65 29 77 71 d6 a5 .|#x.A .<.e)wq..
29 97 6e 88 a1 9c 90 55 b9 c3 a6 94 8f 89 27 cb ).n....U......'.
d6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
00 6b 4d e5 16 f7 e9 1a 2b d0 9b 92 06 37 3b 27 .kM.....+....7;'
ca 00 20 04 68 71 aa cc 53 e9 4f 17 03 db 61 5b .. .hq..S.O...a[
ba 3d db cf 53 f7 47 5a b9 e4 e7 5f eb bc 1c 6a .=..S.GZ..._...j
bf 14 ca ...
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 127
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: true
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: true
Key ACK: true
Key Length: 16
Key Replay Counter: 2
Key NONCE
7c 23 78 f9 41 20 1e 3c b6 65 29 77 71 d6 a5 29 |#x.A .<.e)wq..)
97 6e 88 a1 9c 90 55 b9 c3 a6 94 8f 89 27 cb d6 .n....U......'..
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 01 ........
Key MIC Data
6b 4d e5 16 f7 e9 1a 2b d0 9b 92 06 37 3b 27 ca kM.....+....7;'.
Key Data: len 32
04 68 71 aa cc 53 e9 4f 17 03 db 61 5b ba 3d db .hq..S.O...a[.=.
cf 53 f7 47 5a b9 e4 e7 5f eb bc 1c 6a bf 14 ca .S.GZ..._...j...
> PAE: len 131 0.625934
Interface Index: 2
EAPoL: len 131
02 03 00 7f 02 13 ca 00 10 00 00 00 00 00 00 00 ................
02 33 2b b2 1f 7e 42 78 73 83 ae 9e 5c 4d 49 20 .3+..~Bxs...\MI
c7 32 87 87 a0 60 90 6a 96 6a d3 ba 16 d5 c3 bf .2...`.j.j......
89 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
00 ef 63 89 8e e3 39 41 04 d2 6b 07 7e 66 5d 24 ..c...9A..k.~f]$
de 00 20 8a eb 04 9f 08 b8 54 25 5d a0 92 64 6e .. ......T%]..dn
3c 89 fc c8 fa fb 16 51 53 85 bf eb c7 4e 71 c8 <......QS....Nq.
49 6e 81 In.
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 127
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: true
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: true
Key ACK: true
Key Length: 16
Key Replay Counter: 2
Key NONCE
33 2b b2 1f 7e 42 78 73 83 ae 9e 5c 4d 49 20 c7 3+..~Bxs...\MI .
32 87 87 a0 60 90 6a 96 6a d3 ba 16 d5 c3 bf 89 2...`.j.j.......
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 01 ........
Key MIC Data
ef 63 89 8e e3 39 41 04 d2 6b 07 7e 66 5d 24 de .c...9A..k.~f]$.
Key Data: len 32
8a eb 04 9f 08 b8 54 25 5d a0 92 64 6e 3c 89 fc ......T%]..dn<..
c8 fa fb 16 51 53 85 bf eb c7 4e 71 c8 49 6e 81 ....QS....Nq.In.
< PAE: len 99 0.626452
Interface Index: 2
EAPoL: len 99
02 03 00 5f 02 03 0a 00 00 00 00 00 00 00 00 00 ..._............
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 a5 16 c0 7d 19 f2 96 7f 81 f5 38 be 1c 12 36 ....}......8...6
f3 00 00 ...
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 95
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: false
Key Length: 0
Key Replay Counter: 2
Key NONCE
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
a5 16 c0 7d 19 f2 96 7f 81 f5 38 be 1c 12 36 f3 ...}......8...6.
Key Data: len 0
> PAE: len 99 0.652019
Interface Index: 2
EAPoL: len 99
02 03 00 5f 02 03 0a 00 00 00 00 00 00 00 00 00 ..._............
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 8e 4f ab 78 8b d1 5c fa 8a cf a5 c3 d0 59 5d ..O.x..\......Y]
2e 00 00 ...
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 95
Descriptor Type: 2
Key MIC: true
Secure: true
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: false
Key Length: 0
Key Replay Counter: 2
Key NONCE
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
8e 4f ab 78 8b d1 5c fa 8a cf a5 c3 d0 59 5d 2e .O.x..\......Y].
Key Data: len 0
< Request: New Key (0x0b) len 56 [ack] 0.652311
Key Data: len 16
81 27 ad 28 ee 84 8e da cb 1c 7e 7b 1c 2e ba e4 .'.(......~{....
Key Cipher: CCMP (00:0f:ac) suite 04
MAC Address 6C:71:D9:0D:6E:4B
Key Index: 0 (0x00)
Interface Index: 2 (0x00000002)
> Response: New Key (0x0b) len 4 [0x100] 0.652869
Status: Success (0)
< Request: Set Station (0x12) len 32 [ack] 0.652917
Interface Index: 2 (0x00000002)
MAC Address 6C:71:D9:0D:6E:4B
Station Flags 2: len 8
Mask: 0x00000002
Authorized
Set: 0x00000002
Authorized
> Response: Set Station (0x12) len 4 [root] 0.652936
Status: Success (0)
> Event: Del Station (0x14) len 1128 60.684966
Interface Index: 2 (0x00000002)
MAC Address 6C:71:D9:0D:6E:4B
Generation: 6 (0x00000006)
Station Info: len 1096
Connected time: 60 (0x0000003c)
Inactivity time: 60056 (0x0000ea98)
Total RX bytes: 606 (0x0000025e)
Total TX bytes: 598 (0x00000256)
Total RX bytes: 606 (0x000000000000025e)
Total TX bytes: 598 (0x0000000000000256)
Signal strength: -71
Signal strength average: -72
Per-chain signal strength: len 16
05 00 00 00 af 00 00 00 05 00 01 00 b9 00 00 00 ................
Per-chain signal strength average: len 16
05 00 00 00 b2 00 00 00 05 00 01 00 b8 00 00 00 ................
TX bitrate: len 16
Bit Rate: 10 (0x0000000a)
Bit Rate (Legacy): 10 (0x000a)
RX packets: 4 (0x00000004)
TX packets: 4 (0x00000004)
TX retries: 0 (0x00000000)
TX failed: 0 (0x00000000)
BSS parameters: len 16
DTIM Period: 0 (0x00)
Beacon Interval: 100 (0x0064)
Station flags: len 8
Mask: 0x000000fe
Authorized
ShortPreamble
WME
MFP
Authenticated
TDLS-Peer
Associated
Set: 0x00000000
Reserved: len 8
00 00 00 00 00 00 00 00 ........
Reserved: len 884
34 00 01 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 34 00 02 00 0c 00 01 00 00 00 00 00 ....4...........
00 00 00 00 0c 00 02 00 00 00 00 00 00 00 00 00 ................
0c 00 03 00 00 00 00 00 00 00 00 00 0c 00 04 00 ................
00 00 00 00 00 00 00 00 34 00 03 00 0c 00 01 00 ........4.......
00 00 00 00 00 00 00 00 0c 00 02 00 00 00 00 00 ................
00 00 00 00 0c 00 03 00 00 00 00 00 00 00 00 00 ................
0c 00 04 00 00 00 00 00 00 00 00 00 34 00 04 00 ............4...
0c 00 01 00 00 00 00 00 00 00 00 00 0c 00 02 00 ................
00 00 00 00 00 00 00 00 0c 00 03 00 00 00 00 00 ................
00 00 00 00 0c 00 04 00 00 00 00 00 00 00 00 00 ................
34 00 05 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 34 00 06 00 0c 00 01 00 00 00 00 00 ....4...........
00 00 00 00 0c 00 02 00 00 00 00 00 00 00 00 00 ................
0c 00 03 00 00 00 00 00 00 00 00 00 0c 00 04 00 ................
00 00 00 00 00 00 00 00 34 00 07 00 0c 00 01 00 ........4.......
00 00 00 00 00 00 00 00 0c 00 02 00 00 00 00 00 ................
00 00 00 00 0c 00 03 00 00 00 00 00 00 00 00 00 ................
0c 00 04 00 00 00 00 00 00 00 00 00 34 00 08 00 ............4...
0c 00 01 00 04 00 00 00 00 00 00 00 0c 00 02 00 ................
00 00 00 00 00 00 00 00 0c 00 03 00 00 00 00 00 ................
00 00 00 00 0c 00 04 00 00 00 00 00 00 00 00 00 ................
34 00 09 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 34 00 0a 00 0c 00 01 00 00 00 00 00 ....4...........
00 00 00 00 0c 00 02 00 00 00 00 00 00 00 00 00 ................
0c 00 03 00 00 00 00 00 00 00 00 00 0c 00 04 00 ................
00 00 00 00 00 00 00 00 34 00 0b 00 0c 00 01 00 ........4.......
00 00 00 00 00 00 00 00 0c 00 02 00 00 00 00 00 ................
00 00 00 00 0c 00 03 00 00 00 00 00 00 00 00 00 ................
0c 00 04 00 00 00 00 00 00 00 00 00 34 00 0c 00 ............4...
0c 00 01 00 00 00 00 00 00 00 00 00 0c 00 02 00 ................
00 00 00 00 00 00 00 00 0c 00 03 00 00 00 00 00 ................
00 00 00 00 0c 00 04 00 00 00 00 00 00 00 00 00 ................
34 00 0d 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 34 00 0e 00 0c 00 01 00 00 00 00 00 ....4...........
00 00 00 00 0c 00 02 00 00 00 00 00 00 00 00 00 ................
0c 00 03 00 00 00 00 00 00 00 00 00 0c 00 04 00 ................
00 00 00 00 00 00 00 00 34 00 0f 00 0c 00 01 00 ........4.......
00 00 00 00 00 00 00 00 0c 00 02 00 00 00 00 00 ................
00 00 00 00 0c 00 03 00 00 00 00 00 00 00 00 00 ................
0c 00 04 00 00 00 00 00 00 00 00 00 34 00 10 00 ............4...
0c 00 01 00 00 00 00 00 00 00 00 00 0c 00 02 00 ................
00 00 00 00 00 00 00 00 0c 00 03 00 00 00 00 00 ................
00 00 00 00 0c 00 04 00 00 00 00 00 00 00 00 00 ................
34 00 11 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 04 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 ....
> Event: New Station (0x13) len 32 61.321641
Interface Index: 2 (0x00000002)
MAC Address 6C:71:D9:0D:6E:4B
Generation: 7 (0x00000007)
Station Info: len 0
< PAE: len 121 61.321923
Interface Index: 2
EAPoL: len 121
02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 ...u............
01 69 88 ef fb 5b ec 28 3d be f0 c6 cc c2 f7 12 .i...[.(=.......
1c 7a 25 c4 95 29 c1 2a d3 7c 34 a1 dd da c6 fb .z%..).*.|4.....
3e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 16 dd 14 00 0f ac 04 84 74 54 87 67 e0 7c ..........tT.g.|
e0 03 17 77 ed e4 b4 e1 32 ...w....2
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 117
Descriptor Type: 2
Key MIC: false
Secure: false
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: true
Key Length: 16
Key Replay Counter: 1
Key NONCE
69 88 ef fb 5b ec 28 3d be f0 c6 cc c2 f7 12 1c i...[.(=........
7a 25 c4 95 29 c1 2a d3 7c 34 a1 dd da c6 fb 3e z%..).*.|4.....>
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key Data: len 22
Vendor specific: len 20
IEEE 802.11 (00:0f:ac) type: 04
00 0f ac 04 84 74 54 87 67 e0 7c e0 03 17 77 ed .....tT.g.|...w.
e4 b4 e1 32 ...2
< PAE: len 121 61.422155
Interface Index: 2
EAPoL: len 121
02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 ...u............
02 ce 39 7f ee ff fe d6 34 58 e5 48 df fc 8b d1 ..9.....4X.H....
d6 57 26 b0 ba a0 1f ea 6f 92 38 26 c8 1f 69 b4 .W&.....o.8&..i.
bb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 16 dd 14 00 0f ac 04 84 74 54 87 67 e0 7c ..........tT.g.|
e0 03 17 77 ed e4 b4 e1 32 ...w....2
Protocol Version: 2 (802.1X-2004)
Type: 3 (Key)
Length: 117
Descriptor Type: 2
Key MIC: false
Secure: false
Error: false
Request: false
Encrypted Key Data: false
SMK Message: false
Key Descriptor Version: 2 (02)
Key Type: true
Install: false
Key ACK: true
Key Length: 16
Key Replay Counter: 2
Key NONCE
ce 39 7f ee ff fe d6 34 58 e5 48 df fc 8b d1 d6 .9.....4X.H.....
57 26 b0 ba a0 1f ea 6f 92 38 26 c8 1f 69 b4 bb W&.....o.8&..i..
Key IV
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key RSC
00 00 00 00 00 00 00 00 ........
Key MIC Data
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Key Data: len 22
Vendor specific: len 20
IEEE 802.11 (00:0f:ac) type: 04
00 0f ac 04 84 74 54 87 67 e0 7c e0 03 17 77 ed .....tT.g.|...w.
e4 b4 e1 32 ...2
> Event: Del Station (0x14) len 1088 67.133540
Interface Index: 2 (0x00000002)
MAC Address 6C:71:D9:0D:6E:4B
Generation: 8 (0x00000008)
Station Info: len 1056
Connected time: 6 (0x00000006)
Inactivity time: 5700 (0x00001644)
Total RX bytes: 0 (0x00000000)
Total TX bytes: 310 (0x00000136)
Total RX bytes: 0 (0x0000000000000000)
Total TX bytes: 310 (0x0000000000000136)
Signal strength: 0
Signal strength average: 0
TX bitrate: len 16
Bit Rate: 10 (0x0000000a)
Bit Rate (Legacy): 10 (0x000a)
RX packets: 0 (0x00000000)
TX packets: 2 (0x00000002)
TX retries: 4 (0x00000004)
TX failed: 0 (0x00000000)
BSS parameters: len 16
DTIM Period: 0 (0x00)
Beacon Interval: 100 (0x0064)
Station flags: len 8
Mask: 0x000000fe
Authorized
ShortPreamble
WME
MFP
Authenticated
TDLS-Peer
Associated
Set: 0x00000008
WME
Reserved: len 8
00 00 00 00 00 00 00 00 ........
Reserved: len 884
34 00 01 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 34 00 02 00 0c 00 01 00 00 00 00 00 ....4...........
00 00 00 00 0c 00 02 00 00 00 00 00 00 00 00 00 ................
0c 00 03 00 00 00 00 00 00 00 00 00 0c 00 04 00 ................
00 00 00 00 00 00 00 00 34 00 03 00 0c 00 01 00 ........4.......
00 00 00 00 00 00 00 00 0c 00 02 00 00 00 00 00 ................
00 00 00 00 0c 00 03 00 00 00 00 00 00 00 00 00 ................
0c 00 04 00 00 00 00 00 00 00 00 00 34 00 04 00 ............4...
0c 00 01 00 00 00 00 00 00 00 00 00 0c 00 02 00 ................
00 00 00 00 00 00 00 00 0c 00 03 00 00 00 00 00 ................
00 00 00 00 0c 00 04 00 00 00 00 00 00 00 00 00 ................
34 00 05 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 34 00 06 00 0c 00 01 00 00 00 00 00 ....4...........
00 00 00 00 0c 00 02 00 00 00 00 00 00 00 00 00 ................
0c 00 03 00 00 00 00 00 00 00 00 00 0c 00 04 00 ................
00 00 00 00 00 00 00 00 34 00 07 00 0c 00 01 00 ........4.......
00 00 00 00 00 00 00 00 0c 00 02 00 00 00 00 00 ................
00 00 00 00 0c 00 03 00 00 00 00 00 00 00 00 00 ................
0c 00 04 00 00 00 00 00 00 00 00 00 34 00 08 00 ............4...
0c 00 01 00 00 00 00 00 00 00 00 00 0c 00 02 00 ................
02 00 00 00 00 00 00 00 0c 00 03 00 04 00 00 00 ................
00 00 00 00 0c 00 04 00 00 00 00 00 00 00 00 00 ................
34 00 09 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 34 00 0a 00 0c 00 01 00 00 00 00 00 ....4...........
00 00 00 00 0c 00 02 00 00 00 00 00 00 00 00 00 ................
0c 00 03 00 00 00 00 00 00 00 00 00 0c 00 04 00 ................
00 00 00 00 00 00 00 00 34 00 0b 00 0c 00 01 00 ........4.......
00 00 00 00 00 00 00 00 0c 00 02 00 00 00 00 00 ................
00 00 00 00 0c 00 03 00 00 00 00 00 00 00 00 00 ................
0c 00 04 00 00 00 00 00 00 00 00 00 34 00 0c 00 ............4...
0c 00 01 00 00 00 00 00 00 00 00 00 0c 00 02 00 ................
00 00 00 00 00 00 00 00 0c 00 03 00 00 00 00 00 ................
00 00 00 00 0c 00 04 00 00 00 00 00 00 00 00 00 ................
34 00 0d 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 34 00 0e 00 0c 00 01 00 00 00 00 00 ....4...........
00 00 00 00 0c 00 02 00 00 00 00 00 00 00 00 00 ................
0c 00 03 00 00 00 00 00 00 00 00 00 0c 00 04 00 ................
00 00 00 00 00 00 00 00 34 00 0f 00 0c 00 01 00 ........4.......
00 00 00 00 00 00 00 00 0c 00 02 00 00 00 00 00 ................
00 00 00 00 0c 00 03 00 00 00 00 00 00 00 00 00 ................
0c 00 04 00 00 00 00 00 00 00 00 00 34 00 10 00 ............4...
0c 00 01 00 00 00 00 00 00 00 00 00 0c 00 02 00 ................
00 00 00 00 00 00 00 00 0c 00 03 00 00 00 00 00 ................
00 00 00 00 0c 00 04 00 00 00 00 00 00 00 00 00 ................
34 00 11 00 0c 00 01 00 00 00 00 00 00 00 00 00 4...............
0c 00 02 00 00 00 00 00 00 00 00 00 0c 00 03 00 ................
00 00 00 00 00 00 00 00 0c 00 04 00 00 00 00 00 ................
00 00 00 00 ....
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IBSS timeouts
2018-07-16 19:31 IBSS timeouts James Prestwood
@ 2018-07-17 7:57 ` Nicolas Cavallari
2018-07-17 15:02 ` Ben Greear
2018-07-17 16:19 ` James Prestwood
0 siblings, 2 replies; 8+ messages in thread
From: Nicolas Cavallari @ 2018-07-17 7:57 UTC (permalink / raw)
To: James Prestwood, linux-wireless
On 16/07/2018 21:31, James Prestwood wrote:
> Hello,
>
> I am a developer for IWD and trying to implement IBSS networks. The
> initial IBSS_JOIN, 4-way, and setting the keys all works and I am able
> to connect two stations. The problem is that I am hitting a timeout in
> the kernel once the connection has succeeded and there are no more
> frames flowing between stations. I dug around in the kernel and saw
> there is a 60 second inactivity timeout which is precicely what is
> happening. After setting the keys 60 seconds go by and I recieve a
> DEL_STATION (log attached).
>
> My question is: is this timeout expected after the station has been
> added and the keys are set? If so how does one reset this timeout so
> the connection can remain alive even if no data is being sent?
> heartbeat of some kind?
This is not normal, but it isn't your fault. It's more a problem with your card
firmware/driver. What card/driver do you have ?
In IBSS mode, all stations are required to send beacons. The protocol is a bit
complex to arrange that, every 102.4ms, a station is chosen to emit the beacon.
Receiving beacons from a station is enough to reset its timer, so with a
properly functioning station, this timer does not expire.
Unfortunately, in the wild, nobody test that IBSS beacons are generated, because
without them, an open IBSS still appear to work...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IBSS timeouts
2018-07-17 7:57 ` Nicolas Cavallari
@ 2018-07-17 15:02 ` Ben Greear
2018-07-17 17:44 ` Nicolas Cavallari
2018-07-17 16:19 ` James Prestwood
1 sibling, 1 reply; 8+ messages in thread
From: Ben Greear @ 2018-07-17 15:02 UTC (permalink / raw)
To: Nicolas Cavallari, James Prestwood, linux-wireless
On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
> On 16/07/2018 21:31, James Prestwood wrote:
>> Hello,
>>
>> I am a developer for IWD and trying to implement IBSS networks. The
>> initial IBSS_JOIN, 4-way, and setting the keys all works and I am able
>> to connect two stations. The problem is that I am hitting a timeout in
>> the kernel once the connection has succeeded and there are no more
>> frames flowing between stations. I dug around in the kernel and saw
>> there is a 60 second inactivity timeout which is precicely what is
>> happening. After setting the keys 60 seconds go by and I recieve a
>> DEL_STATION (log attached).
>>
>> My question is: is this timeout expected after the station has been
>> added and the keys are set? If so how does one reset this timeout so
>> the connection can remain alive even if no data is being sent?
>> heartbeat of some kind?
>
> This is not normal, but it isn't your fault. It's more a problem with your card
> firmware/driver. What card/driver do you have ?
>
> In IBSS mode, all stations are required to send beacons. The protocol is a bit
> complex to arrange that, every 102.4ms, a station is chosen to emit the beacon.
I'm not sure this part is correct. In practice, it seems to often happen this way,
but last time I read the spec on this it seems like it is supposed to sort of negotiate
and not have all ibss stations beaconning.
Thanks,
Ben
>
> Receiving beacons from a station is enough to reset its timer, so with a
> properly functioning station, this timer does not expire.
>
> Unfortunately, in the wild, nobody test that IBSS beacons are generated, because
> without them, an open IBSS still appear to work...
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IBSS timeouts
2018-07-17 7:57 ` Nicolas Cavallari
2018-07-17 15:02 ` Ben Greear
@ 2018-07-17 16:19 ` James Prestwood
2018-07-17 18:05 ` Nicolas Cavallari
1 sibling, 1 reply; 8+ messages in thread
From: James Prestwood @ 2018-07-17 16:19 UTC (permalink / raw)
To: Nicolas Cavallari, linux-wireless
On Tue, 2018-07-17 at 09:57 +0200, Nicolas Cavallari wrote:
> On 16/07/2018 21:31, James Prestwood wrote:
> >
> > Hello,
> >
> > I am a developer for IWD and trying to implement IBSS networks. The
> > initial IBSS_JOIN, 4-way, and setting the keys all works and I am
> > able
> > to connect two stations. The problem is that I am hitting a timeout
> > in
> > the kernel once the connection has succeeded and there are no more
> > frames flowing between stations. I dug around in the kernel and saw
> > there is a 60 second inactivity timeout which is precicely what is
> > happening. After setting the keys 60 seconds go by and I recieve a
> > DEL_STATION (log attached).
> >
> > My question is: is this timeout expected after the station has been
> > added and the keys are set? If so how does one reset this timeout
> > so
> > the connection can remain alive even if no data is being sent?
> > heartbeat of some kind?
> This is not normal, but it isn't your fault. It's more a problem with
> your card
> firmware/driver. What card/driver do you have ?
One side has an Intel 7260 and the other has an Atheros 9462. It seems
to only be the 7260 that is getting the DEL_STATION events after the
timeout. I haven't seen the Ath 9k behave like this.
>
> In IBSS mode, all stations are required to send beacons. The protocol
> is a bit
> complex to arrange that, every 102.4ms, a station is chosen to emit
> the beacon.
>
> Receiving beacons from a station is enough to reset its timer, so
> with a
> properly functioning station, this timer does not expire.
>
> Unfortunately, in the wild, nobody test that IBSS beacons are
> generated, because
> without them, an open IBSS still appear to work...
Hmm, so how does one mitigate this? Manually sending beacons? That
would get messy if some cards do it automatically and some don't.
Something else I forgot to mention/ask in my original email was about
deauthentication. If one station does a LEAVE_IBSS, the other side
doesn't recieve a DEL_STATION until that 60 second inactivity timeout.
If we explicitly leave should the kernel send a deauth automatically? I
know wpa_supplicant explicitly sends a deauth, but I wasn't sure if
this was working around a bug or if it was the intended to be that way.
Thanks,
James
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IBSS timeouts
2018-07-17 15:02 ` Ben Greear
@ 2018-07-17 17:44 ` Nicolas Cavallari
2018-07-17 23:53 ` Ben Greear
0 siblings, 1 reply; 8+ messages in thread
From: Nicolas Cavallari @ 2018-07-17 17:44 UTC (permalink / raw)
To: Ben Greear, James Prestwood, linux-wireless
On 17/07/2018 17:02, Ben Greear wrote:
> On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
>> In IBSS mode, all stations are required to send beacons. The protocol
>> is a bit
>> complex to arrange that, every 102.4ms, a station is chosen to emit
>> the beacon.
>
> I'm not sure this part is correct. In practice, it seems to often
> happen this way,
> but last time I read the spec on this it seems like it is supposed to
> sort of negotiate
> and not have all ibss stations beaconning.
Well, in 802.11-2016, section 11.1.3.5 is clear: "All members of the
IBSS participate in beacon generation."
On each TBTT, each station must wait for a random delay before
transmitting, and the first one to transmit wins.
In theory...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IBSS timeouts
2018-07-17 16:19 ` James Prestwood
@ 2018-07-17 18:05 ` Nicolas Cavallari
0 siblings, 0 replies; 8+ messages in thread
From: Nicolas Cavallari @ 2018-07-17 18:05 UTC (permalink / raw)
To: James Prestwood, linux-wireless
On 17/07/2018 18:19, James Prestwood wrote:
> On Tue, 2018-07-17 at 09:57 +0200, Nicolas Cavallari wrote:
>> This is not normal, but it isn't your fault. It's more a problem with
>> your card
>> firmware/driver. What card/driver do you have ?
>
> One side has an Intel 7260 and the other has an Atheros 9462. It seems
> to only be the 7260 that is getting the DEL_STATION events after the
> timeout. I haven't seen the Ath 9k behave like this.
It's not clear who is seeing the DEL_STATION for which station.
Your trace hints at 6C:71:D9:0D:6E:4B not sending beacons. A wireless
capture should confirm this.
>> In IBSS mode, all stations are required to send beacons. The protocol
>> is a bit
>> complex to arrange that, every 102.4ms, a station is chosen to emit
>> the beacon.
>>
>> Receiving beacons from a station is enough to reset its timer, so
>> with a
>> properly functioning station, this timer does not expire.
>>
>> Unfortunately, in the wild, nobody test that IBSS beacons are
>> generated, because
>> without them, an open IBSS still appear to work...
> Hmm, so how does one mitigate this? Manually sending beacons? That
> would get messy if some cards do it automatically and some don't.
Sending null frames could do the trick, i'm not sure userspace is
allowed to send them with cmd_frame in IBSS mode through.
That, or asking the manufacturer to fix their driver :)
> Something else I forgot to mention/ask in my original email was about
> deauthentication. If one station does a LEAVE_IBSS, the other side
> doesn't recieve a DEL_STATION until that 60 second inactivity timeout.
> If we explicitly leave should the kernel send a deauth automatically? I
> know wpa_supplicant explicitly sends a deauth, but I wasn't sure if
> this was working around a bug or if it was the intended to be that way.
wpa_supplicant sends a deauth when leaving an ibss ? I haven't seen any
code doing that. I don't know why it does that.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IBSS timeouts
2018-07-17 17:44 ` Nicolas Cavallari
@ 2018-07-17 23:53 ` Ben Greear
2018-07-18 7:50 ` Nicolas Cavallari
0 siblings, 1 reply; 8+ messages in thread
From: Ben Greear @ 2018-07-17 23:53 UTC (permalink / raw)
To: Nicolas Cavallari, James Prestwood, linux-wireless
On 07/17/2018 10:44 AM, Nicolas Cavallari wrote:
> On 17/07/2018 17:02, Ben Greear wrote:
>> On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
>>> In IBSS mode, all stations are required to send beacons. The protocol
>>> is a bit
>>> complex to arrange that, every 102.4ms, a station is chosen to emit
>>> the beacon.
>>
>> I'm not sure this part is correct. In practice, it seems to often
>> happen this way,
>> but last time I read the spec on this it seems like it is supposed to
>> sort of negotiate
>> and not have all ibss stations beaconning.
>
> Well, in 802.11-2016, section 11.1.3.5 is clear: "All members of the
> IBSS participate in beacon generation."
>
> On each TBTT, each station must wait for a random delay before
> transmitting, and the first one to transmit wins.
>
> In theory...
>
See 11.1.3.5, section d and e. I think this means that if it receives a beacon while
waiting to transmit one, then it cancels its intent to transmit the beacon. So
while they 'participate', they may not actually generate beacons?
I could be wrong about my interpretation of this however, and I am not sure how it
is actually implemented.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: IBSS timeouts
2018-07-17 23:53 ` Ben Greear
@ 2018-07-18 7:50 ` Nicolas Cavallari
0 siblings, 0 replies; 8+ messages in thread
From: Nicolas Cavallari @ 2018-07-18 7:50 UTC (permalink / raw)
To: Ben Greear, James Prestwood, linux-wireless
On 18/07/2018 01:53, Ben Greear wrote:
> On 07/17/2018 10:44 AM, Nicolas Cavallari wrote:
>> On 17/07/2018 17:02, Ben Greear wrote:
>>> On 07/17/2018 12:57 AM, Nicolas Cavallari wrote:
>>>> In IBSS mode, all stations are required to send beacons. The protocol
>>>> is a bit
>>>> complex to arrange that, every 102.4ms, a station is chosen to emit
>>>> the beacon.
>>>
>>> I'm not sure this part is correct. In practice, it seems to often
>>> happen this way,
>>> but last time I read the spec on this it seems like it is supposed to
>>> sort of negotiate
>>> and not have all ibss stations beaconning.
>>
>> Well, in 802.11-2016, section 11.1.3.5 is clear: "All members of the
>> IBSS participate in beacon generation."
>>
>> On each TBTT, each station must wait for a random delay before
>> transmitting, and the first one to transmit wins.
>>
>> In theory...
>>
>
> See 11.1.3.5, section d and e. I think this means that if it receives a beacon while
> waiting to transmit one, then it cancels its intent to transmit the beacon. So
> while they 'participate', they may not actually generate beacons?
>
> I could be wrong about my interpretation of this however, and I am not sure how it
> is actually implemented.
The a to g sections are done at each TBTT. If another station sent a beacon,
then by section d) we lost and we don't transmit. Since the random number in b)
is generated at each TBTT and uses a uniform distribution, all station have a
chance to win.
Considering a BI of 102.4ms, a timeout of 60s and a 100% idle network, a station
must lose 585 times to start risking being deleted. The probability of that
happening for a given station in a IBSS with N station is (1-1/n)**585. Even
with 50 stations, it's only twice as much as the probability to be struck by
lightning. And it does not account for losses, which will cause more beacon to
be transmitted.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-07-18 8:27 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-16 19:31 IBSS timeouts James Prestwood
2018-07-17 7:57 ` Nicolas Cavallari
2018-07-17 15:02 ` Ben Greear
2018-07-17 17:44 ` Nicolas Cavallari
2018-07-17 23:53 ` Ben Greear
2018-07-18 7:50 ` Nicolas Cavallari
2018-07-17 16:19 ` James Prestwood
2018-07-17 18:05 ` Nicolas Cavallari
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.