Owner: Samuel Ortiz <sameo@linux.intel.com>
-- IPv4LL
+- Session API implementation
- Priority: Medium
+ Priority: High
Complexity: C4
- Owner: Julien Massot <jmassot@aldebaran-robotics.com>
+ Owner: Daniel Wagner <daniel.wagner@bmw-carit.de>
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
- The IPv4 Link Local support should be integrated into DHCP-lib.
- IPv4LL should be started when DHCP failed, and then DHCP should
- be scheduled for periodic trials.
- Also, there should be no default route going through an IPv4LL
- interface.
+ The session API should provide a connection abstraction in order to
+ prioritize applications network accesses, prevent or allow network
+ and bearer roaming, or provide applications with a way to request
+ for periodic network connections. On-demand connections will be
+ implemented through this API as well.
+ See http://www.mail-archive.com/connman@connman.net/msg01653.html
-- VPNc
+- Provisioning D-Bus API
- Priority: Low
+ Priority: Medium
Complexity: C2
+ Owner: Henri Bragge <henri.bragge@ixonos.com>
+
+ The current service provisioning lacks a D-Bus interface for modifying
+ existing configurations.
-- Agent callbacks
+- WiSPR support
Priority: Medium
- Complexity: C2
- Owner: Patrik Flykt <patrik.flykt@nokia.com>
+ Complexity: C4
+ Owner: Marcel Holtmann <marcel@holtmann.org>
- Implement Agent API according to doc/agent-api.txt
+ Based on the portal detection parsing results, and provisioned
+ credentials, ConnMan should be able to initiate a WiSPR authentication.
-- Moving DNS proxy code to ConnMan core
+- DNS caching
- Priority: Medium
- Complexity: C2
+ Priority: Low
+ Complexity: C4
+
+ A simple initial implementation would see ConnMan's dnsproxy
+ caching the DNS record based on their TTL.
- 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.
+- Power management
-- WiFi tethering
Priority: Medium
Complexity: C4
+ Owner: Samuel Ortiz <sameo@linux.intel.com>
- WiFi tethering should be done through an extended wpa_supplicant
- D-Bus API, as STA and AP modes are typically mutually exclusive.
+ Implement a simple device pm hook that ConnMan's core code would
+ use whenever it decides to put devices in power save mode. Although
+ the kernel runtime power management code should take care of that,
+ not all driver (especially WiFi ones) implement runtime PM hooks.
-- Session API implementation
+- IPv6 gateway handling
- Priority: High
+ Priority: Medium
Complexity: C4
- Owner: Daniel Wagner <daniel.wagner@bmw-carit.de>
- Owner: Samuel Ortiz <sameo@linux.intel.com>
- The session API should provide a connection abstraction in order to
- prioritize applications network accesses, prevent or allow network
- and bearer roaming, or provide applications with a way to request
- for periodic network connections. On-demand connections will be
- implemented through this API as well.
- See http://www.mail-archive.com/connman@connman.net/msg01653.html
+ We should be able to switch between IPv6 only services and thus
+ change the default IPv6 gateway on the fly. For that we need to
+ improve the connection.c code to properly handle IPv6 gateways.
-- Provisioning D-Bus API
+- IP ranges allocation and check
- Priority: Medium
+ Priority: High
Complexity: C2
- Owner: Lucio Maciel <lucio.maciel@hp.com>
- The current service provisioning lacks inotify support for adding
- new provision files on the fly, and a D-Bus interface for modifying
- existing ones.
+ For both tethering and private networks, but also to detect invalid
+ static IP configurations, we need to have a core IP range layer
+ that manages all currently used IP blocks.
-- WiSPR support
+- Personal firewall
- Priority: Medium
- Complexity: C4
- Owner: Marcel Holtmann <marcel@holtmann.org>
+ Priority: Low
+ Complexity: C8
- Based on the portal detection parsing results, and provisioned
- credentials, ConnMan should be able to initiate a WiSPR authentication.
+ Extend the iptables code and provide a D-Bus API for personal firewalling.
-- IPv6 enhancements
+- PACRunner extensions
- Priority: High
- Complexity: C8
- Owner: Jukka Rissanen <jukka.rissanen@nokia.com>
+ Priority: Low
+ Complexity: C4
- Support IPv6 only networks so that system can go online even if
- there is no IPv4 address. Also support more than one IPv6 address
- in one device so that the addresses are reported correctly via
- dbus interface. The autoconf IPv6 addresses need also some tweaking
- so that system will go online properly.
+ Support more URI schemes, support multiple connections, tighter
+ security integration.
-WiFi
-====
+- Private networks
-- WPS
+ Priority: Medium
+ Complexity: C4
+ Owner: Guillaume Zajac <guillaume.zajac@linux.intel.com>
+
+ The private networks D-Bus API should provide applications with a
+ TUN interface linked to a reserved private IP range.
+ oFono DUN forwarding will use a private network for giving DUN
+ clients access to the default service connectivity.
- Priority: Low
- Complexity: C2
- Dependencies: Core:Agent callbacks
- Owner: Tomasz Bursztyka <tomasz.bursztyka@nokia.com>
- Support in gsupplicant and connman core (network/service).
+WiFi
+====
- Ad-Hoc support
Priority: Medium
Complexity: C2
- Dependencies: Core:IPv4LL
Owner: Samuel Ortiz <sameo@linux.intel.com>
through its pcsc-lite API.
-- EAP-Fast
+- EAP-FAST
Priority: Low
Complexity: C1
+ Owner: Henri Bragge <henri.bragge@ixonos.com>
- EAP-GTC
Priority: Low
Complexity: C1
+ Owner: Henri Bragge <henri.bragge@ixonos.com>
- WiFi p2p
Complexity: C2
-- WiFi CRDA setting through 3G country
+
+Bluetooth
+=========
+
+- DUN client
+
+ Priority: Low
+ Complexity: C4
+
+
+
+Cellular
+========
+
+- IPv6 and IPv6v4 cellular data connection
Priority: Medium
Complexity: C2
Owner: Samuel Ortiz <sameo@linux.intel.com>
- Setting the 802.11 country based on the 3G MNC/MCC.
+ Support IPv6 and dual stack cellular data connections.
+ oFono already supports it and provide an extensive D-Bus API for it.
-Bluetooth
-=========
-- DUN client
+VPN
+===
+
+- l2tp support
Priority: Low
- Complexity: C4
+ Complexity: C2
+ Owner: Mohamed Abbas <mohamed.abbas@intel.com>
-- DUN server
+- pptp support
+
+ Priority: Low
+ Complexity: C2
+ Owner: Mohamed Abbas <mohamed.abbas@intel.com>
+
+
+- IPsec
Priority: Low
Complexity: C4
+
+
+- Split tunnelling
+
+ Priority: Low
+ Complexity: C8
+ Dependencies: Core:Private networks
+
+ The current VPN support puts the VPN interface at the top of the
+ service list, giving VPNs the default route. When doing split
+ tunneling, the system routes packet to the VPN interface for
+ private IPs, while going through the default interface for the rest
+ of the traffic.
projects / framework / connectivity / connman.git / blobdiff