Hi Kalle, > >> * connecting state for icon animation > >> > >> We want to animate an icon whenever connman starts connection > >> establishment from offline state. Currently there is no way to do that. > >> One possibility is to add new state "connecting" to Manager interface > >> (which currently supports only "offline" and "online"). > > > > you can do that already be just following the top service in the > > Services list and follow its state changes. > > No, I can't do that. The associated event (or whatever is the first > state) comes too late. I want to start animation immediately when > connection establishment starts.
the transition goes from IDLE -> ASSOCIATION. Why is that too late. I have done this in connman-applet for some simple demo and it just worked fine. We might have to update ConnMan a bit to re-sort the service list when a service gets into ASSOCIATION state and send the signal right away. We have a delay in the service list change signal to not drive the UI insane with updates in busy environments during scanning. However important signals that are caused by real state changes of active service should trigger this right away. So this might be just a bug. > > No need to complicated the Manager interface with a state machine. > > I think it's not that completed. > > > If the UI wants to do some fancy animation then it is better to do that > > based on a per service anyway. And it is up to the UI to summarize these > > if it wants to represent a global state. > > > > Following the top service is needed anyway if you wanna display > > different icons based on the type of connection. > > I have to disagree here. The current interface makes it very easy to > show the icon on the panel, basically you need just follow State and > DefaultTechnology properties. If I need to start following service > states when changing the panel icon it IMHO complicates the UI code > unnecessary. I did mention that these *Technology properties might go away in favor of technology object paths. In there we could have potentially (I am still no 100% convinced) a State property that combines this and is similar to what we have on a per service level. The State property of the manager stays online/offline since that is suppose to be used be 3rd party applications and not the main connection manager UI. > But let's revisit this when I have a proper patch ready, now I only have > a proof of concept code for connman. Send patches. I prefer them actually ;) > >> * secure storage of credentials > >> > >> For some it's an issue that credentials and certificates are stored to a > >> plaintext file and we have to solve this somehow in Ubuntu. I have been > >> playing with an idea of using gnome keyring and connman's agent > >> interface, but I don't have anything concrete yet. > > > > In theory wpa_supplicant needs to be able to talk directly to a global > > certificate storage. > > > > The secure storage is only one piece of the puzzle. The secure memory is > > also needed and secure IPC in between. > > Yes, if one really wants truly secure connection. But I think this is > more about feeling secure than about being really secure. Still this > seems to an important requirement for some people. The current way on how we deal with certificates is actually pretty secure. We don't expect user input and thus it is protected as best as it gets. The local users keyring and a global connection is still not a good thing to match anyway. That is way we don't bother to secure WPA/RSN passphrases or WEP keys. They are insecure to begin with and thus no need for extra protection. They are call pre-shared-keys for a reason ;) > >> * pppoe > >> > >> PPP over ethernet is needed with certain DSL providers. Otherwise user > >> can't connect to Internet, so this is important. > > > > For a netbook this seems to be the absolut wrong target. If you have a > > netbook then you most likely also have a WiFi router with it. Seriously > > I don't see this use case here at all. > > You have a point here, as usual. But I'm getting feedback that this is > important for some users. Sorry man, but I am not buying into this argument. A netbook with a cable to a DSL modem. Sounds wrong on so many levels. Five years ago maybe, but these days, a WiFi router is less than 50 EUR and most DSL providers just integrate it with their DSL modem all into one piece of hardware. > >> * wifi ad-hoc > >> > >> AFAIK there is no support wifi ad-hoc more currently. It's not that > >> widely used, but still good to support. > > > > I don't really see the big use case here. Use Bluetooth PAN for > > Tethering. > > Yeah, but this is something which has worked in earlier releases and > might frustrate some users. Maybe I should lower the priority of this > item. Within ConnMan we never supported this. It would actually mostly work, but from my side there is zero priority on this one. > >> * eap: ttls, leap (?) > >> > >> EAP TTLS is important, for example some universities use it. Not sure > >> about LEAP, though. I guess it's still used, even it's unsecure. > > > > This should be already working. Exception is that we don't expose this > > in the UI, because it is pointless. There is no way for an end user to > > configure this correctly. That is why we do it via provisioning. See the > > documentation for the file format. > > Sorry, I don't follow your reasoning. But I won't start arguing either, > I have to do some research first :) Read doc/config-format.txt. We use it to provision WPA/WPA2 Enterprise and VPN support. > >> * bt dun > >> > >> I have seen that Gustavo is working on adding this to ofono, which is > >> great: > >> > >> http://padovan.org/blog/2010/04/google-summer-of-code-has-come-again/ > > > > I personally prefer to have people using Bluetooth PAN. It is much more > > saner. > > Not all phones support PAN. And, for example, on my N900 BT DUN is so > much easier to setup. Gustavo is looking into this. So it might come eventually anyway, but Bluetooth DUN is so painful and slow compared to PAN. And the iPhone and Palm Pre nicely support PAN :) And a N900 running MeeGo will get eventually PAN since we are planning to integrate Tethering into ConnMan. > >> * separate manual ip and dhcp services for wired > >> > >> Now if user wants to use manual IPs, he needs to always switch between > >> DHCP and manual mode. That's a bit awkward, it would be nice to have an > >> easier way for this. I believe this isn't that important, more like nice > >> to have feature. > > > > And how is this is suppose to work. This is just a stupid idea since > > doing proper location detection on Ethernet is actually pretty hard. So > > just forget about this and let the user switch manually. Everything else > > will drive you insane. > > I meant manually switching between wired connections, not anything > automatic. But point taken. I still don't understand how you might wanna do this or what you mean by it. The user can always manually switch. The DHCP versus static is really not relevant. It is stored on a per service basis. So if you configure your home WiFi to static and your home Ethernet to static, but your work WiFi to DHCP, then ConnMan will remember it. A WiFi service always is unique based on the SSID, only for Ethernet we have no uniqueness. Since the cable you attach does not have an ID ;) > >> * wifi connection based on BSSID > >> > >> When having problems, users might appreaciate if they could force to use > >> certain AP instead of automatic roaming. Not sure how important this is. > > > > We are not going to support this. > > Ok. > > > These requirements look more like a 1:1 copy on how Network Manager is > > doing things. This is not what we are trying to achieve with ConnMan. > > The APIs are use case driven and they hide a lot of details on purpose > > from the end user. The BSSID being one of them. > > I see your point, but then again in ubuntu we have the burden of legacy. > NM has been in use for ever and some users will get frustrated because > an important feature (from their point of view) is suddenly missing. So > it's not that simple for us. > > > Please take one step back and think about your user requirements again. > > A netbook distro is not meant for the data center operation. The users > > are no admins. They are just people that want to get access to the > > Internet. > > Some of our users are very advanced and we need to balance between the > two groups. I am not buying into this and if this was important for any user before then they were doing something stupid. At some point you have to make a clear cut and call legacy crap just crap and ignore it from now on going forward. Btw. there is some magic in ConnMan when it comes to default SSIDs like linksys etc. We treat them individual. So they are per BSSID actually to not accidentally roam with your neighbor. For everything else we expect that roaming is wanted. No exceptions. If you don't want roaming then name your AP accordingly. Regards Marcel _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
