**** BEGIN LOGGING AT Tue Jan 11 02:59:58 2011
Jan 11 14:00:07 <zrafa> denkenz: holtmann : hello, do you have extra details about what to do on the "Long phone numbers" task?
Jan 11 14:03:23 <zrafa> I see a define OFONO_MAX_PHONE_NUMBER_LENGTH, but no sure if it is really related yet
Jan 11 15:11:44 <zrafa> (checkint 24.008 as well..)
Jan 11 15:11:49 <zrafa> checking*
Jan 11 15:40:56 <inz> Hmm, when I do VCM.SwapCalls on N900 using isiusb, it returns Error.Failed, but the calls are swapped.
Jan 11 15:44:58 <padovan> denkenz: ping
Jan 11 15:45:07 <denkenz> padovan: pong
Jan 11 15:49:23 <padovan> denkenz: what the relation between the gprs atom and the PPP server for DUN? GPRS watch for new incoming connections then ...
Jan 11 15:50:19 <denkenz> initially the only relation is to ensure that the internet context is activated
Jan 11 15:50:38 <denkenz> The rest happens at the connman level
Jan 11 15:58:26 <padovan> Ok, and in which part PPP server will play? or should I discover that by myself?
Jan 11 15:59:02 <denkenz> ppp server is really only used to setup the ppp link and register it with connman
Jan 11 15:59:26 <denkenz> and to tear it down of course
Jan 11 16:27:33 <padovan> I think I need a more low level explanation. I never played with the the GPRS atom
Jan 11 16:30:48 <denkenz> zrafa: Your question is a little broad and in general this part of the spec is quite nasty
Jan 11 16:31:23 <denkenz> zrafa: But basically the network can handle fairly long numbers, see 24.008 for exact details
Jan 11 16:31:42 <denkenz> zrafa: However, changing OFONO_MAX_PHONE_NUMBER_LENGTH is not enough
Jan 11 16:32:05 <denkenz> zrafa: There are implications on various functions that validate phone numbers for e.g. storing to the SIM
Jan 11 16:32:33 <denkenz> zrafa: Have a look at 31.102, EFadn
Jan 11 16:32:49 <denkenz> zrafa: Basically right now we do not support extension records, hence our phone numbers are limited to 20 characters
Jan 11 16:34:11 <denkenz> zrafa: So this task would entail validating outgoing number length, validating incoming number length and making sure long numbers are handled appropriately for all functions that write a phone number to the SIM
Jan 11 16:46:31 <zrafa> denkenz: ah, I see. Thanks for the explanation. I am going to check those functions that validate phone numbers so I understand better the current situation.
Jan 11 16:46:55 <denkenz> valid_phone_number is the one you want
Jan 11 16:47:06 <denkenz> But the current situation is easy because everything is limited to 20 characters
Jan 11 16:50:30 <zrafa> great, going to check valid_phone_number then, so I can work the 80 digits long task or come back with more questions
Jan 11 17:59:41 <xtor> denkenz: I modified udev.c, including an add_sierra function, and also implemented plugins/sierra.c and now my modem is listed by test/list-modems
Jan 11 18:02:04 <xtor> however, I don't understand most of the add_hso code, and would probably need some guidance of someone familiar with this function...
Jan 11 18:03:22 <xtor> for instance, where is "hsotype" supposed to come from? ofono.rules?
Jan 11 18:16:35 <denkenz> xtor: you might want to pull the latest git
Jan 11 18:16:43 <denkenz> holtmann added basic sierra plugin already
Jan 11 18:17:03 <denkenz> but yes, the type is coming from ofono.rules
Jan 11 18:17:14 <emdete> hi, is the ppp part of ofono supposed to work stable? or is it in a work-in-progress state? i had lots of disconnects without reason after using ppp today... ofono does not say much, only that it disconnects, not why.
Jan 11 18:17:58 <denkenz> this is software, it is always in work-in-progress state ;)
Jan 11 18:18:11 <emdete> denkenz: :D
Jan 11 18:18:33 <denkenz> Feel free to try out patches from Martin
Jan 11 18:18:38 <denkenz> They might just fix your problems
Jan 11 18:18:47 <emdete> denkenz: where do i get those?
Jan 11 18:18:55 <denkenz> err, the mailing list?
Jan 11 18:19:19 <holtmann> denkenz: And that is really damn basic.
Jan 11 18:19:54 <holtmann> denkenz: We need to deal with AT$QCSIMSTAT notification on that hardware. The SIM init is a mess on that one. And switching between CFUN=1,4,0, the SIM states keep changing as well.
Jan 11 18:20:21 <denkenz> funny
Jan 11 18:20:37 <holtmann> I call this stupid, but funny works as well ;)
Jan 11 18:20:50 <denkenz> Well you know my solution already
Jan 11 18:21:01 <holtmann> Yeah, yeah, window open etc.
Jan 11 18:21:07 <denkenz> exactly
Jan 11 18:22:30 <xtor> denkenz: ok, I'll try the latest git
Jan 11 18:24:50 <xtor> so hsotype is supposed to come from ofono.rules, but then
Jan 11 18:25:09 <xtor> grep hsotype plugins/*rules doesn't match any line
Jan 11 18:25:34 <emdete> denkenz: what should i search for? 
Jan 11 18:25:55 <xtor> is there some rule missing?
Jan 11 18:26:00 <holtmann> denkenz: I think we can just apply Martin's patches. Did you take a look.
Jan 11 18:26:10 <holtmann> Besides the fact that he messed up the coding style ;)
Jan 11 18:26:26 <denkenz> emdete: try searching for PPP
Jan 11 18:26:47 <emdete> found only one about default gateway
Jan 11 18:26:50 <denkenz> holtmann: We could, but then I rewrite all of them
Jan 11 18:26:57 <denkenz> holtmann: Let him take the credit
Jan 11 18:27:12 <denkenz> xtor: hsotype is set by the kernel driver I believe
Jan 11 18:27:34 <xtor> denkenz: ok, thanks :)
Jan 11 18:28:06 <courmisch> AT+CFUN=0 should power the SIM down, from my experience with automatic test scripts
Jan 11 18:28:44 <courmisch> some use AT+CFUN=0 to "change" the simulated SIM, in SIM test cases
Jan 11 18:29:29 <emdete> denkenz: if you like you could implement the missing part for the em770. it's probably piece of cake for you but  i don't know enough to make it proper. i could explain what's needed...
Jan 11 18:30:34 <holtmann> courmisch: The Sierra one is funny. Even the transition from CFUN=4 to CFUN=1 gives a SIM state.
Jan 11 18:30:46 <holtmann> So oFono is so fast that the network registration then fails.
Jan 11 18:30:56 <holtmann> We need to watch for SIM state changes.
Jan 11 18:31:02 <holtmann> A bit nasty.
Jan 11 18:31:13 <courmisch> yeah that's pretty damn stupid
Jan 11 18:31:33 <holtmann> Also three of their AT command ports don't accept all AT commands. Just a random selection and I have had no time to dig through this.
Jan 11 18:32:01 <holtmann> And in addition I prefer to run CnS on their binary ports actually. Since we have GAtHDLC it should be a piece of cake, but I got lazy.
Jan 11 18:32:16 <emdete> denkenz: not interested?
Jan 11 18:32:31 <denkenz> emdete: Simply too busy
Jan 11 18:33:25 <emdete> denkenz: could you at least give an url to the patches you mentioned?
Jan 11 18:34:00 <holtmann> emdete: Search for Martin Xu.
Jan 11 18:34:09 <denkenz> http://lists.ofono.org/pipermail/ofono/2011-January/007137.html
Jan 11 18:35:31 <emdete> denkenz: thanks!
Jan 11 18:36:09 <emdete> holtmann: i did. probably with the wrong search engine. you should know that i am not that deep into ofono.org web structure :/
Jan 11 18:36:35 <holtmann> I just type it into Evolution on my oFono folder.
Jan 11 18:37:47 <emdete> holtmann: that requires that you have the archive already
Jan 11 18:38:41 <denkenz> your grace period will eventually run out you know ;)
Jan 11 18:40:41 <demarchi> emdete: the time you get stuck with things like this is much greater than the required for subscribing to ML (even creating a new email account for this)
Jan 11 18:41:28 <darasd> morning denkenz:
Jan 11 18:41:46 <darasd> i have a quick question regarding a simple patch i'm preparing for CDMA devinfo
Jan 11 18:42:39 <darasd> it just reuses the same gsm atom, and the nokiacdma plugin code is basically identical to the atmodem but with different AT command syntax
Jan 11 18:43:18 <darasd> do you have any preference about code duplication here? e.g. sharing the attr_cb utility methods between the two
Jan 11 18:44:34 <denkenz> Feel free to stick attr_cb style utility into atutil.h and write a brand new devinfo for your device
Jan 11 18:44:51 <darasd> ok great - shall do - thank you!
Jan 11 18:45:23 <xtor> holtmann: which Sierra device are you working with? Mine is MC8775 (AT+GMM)
Jan 11 19:10:59 <mickeyl> speaking about the mailing list... is anyone moderating once and then? i have sent a mail on 12/25 that seems to be still in the moderation queue
Jan 11 19:15:29 <denkenz> mickeyl: Nobody moderates, you have to subscribe to send
Jan 11 19:15:59 <mickeyl> denkenz: i see
Jan 11 19:16:02 <mickeyl> oh well
Jan 11 19:16:14 <mickeyl> it was just a n900 forwarding question that probably noone can answer anyways
Jan 11 19:16:18 <mickeyl> *shrug*
Jan 11 19:17:27 <mickeyl> might change the default message then... "Either the message will get posted to the list, or you will receive
Jan 11 19:17:27 <mickeyl> notification of the moderator's decision. " is not quite true
Jan 11 19:21:04 <holtmann> xtor: C885 says mine right now. It is from AT&T.
Jan 11 19:26:34 <xtor> holtmann: thanks, I was double-checking the stuff you mentioned about CFUN, because in mine's AT Command Reference, there is just partial CFUN support, with only CFUN=0 and CFUN=1
Jan 11 19:27:03 <xtor> but C885 is not listed, only older models
Jan 11 19:27:20 <holtmann> I just started looking into the Sierra stuff.
Jan 11 19:27:45 <holtmann> I also wanna support CnS from Sierra to get some additional direct access to the internals. We will see how this goes.
Jan 11 19:27:45 <xtor> holtmann: me too
Jan 11 19:28:17 <xtor> I just want to support my laptop's embedded module :)
Jan 11 19:28:48 <holtmann> Then go ahead and send patches. Writing a oFono modem plugin is actually simple.
Jan 11 19:34:37 <xtor> holtmann: I'll try, I managed to get my card recognised by list-modems, but with the latest git I will have to test some things again
Jan 11 19:39:34 <xtor> holtmann: btw, how does this OFONO_IFACE_NUM stuff work? I mean, what are those two-digit ids?
Jan 11 19:39:53 <holtmann> They are interface numbers on USB endpoints.
Jan 11 19:41:11 <xtor> are they used in udev.c? I suppose they are related to mapping the different serial ports to control, data, diagnostics, etc
Jan 11 19:46:51 <xtor> or do I need to just use "bInterfaceNumber"? I am a bit confused about bInterfaceNumer vs OFONO_IFACE_NUM... 
Jan 11 19:47:04 <xtor> s/Numer/Number
Jan 11 19:48:29 <holtmann> /proc/bus/usb/devices
Jan 11 19:48:51 <holtmann> C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
Jan 11 19:48:51 <holtmann> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=sierra
Jan 11 19:48:52 <holtmann> Echo_:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Jan 11 19:48:52 <holtmann> Echo_:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Jan 11 19:48:52 <holtmann> I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=sierra
Jan 11 19:48:54 <holtmann> Echo_:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Jan 11 19:48:55 <holtmann> Echo_:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Jan 11 19:48:56 <holtmann> I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=sierra
Jan 11 19:48:58 <holtmann> Echo_:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Jan 11 19:49:00 <holtmann> Echo_:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Jan 11 19:49:00 <Echo_> wtf
Jan 11 19:49:01 <Echo_> wtf
Jan 11 19:49:02 <holtmann> I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=sierra
Jan 11 19:49:02 <Echo_> wtf
Jan 11 19:49:02 <Echo_> wtf
Jan 11 19:49:04 <holtmann> Echo_:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
Jan 11 19:49:06 <holtmann> Echo_:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Jan 11 19:49:08 <holtmann> Echo_:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Jan 11 19:49:10 <holtmann> I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=sierra
Jan 11 19:49:14 <holtmann> Echo_:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
Jan 11 19:49:16 <holtmann> Echo_:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Jan 11 19:49:18 <holtmann> Echo_:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Jan 11 19:49:20 <holtmann> I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=sierra
Jan 11 19:49:22 <holtmann> Echo_:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
Jan 11 19:49:24 <holtmann> Echo_:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Jan 11 19:49:26 <holtmann> Echo_:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Jan 11 19:49:28 <holtmann> I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=sierra
Jan 11 19:49:30 <holtmann> Echo_:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
Jan 11 19:49:32 <holtmann> Echo_:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Jan 11 19:49:33 <Echo_> wtf
Jan 11 19:49:34 <Echo_> wtf
Jan 11 19:49:34 <holtmann> Echo_:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
Jan 11 19:49:34 <Echo_> wtf
Jan 11 19:49:34 <Echo_> wtf
Jan 11 19:49:36 <holtmann> The things listed as If#x are your interface numbers. However they are prefixed with a 0. So 02, 03 etc.
Jan 11 19:49:38 <Echo_> wtf
Jan 11 19:49:38 <Echo_> wtf
Jan 11 19:49:38 <Echo_> wtf
Jan 11 19:49:42 <denkenz> lol
Jan 11 19:49:47 <Echo_> paste it in fucking pastebin man
Jan 11 19:49:49 <xtor> :PPP
Jan 11 19:50:01 <xtor> holtmann: thanks
Jan 11 19:50:15 <denkenz> OFONO_IFACE_NUM is just magic internal to ofono.rules
Jan 11 19:50:23 <holtmann> Echo_: So xchat magic turned it into addressing you ;)
Jan 11 19:50:27 <holtmann> Sorry about that.
Jan 11 19:50:45 <Echo_> lol np
Jan 11 19:51:12 <denkenz> Its a way to forward the interface number that holtmann referred to up to a higher (or is it lower) node in the udev tree
Jan 11 19:51:48 <denkenz> If you don't want to understand, then don't ;)
Jan 11 19:51:58 <denkenz> Just follow what the other udev rules do
Jan 11 19:52:22 <xtor> denkenz: thank you, I prefer the "understand" way ;)
Jan 11 19:52:44 <denkenz> Then have fun, took me a day to figure this out ;)
Jan 11 22:38:48 <sabotage> denkenz: if I read the api docs right... if I call org.ofono.SupplementaryServices.Initiate() and the provided string would require a response, any other app listening to changes in State property could reply, but it would not have the response value, or any way to get it, unless it was expressly passed to it from the originating process, right?
Jan 11 22:42:25 <denkenz> eh?
Jan 11 22:43:11 <denkenz> If you're talking about a USSD dialogue, then the network request is still signaled over D-Bus
Jan 11 22:43:36 <denkenz> you would not be able to obtain the response generated locally, that is correct
Jan 11 22:44:19 <denkenz> But then, what is your concern here?
Jan 11 23:28:13 <sabotage> denkenz: sorry, phone call took me away
Jan 11 23:28:38 <denkenz> no prob
Jan 11 23:29:34 <sabotage> so, not a net req event... but an initiate with a "USSD" result string and ussd_reponse in the varient
Jan 11 23:30:11 <sabotage> when/if this USSD is going to be awaiting a reply... no other app can/will see that ussd_response unless I sent it to them, correct?
Jan 11 23:30:28 <sabotage> where "I" == Initiate() caller
Jan 11 23:30:56 <denkenz> Correct, the *magic* ussds are not really ussds
Jan 11 23:31:13 <denkenz> They are queried slightly differently, and only the initiator will see the response
Jan 11 23:31:16 <sabotage> denkenz: my "concern" is that we were planning to off-load all USSD interactions to external handler, not dialer
Jan 11 23:32:04 <denkenz> IMO that is a bad idea
Jan 11 23:32:12 <sabotage> and according to what you said on the phone, if I call initiate first before I call dial, I will never be able to truely "off-load" USSD interactions to an seperate app
Jan 11 23:32:38 <denkenz> you could, but then you'd have to repeat all the logic in oFono yourself
Jan 11 23:32:39 <sabotage> maybe, but it is the plan, so trying to figure out how viable it is
Jan 11 23:32:42 <denkenz> A bad idea ;)
Jan 11 23:33:20 <sabotage> problem is that by UI design, the "dialer" is not the UI owner for general purpose USSD...
Jan 11 23:33:35 <denkenz> Who is?
Jan 11 23:34:38 <sabotage> seperate USSD listener that would, as necessary, present dialogs/messages for USSD events
Jan 11 23:35:19 <denkenz> You can still do this
Jan 11 23:35:22 <sabotage> so dialer, upon dedecting that string was SS/USSD format, would invoke the external handler to initiate the session
Jan 11 23:35:35 <denkenz> However, I'd still initiate all requests in the dialer
Jan 11 23:35:53 <denkenz> The 'external' handler can take over for network dialogs or network initiated responses
Jan 11 23:36:11 <sabotage> ok, so then again... I would have to pass any "ussd_response" varients to it, correct?
Jan 11 23:36:28 <denkenz> no, I'd handle those in the dialer itself
Jan 11 23:36:56 <sabotage> *wrong* (according to designers at least ...)
Jan 11 23:37:00 <sabotage> ok
Jan 11 23:37:05 <sabotage> so I will pass this along
Jan 11 23:37:08 <denkenz> Have they looked at the iPhone?
Jan 11 23:37:17 <denkenz> That by far has the slickest magic mmi implementation I've seen
Jan 11 23:37:17 <sabotage> don't know
Jan 11 23:38:23 <sabotage> what I'm trying to avoid is this (and tell me if it's even possible or I'm just being paranoid):
Jan 11 23:38:46 <sabotage> string entered is USSD that results in a session that requires user-response
Jan 11 23:39:16 <sabotage> so now dialer must have embedded logic for all USSD session types
Jan 11 23:39:28 <sabotage> this is insane to expect as possible
Jan 11 23:39:53 <denkenz> I think you're just overcomplicating things
Jan 11 23:40:06 <sabotage> willing to accept that ;)
Jan 11 23:40:15 <sabotage> explain how?
Jan 11 23:40:45 <denkenz> So forget about MMIs for now, for simple USSDs your job is easy
Jan 11 23:40:52 <denkenz> you initiate, and get back a response
Jan 11 23:41:21 <denkenz> optionally there might be a network dialog, but that's just an input dialog away from being done
Jan 11 23:41:26 <sabotage> by "simple USSDs" do you mean standard GSM SS types?
Jan 11 23:41:42 <denkenz> yeah, things like recharging your account, etc
Jan 11 23:42:27 <denkenz> For network initiated ussds you can let the home screen handle it, but again, it is just a text dialog / input dialog away from being done
Jan 11 23:42:53 <denkenz> For the magic MMI ones oFono does all the hard work
Jan 11 23:43:09 <denkenz> All you really need to do is build a grid to present the information
Jan 11 23:43:34 <sabotage> ok, but all it takes is some custom manufacturer SS of SIM control procedure and now the potential for what needs to be handled is completely unknown, no?
Jan 11 23:43:59 <denkenz> There are no such custom procedures
Jan 11 23:44:12 <sabotage> guarenteed ;)
Jan 11 23:44:13 <denkenz> The ones documented in doc/supplementary-services.txt are all there are
Jan 11 23:44:33 <sabotage> those are SS, sure, but what about USSD
Jan 11 23:44:44 <denkenz> USSD is always text
Jan 11 23:44:50 <sabotage> by definition, those are undefined and custom
Jan 11 23:44:56 <denkenz> no magic structure
Jan 11 23:44:57 <sabotage> is it
Jan 11 23:45:01 <denkenz> yes
Jan 11 23:45:11 <sabotage> no response requested for special types?
Jan 11 23:45:29 <denkenz> nope, its just text
Jan 11 23:45:55 <denkenz>         "USSD"                          string ussd_response
Jan 11 23:45:58 <denkenz> we do mean that ;)
Jan 11 23:47:04 <sabotage> I guess what was/is not clear is what "ussd_response" *could* be
Jan 11 23:47:20 <denkenz> text ;)
Jan 11 23:47:24 <sabotage> moreover, that we could then be in a "State" of "user-response"
Jan 11 23:47:50 <sabotage> but is that text that is asking for more input to continue the session?
Jan 11 23:48:06 <denkenz> Basically it might go something like this:
Jan 11 23:48:15 <denkenz> ussd.Initiate("*300#")
Jan 11 23:48:18 <sabotage> this is the uncertainty the created the desire to off-load all USSD interactions
Jan 11 23:48:55 <denkenz> ---> "Would you like to recharge by 1. Credit Card\r2. Bank\r3. Abort"
Jan 11 23:49:07 <denkenz> ussd.Respond("3")
Jan 11 23:49:12 <denkenz> ----> OK
Jan 11 23:49:45 <denkenz> nothing more complicated will happen
Jan 11 23:50:22 <sabotage> so never need to translate the text into buttons, toggles, drop-downs, etc...
Jan 11 23:50:37 <denkenz> no
Jan 11 23:50:47 <sabotage> just present the message and (if user-reposnse is the state) a text entry?
Jan 11 23:51:25 <sabotage> is it correct to assume that if the state is not user-response, then we only need to present the message?
Jan 11 23:51:33 <denkenz> correct
Jan 11 23:52:29 <sabotage> can any process invoke the USSD.response()... IOW, the session is "global" until complete or canceled, right?
Jan 11 23:53:42 <denkenz> correct, however that is up to the security framework to enforce
Jan 11 23:54:07 <sabotage> meh
Jan 11 23:54:09 <sabotage> ;)
Jan 11 23:55:10 <sabotage> ok, on related subject... it was not clear from the docs what response would be received if I call ussd.initiate("5551212")...
Jan 11 23:55:26 <denkenz> InvalidFormat
Jan 11 23:55:27 <sabotage> on the call you said I would get some error or other
Jan 11 23:55:31 <sabotage> ok
Jan 11 23:55:37 <sabotage> thanks
Jan 11 23:56:10 <sabotage> think I got my head around this now, sorry for the churn
**** ENDING LOGGING AT Wed Jan 12 02:59:58 2011