loopback: Recover Loopback on Setup when Up but No Address
[framework/connectivity/connman.git] / TODO
1 Background
2 ==========
3
4 - Priority scale: High, Medium and Low
5
6 - Complexity scale: C1, C2, C4 and C8.
7    The complexity scale is exponential, with complexity 1 being the
8    lowest complexity. Complexity is a function of both task 'complexity'
9    and task 'scope'.
10
11 Core
12 ====
13
14 - Session API implementation
15
16    Priority: High
17    Complexity: C4
18    Owner: Daniel Wagner <daniel.wagner@bmw-carit.de>
19    Owner: Samuel Ortiz <sameo@linux.intel.com>
20
21    The session API should provide a connection abstraction in order to
22    prioritize applications network accesses, prevent or allow network
23    and bearer roaming, or provide applications with a way to request
24    for periodic network connections. On-demand connections will be
25    implemented through this API as well.
26    See http://www.mail-archive.com/connman@connman.net/msg01653.html
27
28
29 - WiSPR support
30
31    Priority: Medium
32    Complexity: C4
33    Owner: Marcel Holtmann <marcel@holtmann.org>
34
35    Based on the portal detection parsing results, and provisioned
36    credentials, ConnMan should be able to initiate a WiSPR authentication.
37
38
39 - DNS caching
40
41    Priority: Low
42    Complexity: C4
43
44    A simple initial implementation would see ConnMan's dnsproxy
45    caching the DNS record based on their TTL.
46
47
48 - Power management
49
50    Priority: Medium
51    Complexity: C4
52    Owner: Samuel Ortiz <sameo@linux.intel.com>
53
54    Implement a simple device pm hook that ConnMan's core code would
55    use whenever it decides to put devices in power save mode. Although
56    the kernel runtime power management code should take care of that,
57    not all driver (especially WiFi ones) implement runtime PM hooks.
58
59
60 - IP ranges allocation and check
61
62    Priority: High
63    Complexity: C2
64
65    For both tethering and private networks, but also to detect invalid
66    static IP configurations, we need to have a core IP range layer
67    that manages all currently used IP blocks.
68
69
70 - Personal firewall
71
72    Priority: Low
73    Complexity: C8
74
75    Extend the iptables code and provide a D-Bus API for personal firewalling.
76
77
78 - PACRunner extensions
79
80    Priority: Low
81    Complexity: C4
82
83    Support more URI schemes, support multiple connections, tighter
84    security integration.
85
86
87
88 WiFi
89 ====
90
91 - Ad-Hoc support
92
93    Priority: Medium
94    Complexity: C2
95    Owner: Samuel Ortiz <sameo@linux.intel.com>
96
97
98 - Fast Connect
99
100    Priority: Low
101    Complexity: C4
102    Owner: Samuel Ortiz <sameo@linux.intel.com>
103
104
105 - EAP-AKA/SIM
106
107    Priority: Medium
108    Complexity: C2
109    Owner: Samuel Ortiz <sameo@linux.intel.com>
110
111    This EAP is needed for SIM card based network authentication.
112    ConnMan here plays a minor role: Once wpa_supplicant is set up for
113    starting and EAP-AKA/SIM authentication, it will talk to a SIM card
114    through its pcsc-lite API.
115
116
117 - EAP-FAST
118
119    Priority: Low
120    Complexity: C1
121    Owner: Henri Bragge <henri.bragge@ixonos.com>
122
123
124 - EAP-GTC
125
126    Priority: Low
127    Complexity: C1
128    Owner: Henri Bragge <henri.bragge@ixonos.com>
129
130
131 - WiFi p2p
132
133    Priority: Medium
134    Complexity: C2
135
136
137
138 Bluetooth
139 =========
140
141 - DUN client
142
143    Priority: Low
144    Complexity: C4
145    Owner: Mario Tokarz <mario.tokarz@bmw-carit.de>
146
147
148
149 Cellular
150 ========
151
152
153 VPN
154 ===
155
156 - l2tp support
157
158    Priority: Low
159    Complexity: C2
160    Owner: Mohamed Abbas <mohamed.abbas@intel.com>
161
162
163 - pptp support
164
165    Priority: Low
166    Complexity: C2
167    Owner: Mohamed Abbas <mohamed.abbas@intel.com>
168
169
170 - IPsec
171
172    Priority: Low
173    Complexity: C4
174
175
176 - Split tunnelling
177
178    Priority: Low
179    Complexity: C8
180    Dependencies: Core:Private networks
181
182    The current VPN support puts the VPN interface at the top of the
183    service list, giving VPNs the default route. When doing split
184    tunneling, the system routes packet to the VPN interface for
185    private IPs, while going through the default interface for the rest
186    of the traffic.