**** BEGIN LOGGING AT Wed Jun 23 02:59:56 2010
Jun 23 13:28:33 <kvalo> denkenz: morning. quick questions about ppp usernamed and passwords. should connman set them?
Jun 23 13:29:05 <kvalo> denkenz: ie. are there networks which require certain username/password or is that history already?
Jun 23 13:33:51 <denkenz> there are networks
Jun 23 13:33:58 <denkenz> very few of them though
Jun 23 13:35:29 <kvalo> denkenz: good to know, thanks
Jun 23 15:19:08 <wagi> CGREG tells me when the gprs context is attached
Jun 23 15:19:30 <wagi> registrastion_status_cb will be called eventually
Jun 23 15:19:37 <wagi> registration_status_cb
Jun 23 15:19:55 <wagi> and there the gprs->flags is updated
Jun 23 15:20:24 <wagi> Does gprs->flags tell me when the context is attached, e.g. when it is 0?
Jun 23 15:22:16 <denkenz> Not really
Jun 23 15:22:28 <denkenz> FLAG_ATTACHING is to flag an attach / detach operation in progress
Jun 23 15:22:45 <denkenz> You have to pay attention to the status from registration_cb / notify
Jun 23 15:22:57 <denkenz> if you're roaming / home then you're attached
Jun 23 22:02:01 <sameo> denkenz: what's needed for DUN on the oFono side ?
Jun 23 22:03:57 <holtmann> You need a PPP server and a DUN server. And then after establishing the connection it needs to add the ppp0 interface to the bridge provided by ConnMan.
Jun 23 22:04:44 <holtmann> DUN -> RFCOMM socket -> PPP -> ppp0 -> bridge.
Jun 23 22:05:10 <holtmann> So the only nasty part is that the PPP server needs to get its IP from the range that ConnMan's DHCP server provides.
Jun 23 22:05:54 <holtmann> So there is a little bit of IP magic involved here to get the point-to-point interface working properly on a bridge.
Jun 23 22:07:50 <holtmann> Everything else is then IP forwarding of the bridge into the actual default route interface (main service) of ConnMan.
Jun 23 22:09:54 <denkenz> Why magic? Isn't it simply allocating a private address?
Jun 23 22:10:11 <denkenz> The PPP server part is nearly done, however the option handling code still needs work
Jun 23 22:10:33 <denkenz> holtmann: And you're supposed to be on vacation ;)
Jun 23 22:10:35 <holtmann> It is a point-to-point interface. I am not sure you can actually bridge them.
Jun 23 22:11:00 <holtmann> Just got bored and started reading my emails ;)
Jun 23 22:11:49 <denkenz> You sure? isn't it point-to-point on the ppp link?
Jun 23 22:11:58 <denkenz> Not point to point on bridge -> local ip?
Jun 23 22:13:00 <holtmann> We have to play with this. I have never tried this.
Jun 23 22:16:31 <denkenz> balrog-k1n: Lol, maybe I'm missing something about your intended usage
Jun 23 22:16:52 <denkenz> balrog-k1n: Btw, executing a proactive command if terminal_response is not implemented in the driver is silly
Jun 23 22:18:18 <balrog-k1n> denkenz: true,
Jun 23 22:18:59 <balrog-k1n> it's just i don't like to have to handle some types of errors in the callback and some in the caller
Jun 23 22:19:43 <denkenz> seems like there are two errors here, not implemented and out of memory
Jun 23 22:20:31 <balrog-k1n> yeah (it's either out of memory or we set the fields of the structure wrongly, e.g. some string was too long)
Jun 23 22:23:02 <denkenz> And you never do anything with type FAILURE
Jun 23 22:23:32 <denkenz> It seems returning an error right there and then would be easier
Jun 23 22:24:40 <balrog-k1n> may be, but the only sensible thing for the caller to do is to invoke the callback then
Jun 23 22:24:49 <balrog-k1n> or duplicate the code in the callback
Jun 23 22:25:37 <denkenz> What code? most of the time you can return straight from the function registered in the method_table
Jun 23 22:25:44 <denkenz> without setting pending, etc
Jun 23 22:27:09 <denkenz> Give me a concrete example, maybe I'm blind :)
Jun 23 22:30:40 <balrog-k1n> denkenz: stk_response is used a couple of times in patch 4/8
Jun 23 22:31:07 <balrog-k1n> in all of these cases if i'd rather invoke the callback when stk_response fails anyway
Jun 23 22:32:02 <balrog-k1n> you could just return __ofono_error_failed(msg); but that's an additional code path to handle
Jun 23 22:32:13 <denkenz> yeah but its also more readable
Jun 23 22:32:17 <denkenz> Lets take an example
Jun 23 22:32:18 <denkenz> +       stk->pending = dbus_message_ref(msg);
Jun 23 22:32:20 <denkenz> +
Jun 23 22:32:21 <denkenz> +       if (stk->current_menu)
Jun 23 22:32:23 <denkenz> +               select_item_respond(stk, item, help);
Jun 23 22:32:24 <denkenz> +       else
Jun 23 22:32:26 <denkenz> +               send_menu_selection(stk, item, help);
Jun 23 22:32:32 <denkenz> you set pending without checking that driver->envelope is NULL
Jun 23 22:32:39 <denkenz> my alarm bells start ringing
Jun 23 22:32:55 <denkenz> Then I go through 2 layers of functions to figure out its OK
Jun 23 22:33:20 <balrog-k1n> you later unref it in case of error
Jun 23 22:33:32 <denkenz> I know its OK
Jun 23 22:33:38 <denkenz> but lets look at the alternative
Jun 23 22:33:45 <denkenz> if (stk->current_menu)
Jun 23 22:33:47 <balrog-k1n> but since the functions have no return value it should just makes you assume the function can't fail
Jun 23 22:33:50 <denkenz> error = select_item_respond()
Jun 23 22:33:55 <denkenz> if (error < 0)
Jun 23 22:34:00 <denkenz> return ofono_error_failed()
Jun 23 22:34:06 <denkenz> so much more readable
Jun 23 22:34:25 <balrog-k1n> and then stk->pending = dbus_message_ref(msg); ?
Jun 23 22:34:30 <denkenz> correct
Jun 23 22:34:39 <denkenz> We do this about everywhere this way too
Jun 23 22:35:54 <balrog-k1n> ok, let's do that for consistency then
Jun 23 22:36:20 <denkenz> Btw, readability sometimes makes code longer
Jun 23 22:36:27 <denkenz> And its actually fine this way
Jun 23 22:36:43 <denkenz> As long as its easier to understand, it can be more long-winded :)
Jun 23 22:37:56 <denkenz> And boy do I get complaints from kernel devs about our stuff happening in the callback way of doing things
Jun 23 22:38:03 <balrog-k1n> i know, i just don't see it as more readable, the error handling should occupy as few lines as possible
Jun 23 22:38:30 <balrog-k1n> so i think let's do it in one place instead of having it clutter code everywhere
Jun 23 22:39:14 <balrog-k1n> it's different if the reason you read the code is to spot mistakes i guess
Jun 23 22:39:45 <denkenz> Or read the code in paranoid mode 6 months later
Jun 23 22:40:05 <denkenz> And some people read code with paranoid mode always on ;)
Jun 23 22:41:35 <denkenz> Note, that I'm guilty of this myself ;)
Jun 23 22:41:52 <denkenz> There are still parts in gatchat and smsutil I fear to tread
Jun 23 22:43:31 <balrog-k1n> denkenz: btw. do you think the main menu should stay on the SimApplication interface, but the rest go through another interface?
Jun 23 22:44:48 <denkenz> My feeling is that the main menu can stay
Jun 23 22:44:57 <balrog-k1n> one thing to consider is that the application can only do one thing at a time, if you can see a submenu, you can't see the main menu, if it is displaying text, none of the menus are available
Jun 23 22:45:54 <denkenz> Yeah, it may be we want an agent for everything
Jun 23 22:46:38 <denkenz> However, the semantics of GoBack, EndSession, etc are much easier with an Agent
Jun 23 22:47:18 <denkenz> e.g. StkApplicationAgent::SelectItem -> returns int or error: UserCancel, UserGoBack, etc
Jun 23 22:48:13 <balrog-k1n> makes sense
Jun 23 22:48:49 <denkenz> Menus are a bit different since its the app driving them
Jun 23 22:49:07 <denkenz> so maybe they can remain on an oFono interface (and also allow the app some time to register)
Jun 23 22:49:25 <balrog-k1n> yeah, the main menu is different
Jun 23 22:49:36 <balrog-k1n> can the Agent handle a timeout?
Jun 23 22:49:41 <denkenz> Then we can invent some error (like busy or more specific) for when Agent is active
Jun 23 22:49:48 <balrog-k1n> i probably need to read up on it, will do tomorrow
Jun 23 22:50:01 <denkenz> Yeah, so you can do something like SelectItem and Cancel()
Jun 23 22:50:06 <denkenz> BlueZ does that for PIN dialogs
Jun 23 22:50:45 <denkenz> Its a bit racy, but I think we can do it
Jun 23 22:51:15 <balrog-k1n> so you call Cancel() simultaneously, while SelectItem() is "running"?
Jun 23 22:51:32 <denkenz> sure, why not? :)
Jun 23 22:52:01 <denkenz> We could even do that in oFono, only some old legacy preventing us
Jun 23 22:52:09 <denkenz> (and expedience)
Jun 23 22:53:12 <balrog-k1n> ah, gdbus wouldn't let a client call GetProperties while something else was running?
Jun 23 22:53:47 <balrog-k1n> never tried it
Jun 23 22:53:47 <denkenz> No, the 'old' backend was stupid ;)
Jun 23 22:54:07 <denkenz> hence I invented .Error.Busy
Jun 23 22:54:24 <denkenz> In some cases we still want it
Jun 23 22:54:35 <denkenz> In others (like most properties) we don't have to check busy
Jun 23 22:56:04 <denkenz> However, pretty much all bindings I'm aware of support multiple outstanding method calls
Jun 23 22:56:27 <denkenz> I think even python ones can do it now with some trickery
Jun 23 22:57:57 <balrog-k1n> yeah, python lets you make a call and receive the response asynchronously
Jun 23 22:58:48 <balrog-k1n> only with glib main loop currently (also required for signal handling)
Jun 23 22:59:16 <denkenz> so there you go, nothing really prevents you from calling SelectItem and Cancel
Jun 23 22:59:34 <denkenz> And the nice thing here is that Cancel will now work for every single proactive command
Jun 23 22:59:46 <denkenz> That goes through the agent
Jun 24 02:18:38 <zhenhua> denkenz: and for NBNS info, it's ok to remove them at all. also remove them ipcp_rcr, is that ok?
Jun 24 02:18:38 <zhenhua> s/remove them ipcp_rcr/remove them in ipcp_rcr verification
Jun 24 02:21:11 <denkenz> imo we should Conf-Rej them
Jun 24 02:21:22 <denkenz> It is safer than letting some weird client get a wrong NBNS address
Jun 24 02:22:14 <denkenz> For RCA and NAK sounds fine, we shouldn't modify our IP Address if the peer naks ;)
Jun 24 02:31:23 <zhenhua> so in RCR, we need to Conf-Rej the options we don't unreconginzed
Jun 24 02:31:39 <denkenz> Yeah
Jun 24 02:31:59 <zhenhua> so i just want to remove memcpy in PRIMARY_NBNS_SERVER and SECOND
Jun 24 02:32:28 <denkenz> Well careful, for the client side we do want them
Jun 24 02:32:49 <denkenz> It helps to have a pppdump of IPCP negotiation with a real PPP modem
Jun 24 02:33:24 <denkenz> Goes something like:
Jun 24 02:33:29 <zhenhua> ops, i don't happen to view pppdump log yet
Jun 24 02:33:50 <zhenhua> they don't support NBNS negotitaion?
Jun 24 02:33:52 <denkenz> Conf-Req[IPAddr = 0, NBNS1/2 = 0, DNS1/2 = 0]
Jun 24 02:34:00 <denkenz> Conf-Rej[NBNS1/2]
Jun 24 02:34:08 <denkenz> Conf-Req[IPAddr = 0, DNS1/2 = 0]
Jun 24 02:34:18 <denkenz> Conf-Nak[IPAddr = some value, DNS1/2 = some value]
Jun 24 02:34:35 <denkenz> Conf-Req[IP-Addr = value from Nak, DNS1/2 = value from nak]
Jun 24 02:34:41 <denkenz> Conf-Ack
Jun 24 02:35:00 <zhenhua> i see
Jun 24 02:35:44 <denkenz> The Conf-Req / Conf-Nak step can be repeated several times
Jun 24 02:35:58 <denkenz> Usually happens when the modem is busy obtaining the IP address from the network
Jun 24 02:36:25 <denkenz> In which case the PPP modems tend to set bogus DNS addresses, but keep IP-Addr at 0
Jun 24 02:36:42 <denkenz> Have a look using gsmdial with the pppdump option turned on
Jun 24 02:36:50 <denkenz> Then just run wireshark on the dump file
Jun 24 02:37:44 <zhenhua> okay, i will try. i have wireshark ;-)
Jun 24 02:39:09 <zhenhua> discuss something with xiaodan now. wait mintues
Jun 24 02:57:57 <zhenhua> denkenz: Conf-Req/Conf-Nak could repeat but i am worried about timeout soon.
Jun 24 02:58:35 <zhenhua> in my current prototype, i am using another way: build real GPRS connection on real modem first.
Jun 24 02:58:47 <zhenhua> then echo 'CONNECT' to DUN client and start PPP connection.
Jun 24 02:59:12 <zhenhua> otherwise, i believe we will timeout with PPP client soon
**** ENDING LOGGING AT Thu Jun 24 02:59:58 2010