**** BEGIN LOGGING AT Sun Jul 18 02:59:56 2010
Jul 18 16:21:02 <fsteinel> denkenz: Thanks for the email. I can't get the sim into the online state on huawei e176.
Jul 19 01:49:34 <holtmann> denkenz: So about the bluetooth stuff.
Jul 19 01:49:59 <holtmann> How are we planning to do DUN? Purely as a plugin with its own D-Bus interfaces. Or as a separate daemon?
Jul 19 01:51:11 <denkenz> which DUN profile?
Jul 19 01:51:30 <denkenz> The thought is to do DUN client as separate daemon (for the silly dial string stuff)
Jul 19 01:51:52 <denkenz> and the DUN server as part of a greater modem emulator framework being atom based inside oFono core
Jul 19 01:51:54 <holtmann> For DUN server, I think we do an atom, right?
Jul 19 01:52:07 <holtmann> So now what about the client?
Jul 19 01:52:22 <denkenz> separate daemon
Jul 19 01:52:42 <holtmann> Something like we do with obex-client? So for example dialup-client.
Jul 19 01:53:11 <denkenz> I've never peeked into that one, but basically something like a stripped down oFono
Jul 19 01:53:24 <denkenz> it can listen to BlueZ dun uuids
Jul 19 01:53:34 <denkenz> create modem objects with a simple interface
Jul 19 01:53:44 <denkenz> like Connect/Disconnect + Dial String property
Jul 19 01:54:06 <denkenz> Then ppp connection info gets emitted similar to how oFono does it
Jul 19 01:54:16 <holtmann> So basically gsmdial with D-Bus interface.
Jul 19 01:54:37 <denkenz> Yep, a fancy gsmdial
Jul 19 01:55:24 <denkenz> Hence why I want bluetooth stuff as a separate lib
Jul 19 01:55:35 <holtmann> Are we using purely TTY's as base? Or also direct Bluetooth RFCOMM socket magic?
Jul 19 01:55:53 <denkenz> I was assuming same setup as HFP
Jul 19 01:56:10 <denkenz> e.g. BlueZ DUN client interface + Agent
Jul 19 01:56:14 <denkenz> then fd passing
Jul 19 01:57:33 <holtmann> Actually. Doing similar to org.bluez.Network.Connect() would be better.
Jul 19 01:57:40 <holtmann> It is more similar to PAN.
Jul 19 01:57:56 <holtmann> You connect/dial and you get a network interface back.
Jul 19 01:57:58 <denkenz> I'm not sure the Agent is really needed for DUN
Jul 19 01:58:01 <holtmann> Would make it easier for ConnMan to use.
Jul 19 01:58:26 <denkenz> Probably .Connect/.Disconnect on oFono side and oFono simply owns the connection might be easier
Jul 19 01:58:35 <holtmann> BlueZ has a org.bluez.Serial.Connect() that can connect to DUN, but it just gives you a TTY back.
Jul 19 01:58:54 <denkenz> Just use BlueZ for device UUID tracking
Jul 19 01:59:03 <denkenz> And create modem devices automagically
Jul 19 01:59:31 <holtmann> Also we can adjust this internally. Initially use Serial.Connect() and TTY. Then later switch to direct RFCOMM socket.
Jul 19 01:59:35 <denkenz> Honestly I think bluez.Serial is overkill for this, especially once we run PPP
Jul 19 01:59:49 <denkenz> Doing a direct socket is way better
Jul 19 01:59:58 <holtmann> I want this similar to PAN interface. ConnMan calls a method and gets a network interface as result.
Jul 19 02:00:41 <denkenz> Sure, but connman doesn't see the details of tty vs socket
Jul 19 02:00:50 <holtmann> It doesn't care.
Jul 19 02:00:52 <denkenz> So we might as well do it right the first time
Jul 19 02:01:04 <denkenz> Especially since we know we want to go in that direction anyway
Jul 19 02:01:32 <holtmann> My only point here is that eventually a dialup-client should also be capable to be used over USB with ttyACM0.
Jul 19 02:02:09 <denkenz> Yeah, this is up to padovan
Jul 19 02:02:22 <denkenz> We can probably do a very similar setup with drivers & jazz 
Jul 19 02:02:28 <denkenz> just like mini-ofono
Jul 19 02:02:42 <holtmann> Not sure if that much is needed. USB is pretty static.
Jul 19 02:02:59 <holtmann> So to summarize.
Jul 19 02:03:05 <denkenz> You still need at least basic powered / presence tracking
Jul 19 02:03:17 <holtmann> We concentrate all bluetooth handling in bluetooth/ directory.
Jul 19 02:03:23 <denkenz> After that its just a socket
Jul 19 02:03:38 <holtmann> Then we can create a dialup/ directory for the dialup-client daemon.
Jul 19 02:05:02 <denkenz> We can argue about names later, but yes that's what I'm thinking
Jul 19 02:05:23 <denkenz> bluetooth/ with general BlueZ utilities, dialup/ with the dund
Jul 19 02:06:40 <holtmann> I do wanna support dialup over USB as well. If this means we do some udev magic to detect USB modems and alike and not interfere with oFono itself, then that is what we have to do.
Jul 19 02:07:51 <denkenz> Yeah, I think we should get proper present / powered logic inside dund
Jul 19 02:08:03 <denkenz> Similar to how we do it in oFono
Jul 19 02:08:08 <denkenz> But waay simpler
Jul 19 02:08:15 <holtmann> Strictly speaking from a Profile point of view, that should not be needed.
Jul 19 02:08:20 <denkenz> Then we can support fds from bluetooth or usb
Jul 19 02:08:37 <holtmann> However I assume that most modems are just fucked up anyway.
Jul 19 02:08:38 <denkenz> Or even TCP/IP :P
Jul 19 02:09:23 <denkenz> Yeah I know, if the dial string wasn't necessary we could have made it an oFono atom driver
Jul 19 02:10:03 <denkenz> But we'd need to fake some netreg / sim logic, so its a wash
Jul 19 02:10:16 <holtmann> You don't see a way that we can make this work as an atom driver?
Jul 19 02:10:23 <holtmann> Like some special modem quirk?
Jul 19 02:10:48 <denkenz> The core has lots of baggage for something this simple
Jul 19 02:11:01 <denkenz> e.g. sim pin, sim presence, netreg suitability, attachment
Jul 19 02:11:19 <denkenz> We probably could make it work, but we'd have to short circuit alot of paths
Jul 19 02:11:36 <holtmann> So from a ConnMan point of view speaking it would be nice.
Jul 19 02:11:44 <holtmann> We save a lot of logic there.
Jul 19 02:12:11 <holtmann> Since in the end we just care about if it is a real full blown modem or just a dialup. And that we can easily export.
Jul 19 02:13:04 <denkenz> My feeling right now is that unnecessary complexity within the core of oFono is too much crud
Jul 19 02:13:15 <denkenz> However, what we *can* do is use the atmodem driver statically
Jul 19 02:13:30 <denkenz> That way all the ppp magic comes for free
Jul 19 02:13:53 <holtmann> My problem currently is that we would have two daemons running where we could just have one.
Jul 19 02:14:45 <denkenz> Sure, but there's also overhead in using oFono setup, since we'd require extra objects
Jul 19 02:14:56 <holtmann> As much baggage oFono carries around, it would need to run anyway. So why not just use it.
Jul 19 02:15:36 <holtmann> So the Bluetooth plugin would have to create modems (with dialup marker set) for every Bluetooth DUN device we have paired.
Jul 19 02:15:46 <denkenz> I'm not set in stone either way actually, just thinking that surgery inside oFono core for this feature might be too invasive
Jul 19 02:16:17 <denkenz> lots of paths to check, and the logic for GPRS is actually nasty
Jul 19 02:16:34 <holtmann> Lets assume we need the SIM atom, netreg ATOM and GPRS. Wouldn't we just get away with it.
Jul 19 02:17:16 <denkenz> We would if the driver provides a custom interface for setting the Dial string
Jul 19 02:17:22 <holtmann> Best would be to just do SIM + GPRS actually. netreg + GPRS and one GAtChat is actually nasty.
Jul 19 02:17:47 <denkenz> netreg would just return fake info
Jul 19 02:17:49 <holtmann> Why do we bother with the dial string. Aren't they suppose to support CGDATA anyway. And if not we can map it.
Jul 19 02:18:07 <holtmann> Or that, a special dunmodem/netreg.c driver.
Jul 19 02:18:09 <denkenz> Some modems actually require +CGDCONT
Jul 19 02:18:18 <denkenz> and ATD*99
Jul 19 02:18:27 <denkenz> + some people use weird contexts for dialup
Jul 19 02:18:53 <holtmann> Fair enough. Then it will just fail in some cases.
Jul 19 02:19:19 <denkenz> Faking netreg and sim can be done
Jul 19 02:19:48 <denkenz> Its the context setup / dial string that is a bit nasty
Jul 19 02:19:58 <denkenz> And the complexity of using oFono API for something as simple as DUN
Jul 19 02:20:20 <holtmann> oFono API is not really that complex. And ConnMan already supports it anyway ;)
Jul 19 02:20:47 <denkenz> Yeah, but your autoconfig magic for PrimaryContexts won't work for instance
Jul 19 02:20:57 <denkenz> so someone has to go in and setup the dial string
Jul 19 02:21:08 <holtmann> That is something that is nasty anyway and I wanna get rid off.
Jul 19 02:21:25 <denkenz> Also, the context info is actually useless
Jul 19 02:21:29 <holtmann> We have to figure that out anyway.
Jul 19 02:21:36 <denkenz> You really want the dial string and not the context info
Jul 19 02:21:57 <holtmann> Why?
Jul 19 02:22:11 <holtmann> We can't present that to the end users anyway.
Jul 19 02:22:37 <holtmann> Asking them for APN is a complicated enough question.
Jul 19 02:23:06 <denkenz> Fair enough, we might need some testing here
Jul 19 02:23:19 <holtmann> We could ask for APN and CID if we want a bit more flexibility, but dial string. They can't answer.
Jul 19 02:23:21 <denkenz> If 99% of the market simply does a CGDCONT=1,IP,apn
Jul 19 02:23:39 <denkenz> Then we can simply use oFono atom driver and be done with it
Jul 19 02:23:41 <holtmann> Even the APN question to the shop that sold you the SIM card is sometimes too much. They are clueless.
Jul 19 02:24:09 <holtmann> So my Novatel card on Apple MacOS X asks me for APN and CID. That is it.
Jul 19 02:24:23 <holtmann> Besides the username/password stuff if I want to.
Jul 19 02:24:50 <holtmann> Maybe we just add an extra property for CID and if != 0 then we use that.
Jul 19 02:25:24 <denkenz> CID is a bit funny because we actually manage uniqueness internally
Jul 19 02:25:37 <denkenz> But we can think of something
Jul 19 02:25:59 <denkenz> So I'm fine doing it this way too
Jul 19 02:26:08 <holtmann> I know. Initially I would just try 1 and then see what actually fails.
Jul 19 02:26:28 <denkenz> You do get alot of stuff for free doing it this way
Jul 19 02:26:36 <denkenz> But you need to fake some info
Jul 19 02:26:39 <holtmann> Maybe these are all rumors of people having had problems, but they were clueless what they were doing.
Jul 19 02:27:02 <holtmann> I could be that 99% really will just work.
Jul 19 02:28:52 <denkenz> If we go this direction then bluetooth.c can remain in plugins
Jul 19 02:28:59 <denkenz> Though we can still make it a separate lib
Jul 19 02:29:11 <denkenz> I have no preference there
Jul 19 02:29:52 <denkenz> We can dump some btio stuff from bluez for use by oFono plugins
Jul 19 02:30:38 <holtmann> Could be a bit overhead since we only care about RFCOMM clients.
Jul 19 02:30:47 <holtmann> The BtIO is more for server connections.
Jul 19 02:30:55 <denkenz> We need both eventually
Jul 19 02:31:00 <denkenz> e.g. for DUN Server
Jul 19 02:31:33 <holtmann> That needs some extra looking into, but in general we can.
Jul 19 02:31:54 <denkenz> Yeah we don't have to solve it now, let it evolve
Jul 19 02:31:56 <holtmann> So I am all for doing a fake SIM and netreg dunmodem atom driver.
Jul 19 02:32:00 <denkenz> But something to keep in mind
Jul 19 02:32:25 <denkenz> So lets do this for now, keep bluetooth.c the way it is in plugins/
Jul 19 02:32:31 <holtmann> We will make that a standalone library. Just need to get the Bluetooth 4.0 work sorted out first. It might change some details in actually.
Jul 19 02:32:33 <denkenz> Have padovan try the atom approach
Jul 19 02:32:42 <denkenz> And see how far we get
Jul 19 02:33:51 <holtmann> So the only part left is that when activating the context, we need to establish the Bluetooth connection first.
Jul 19 02:34:14 <holtmann> And we need a special marker in the modem properties so that ConnMan can tell that this is dialup thing.
Jul 19 02:35:08 <denkenz> Yeah, the semantics of powered are going to be funny
Jul 19 02:35:51 <holtmann> Anyway it is worth a try.
Jul 19 02:36:05 <holtmann> padovan: I assume you are reading the backlog here. Go with the atom approach for DUN client.
Jul 19 02:36:15 <holtmann> And see how far you get with it.
Jul 19 02:36:25 <denkenz> sure, just it has some funny problems
Jul 19 02:36:50 <denkenz> But maybe they are minimal enough the positives outweigh the negatives
Jul 19 02:41:24 <holtmann> I would almost assume so. However we only know after we tried.
**** ENDING LOGGING AT Mon Jul 19 02:59:56 2010