**** BEGIN LOGGING AT Thu Jun 23 02:59:56 2011 Jun 23 10:23:32 Hi All geeks I am a Newbeeee and have a simple stupid question ....as i could not get more info from google Jun 23 10:23:50 Question: What is the support for connman_ofono to 4G network connections Jun 23 10:24:08 as my knowledge 4G use "4G LTE uses the GSM APN authentication method through a GGSN (similar to AT&T)" Jun 23 10:24:26 is it possible for using or extend connman+ofono for 4G LTE networks as I would like to make my openwrt system to work with a 4G backup mode Jun 23 16:06:49 denkenz: ping Jun 23 16:08:48 fdalleau: pong Jun 23 16:08:59 hi, Jun 23 16:09:34 there is a pts test that sends AT+CHLD=3 to the emulator Jun 23 16:10:02 it complains that the mpty field is not set to 1 event if all calls are active Jun 23 16:10:36 I meant the mpty field of a CLCC Jun 23 16:11:57 CHLD=3 is a join? Jun 23 16:12:00 I see that Phonesim fills correctly the mpty field but when the atmodem driver reads the clcc response, the field is ignored Jun 23 16:12:07 yes Jun 23 16:12:57 The mpty field is worthless Jun 23 16:13:33 And we do generate the mpty correctly in voicecall.c Jun 23 16:14:12 you mean in CreateMultiparty dbus call? Jun 23 16:14:40 emulator_clcc_cb Jun 23 16:15:33 Sounds like maybe our chld3 implementation is not doing the right thing Jun 23 16:15:38 ok so this means the list is empty Jun 23 16:15:52 the chld3 calls the driver Jun 23 16:16:15 yes, but we never update the multiparty list Jun 23 16:16:28 see multiparty_create_callback for what we should be doing Jun 23 16:17:28 ok I see thanks! Jun 23 19:30:47 hi guys!! 1 query Jun 23 19:31:01 is video telephony going to be supported in oFono in near future Jun 23 19:43:46 no Jun 23 20:14:22 denkenz: ping Jun 23 20:18:53 pnunes: pong Jun 23 20:20:46 denkenz: As suggested, I implemented the use of the ioctl operation with FIONREAD to get the bytes to read and I'm facing with an issue. Jun 23 20:21:39 denkenz: This operation is placed in the receive callback positioned by g_io_add_watch_full. In practice, this callback is repeatedly called until I read precisely the kernel buffer. Jun 23 20:22:09 denkenz: For UDP, it's useless, for TCP, it can maybe be interesting to get a live update of the bytes to read. Jun 23 20:22:27 denkenz: But I don't feel this is a good behavior. Jun 23 20:34:06 pnunes: So why do you bother using a read watch? Jun 23 20:34:31 Just use FIONREAD, then read however many bytes the sim tells you to read Jun 23 20:34:40 No need for a read watch at all Jun 23 20:37:18 denkenz: I'm looking to the bytes to read when I know precisely that some data are pending. Without read watch, how can I trigger the use of FIONREAD ? Jun 23 20:38:02 Doesn't the SIM ask in Get channel status? Jun 23 20:41:47 denkenz: no, the number of bytes to read is returned the first time through the event 'data available' and then in the terminal response of the proactive command 'Receive data' Jun 23 20:43:20 so what you can do is something like: Jun 23 20:43:23 enable read_watch Jun 23 20:43:40 once read_watch fires, remove it and check the number of bytes in the buffer Jun 23 20:43:52 if the sim requests all bytes, re-enable the write watch Jun 23 20:44:13 if not, then return however many in wants and tell it x bytes are pending Jun 23 20:44:53 on the next read give it however go back to step 'if sim requests all bytes...' Jun 23 20:45:55 The above meant to say: 'On next receive data go back to step .." Jun 23 20:46:37 denkenz: Ok, I like your sequence. Let's try that. Jun 23 20:47:20 denkenz: An other point, you suggested also to get by without TX buffer Jun 23 20:48:08 yes, it is highly likely you will never need intermediate tx buffering Jun 23 20:48:35 denkenz: But in my case, even in blocking mode, I need at least this buffer to concatenate the SDUs (parts of the PDU) before sending the complete PDU to the interface. Jun 23 20:50:41 err, I'm lost now Jun 23 20:50:58 Aren't SDUs always smaller than 255? Jun 23 20:51:15 Or is this some UDP silliness? Jun 23 20:51:31 denkenz: yes, 243 bytes max Jun 23 20:52:41 so whats the problem? Jun 23 20:52:49 denkenz: yes, I presume we are building the datagram before sending it Jun 23 20:53:49 denkenz: no problem, just to not be surprised to see again this TX buffer despite your advice... Jun 23 20:54:19 This is only a problem if we have UDP frames bigger than 243 Jun 23 20:54:30 pnunes: You guys know that the kernel could buffer as well. Check MSG_MORE flag in send() in case that is needed. Jun 23 20:55:33 Ooh, and MSG_MORE looks cool for this as well Jun 23 20:55:56 holtmann: thanks for the tip. Jun 23 20:55:58 Even though I bet you we will never support UDP anyhow Jun 23 20:57:05 denkenz: in practice the buffer size requested by the SIM is bigger than 243 so yes, we need to handle UDP frame bigger than one SDU. Jun 23 20:57:35 I'd say we don't need to handle UDP channels in the first place ;) Jun 23 20:58:46 denkenz: you may know that I have an Orange USIM card which is supposed to use BIP commands. Jun 23 20:58:57 Since you have the same SDU issue with UDP on recv Jun 23 20:59:41 UDP is unordered and unreliable. Nobody in their right mind would use that. Jun 23 21:00:10 denkenz: unfortunately, no way to find the SIM app , so I can't confirm your well mind opinion Jun 23 21:00:40 holtmann: This is STK we're talking about here Jun 23 21:01:46 pnunes: Where is the SDU size negotiated? Jun 23 21:01:58 denkenz: at least, this SIM card is asking to monitor events (channel status and data available), so it proves that this SIM card has some BIP command hidden somewhere... Jun 23 21:02:30 denkenz: the SDU is not negotiated Jun 23 21:03:12 I guess I mean the PDU, or whatever the datagram size is for the protocol Jun 23 21:03:22 How does one know when to send Jun 23 21:04:33 denkenz: the PDU size is negotiated indeed with the open channel command. SIM gives its size, and terminal confirms this size or gives it's own size. Jun 23 21:04:52 That's the buffer size no? Jun 23 21:05:02 denkenz: yes. Jun 23 21:05:10 So that's not the PDU Jun 23 21:05:39 denkenz: the sending is triggered with the command Send data with the qualifier "immediately" Jun 23 21:05:40 "or to be stored in a Tx buffer. Then it is up to the terminal to manage the data sending in order to use the bearer Jun 23 21:05:40 in an optimized way. To send the data stored in a Tx buffer, the terminal shall be notified by a "send data Jun 23 21:05:41 immediately" and it shall consider the data presently and previously concatenated in its Tx buffer as one SDU, Jun 23 21:05:41 and send it in only one PDU. The Tx buffer shall then be emptied before returning the TERMINAL Jun 23 21:05:41 RESPONSE to the UICC and allowing new UICC sending." Jun 23 21:06:19 So that's the magic, immediate flag Jun 23 21:07:24 And that paragraph still makes no sense since it talks about "up to the terminal" Jun 23 21:09:07 denkenz: that's why it's a pity to not being able to test with the SIM card I have...We could at least see how the operator is interpreting the spec. Jun 23 21:10:04 I suspect the immediate flag only comes into effect with UDP Jun 23 21:10:11 with TCP it really makes no freaking sense Jun 23 21:12:42 denkenz: or the 'store' flag makes no sense for TCP ? Jun 23 21:13:28 That would be my guess, that it is never used Jun 23 21:13:42 However, with these guys you never know Jun 23 21:13:48 You probably need to handle both Jun 23 21:15:26 denkenz: So let's try to bufferize in the kernel side ? Jun 23 21:15:59 For writing yes, for reading you're gonna have fun again Jun 23 21:16:31 TCP is not really guaranteed to preserve packet boundaries Jun 23 21:16:38 and partial reads on UDP might be fun Jun 23 21:18:33 What I would really do is get the basics up and running and forget about the rest for now Jun 23 21:18:39 TCP/IP only Jun 23 21:18:49 none of this buffering / immediate crap Jun 23 21:19:09 blocking sockets after the connect phase Jun 23 21:19:20 kernel buffers only Jun 23 21:19:24 See how far you get with that Jun 23 21:20:42 denkenz: OK, sounds good to me. Thanks for your advices. **** ENDING LOGGING AT Fri Jun 24 02:59:57 2011