**** BEGIN LOGGING AT Tue Nov 10 02:59:57 2009
Nov 10 04:53:02 <martin_office> denkenz, holtmann ping
Nov 10 15:36:05 <denkenz> holtmann, martin_office: I'm here now
**** BEGIN LOGGING AT Tue Nov 10 16:04:06 2009
Nov 10 16:42:10 <holtmann> denkenz: Martin will be sleeping.
Nov 10 17:07:22 <holtmann> denkenz: You were still on #connman and followed what Martin had commented about his patches?
Nov 10 17:31:30 <denkenz> holtmann: Yes, but I don't really understand his points
Nov 10 17:32:11 <denkenz> holtmann: The context in oFono can exist without having an interface
Nov 10 17:36:27 <denkenz> holtmann: So connman plugin has to wait until activated is true and grab the interface then
Nov 10 17:40:32 <holtmann> It is kinda chicken and egg problem. We have to have the interface to create connman_network. Otherwise it doesn't show up. If it doesn't show up, we can't click connect. Neither do auto-connect.
Nov 10 17:41:03 <denkenz> Problem is, I might have n contexts defined
Nov 10 17:41:08 <holtmann> We can work around it, but I am not sure if we really want that. However a lot of times we only know at attach time which interface name we get.
Nov 10 17:41:10 <denkenz> And only 1 active at a time
Nov 10 17:41:14 <holtmann> s/attach/activate/
Nov 10 17:41:29 <holtmann> We gonna map each context to its own network.
Nov 10 17:41:41 <holtmann> So if you configure two with "internet" they both will show up.
Nov 10 17:41:51 <denkenz> That's fine I think
Nov 10 17:42:01 <denkenz> However, the device might be "shared" between them
Nov 10 17:42:19 <denkenz> And with ppp, we don't know what the device is until we create the tun device
Nov 10 17:44:10 <denkenz> holtmann: Also consider that we might have weird setup where we can do high-speed on one port and ppp on another
Nov 10 17:44:17 <holtmann> Not sure if the interface will be shared actually. We have no clue at all, but yes, with PPP we only get the interface name when activated.
Nov 10 17:44:31 <denkenz> The first context will get the high-speed, the second will get ppp, but unknown until runtime
Nov 10 17:45:04 <denkenz> holtmann: It has to be shared
Nov 10 17:45:09 <holtmann> I think the newer MBM support multiple high-speed interfaces. Our kernel driver is just too stupid to recognize them.
Nov 10 17:45:15 <denkenz> holtmann: If we have internet and visual voicemail for instance
Nov 10 17:45:36 <denkenz> holtmann: Sure, but HSO devices only support 1, correct?
Nov 10 17:46:03 <holtmann> The current data cards yes, I am not sure about their voice capable cards. I think they have some firmware that can do more than one.
Nov 10 17:46:31 <denkenz> But that's the issue, you can have 200 contexts defined
Nov 10 17:46:38 <denkenz> But only up to 11 active
Nov 10 17:46:48 <denkenz> More like 1-3 on most devices
Nov 10 17:47:02 <holtmann> Never the less, I think we just have to listen to the PropertyChanged for Interface and deal with the fact that we have to set the ifindex later. Maybe needs some fixing in ConnMan.
Nov 10 17:47:40 <holtmann> We will have to figure out the limits of these cards eventually. I really have no clue what is possible with certain hardware.
Nov 10 17:48:00 <denkenz> So that's my point
Nov 10 17:48:12 <denkenz> You either have to make connman deal with this, or we have to redesign the GPRS API
Nov 10 17:49:07 <holtmann> Personally I don't like it. However if we assume that we always send PropertyChanged("Interface", ...) before PropertyChanged("Active", true) we should be good.
Nov 10 17:49:30 <holtmann> Otherwise we are in race condition hell and do round-trips like crazy.
Nov 10 17:49:59 <denkenz> We could make 'Active' a readonly property
Nov 10 17:50:08 <denkenz> and have a proper Activate/Deactivate methods
Nov 10 17:50:17 <denkenz> Activate might event return the 'interface'
Nov 10 17:50:43 <holtmann> Having Activate and Deactive method seems better right now.
Nov 10 17:51:11 <holtmann> Besides the interface we also need the IP method (DHCP or static) and the address details.
Nov 10 17:51:27 <denkenz> Yeah, we need to discuss that
Nov 10 17:51:47 <denkenz> We never documented how we do address selection
Nov 10 17:52:41 <holtmann> Actually thinking about it, we might wanna do an Activated signal that contains a dict with all the details.
Nov 10 17:53:20 <denkenz> and break our PropertyChanged rule?
Nov 10 17:53:36 <denkenz> Or not have IP/Gateway as properties at all?
Nov 10 17:53:52 <holtmann> We might not wanna have these as properties at all in this case.
Nov 10 17:53:59 <holtmann> Including interface.
Nov 10 17:54:25 <holtmann> Or we do dict of dict.
Nov 10 17:54:41 <denkenz> dict of dict?
Nov 10 17:54:46 <denkenz> dict of variant more like
Nov 10 17:55:14 <holtmann> Someting like PropertyChanged("Connection", { "Interface": "ppp0", "Address": "192.168.0.1", ... } )
Nov 10 17:55:24 <holtmann> Or call it "Settings".
Nov 10 17:56:01 <denkenz> Yuck, glib-dbus weenies will hate us
Nov 10 17:56:09 <holtmann> Actually I like that one more. This way you only listen to one signal.
Nov 10 17:56:23 <holtmann> And you get all the required details at once.
Nov 10 17:57:03 <denkenz> yes, but you do realize that we 'Settings' is a dict of variants
Nov 10 17:57:12 <holtmann> So we can send out "Active" when we get it. Then ConnMan can move over to CONFIGURATION state, then gets the "Settings" details, configures the interface and is READY.
Nov 10 17:57:37 <denkenz> PropertiesChanged is a variant too
Nov 10 17:57:43 <denkenz> hence we get nested variants, fun :)
Nov 10 17:57:46 <holtmann> It is a a{sa{sv}}
Nov 10 17:58:11 <denkenz> we don't need a nested dict
Nov 10 17:58:19 <denkenz> just a{sv}
Nov 10 17:58:21 <holtmann> And yes, so be it. dbus-glib should be able to handle it. Zeuthen does something crazy like that with PolicyKit1.
Nov 10 17:58:34 <holtmann> ???
Nov 10 17:58:51 <denkenz> why do you need a nested dict?
Nov 10 17:58:52 <holtmann> My bad that was for GetProperties ;)
Nov 10 17:58:58 <denkenz> heh
Nov 10 17:59:03 <holtmann> The signal is sa{sv}
Nov 10 17:59:13 <denkenz> signal is sv
Nov 10 17:59:23 <holtmann> And in this case the v is a{sv}
Nov 10 17:59:40 <denkenz> correct, so sa{sv} :)
Nov 10 17:59:49 <holtmann> D-Bus wire protocol wise it results in some nasty containers, but whatever.
Nov 10 18:00:20 <denkenz> Anyway, I'm fine with that
Nov 10 18:00:28 <holtmann> I think that is the only way to do it without race conditions and not complicating it with too many methods and signals.
Nov 10 18:00:49 <denkenz> So Activated -> True, Settings -> dict
Nov 10 18:00:57 <denkenz> Activated -> False, Settings -> Empty Dict
Nov 10 18:01:09 <denkenz> Emitted in that order
Nov 10 18:02:38 <holtmann> Not sure if we need the Settings empty, but for completion it makes sense.
Nov 10 18:03:05 <holtmann> We might wanna emit the Settings empty before Activated false, so that ConnMan can clean up the interface before it goes away.
Nov 10 18:03:27 <denkenz> What's the difference?
Nov 10 18:03:54 <denkenz> strictly speaking we shouldn't even bother for empty settings
Nov 10 18:04:04 <denkenz> useless signal anyway
Nov 10 18:04:13 <holtmann> Yeah. Just easier for some code path in ConnMan.
Nov 10 18:04:15 <padovan> denkenz: ping
Nov 10 18:04:38 <denkenz> padovan: pong
Nov 10 18:04:49 <denkenz> holtmann: ok, that's simple enough anyway
Nov 10 18:05:39 <holtmann> martin_office: Just read the backlog when you are up.
Nov 10 18:07:21 <padovan> denkenz: I trying to understand the HFP API. To it will works this way: oFono will call org.bluez.HFGW.RegisterAgent and registry it org.bluez.HFAgent, then someone will call org.bluez.HFGW.Connect, which will create a rfcomm link and call the NewConnection method of oFono.
Nov 10 18:07:55 <padovan> denkenz: the oFono ofono will do HFP protocol stuff as it does today. Am I right?
Nov 10 18:08:28 <denkenz> padovan: yep, when ofono starts up it looks for all devices with Gateway interface, then creates a modem for each and registers an agent for it
Nov 10 18:09:03 <denkenz> padovan: Then either gateway connects / someone calls bluez.Gateway.Connect / someone calls ofono.modem.powered brings up the rfcomm link
Nov 10 18:09:22 <denkenz> padovan: NewConnection gets called and ofono does the hfp part as usual
Nov 10 18:11:48 <jprvita> denkenz: and when does the SCO is created?
Nov 10 18:12:09 <denkenz> jprvita: The AG controls that part
Nov 10 18:12:57 <jprvita> hum, ok
Nov 10 18:13:19 <padovan> denkenz: So, I will start with gw.RegisterAgent stuff, and then gw.Connect
Nov 10 18:14:00 <denkenz> jprvita: Speak to jhe about it, he knows that part inside out
Nov 10 18:14:05 <denkenz> padovan: Sounds good
Nov 10 18:14:10 <jprvita> so basically bluez will have to way for a SCO connection from AG, handle the handshake and then pass a fd to one of its audio clients (pulse, alsa)
Nov 10 18:15:56 <jprvita> denkenz: I know a bit about it too, since I did the pulse module for HSP/A2DP, and I guess this part would be similar
Nov 10 18:16:36 <jprvita> just trying to figure if some changes would be needed on pulse part for HFP
Nov 10 18:20:09 <denkenz> jprvita: I doubt it
Nov 10 18:20:25 <denkenz> jprvita: But I'm not up to date on how the audio part works anymore
Nov 10 18:22:18 <jprvita> denkenz: right, I'll check with jhe latter
Nov 10 18:22:51 <denkenz> jprvita: Remember BlueZ already has an HFP Client implementation that works with SCO over HCI
Nov 10 18:23:12 <denkenz> jprvita: So I'm assuming the existing infrastructure should handle hfp protocol residing in ofono
Nov 10 18:27:07 <jprvita> I'll have a look at that
Nov 10 18:27:51 <denkenz> holtmann: We still need to figure out whether to do DHCP assignment from connman or to somehow use static assignment on the device
Nov 10 18:28:27 <denkenz> holtmann: So having IP/DNS/Gateway as attributes might actually be required
Nov 10 19:28:32 <jprvita> hey, I've just notice the alt text for the "About" link in ofono.org says "About ConnMan"
Nov 10 19:28:43 <jprvita> don't know who's the responsible for the website
Nov 10 19:29:05 <holtmann> denkenz: I would just add something like "Method" : (dhcp, static) to the Settings dict.
Nov 10 19:31:23 <holtmann> denkenz: And GetProperties should return "Settings" of course. So you get all that. Except they are nested, but hey only ConnMan should care about these details aynway.
Nov 10 19:43:38 <denkenz> holtmann: But how would set the 'settings'
Nov 10 19:44:01 <denkenz> Assuming I want a static IP setup, I must provide IP, Gateway, DNS
Nov 10 19:44:16 <denkenz> I'd hate to have to parse & validate the dict :)
Nov 10 19:44:21 <holtmann> oFono sets these based on the results it gets from the network.
Nov 10 19:44:32 <holtmann> ConnMan will never set them.
Nov 10 19:44:38 <holtmann> s/oFono/
Nov 10 19:44:48 <holtmann> ConnMan reads these details and then configures the interface.
Nov 10 19:44:59 <denkenz> holtmann: Yes, but can't you have a static IP setup?
Nov 10 19:45:08 <holtmann> You lost me.
Nov 10 19:45:11 <denkenz> holtmann: In which case the settings need to be passed down to the context
Nov 10 19:45:35 <denkenz> holtmann: Ok, lets restart
Nov 10 19:45:46 <denkenz> holtmann: You can do assignment via DHCP, or statically
Nov 10 19:46:13 <denkenz> holtmann: If DHCP, then IP/Gateway/Netmask/DNS oFono has as blanks, and connman takes care of
Nov 10 19:46:21 <holtmann> Yes. MBM being the DHCP exception. Nobody else will implement a DHCP server in their firmware.
Nov 10 19:46:39 <denkenz> holtmann: If Static, then these must be setup when context is created
Nov 10 19:46:42 <holtmann> Mainly Settings : { Method: DHCP }
Nov 10 19:46:54 <denkenz> holtmann: And the information passed down to activate_primary()
Nov 10 19:47:16 <holtmann> For static:  Settings : { Method: static, Address: 192.186.0.1, ... }
Nov 10 19:47:42 <holtmann> That is both from a D-Bus API point of view.
Nov 10 19:47:47 <denkenz> Yes, so I must parse the dict full of variants
Nov 10 19:47:55 <holtmann> oFono is not touching the IP configuration of the interface.
Nov 10 19:47:56 <denkenz> Anyway, can be done, but nasty
Nov 10 19:48:16 <holtmann> Seriously. No idea what you wanna parse. You just have to build that dict of dict.
Nov 10 19:48:17 <denkenz> Actually, MBM allows you to setup all of those parameters
Nov 10 19:48:38 <holtmann> I think you are confusing something here.
Nov 10 19:49:23 <holtmann> oFono will activate the context, and then start PPP or whatever method, then get the IP details and export it over D-Bus. MBM is just an exception where it just exports Method=dhcp.
Nov 10 19:49:46 <holtmann> Then ConnMan picks up these settings and puts them on the interface.
Nov 10 19:50:00 <holtmann> In case of static it just sets them, in case of dhcp it start dhcp.
Nov 10 19:50:50 <denkenz> holtmann: Look for AT*EIAIPCPW
Nov 10 19:51:13 <denkenz> holtmann: I think static IP assignment by the user is possible
Nov 10 19:51:37 <holtmann> Then just ignore that. We don't have to implement it.