**** BEGIN LOGGING AT Tue Jun 21 02:59:56 2011
Jun 21 04:10:26 <qlaude> hi if in my driver code i am listening to sockets can it then block the g_idle_add function
Jun 21 04:10:44 <qlaude> which is used for simio
Jun 21 13:02:06 <wagi> Hi, a colluege of mine and I are about to add DUN client support to oFono. We got the the point where we get from BlueZ the TTY and we set the PPP client to talk to the other side. We see that the ppp_connect callback comes back from phase 4 (what ever that means) from the ppp layer. All settings like IP, peer, etc. 0. Is this supposed to be correct? Or do we have to do something more (e.g. send some magic AT command)?
Jun 21 13:46:01 <denkenz> wagi: What ppp implementation is on the other side? phase 4 means link is up, however getting all zeros is not right
Jun 21 13:50:24 <wagi> denkenz: It's a Nokia 6303i classic
Jun 21 13:53:04 <denkenz> sounds weird
Jun 21 13:56:35 <denkenz> You'll probably have to enable the ppp_dump file and wireshark it
Jun 21 13:56:44 <denkenz> Sounds like the Nokia is giving bogus info
Jun 21 13:59:35 <wagi> okay, thanks for the ppp_dump tip. let's see 
Jun 21 14:01:02 <wagi> Mario is about to cleanup his code first. After that we can test with a few other devices first. 
Jun 21 14:34:37 <pnunes> denkenz: ping
Jun 21 14:40:56 <denkenz> pnunes: pong
Jun 21 14:41:59 <pnunes> Hi, I apologize. Last time, I was confused, I supposed  you didn't read my questions because I inadvertently missed to read your  answers (for some reason, your reply is dated anterior to my mail!?)
Jun 21 14:42:23 <pnunes> denkenz: So, thank you for your email. It reiterates what you kindly explained to me through irc.
Jun 21 14:43:04 <pnunes> denkenz: Now, I would like to precise something:  I would like to  handle the channel identifier as equal to the context id. But it  requires to introduce another private API to assign the context from  stk.c. Do you agree?
Jun 21 14:43:29 <pnunes> denkenz: It's true that we are not currently targeting to support  multiple channel and we can think to assign arbitrarily a channel id or  to use idmap functions. What do you prefer?
Jun 21 14:45:08 <denkenz> why do you need any of this? just store the activated context id in your stk.c object that represents an open channel
Jun 21 14:45:38 <denkenz> And there's no easy way to mess with idmap or context ids
Jun 21 14:48:56 <pnunes> denkenz: yes, but open channel doesn't mean necessarily 'activate context'. So, before activating the context, I thought to add an API to precisely assign the context and get the cid.
Jun 21 14:49:22 <denkenz> you can't, there might already be context active and assigned
Jun 21 14:50:00 <denkenz> And I know open channel can be deferred, but it still doesn't matter
Jun 21 14:50:18 <denkenz> You're thinking too hard about this
Jun 21 14:53:12 <pnunes> denkenz: The assign function I was looking for was trying to get the first "non used" context. But, ok, so let's try to assign arbitrary a channel id?
Jun 21 14:55:27 <denkenz> Just activate a context when you need it and track the uid returned by the activate function
Jun 21 14:55:48 <denkenz> The activate will do the needed magic to find the free cid & free gprs_context atom
Jun 21 15:03:33 <pnunes> denkenz: Actually, it's what I implemented in the function __ofono_gprs_activate_context. I can get the uid but how to handle the case where the open channel is deferred (in background mode) ? In this case, I need the uid as a preliminary step.  But again, it's only a problem if the channel id = the context id. So, should I define the channel id differently?
Jun 21 15:03:58 <denkenz> why do you need the uid?
Jun 21 15:04:02 <denkenz> The context is not active yet
Jun 21 15:05:25 <pnunes> denkenz: I mean the cid (a value in the range of CGDCONT). 
Jun 21 15:05:37 <denkenz> you still don't need it
Jun 21 15:12:55 <pnunes> denkenz: yes, I don't need it if the channel id is not equal to the cid. Otherwise, in 'Link on demand' mode, I need to return the channel id (id the cid) even if the context is not activated. In this mode, the context is just assigned but not active.
Jun 21 15:16:49 <denkenz> so return the channel id, what does it have to do with cid?
Jun 21 15:17:36 <denkenz> There is no link between cgdcont and stk, you're just trying to make one up
Jun 21 15:23:52 <pnunes> denkenz: right, there is no link. So, I give up to handle the channel id as equal to the cid. I will return a channel id by default (in the open channel terminal response) since only one channel can be created in stk. Thanks for your answers. 
**** ENDING LOGGING AT Wed Jun 22 02:59:57 2011