+Background
+==========
- o Support for WPA/WPA2 Enterprise WiFi authentication
+- Priority scale: High, Medium and Low
- With wpa_supplicant the support for WPA/WPA2 Enterprise is already
- present, but it needs properly hooked up. This involves a correct
- security architecture since it uses personalized credentials.
+- 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'.
- o Support for multiple profiles
+Core
+====
- Currently only one active profile (the default profile) is supported.
+- connman_element removal
- o Support for static IPv4 configuration
+ Priority: Low
+ Complexity: C8
- This is in theory possible, but no D-Bus API has been defined on how
- to configure it.
- o Support for interface statistics
+- DHCP lib server
- Information about carrier speed etc. should be exported.
+ Priority: High
+ Complexity: C4
+ Owner: Martin Xu <martin.xu@intel.com>
- o Support for handling RFKILL events
- The RFKILL events are received via the udev infrastructure, but not
- acted upon. Current problem is to assign the event to the correct
- physical device. In case of platform RFKILL switches this is a real
- problem and not solved yet.
+- On demand connection
+ Priority: Medium
+ Complexity: C4
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
+
+ With on demand connection applications get connectivity access
+ simply by trying to reach the network. They don't need to
+ specifically request for a service connection, but ConnMan
+ establishes it on their behalf.
+ This feature counter part is idle disconnect. ConnMan needs to be
+ able to close the on demand established connections by monitoring
+ the link activity. This requires kernel support with e.g. the
+ netfilter IDLETIMER target.
+
+- Avahi-zeroconf
+
+ Priority: Medium
+ Complexity: C4
+
+ The IPv4 Link Local part should be integrated into DHCP-lib.
+
+- OpenVPN
+
+ Priority: Low
+ Complexity: C2
+
+
+- VPNc
+
+ Priority: Low
+ Complexity: C2
+
+
+- iptables wrapper
+
+ Priority: High
+ Complexity: C4
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
+
+ ConnMan needs to be able to set iptables rules and tables for both
+ tethering and on demand connection.
+ The main idea is to define an internal API for talking to the
+ netfilter socket in order to set our tables and rules. Being in
+ sync with the actual iptables library might be problematic.
+ A less elegant solution would be a process based one, that would
+ simply call the iptables executable.
+
+- Tethering
+
+ Priority: Medium
+ Complexity: C8
+ Owner: Marcel Holtmann <marcel@holtmann.org>
+ Dependencies: Core:iptables wrapper
+ Dependencies: Core:DHCP lib server
+
+ Bluetooth, USB and WiFi tethering.
+ The tethering framework would typically allow sharing the 3G data
+ link between WiFi, Bluetooth or USB clients.
+ A bridge needs to be setup and all tethering connections are added
+ to it. A DHCP server and a DNS proxy will be running on the bridge.
+ Then IP forwarding and masquerading will be set between the default
+ service and the bridge interface.
+
+
+- Agent callbacks
+
+ Priority: Medium
+ Complexity: C2
+
+
+- pacrunner
+
+ Priority: High
+ Complexity: C4
+ Owner: Mohamed Abbas <mohamed.abbas@intel.com>
+
+ pacrunner is a standalone daemon that downloads and interpret PAC
+ files through a JavaScript interpreter. Once the interpretation is
+ done, pacrunner is able to associate a proxy with an URL.
+ pacrunner D-Bus interface exports a configuration API for passing
+ it the PAC URLs. It also provide a FindProxyForURL() API for
+ application to know which proxies to use.
+ ConnMan will use pacrunner for both auto and manual proxy
+ configurations. Then applications should talk to pacrunner (through
+ libproxy for example) to find the right proxies.
+ ConnMan will also use the FindProxyForURL() pacruner API for a more
+ stable and accurate online detection code.
+
+
+- Moving DNS proxy code to ConnMan core
+
+ Priority: Medium
+ Complexity: C2
+
+ Supporting DNS proxy or resolv.conf direct editing seems more than
+ plenty as far as resolving is concerned. So the idea is to move the
+ dnsproxy plugin code to ConnMan core and have an additional command
+ line option in case one would like to stick with the current
+ resolver.c code for editing resolv.conf.
+
+
+WiFi
+====
+
+- WPS
+
+ Priority: Low
+ Complexity: C2
+ Dependencies: Core:Agent callbacks
+
+
+- Ad-Hoc support
+
+ Priority: Medium
+ Complexity: C2
+ Dependencies: Core:Avahi-zeroconf
+
+
+- Fast Connect
+
+ Priority: Low
+ Complexity: C4
+ Dependencies: WiFi:libsupplicant
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
+
+
+- EAP-AKA/SIM
+
+ Priority: Medium
+ Complexity: C2
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
+
+ This EAP is needed for SIM card based network authentication.
+ ConnMan here plays a minor role: Once wpa_supplicant is set up for
+ starting and EAP-AKA/SIM authentication, it will talk to a SIM card
+ through its pcsc-lite API.
+
+
+- EAP-Fast
+
+ Priority: Low
+ Complexity: C1
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
+
+
+- EAP-GTC
+
+ Priority: Low
+ Complexity: C1
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
+
+
+- WiFi p2p
+
+ Priority: Medium
+ Complexity: C2
+
+
+- WiFi CRDA setting through 3G country
+
+ Priority: Low
+ Complexity: C2
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
+
+ Setting the 802.11 country based on the 3G MNC/MCC.
+
+
+Bluetooth
+=========
+
+- DUN client
+
+ Priority: Low
+ Complexity: C4
+
+
+- DUN server
+
+ Priority: Low
+ Complexity: C4
projects / framework / connectivity / connman.git / blobdiff