mirror of
				https://git.kernel.org/pub/scm/network/wireless/iwd.git
				synced 2025-11-04 00:37:22 +01:00 
			
		
		
		
	
		
			
				
	
	
		
			393 lines
		
	
	
		
			13 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			393 lines
		
	
	
		
			13 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
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
 | 
						|
 | 
						|
 | 
						|
cfg80211 / nl80211
 | 
						|
==================
 | 
						|
 | 
						|
- Disconnect from network / station when client crashes
 | 
						|
 | 
						|
  When associating or connecting to a network, it should be possible to
 | 
						|
  bind this transaction to a specific netlink client.  So that in case
 | 
						|
  this client terminates without, any connection will be also terminated.
 | 
						|
 | 
						|
  This should affect NL80211_CMD_ASSOCIATE and NL80211_CMD_CONNECT.  It
 | 
						|
  seems that this is not needed for NL80211_CMD_AUTHENTICATE since that
 | 
						|
  command will eventually time out, but it might be a good idea to even
 | 
						|
  support it there.
 | 
						|
 | 
						|
  Maybe a new attribute similar to NL80211_ATTR_IFACE_SOCKET_OWNER should
 | 
						|
  be used for this behavior.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C4
 | 
						|
 | 
						|
- Add missing support for NL80211_CMD_GET_INTERFACE filtering
 | 
						|
 | 
						|
  The NL80211_CMD_GET_INTERFACE command description indicates that you
 | 
						|
  can filter results based NL80211_ATTR_WIPHY.  This feature has never
 | 
						|
  been implemented.
 | 
						|
 | 
						|
  Either remove that feature from the description since it does not exist
 | 
						|
  or actually implemented the filtering on wiphy.  Johannes indicated that
 | 
						|
  fixing the description might be the better approach.  If the feature is
 | 
						|
  easy to add, then it should be added.  However if filtering on wiphy is
 | 
						|
  a rather complicated task, then better just update the description to
 | 
						|
  match the reality.
 | 
						|
 | 
						|
  Priority: Low
 | 
						|
  Complexity: C2
 | 
						|
 | 
						|
 | 
						|
Wireless monitor
 | 
						|
================
 | 
						|
 | 
						|
- Decode HT Capabilities IE element
 | 
						|
 | 
						|
  HT Capabilities element has ID 45.
 | 
						|
 | 
						|
  Priority: Medium
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
- Decode HT Operation IE element
 | 
						|
 | 
						|
  HT Operation element has ID 61.
 | 
						|
 | 
						|
  Priority: Medium
 | 
						|
  Complexity: C1
 | 
						|
  Owner: Patrik Flykt <patrik.flykt@linux.intel.com>
 | 
						|
 | 
						|
- 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
 | 
						|
 | 
						|
- Add support for writing PCAP files
 | 
						|
 | 
						|
  The new -w <file> option should allow for writing PCAP files with the
 | 
						|
  Linux SLL link type.
 | 
						|
 | 
						|
  When creating PCAP files using tcpdump a lot of extra information from
 | 
						|
  all netlink sockets are written.  This write support should only write
 | 
						|
  the information related to nl80211.  However parts from the generic
 | 
						|
  netlink control channel from resolving the nl80211 family name must
 | 
						|
  be included as well.
 | 
						|
 | 
						|
  It might be also beneficial to include RTNL messages related to the
 | 
						|
  wireless network interfaces.  Currently these are all filtered out.
 | 
						|
 | 
						|
  Priority: Medium
 | 
						|
  Complexity: C2
 | 
						|
 | 
						|
- Decode the RSNE field
 | 
						|
 | 
						|
  Properly decode and display the RSNE field.  This is particularly important
 | 
						|
  to properly analyze scan results and improve the scan categorization
 | 
						|
  functionality.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  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
 | 
						|
===============
 | 
						|
 | 
						|
- Building 802.11 authentications management frames
 | 
						|
 | 
						|
  The other way round, provide a core API to encode an authentication
 | 
						|
  or deauthentication frame from a generic structure representing the
 | 
						|
  MPDU.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C2
 | 
						|
  Owner: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
 | 
						|
 | 
						|
- Handle the relevant logic of the authentication management frames
 | 
						|
 | 
						|
  When an authentication management frame is received, such frame needs
 | 
						|
  to be understood and handled properly.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C2
 | 
						|
 | 
						|
- Add support for EAP based authentication and key generation
 | 
						|
 | 
						|
  Provide full EAP support for enterprise wireless.  However it should be
 | 
						|
  possible to build wireless daemon without EAP support.
 | 
						|
 | 
						|
  It is also intended that this EAP code can be utilized as shared library
 | 
						|
  and be beneficial for systemd-networkd for wired authentication.
 | 
						|
 | 
						|
  Priority: Low
 | 
						|
  Complexity: C8
 | 
						|
 | 
						|
