**** BEGIN LOGGING AT Wed Feb 16 02:59:57 2011
Feb 16 05:20:04 <holtmann> denkenz: Just mail Gemalto and ask for it.
Feb 16 05:26:45 <denkenz> I don't want it that badly ;)
Feb 16 09:34:08 <fdanis> denkenz: ping
Feb 16 15:05:50 <denkenz> fdanis: pong
Feb 16 15:09:09 <Gzajac> padovan: ping
Feb 16 15:09:39 <padovan> Gzajac: pong
Feb 16 15:10:41 <Gzajac> I have used gsmdial -b for testing PPP server and it is working until we disconnect. However after we disconnect I experiment a crash. Did you notice one crash here also ?
Feb 16 15:11:02 <padovan> Gzajac: which crash? logs please
Feb 16 15:11:13 <Gzajac> ok
Feb 16 15:12:29 <Gzajac> I give you the end of it.
Feb 16 15:12:32 <Gzajac> ofonod[15217]: PPP: lcp: pppcp_process_terminate_ack: current state 4:CLOSING
Feb 16 15:12:32 <Gzajac> ofonod[15217]: PPP: lcp: pppcp_generate_event: current state 4:CLOSING
Feb 16 15:12:32 <Gzajac> ofonod[15217]: PPP: event: 11 (RTA), action: 802, new_state: 2 (CLOSED)
Feb 16 15:12:32 <Gzajac> ofonod[15217]: PPP: lcp: pppcp_this_layer_finished: current state 2:CLOSED
Feb 16 15:12:32 <Gzajac> Entering new phase: 0
Feb 16 15:12:32 <Gzajac> ofonod[15217]: src/emulator.c:ppp_disconnect() 
Feb 16 15:12:32 <Gzajac> (ofonod:15217): GLib-CRITICAL **: g_io_channel_write_chars: assertion `buf != NULL' failed
Feb 16 15:12:33 <Gzajac> ofonod[15217]: Aborting (signal 11)
Feb 16 15:12:33 <Gzajac> ofonod[15217]: ++++++++ backtrace ++++++++
Feb 16 15:12:34 <Gzajac> ofonod[15217]: [0]: [0xb771b400]
Feb 16 15:12:34 <Gzajac> ofonod[15217]: [1]: /home/guillaume/Work/Meego/ofono/src/ofonod() [0x80744aa]
Feb 16 15:12:35 <Gzajac> ofonod[15217]: [2]: /lib/libglib-2.0.so.0(+0x84e5b) [0xb7699e5b]
Feb 16 15:12:35 <Gzajac> ofonod[15217]: [3]: /lib/libglib-2.0.so.0(g_main_context_dispatch+0x1d5) [0xb7652855]
Feb 16 15:12:36 <Gzajac> ofonod[15217]: [4]: /lib/libglib-2.0.so.0(+0x41668) [0xb7656668]
Feb 16 15:14:49 <Gzajac> I am using Denis example/emulator and I gsmdial over its TCP port
Feb 16 15:19:57 <padovan> I think it's due to the IOChannel -> fd -> IOChannel conversion.
Feb 16 15:21:20 <padovan> By some reason the IOchannel in the plugin is not closed. That's why I added a watch there to unref on  disconnect
Feb 16 15:21:56 <padovan> Gzajac: I don't think it's right solution, I might not had found the real cause of this.
Feb 16 15:22:10 <Gzajac> padovan: ok
Feb 16 15:22:50 <Gzajac> padovan: but I am using TCP example/emulator for testing dun_dial.
Feb 16 15:23:04 <Gzajac> so I am not in case of dun gateway
Feb 16 15:23:49 <Gzajac> I will test bluetooth later because it is more tricky
Feb 16 15:28:20 <Gzajac> Padovan: In case of dun_gw we retrieve an IOChannel --> get fd --> create new IOchannel
Feb 16 15:28:49 <Gzajac> Padovan: In case of example/emulator: we retrieve fd -> create new IOchannel
Feb 16 15:30:31 <denkenz> There should be no IOChannel -> fd -> IOChannel conversion
Feb 16 15:30:53 <denkenz> in example/emulator we get the raw fd from accept and send it straight up
Feb 16 15:31:41 <Gzajac> denkenz: right, so the crash doesn't come from this conversion.
Feb 16 15:46:46 <denkenz> you will have to gdb it, sounds like we're writing to a socket after its dead
Feb 16 15:48:19 <Gzajac> denkez: yes
Feb 16 15:48:45 <Gzajac> I have noticed that when we do a g_at_ppp_server_new_from_io()
Feb 16 15:49:00 <Gzajac> we call g_at_hdlc_unref()
Feb 16 15:49:29 <Gzajac> however when we unref from PPP
Feb 16 15:49:42 <Gzajac> we do again a  g_at_hdlc_unref()
Feb 16 15:50:16 <Gzajac> although I didn't notice any g_at_hldc_ref()
Feb 16 15:51:16 <denkenz> ppp_init_common, we ref it there
Feb 16 15:54:57 <Gzajac> right and we unref it during ppp_unref
Feb 16 15:57:19 <Gzajac> I noticed in debugging, that we try to use the write_handler of hldc although we are disconnected from ppp server
Feb 16 16:03:58 <denkenz> Maybe we're not disabling the write handler if we're disconnected
Feb 16 16:15:57 <Gzajac> denkenz: when we are disconnected from PPP server we resume the GAtServer so we set the new write_handler from GAtServer
Feb 16 16:17:55 <Gzajac> into GAtIO
Feb 16 16:20:19 <denkenz> hm, so should we check that GAtIO is suspended before trying to resume GAtServer?
Feb 16 16:20:50 <denkenz> The channel returned by GAtIO should be NULL in that case
Feb 16 16:21:03 <denkenz> Or better yet, handle this in GAtIO if possible
Feb 16 16:25:07 <Gzajac> the PPP server is created from the GAtIO of GAtServer using g_at_ppp_server_new_from_io()
Feb 16 16:26:31 <denkenz> I suspect that we simply need to return FALSE in g_at_io_set_write_handler if io->channel is NULL
Feb 16 16:33:48 <Gzajac> I have tried it but it is not working
Feb 16 16:34:13 <Gzajac> I have tried also to do the same thing as when we suspend GAtServer e.g. set write handler to NULL
Feb 16 16:34:23 <Gzajac> when we unref PPP server
Feb 16 16:34:34 <Gzajac> during the hdlc_unref
Feb 16 16:36:15 <Gzajac> It is no more crashing but there are some data written by GAtServer write_handler
Feb 16 16:36:18 <Gzajac> into the console
Feb 16 16:36:57 <denkenz> so I suspect that we need to distinguish between the different disconnect reasons
Feb 16 16:37:19 <denkenz> namely the socket was closed or the NO CARRIER condition that GAtServer is trying to take care of
Feb 16 16:39:08 <denkenz> I don't really have the code in front of me, but likely the ppp_disconnect function should unref the GAtServer if the disconnect happened due to a socket closure
Feb 16 16:39:17 <Gzajac> ok
Feb 16 16:39:21 <denkenz> And not try to send the NO CARRIER
Feb 16 16:39:27 <Gzajac> yes
Feb 16 16:39:34 <Gzajac> exactly
Feb 16 16:39:46 <Gzajac> when gsmdial is finished to write data
Feb 16 16:40:11 <Gzajac> it closes the socket but we only let the GAtServer continuing to handle the AT command
Feb 16 16:40:19 <Gzajac> although we should close it
Feb 16 16:40:35 <Gzajac> I will try to find a solution
Feb 16 16:41:02 <denkenz> yep, feel free to fix it in test-server first
Feb 16 16:41:08 <Gzajac> ok
Feb 16 16:41:14 <denkenz> Since padovan's code is almost verbatim copy of that
Feb 16 16:42:31 <Gzajac> right
Feb 16 17:05:29 <fdanis> denkenz: are you ok with hfp.c renamed in hfp_ag.c ?
Feb 16 17:10:26 <padovan> fdanis: hfp_hf.c right?
Feb 16 17:11:10 <fdanis> padovan: yes, I have some problems with my fingers ;)
Feb 16 17:11:21 <padovan> :-)
Feb 16 18:20:06 <padovan> denkenz: why let the gprs atom register the ATD handler?
Feb 16 19:24:33 <denkenz> padovan: Seems more logical, but at this point it doesn't matter
Feb 16 19:24:46 <denkenz> padovan: For BT DUN we can stuff this inside emulator.c for now
Feb 16 19:25:08 <denkenz> Maybe later when all the funny carrier requirements are examined
Feb 16 19:29:06 <padovan> Seems more clear to me do it inside emulator.c
Feb 16 19:29:59 <denkenz> It will get funny if we ever need to use CGDCONT and actually activate a proper context
Feb 16 19:30:05 <denkenz> But yeah, for now do it inside emulator.c
Feb 16 19:30:41 <padovan> Yeah, I'm not thinking on CGDCONT right now.
Feb 16 19:47:19 <denkenz> padovan: It might be fun to run Bluetooth PTS against our DUN implementation and see what we're missing
Feb 16 19:47:44 <denkenz> The spec mentions a bunch of mandatory commands, but most of them are pointless
Feb 16 19:49:21 <padovan> denkenz: I have the PTS task in TODO list for DUN Server.
Feb 16 19:49:58 <denkenz> ok coo
Feb 16 19:49:59 <denkenz> +l
Feb 16 19:50:55 <padovan> I just have to implement DUN server first and then re-setup my PTS here.
Feb 16 21:50:46 <padovan> denkenz: I rebased my patches. I'm still not checking if the called number is *99
Feb 16 21:51:36 <padovan> I'm also asking if we need, i.e, maybe the DUN spec allow calling something different from *99
Feb 16 21:51:54 <courmisch> it's not in DUN, it's in 3GPP
Feb 16 21:53:01 <denkenz> D Dial Shall be supported either as defined in
Feb 16 21:53:01 <denkenz>       [6] or as defined in [10].
Feb 16 21:53:09 <denkenz> So basically you take your pick
Feb 16 21:53:16 <denkenz> for us *99 is the only sensible thing
Feb 16 21:53:43 <denkenz> +       if (c == '*' || c == '#' || c == 'T' || c == 't') {
Feb 16 21:53:44 <denkenz> +
Feb 16 21:53:44 <denkenz> +               g_at_server_send_intermediate(e->server, "CONNECT");
Feb 16 21:53:44 <denkenz> +               g_idle_add(setup_ppp, e);
Feb 16 21:53:45 <denkenz> +       }
Feb 16 21:53:45 <denkenz> +
Feb 16 21:53:45 <denkenz> +       return TRUE;
Feb 16 21:54:01 <denkenz> Can we at least get rid of the extra empty line and track the GSource created by g_idle_add
Feb 16 21:54:14 <denkenz> That code is fine in test-server, not really kosher in the core ;)
Feb 16 23:56:40 <crevetor> Hi, anyonw here ?
Feb 16 23:56:43 <crevetor> anyone
Feb 17 00:47:39 <crevetor> Could anyone help ? My N900 can't connect to cell data network anymore. When I activate the context something goes wrong
Feb 17 02:59:21 <zgli> holtmann: how about the patch for hs 2230 modem enabling?  I reply your mail in ML, with my test it works fine. could you apply it ? 
**** ENDING LOGGING AT Thu Feb 17 02:59:57 2011