X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=TODO;h=75022f65bafbd7a71921cadcf177318e8b40b4bc;hb=1e7bd9934c4889efcae40d47a8d079cb9bd1e537;hp=075bc5acbf4cf2a5bc2544f5601061b3d35e0ee4;hpb=74e4040bdcbd5f0ad166b70453835b9ee17ae494;p=framework%2Fconnectivity%2Fconnman.git diff --git a/TODO b/TODO index 075bc5a..75022f6 100644 --- a/TODO +++ b/TODO @@ -18,105 +18,119 @@ Core Owner: Samuel Ortiz -- IPv4LL +- Session API implementation - Priority: Medium + Priority: High Complexity: C4 - Owner: Julien Massot + Owner: Daniel Wagner + Owner: Samuel Ortiz - 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 + + The current service provisioning lacks a D-Bus interface for modifying + existing configurations. -- Agent callbacks +- WiSPR support Priority: Medium - Complexity: C2 - Owner: Patrik Flykt + Complexity: C4 + Owner: Marcel Holtmann - 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 - 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 - Owner: Samuel Ortiz - 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 - 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 + Priority: Low + Complexity: C8 + + Extend the iptables code and provide a D-Bus API for personal firewalling. + + +- PACRunner extensions + + Priority: Low Complexity: C4 - Owner: Marcel Holtmann - Based on the portal detection parsing results, and provisioned - credentials, ConnMan should be able to initiate a WiSPR authentication. + Support more URI schemes, support multiple connections, tighter + security integration. -WiFi -==== +- Private networks + + Priority: Medium + Complexity: C4 + Owner: Guillaume Zajac + + 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. -- WPS - Priority: Low - Complexity: C2 - Dependencies: Core:Agent callbacks +WiFi +==== - Ad-Hoc support Priority: Medium Complexity: C2 - Dependencies: Core:IPv4LL Owner: Samuel Ortiz @@ -139,16 +153,18 @@ WiFi through its pcsc-lite API. -- EAP-Fast +- EAP-FAST Priority: Low Complexity: C1 + Owner: Henri Bragge - EAP-GTC Priority: Low Complexity: C1 + Owner: Henri Bragge - WiFi p2p @@ -157,25 +173,62 @@ WiFi 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 - 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 -- DUN server +- pptp support + + Priority: Low + Complexity: C2 + Owner: Mohamed Abbas + + +- 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.