- Create a document to doc describing general architecture and relation
 | 
						|
  between different objects.
 | 
						|
 | 
						|
  Current understanding is that diffrent relation between elements
 | 
						|
  looks probably like this:
 | 
						|
      Manager->Wiphy->NetDevice->AvailableNetwork
 | 
						|
 | 
						|
  Wiphy is the actual physical device, NetDevice is the network interface
 | 
						|
  and AvailableNetwork is {SSID, security} combo. Each network can have
 | 
						|
  a list of BSSs.
 | 
						|
  Consider also multi-wifi device scenarios. If user has multiple USB
 | 
						|
  WiFi dongles and switches between those cards, all previously configured
 | 
						|
  networks should still be available.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C2
 | 
						|
 | 
						|
- Implement D-Bus API to Disconnect from an AP
 | 
						|
 | 
						|
  If we are currently connected to an AP, the Disconnect() method call should
 | 
						|
  trigger a disassociation.  If we are in the process of connecting to an AP,
 | 
						|
  the connection attempt should be aborted and a disassociation procedure
 | 
						|
  should be triggered.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C2
 | 
						|
 | 
						|
- Centralize scanning logic and handling into scan.c.
 | 
						|
 | 
						|
  There can be passive, active, listening (P2P) scanning to handle.
 | 
						|
  We need to handle background scan for roaming. Also scheduled scan
 | 
						|
  might need to be simulated when hw does not support it.
 | 
						|
  All scanning operations should be cancellable.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C4
 | 
						|
 | 
						|
- Add utility to create netlink REKEY_DATA attributes
 | 
						|
 | 
						|
  The REKEY_DATA needs to be uploaded to the driver so that if re-keying is
 | 
						|
  triggered by the AP, the TK is updated properly.  Additionally, helper
 | 
						|
  function to send NL80211_CMD_SET_REKEY_OFFLOAD command is required.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
- React to NL80211_CMD_SET_REKEY_OFFLOAD events
 | 
						|
 | 
						|
  This command can be sent to userspace whenever a re-key transaction has
 | 
						|
  occurred.  The information contains the Replay Counter.  The Replay Counter
 | 
						|
  used by iwd needs to be updated with the new value.
 | 
						|
 | 
						|
  Priority: Medium
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
- Add utilities to set Transient Key into the driver
 | 
						|
 | 
						|
  Once the 4-Way handshake is complete and the TK is generated, it must be sent
 | 
						|
  to the kernel so that normal traffic can be encrypted and decrypted
 | 
						|
  appropriately.  This seems to be accomplished by NL80211_CMD_NEW_KEY
 | 
						|
  and NL80211_CMD_SET_KEY commands.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
- RSN IE Generation for WPA2 Association
 | 
						|
 | 
						|
  When connecting to a WPA2 Network, we must provide an RSN IE that describes
 | 
						|
  our ciphering capabilities.  For WPA2 this generally means CCMP as the
 | 
						|
  pairwise cipher.  The same RSN IE is sent during step 2 of the 4-way
 | 
						|
  handshake to the Authenticator (AP).  The AP will match RSN IEs received
 | 
						|
  in the Association frame and the EAPoL 2/4 frame.  The RSN IE is included
 | 
						|
  as part of the Netlink Association Request.
 | 
						|
 | 
						|
  Information Elements: len 22
 | 
						|
  Tag 48: len 20
 | 
						|
    01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f  ................
 | 
						|
    ac 02 00 00                                      ....
 | 
						|
  Cipher Suites Pairwise: len 4
 | 
						|
  CCMP (0x000fac04)
 | 
						|
  Cipher Suite Group: CCMP (0x000fac04)
 | 
						|
  Control Port: true
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
- Take hardware capabilities into account for RSNE generation
 | 
						|
 | 
						|
  When generating RSNE, take hardware capabilities into account.
 | 
						|
 | 
						|
  Priority: Medium
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
- Parse & utilize the 2nd RSNE element in Step 3/4 of the 4-way Handshake
 | 
						|
 | 
						|
  EAPoL Key Data can contain two RSN elements.  The second element contains
 | 
						|
  ciphering settings which were mandated by the AP and could be different
 | 
						|
  from settings we provided.  We should parse the 2nd RSNE and determine
 | 
						|
  whether the settings are acceptable.  If so, these settings should be
 | 
						|
  utilized for the established connection.  Otherwise, connection establishment
 | 
						|
  should be aborted.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
- Extract GTK from Key Data in Step 3/4 of the 4-way Handshake
 | 
						|
 | 
						|
  GTK is carried inside a KDE.  For KDE format, refer to 802.11 Figure 11-30.
 | 
						|
  The GTK KDE format is given in Figure 11-31.  Care must be taken to make sure
 | 
						|
  that packets that contain the GTK KDE are encrypted.  If the packet is
 | 
						|
  not encrypted, it should be silently dropped.
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
- Add unit test for each of the mpdu management frame type
 | 
						|
 | 
						|
  Currently, only authentication and deauthentication frames have
 | 
						|
  proper unit test. Update unit/test-mpdu.c to handle other frames as
 | 
						|
  well.
 | 
						|
 | 
						|
  Priority: Medium
 | 
						|
  Complexity: C1
 | 
						|
 | 
						|
 | 
						|
Client
 | 
						|
======
 | 
						|
 | 
						|
- Implement dbus-based command-line client for iwd using ell supporting at least
 | 
						|
  the following: Scanning, Connect, Disconnect and agent functionality
 | 
						|
 | 
						|
  Priority: High
 | 
						|
  Complexity: C2
 | 
						|
 |