aboutsummaryrefslogtreecommitdiffstats
path: root/TODO
blob: b3a03bd6232da566d4c05c7a3258199ff1454cbf (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
Background
==========

- Priority scale: High, Medium and Low

- Complexity scale: C1, C2, C4 and C8.  The complexity scale is exponential,
  with complexity 1 being the lowest complexity.  Complexity is a function
  of both task 'complexity' and task 'scope'.

  The general rule of thumb is that a complexity 1 task should take 1-2 weeks
  for a person very familiar with the codebase.  Higher complexity tasks
  require more time and have higher uncertainty.

  Higher complexity tasks should be refined into several lower complexity tasks
  once the task is better understood.


mac80211_hwsim
==============

- Add support for HWSIM_CMD_SET_RADIO command

  To allow modifying an existing radio, add the HWSIM_CMD_SET_RADIO.  The
  first possible feature should be to emulate the hardware RFKILL switch.

  It might be required to add a HWSIM_ATTR_RADIO_HW_RFKILL attribute flag
  to the HWSIM_CMD_NEW_RADIO to enable virtual radios with a hardware
  level RFKILL switch.

  Priority: Medium
  Complexity: C1

- Allow configuration of MAC address or list of MAC addresses

  The radios are auto-generating a fake MAC address.  It would be useful
  to allow specifying a MAC address to be used.  In certain cases it might
  be also useful to provide a list of MAC addresses so that for example
  with secondary interfaces these can be used.

  Priority: Low
  Complexity: C2

- Move mac80211_hwsim.h header file to UAPI includes

  The mac80211_hwsim.h is the public API description of this netlink
  interface and thus it should be provided via UAPI includes.

  For this work work the mac80211_hwsim.h header needs to be modified
  so that it also compiles from userspace.  At the moment it throws
  errors.  And it needs to become part of the UAPI headers of the
  Linux kernel.

  In addition it should provide HWSIM_GENL_NAME that provides the
  generic netlink "MAC82011_HWSIM" family string.

  Priority: Low
  Complexity: C1

- Provide kernel option to allow defining the number of initial radios

  By default the mac80211_hwsim modules creates 2 radios by default unless
  it is overwritten with the radios=x module parameter.

  To allow loading the mac80211_hwsim by default and even with accidental
  loading of the module, it would be good to provide a kernel configuration
  option that allows changing the default value here.

  For our testing we want to load mac80211_hwsim without any radios. Maybe
  this should be the default for the new kernel option.

  If the default of initial radios can be changed to zero, then it is also
  possible to add MODULE_ALIAS_GENL_FAMILY to support auto-loading of
  the mac80211_hwsim kernel module.

  Priority: Low
  Complexity: C1

- New configuration options for radios

  At the moment the radios created are all equal and feature rich.  However
  for testing we want to create radios with different emulated hardware
  capabilities.  Provide new attributes or flags that allow enabling or
  disabling certain mac80211 features.

  For example AP mode, P2P mode, number of interface combinations, TDLS
  support, number of Scan SSIDs, supported ciphers and so on.

  Priority: Low
  Complexity: C2


Wireless monitor
================

- Add support for PACKET_RECV_OUTPUT socket option of AF_PACKET

  Instead of having to switch every interface manually into promiscuous
  mode, it would be useful to set PACKET_RECV_OUTPUT to receive also
  the traffic that leaves the system.

  This would make tracing PAE / EAPoL traffic easy and provides better
  sniffing capabilities.

  Unfortunately, PACKET_RECV_OUTPUT logic is not implemented at all in
  the kernel. So, first implement it in the kernel, and then use it in
  nlmon.c as a set_sockopt option.

  Priority: Low
  Complexity: C8

- Subscribe to all nl80211 multicast groups at startup

  It seems the nlmon packets are limited to actual subscribed mutlicast
  groups.  To get a complete picture of all the nl80211 commands and
  events, it is required that iwmon adds membership to all multicast
  groups that the nl80211 lists.

  This means that the netlink socket used for resolving nl80211 family
  name needs to be kept open and actively processed since it will also
  receive these multicast events.  However the event itself can be dropped
  since the one from nlmon with the proper kernel level timestamps should
  be taken into account.

  An alternative is to fix the netlink_deliver_tap() function in the
  kernel netlink layer to not be affected by the broadcast filtering.

  Priority: Medium
  Complexity: C1

- Print the 'group' of the decoded message

  Whenever an event / message is received, iwmon should print the genl
  group of the message (e.g. mlme, scan, config, regulatory).  This will
  make it easier to add handling of such events / commands inside iwd.

  Priority: Medium
  Complexity: C1


Wireless simulator
==================

- Add support for builtin wireless access point emulator

  When creating a pair of mac80211_hwsim radios, allow one to operate as
  access point.  The hwsim utility will emulate the access point on the
  second interface for as long as it is running.  Which means that from
  the first interface it is possible to scan and connect to this access
  point using standard wireless tools (including iwd and iwctl).

  Code for the AP mode can be shared from iwd feature for access point
  operation once that has been implemented.

  Priority: Medium
  Complexity: C8


Wireless daemon
===============

- Add unit test data with 2nd RSNE in Authenticator 3/4 message

  The specification allows the AP to send a second RSN element in its 4-way
  handshake message 3/4.  Find some test data for this case and create a unit
  test case.

  Priority: Low
  Complexity: C1

- Handle "Use group cipher suite" option for pairwise ciphers

  If the AP specifies "Use group cipher suite" as its only pairwise suite, then
  handle this appropriately inside EAPoL handshaking code.  The install_gtk
  callback might need to be modified to handle this case.

  Priority: Low
  Complexity: C1

- Add support for PMK Caching from 802.11-2007.  This is sometimes referred to
  as "fast, secure roam back".  Essentially the client caches PMKIDs generated
  when connecting to various APs.  If the client roams back to an AP that has
  already been connected to, and the PMK is cached by both, then the 802.1X
  exchange can be skipped.

  Priority: Low
  Complexity: C4

- Add support for Opportunistic Key Caching (OKC).  This is not defined by
  any 802.11 standards, but is made available by major vendors such as Cisco
  and Microsoft.

  Priority: Low
  Complexity: C4

- Add support for Automatic Power Save Delivery (APSD).  This includes
  scheduled (s-APSD) and unscheduled (u-APSD).  This will require rudimentary
  support of WMM protocol.  This feature was introduced in 802.11e.

  Priority: Low
  Complexity: C4

- Add support for Wireless Network Management (WNM) from 802.11v.  Parts of
  this are needed for Passpoint support.

  Priority: Low
  Complexity: C8

- Add support for Tunneled Direct Link Setup (TDLS) from 802.11z.

  Priority: Medium
  Complexity: C8

- Add support for WiFi P2P.

  iwd will require a new P2P D-Bus API to be exposed in order for clients to
  manage P2P connections.  P2P specific logic for device management and
  switching between P2P and STA/AP modes for a particular interface will be
  required.

  Priority: Medium
  Complexity: C8

- Add support for EAP-LEAP.  This is a Cisco proprietary EAP method that is
  quite widespread.

  Priority: Medium
  Complexity: C4

- Add support for EAP-OTP.  OTP stands for 'One Time Password' and can be
  found in RFC3784.

  Priority: Low
  Complexity: C4

- Implement Enrollee Session Overlap Detection after WSC Protocol Run

  WSC Best Practices v2.0.1, Section 3.15 describes an enhacement to detect
  PBC session overlaps.  The Enrollee is asked to perform an extra scan without
  the PBC request in the ProbeRequest frames after EAP-WSC completes
  successfully.  If another AP in PBC mode is found, then a SessionOverlap
  error should be reported to the user.

  Priority: Low
  Complexity: C2

- DPP Support

  Device Provisioning Protocol is a new specification from WiFi Alliance.
  This allows devices to be provisioned, typically via a QR code.

  Priority: Low
  Complexity: C8

- Support receiving OCE FILS Discovery Frames

  When operating in station mode, we should support receiving of FILS
  Discovery frames.

  Priority: Medium
  Complexity: C2

- Support OCE Reduced Neighbor Reports

  OCE specifies that the AP can send Reduced Neighbor Reports if the STA sets
  the FILS Capability bit to true.  Reduced Neighbor Reports can be used to
  replace the need to scan, particularly if the AP reports RNR Completeness
  attribute.  RNRs can be sent in Probe Responses, Beacons and FILS Discovery
  frames.

  Priority: Medium
  Complexity: C2

- Support OCE Scanning

  OCE Specifies various scanning optimizations.  When OCE scanning is enabled,
  (e.g. when OCE APs are detected, or via some other means), enable the
  relevant optimizations if driver support is present:
    NL80211_SCAN_FLAG_FILS_MAX_CHANNEL_TIME
    NL80211_SCAN_FLAG_ACCEPT_BCAST_PROBE_RESP
    NL80211_SCAN_FLAG_OCE_PROBE_REQ_HIGH_TX_RATE
    NL80211_SCAN_FLAG_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION

  Priority: Medium
  Complexity: C2

- Support OCE mutually non-overlapping channels optimization.

  OCE Section 3.10 mandates that the STA should scan channels 1, 6 and 11 in
  the 2.4GHz band first, unless it expects to find an AP on a different
  channel.

  Priority: Low
  Complexity: C1

- Support OCE RSSI-based Association Rejection attribute

  OCE APs can reject a Re(Association) request with Status Code 34 and
  optionally include RSSI-based Association Rejection attribute.  This
  attribute can either contain a time delay information or an RSSI delta
  value.  If the time delay info is included, make sure that this particular
  BSS is blacklisted only for the duration of the delay.  If RSSI delta
  is included, make sure to handle that as well.

  Priority: Low
  Complexity: C1

- Support additional metrics sent by OCE APs

  OCE APs can send BSS Load and Extended BSS Load IEs.  iwd already takes the
  BSS Load IE into account for ranking purposes.  If Extended BSS Load IE is
  present, it should be taken into account as well.

  Additionally, Estimated Service Parameter (ESP) and Reduced WAN Metrics
  should be taken into account if available.

  Priority: Low
  Complexity: C4

- Support OCE FILS Indication element

  OCE APs that support FILS authentication can notify which domains they
  support.  This information is made available using the FILS Indication
  element as part of the Probe Response and Beacon frames.

  Priority: Low
  Complexity: C4

- Support OCE Higher Layer Protocol Encapsulation

  This can be used to obtain DHCPv4 address faster.

  Priority: Medium
  Complexity: C4


Network Configuration
=====================

- Support elements of RFC4436 - DNAv4

  Assumption: netconfig is able to save lease information for networks that
  have been joined previously and does not release the lease when the network
  is left temporarily.

  Attempt to re-assume the lease via methods described in DNAv4 if we attempt
  to rejoin a network and the lease has not expired yet.

  Priority: Low
  Complexity: C4