**** BEGIN LOGGING AT Fri Jun 25 02:59:57 2010
Jun 25 03:00:00 <denkenz> zhenhua: So in your log, pppd is the client right?
Jun 25 03:00:06 <zhenhua> yes
Jun 25 03:00:16 <zhenhua> pppd is client side
Jun 25 03:00:44 <denkenz> So log looks fine, I think there's a way to tell pppd not to ask for the remote address
Jun 25 03:01:51 <zhenhua> don't know if pppd has option to stop asking remote addr
Jun 25 03:02:10 <zhenhua> but i add such code in our ppp client side like pppd does
Jun 25 03:02:21 <zhenhua> i suggest to remove NBNS at all
Jun 25 03:02:27 <zhenhua> both for client and server
Jun 25 03:02:42 <denkenz> Keep it for client for now, no harm in it
Jun 25 03:03:07 <denkenz> For server feel free to remove them if you make the default: label work
Jun 25 03:03:09 <zhenhua> okay, anyway.
Jun 25 03:03:39 <zhenhua> yes, i already update the patch locally.
Jun 25 03:03:47 <denkenz> Ok, then send it in
Jun 25 03:04:12 <zhenhua> for client, also reject unknown option, right?
Jun 25 03:04:35 <denkenz> That would be more correct, yes
Jun 25 03:04:37 <zhenhua> i means default label only, not for DNS, NBNS
Jun 25 03:05:39 <denkenz> Any other concerns?
Jun 25 03:07:47 <zhenhua> nothing
Jun 25 04:43:12 <denkenz> kvalo: Once you get done with your Huawei HUP patch, can you also send a patch to the TODO list to remove the 'PPP context' task and update doc/overview.txt?
Jun 25 04:43:38 <denkenz> kvalo: I think we can call PPP more or less done
Jun 25 06:16:13 <kvalo> denkenz: sure, I can do that. but not today, I'm taking day off :)
Jun 25 06:16:30 <kvalo> denkenz: what about ipv6?
Jun 25 13:12:36 <denkenz> kvalo: The way we do this is to close the original task and make a new one
Jun 25 13:13:38 <denkenz> kvalo: So feel free to add IPv6 support task to the TODO
Jun 25 15:29:19 <denkenz> wagi: I'm giving up on tech reporting for a while :P
Jun 25 15:31:26 <wagi> denkenz: oh, I hope it's not me
Jun 25 15:33:28 <wagi> in the last series I did only realy on notifcation for getting the initial CurrentTechnology update
Jun 25 15:34:08 <wagi> because HSO does not allow to ask for OSSYSI
Jun 25 15:35:41 <denkenz> no its not you
Jun 25 15:36:07 <wagi> uff :)
Jun 25 15:36:09 <denkenz> Just all hardware acts way too different
Jun 25 15:36:16 <denkenz> So we need to step back a bit
Jun 25 15:37:13 <wagi> okay, so adding all those quirk into atmodem.c or gprs.c is really an option
Jun 25 15:37:37 <denkenz> Yeah, but I'm not sure about introducing the Tech field into DCM
Jun 25 15:39:16 <wagi> we'd like to some simple tech messurements, e.g. in which area do we have what kind of tech to do some prediction. Don't know if this is feasable or not
Jun 25 15:39:35 <denkenz> Well let me send my email, we can discuss in ~5 min
Jun 25 15:39:42 <wagi> okay
Jun 25 15:54:41 <wagi> I'm back in 30min
Jun 25 15:55:09 <holtmann> denkenz: I think we need to have the tech reporting in DCM.
Jun 25 15:55:15 <holtmann> Just for stupid UI reasons.
Jun 25 15:55:49 <denkenz> We have to be careful here
Jun 25 15:56:06 <denkenz> There are several layers of this tech reporting, as I've said
Jun 25 15:56:36 <holtmann> I fully see the problem, but from a UI point of view, we need GSM, GPRS, EDGE, UMTS, HSPA reporting of the data connection.
Jun 25 15:56:43 <holtmann> For voice calls GSM and UMTS would be enough.
Jun 25 15:57:04 <holtmann> Don't ask me for the solution, I just mention what a UI requirement we have on our API that is exposed to the panel icon.
Jun 25 15:57:31 <denkenz> So today we already have that anyway
Jun 25 15:57:37 <denkenz> except maybe for HSO
Jun 25 15:57:55 <denkenz> But then HSO just never reports hspa/hsupa/hspa
Jun 25 15:58:06 <denkenz> still reports gsm/gprs/edge/umts
Jun 25 15:59:30 <holtmann> I know. My view is just purely from the UI point of view. If the hardware can't do it, then so be it.
Jun 25 16:01:35 <denkenz> Nod, I'm also trying to be nice to the UI and report this sanely
Jun 25 16:01:57 <denkenz> We could just say this is a pure display attribute, with no atomicity
Jun 25 16:02:29 <denkenz> So if tech gets reported to be UMTS while we're not registered, we'd allow that, etc
Jun 25 16:08:30 <holtmann> I disagree. If we are not registered then tech should be reported as none.
Jun 25 16:08:46 <holtmann> The less the UI has to "think" the better :)
Jun 25 16:09:16 <denkenz> This is the ideal, however some hw just makes this impossible to do nicely
Jun 25 16:09:17 <holtmann> But then again, we could also just delay tech updates be a second or two. From a UI point of view that is not a big deal.
Jun 25 16:09:27 <holtmann> s/be/by/
Jun 25 16:09:32 <denkenz> Actually that won't work
Jun 25 16:09:46 <holtmann> We do this inside ConnMan since other the UI shits itself in some cases.
Jun 25 16:09:59 <denkenz> for instance, my Huawei can be reporting mode while it never actually registers
Jun 25 16:10:05 <denkenz> And I mean minutes / hours
Jun 25 16:10:21 <denkenz> Same with MBM actually
Jun 25 16:10:45 <holtmann> So it gets a bit complicated, but hey that is what oFono is suppose to solve. Get rid of this stupid HW details for the UI.
Jun 25 16:11:00 <holtmann> We have to find a way. Even if it makes us hate the HW even more.
Jun 25 16:11:00 <denkenz> You're preaching to the choir here
Jun 25 16:11:09 <denkenz> My mail was mostly about wtf do we do now?
Jun 25 16:11:28 <denkenz> Personally I'm out of ideas on how to do this nicely
Jun 25 16:11:40 <holtmann> And I feel your pain. Don't get me wrong. I really see the problem and I have thrown all my dongles out of the window, but then picked it up again ;)
Jun 25 16:11:40 <denkenz> The current way is about the best I can come up with
Jun 25 16:17:00 <holtmann> Btw. on top of that, my older HSO device is not supported all tech reporting commands. Don't remember which ones were missing.
Jun 25 16:17:20 <holtmann> I have started to document this all with hardware models and examples, but I am not done yet.
Jun 25 16:17:35 <holtmann> So firmware updates for HSO with fixes for this crap would be nice.
Jun 25 16:18:35 <denkenz> yeah, _OUWCTI doesn't work on older HSO devices
Jun 25 16:37:09 <wagi> CPSB is what I was hoping to get somehow. But after reading your mail, this sounds like it isn't really possible
Jun 25 16:37:46 <denkenz> wagi: CPSB is not supported on vast majority of the dongles I have, I think its a fairly recent addition to the spec
Jun 25 16:38:57 <wagi> propably to get those OCTI & co. away
Jun 25 16:39:39 <denkenz> it seems octi really maps to +CREG <tech> attribute
Jun 25 16:39:49 <denkenz> However, HSO does not report <tech> in CREG
Jun 25 16:39:57 <denkenz> or CGREG for that matter
Jun 25 16:41:14 <wagi> What is now the conclusion? No CurrentTechnology at all? Or just 'best effort' style as my patches try to do it?
Jun 25 16:41:45 <denkenz> I have no idea, I'm basically out of ideas myself
Jun 25 16:42:15 <denkenz> Reporting CPSB style tech in DCM could be useful, but with no hw that supports it... sort of silly
Jun 25 16:44:19 <wagi> So HSO's OSSYSI is only a half working CPSB in the end. Damn, I hoped that would work better
Jun 25 16:44:36 <denkenz> What we have in git today seems to cover all cases nicely with the exception of HSO
Jun 25 16:44:50 <denkenz> And there its only because _OUWCTI is kinda weird
Jun 25 16:44:51 <wagi> Maybe I can get real measurement equiment from Scharz&Rhode :)
Jun 25 16:45:33 <denkenz> I'm sure you can get more info using Neighbor Cell queries
Jun 25 16:45:45 <denkenz> Those types of commands typically give more information
Jun 25 16:46:09 <denkenz> But they're also highly vendor specific ;)
Jun 25 16:46:24 <wagi> ahh, I knew there is a catch :)
Jun 25 16:46:52 <denkenz> balrog-k1n: Ok, so I can see both ways working and both ways having problems for the STK API
Jun 25 16:47:46 <denkenz> balrog-k1n: At least Qtopia does the unified approach, so I'm actually fine going in that direction
Jun 25 16:51:10 <denkenz> balrog-k1n: The one thing I sort of don't like is the tuple return from Menu() though
Jun 25 16:51:31 <denkenz> balrog-k1n: bit nasty to map in C/C++, but can be done I guess
Jun 25 16:51:54 <wagi> I think I'm going to use just a different modem then. 
Jun 25 16:52:45 <denkenz> They all have problems, but at least my MBM F3607gw works with EPSB
Jun 25 16:52:52 <denkenz> The older F3507 doesn't
Jun 25 16:53:26 <wagi> it's not easy to get those ones
Jun 25 16:54:10 <denkenz> Easy if you're willing to get a Netbook or the PCIX card
Jun 25 16:54:59 <wagi> Which netbook do I have to order? :)
Jun 25 16:55:59 <denkenz> Dell ships them AFAIK
Jun 25 17:00:02 <sameo> denkenz: once I get a DataConnectionManager signal letting me know that GPRS is attached, I should be able to activate my primary context(s), right ?
Jun 25 17:00:12 <denkenz> yep
Jun 25 17:02:30 <sameo> ok, then we might have a race there. I do get the Attached signal, but then when I try to activate my primary context after that, I get a "GPRS Attach is in progress" error.
Jun 25 17:02:49 <denkenz> eek
Jun 25 17:03:16 <sameo> this happens always when I get the network name asynchronously.
Jun 25 17:05:04 <denkenz> yes, there's a race
Jun 25 17:06:39 <sameo> do you want me to look at it, or is it something you can easily fix ?
Jun 25 17:07:13 <wagi> denkenz: thanks. at least I know now that CPSB is not here yet. 
Jun 25 17:07:38 <denkenz> sameo: beware, there be dragons
Jun 25 17:08:46 <denkenz> sameo: I think I have a fix, give me a sec
Jun 25 17:09:18 <sameo> denkenz: thanks, I have enough dragons with ConnMan ;)
Jun 25 17:19:37 <denkenz> sameo: I mailed you a patch to try
Jun 25 17:22:28 <sameo> denkenz: thanks, testing it.
Jun 25 18:03:09 <sameo> denkenz: it seems the race is fixed now.
Jun 25 18:07:11 <denkenz> sameo: Ok good, I'll push it later today
Jun 25 18:07:22 <sameo> denkenz: many thanks
Jun 25 22:27:39 <holtmann> +				"cs" - Circuit Switched only
Jun 25 22:27:39 <holtmann> +				"ps" - Packet Domain only
Jun 25 22:27:40 <holtmann> +				"cs_preferred" - Use PS if CS is unavailable
Jun 25 22:27:40 <holtmann> +				"ps_preferred" - Use CS if PS is unavailable
Jun 25 22:27:47 <holtmann> denkenz: Really?
Jun 25 22:28:29 <holtmann> Do we need the preferred part?
Jun 25 22:30:02 <denkenz> Yeah, there are cells with no gprs, or cells with only gprs
Jun 25 22:30:45 <denkenz> we can rename them however
Jun 25 22:31:24 <denkenz> Also consider roaming cases
Jun 25 22:31:35 <denkenz> where you're forcing a detach
Jun 25 22:40:34 <holtmann> I was more thinking along the way cs = means try CS and fallback to PS. And ps = try PS and fallback to CS.
Jun 25 22:40:44 <holtmann> Is there a use case to force only one.
Jun 25 22:40:58 <denkenz> Maybe regulatory
Jun 25 22:41:06 <holtmann> Should it not always be a preferred setting.
Jun 25 22:41:20 <denkenz> It might be countries really don't want you to ever send CS
Jun 25 22:41:22 <holtmann> And for regulatory having a config file option seems better.
Jun 25 22:41:57 <holtmann> So the Bearer property selects the preferred one. And a config file does cs only, ps only or any.
Jun 25 22:42:01 <denkenz> Thought about it, but then I do 2x the work
Jun 25 22:42:18 <denkenz> And not much benefit
Jun 25 22:42:34 <holtmann> Fair enough, but if we care about regulatory then we need to protect against changes via end users.
Jun 25 22:42:54 <denkenz> That is up to PolicyKit
Jun 25 22:43:22 <holtmann> Not sure about it, but we can also fix that later on.
Jun 25 22:43:51 <denkenz> Honestly I've seen this setting on some phones
Jun 25 22:44:01 <denkenz> So if some OEM wants to enable this in the UI, let them
Jun 25 22:44:24 <holtmann> What about having PreferredBearer and Bearer properties.
Jun 25 22:44:27 <denkenz> Just like 'UseDeliveryReports' or 'ServiceCenterAddress' I see no harm in it
Jun 25 22:44:46 <denkenz> What would that do?
Jun 25 22:45:09 <holtmann> No idea. I am just throwing ideas around. I am not 100% sold on the current one.
Jun 25 22:45:26 <holtmann> I really think that exposing regulatory settings via D-Bus is a bad idea.
Jun 25 22:46:13 <denkenz> Well, unless you do something like PrimaryBearer / SecondaryBearer
Jun 25 22:46:26 <denkenz> But then you're back to cs_preferred, just in a roundabout way ;)
Jun 25 22:47:03 <holtmann> Btw. can we at least rename them to cs-only, ps-only, cs-preferred, ps-preferred. The _ bugs me since we don't use in any D-Bus strings. And ConnMan uses - actually.
Jun 25 22:47:19 <denkenz> That's fine with me
Jun 25 22:50:16 <denkenz> done
Jun 25 22:50:40 <holtmann> Sweet. Thanks.
Jun 25 22:51:25 <holtmann> What is our default btw.?
Jun 25 22:51:37 <denkenz> CS Preferred
Jun 25 22:51:45 <denkenz> That is basically the default on every modem I've ever seen
Jun 25 22:51:58 <holtmann> So it is a modem setting and not a SIM setting?
Jun 25 22:52:03 <denkenz> correct
Jun 25 22:52:18 <holtmann> Fine with me. Did you mention it in the API docs?
Jun 25 22:52:20 <denkenz> We do store it in the settings
Jun 25 22:52:34 <denkenz> The default?
Jun 25 22:52:43 <denkenz> Nope I didn't, good point ;)
Jun 25 22:52:44 <holtmann> Yes.
Jun 25 22:52:54 <holtmann> Please add that then.
Jun 25 22:53:46 <denkenz> ok, done
Jun 25 22:58:08 <holtmann> kvalo: I want your Huawei HUP patches. And then I can make a new release ;)
Jun 25 22:58:20 <holtmann> denkenz: Do you have anything major pending?
Jun 25 22:58:33 <holtmann> Target date is late Monday or Tuesday for me.
Jun 25 22:58:52 <denkenz> The only thing I didn't get to today was the PPP server patches
Jun 25 22:59:08 <denkenz> Last version was pretty close, so probably that will go in
Jun 25 22:59:13 <denkenz> Otherwise we should be ready for release
Jun 25 23:02:39 <holtmann> Okay. Sounds good.
**** ENDING LOGGING AT Sat Jun 26 02:59:57 2010