**** BEGIN LOGGING AT Fri Jan 21 02:59:57 2011 Jan 21 03:48:22 denkenz, ping Jan 21 05:16:49 hi, does ofono support cdma2000 currently? Jan 21 05:20:05 currently, CDMA support is very minimal Jan 21 05:21:13 If I Jan 21 05:21:35 addition of support is ongoing. it would be nice you send your questions to ofono.org Jan 21 05:21:42 've understood correctly, CDMA is registered to QualComm, but W-CDMA is more open standard. How about that? Jan 21 05:22:21 s Jan 21 05:22:43 you mean mailing list_ Jan 21 05:22:49 ? Jan 21 05:22:58 ofono@ofono.org Jan 21 05:23:08 s Jan 21 05:25:01 ok thanks. Actually I'm just curious about the support atm. Might be interested to participate for adding support for CDMA techs Jan 21 06:19:29 denkenz, holtmann: ping **** BEGIN LOGGING AT Fri Jan 21 07:52:17 2011 Jan 21 07:56:18 Jeevaka: What's up? Jan 21 08:03:22 found an issue with isimodem for incoming call reject case Jan 21 08:05:10 holtmann: wanted to know whether i can submit a patch for the issue in isimodem? Jan 21 08:05:27 Jeevaka: Of course you can. Jan 21 08:06:01 We might have to wait for Aki and Pekka to review it in case I don't the detail, but of course you can submit a patch for it. Jan 21 08:39:18 Jeevaka: So that is really patch that Aki or Pekka has to ack. I have no idea if this is correct or not. Jan 21 08:40:00 holtmann: ok. patch verified with n900 Jan 21 08:40:40 Jeevaka: I don't doubt you. I just don't have the ISI specification to review it properly. Jan 21 09:32:29 Hello, I was wondering if anybody can shed some light on "Airplane"/"online" mode of ofono. How does this property kill the antenna? I can't find any rfkill stuff in ofono. thanks! Jan 21 09:32:50 denkenz: any pointers ? Jan 21 09:39:10 holtmann: I got it, but its actually intended as info :) Jan 21 09:39:38 alokb: It is suppose to put the antennas off. Jan 21 09:39:53 Depends a little bit on the hardware, but for all proper hardware it will kill the antennas. Jan 21 09:40:34 holtmann: hmmm ok. do cellular antennas drivers use rfkill ? Jan 21 09:40:44 Some of them do. Jan 21 09:40:48 Most of them don't. Jan 21 09:43:31 holtmann: hmm ok thanks. Do you think its a good idea to let connman handle "offlinemode"/"airplane" centrally for cellular, wlan, bt, gps, fm and nfc antennas ? Jan 21 09:43:45 Yes. I think that is a good idea. Jan 21 09:43:53 I agree. Jan 21 09:43:56 The UI will only expose one big button anyway. Jan 21 09:44:07 So we have to hide all the nasty details here. Jan 21 09:45:21 holtmann: hmmm. If cellular drivers are not using rfkill , that means connman has to talk to ofono to kill them. Jan 21 09:47:28 Yes. It has to do that anyway. Jan 21 09:47:55 alokb: drivers not using rfkill doesn't mean they're not capable of turning their antennas off, just that they're not exposing this feature through the rfkill API. Jan 21 09:48:15 So some cellular driver might have switches to kill the antenna (my Gobi hardware in my laptop for example), but additionally we also need to tell oFono about that cellular needs to go in offline mode. Jan 21 09:48:51 On my other laptop the rfkill switch for cellular takes the device off the bus (like with Bluetooth). For the Gobi ones it stays on the bus. Jan 21 09:49:29 holtmann, hmmm. we ofono can always listen to rfkill signals and alter its states. but the problem is there is no consistency in the way cellular drivers are exposing the RF interface. Jan 21 09:49:36 s/we/well Jan 21 09:50:37 holtmann: so its a good idea to let ofono handle this. Jan 21 09:54:27 cellular rfkill switches are all platform switches. Jan 21 09:54:53 Essentially ConnMan has to tell oFono to go offline and then CHANGE_ALL for WWAN. Jan 21 10:04:19 holtmann: it could have been simpler with rfkill, so u actually do "rfkill block all" and all RF components are switched off. and ofono listens to rfkill signal and alter its state accordingly Jan 21 10:04:51 Will not work. We don't know which ones got modified. Jan 21 10:05:09 As I said, they are all platform switches. Jan 21 10:13:33 holtmann: why wouldnt we know which ones got modified? we will get rfkill events (even from the platform switches), no? Jan 21 10:13:57 And then, how you match it. Jan 21 10:14:49 Same problem as with Bluetooth. Jan 21 10:15:48 holtmann: ahh right. there is definitely an issue with matching. Jan 21 10:16:24 Hence it is always OP_CHANGE_ALL and then fix up the rest. In case of oFono we just have to fix up all. Since there needs further action. Jan 21 10:16:54 holtmann: got it Jan 21 10:40:51 hi in ofono-0.39 is there any sample python script showing how to start 3G connection? Jan 21 10:50:57 hi in ofono-0.39 is their any sample python script to show how to start3g connection on usb modem Jan 21 12:35:24 Does anyone know how you tell the ofono Cell Broadcast code what channel you want to listen to? Jan 21 12:37:25 There's a tool in the test directory if I remember correctly, although I'm unsure of how you'd set it through the API. Jan 21 12:37:53 I've known it to "Just Work(TM)" when using certain operators, though. Jan 21 12:40:30 Running "test/enable-cbs" after bringing the modem up, and "test/set-cbs-topics 200" (substitute "200" with your desired topic) should do the trick Jan 21 12:41:29 At least for O2 UK and an ISI modem connected via USB, that enables retrieving a broadcast containing local area dialling codes. Jan 21 12:41:45 Your Mileage May Vary, though. :) Jan 21 12:41:48 where would I find out what the default channel it listens to is? I know my operator transmits cell tower names/locations on channel 50 Jan 21 12:42:00 or is the default "listen on all channels"? Jan 21 12:42:01 Good question Jan 21 12:42:12 I think it's listen on all channels, but I'll check one of my logs. Jan 21 12:42:19 I am dealing with an isi modem (N900) here Jan 21 12:42:44 It does not. I only listens on the emergency required ones. 0-999 are freely configurable by the user. Jan 21 12:42:53 list-modems tells you the current configuration. Jan 21 12:44:50 When bringing the modem up here, I see the following in the debug output: Jan 21 12:44:54 ofonod[4120]: drivers/isimodem/sim.c:isi_read_file_info() Fileid 6F48 not implemented Jan 21 12:44:54 ofonod[4120]: drivers/isimodem/cbs.c:isi_set_topics() Not implemented (topics=1,4352-4356), all topics accepted Jan 21 12:44:54 ofonod[4120]: src/cbs.c:cbs_dispatch_base_station_id() Base station id: 01423,01765,01347,01845 Jan 21 12:45:00 (Apologies for the lengthy paste). Jan 21 12:45:19 Unsure if it differs for the N900, though. Jan 21 12:45:20 this is on an n900? Jan 21 12:45:28 An N73 connected via USB. Jan 21 12:45:30 ok Jan 21 12:46:06 ok, so "topics" in ofono are what might be called channels in the UI of other phones? Jan 21 12:46:16 Yup Jan 21 12:46:19 ok Jan 21 12:46:34 thanks for the info Jan 21 12:56:10 pessi: kill-yank error ??? Jan 21 13:12:10 holtmann: that's emacs-speak ;) Jan 21 13:13:59 Someone accidentally killed an American? ;) Jan 21 13:14:01 * vmlemon_ hides Jan 21 13:14:26 jonwil, vmlemon_: the isimodem driver doesn't implement the set_topics() and clear_topics() ops Jan 21 13:14:42 instead, it will just accept all topics by default Jan 21 13:15:11 Good to know, akiniemi. :) Jan 21 13:15:23 Sadly, it seems that jonwil has vanished. Jan 21 13:15:58 akiniemi: I am a vi person ;) Jan 21 13:23:40 holtmann: vade retro Jan 21 13:26:28 hmmm, how is oFono supposed to deal with multiple context types on a single APN? Jan 21 13:27:05 courmisch: Double activate them. Jan 21 13:27:18 you mean two contexts? Jan 21 13:27:28 Yes. Activate the same APN twice. Jan 21 13:27:37 some networks won't allow that, I'm afraid Jan 21 13:27:44 Tested this with O2 here in Germany and works just fine. Jan 21 13:28:02 Tell which network does not. I need to buy a SIM card for it. Jan 21 13:31:07 Hutchison 3G I'm told Jan 21 13:31:39 Which country? Jan 21 13:31:59 UK? Jan 21 13:32:01 AFAIK, all of them Jan 21 13:32:05 but it's HK based Jan 21 13:32:57 We need to get this confirmed. The oFono API potentially allows us to handle this nicely, but so far I have not bothered since all the networks I check with, the double activation just worked fine. Jan 21 13:33:28 I wonder what nicely is supposed to mean Jan 21 13:33:30 So anybody with Hutchison 3G and a N900 or IFX/STE/MBM that allows multiple contexts and can test this. Jan 21 13:34:11 You read doc/connman-api.txt and the part about MMS context type. And how we just give the address for the MMSC proxy as result and not IP details. Jan 21 13:34:34 did I say this was about MMS? Jan 21 13:34:57 What else would it be? Jan 21 13:35:15 and even if it were MMS, if ConnMan ifconfig down the "Internet", MMS won't work Jan 21 13:35:16 IMS really needs to be on a separate context. Everything else is insane. Jan 21 13:35:39 I agree. But somehow the operators don't listen to me Jan 21 13:36:09 from what I have heard, you need to pay the network vendors more if you want more contexts... Jan 21 13:36:11 It is a security issue to have Tethering support and MMS/IMS and other networks services on a public Internet APN. Jan 21 13:36:48 I have seen the spec of a very big operator that is planning to do exactly that, IMS and Internet on the same APN Jan 21 13:37:03 I just _hope_ that that particular operator will allow multiple contexts Jan 21 13:37:23 I have heard about that operator as well. It is a dumb broken idea. Jan 21 13:37:26 (and yes, this would be a violation of the VoLTE spec) Jan 21 13:37:54 I really hope that someone kicks some sense into them. Jan 21 13:37:59 big customers idea are never dumb nor broken, did you not get the memo :D Jan 21 13:38:11 My dog must have eaten it. Jan 21 13:40:54 well well, I still have a feeling they do this on purpose just to force their customers away from WiFi Jan 21 13:41:49 then I have also seen a problem with SUPL for E911 only working if the device is connected to 3G because the operator's SUPL server is only reachable via its own "Internet" Jan 21 13:42:06 not sure if this grants a new context "type" Jan 21 13:47:05 Heh, it looks like H3G UK use the same APN for general purpose connectivity and MMS - which was a holdover from the days where they blocked all Internet connectivity, and only provided an internally hosted e-mail system. Jan 21 13:48:37 Can you activate the context twice? Jan 21 13:48:53 (That uses the "three.co.uk" APN; although there's also a "3internet" APN for their "Mobile Broadband" service, which blocks access to their proprietary content portal, and dispenses public IP addresses instead of putting users behind a NAT). Jan 21 13:49:02 vmlemon_: VF-UK use two APNs, one for contract internet, one for MMS, is it possible to be connected to both at the same time with single device/SIM? Jan 21 13:49:18 not sure if this grants a new context "type" Jan 21 13:49:21 oops Jan 21 13:49:23 holtmann: I haven't tried it yet, but I'll have a go soon, and let you know. Jan 21 13:49:23 Yes. Jan 21 13:49:42 You can connect up to 4 context at the same time depending on your hardware resources. Jan 21 13:49:47 Some hardware even allows more. Jan 21 13:50:11 I hear that the Swedish branch of H3G took a more sane approach to things, though... Jan 21 13:51:03 calypsoscomforts: I'm uncertain, since I haven't got any Vodafone SIM cards to test with. :( Jan 21 13:52:18 (I've got a bunch of O2 ones, some "legacy" and "modern" H3G USIMs, some Orange ones, a T-Mobile one, and a Tesco Mobile (O2 MVNO) handy). Jan 21 13:52:58 vmlemon_: but in principle, connected to two APNs from the same Operator is possible? Jan 21 13:53:28 sure Jan 21 13:53:39 I don't see why not, if the handset supports it. (I know that S60 devices allow for sending MMSes when browsing the Web over UMTS). Jan 21 13:53:46 why else would 27.007 specify multiple CIDs Jan 21 13:53:50 how would that be seen by the OS, one pppd connection Jan 21 13:54:07 that's an implementation detail Jan 21 13:54:26 the modem provides one pipe per context Jan 21 13:54:55 calypsoscomforts: No sane device would use PPP ;) Jan 21 13:54:59 courmisch: yes wondered about that, but couldn't understand how we could have mutiple pppds running over since tty device Jan 21 13:55:11 TTY multiplexer. Jan 21 13:56:17 are there any OSS implementations that do this yet? Jan 21 13:56:52 You do have looked into oFono, right. We ship one, we even ship our own PPP code so we do NOT have to deal with pppd crap. Jan 21 13:57:03 gatchat/gatmux.c Jan 21 13:57:07 gatchat/gatppp.c Jan 21 13:57:24 wasn't kernel supposed to be able to do that? Jan 21 13:57:33 Infineon and Calypso modems need TTY multiplexers. Jan 21 13:57:45 The N_GSM from Alan Cox is getting in that direction. Jan 21 13:58:26 holtmann: I'm just starting out with ofono, been messing with other connection managers for too long Jan 21 13:58:30 courmisch: I heard rumors about patches that integrate that one with oFono. have not yet seen them. Jan 21 13:59:26 holtmann: thanks I'll take a look at gatchat/gatmux.c etc Jan 21 13:59:34 Have fun. Jan 21 13:59:40 :-) Jan 21 14:10:02 I assume that SIM operator icon retrieval is unimplemented for ISI? (I had a play with the "get-icon" script ages ago, but never managed to obtain anything interesting/useful). Jan 21 14:11:34 (Indeed, from looking at older IRC logs that I turfed up using Google, it appears that there was some interesting conversation around them). Jan 21 14:15:43 vmlemon_: If you even find a SIM card that supports these, let me know. Jan 21 14:15:58 I tried hard, but none of my SIM cards does. Jan 21 14:16:07 And for IFX this is suppose to be working. Jan 21 14:19:32 Unsure if it was a feature of the USIM card, or a firmware branding thing that H3G did; but I noticed that my ancient Motorola A835 would display the operator logo instead of the name, when connected to the H3G network, and displayed a textual operator name when roaming. Jan 21 14:20:13 Might have been a handset quirk though, given that I haven't noticed it since when testing new H3G SIM cards in non-Motorola devices. Jan 21 14:21:40 I'll try and dig out some older H3G USIMs tonight - if I haven't accidentally disposed of them, during various reorganisations and clean-ups of the house... Jan 21 14:26:27 For what it's worth, I've also noticed that an a T-Mobile UK SIM card will have its operator display name file updated (the text corresponding to the record for "Orange" is replaced with "T-Mobile Orange"), if the account has had its MSISDN added to the T-Mobile VLR during activation of the "Everything Everywhere" roaming arrangement. Jan 21 14:27:25 Unsure of how that works, although I was unable to obtain an ISI trace of that process occurring, so I assume that it's SIM Toolkit-related... Jan 21 14:35:25 vmlemon_: It's basic OTA data download, but on the N900, modem firmware handles it, hence no traces :) Jan 21 14:37:05 Makes sense. I usually run my handset's baseband in Offline mode (which seems to let me see and do quite a lot - including receiving SMSes :)) when working with OFono, so I expected to see something interesting. Jan 21 14:38:21 * vmlemon_ suspects the same of his handset, as far as the baseband firmware is concerned... Jan 21 14:38:36 * vmlemon_ wonders how S40 handsets handle it Jan 21 14:38:52 vmlemon_: Or actually, that looks like SPN + roaming PLMN display, based on EFspn and EFspdi Jan 21 14:39:00 holtmann: hmm, isn't IFX handing out more than one TTY at the HW level anyway?? Jan 21 14:39:14 vmlemon_: They're separated by SP in N900 Jan 21 14:39:21 Aah Jan 21 14:39:41 I only observe the update when I power cycle the handset Jan 21 14:40:11 courmisch: Nope. Jan 21 14:40:17 (Prior to that, switching networks on the handset manually results in the emission of packets containing a single operator name (either "Orange" or "T-Mobile UK") Jan 21 14:40:21 *resulted Jan 21 14:40:28 courmisch: Just one TTY over SPI. Jan 21 14:40:33 holtmann: so there's IP data path is not fully in kernel ?! Jan 21 14:40:44 Now, they contain "T-Mobile UK" and "T-Mobile Orange" Jan 21 14:41:04 courmisch: Right now, it is not. Not until we get a proper kernel mux, Jan 21 14:42:46 vmlemon_: interesting... Jan 21 14:43:31 Amusingly, if I remove the T-Mobile SIM card, replace it with an O2 UK one, and do another manual scan, Orange disappears from the network list completely... Jan 21 14:44:03 Although it seems that it returns after a few more SIM swaps. Jan 21 14:51:27 oh my Jan 21 15:07:56 *Orange VLR, even Jan 21 15:08:18 Stupid typo Jan 21 16:34:46 balrog-k1n: here? Jan 21 16:45:25 denkenz: hi Jan 21 17:16:10 leiyu: heya Jan 21 17:24:39 just a friendly reminder that I have re-submitted v4 of CDMA-SMS patch and really appreciate if you can review it again. :-) Jan 21 17:33:11 denkenz: sometime back, after discussing with balrog-k1n we agreed to reduce the stk timeout from 10 to 3minutes Jan 21 17:34:00 denkenz: if its ok with you i can deliver the patch Jan 21 17:43:08 sure, feel free Jan 21 17:48:07 balrog-k1n: So I have a task for you, the current simfs APIs do not support cancellation, so we're in trouble if the SIM is removed or the online -> offline transition happens and some atoms go away during a read Jan 21 17:48:23 balrog-k1n: So I need some ideas on how to fix that nicely Jan 21 18:07:12 denkenz: Could u pls review v4 CDMA-SMS patch at your earliest convenience? :-) Jan 21 18:10:59 leiyu: I always do ;) Jan 21 18:12:16 denkenz: Once this CDMA-SMS basic framework is in good shape and accepted, we will flood you a lot more CDMA-SMS patches. ;-) Jan 21 18:12:34 Hmm, so maybe I should delay this review Jan 21 18:12:43 Not like I have a shortage of patches as it is ;) Jan 21 18:13:18 denkenz: pls not, I can always be a nice patch flood gate for you. :-D Jan 21 18:13:35 lol Jan 21 21:34:22 denkenz: ping Jan 21 22:01:47 padovan: pong Jan 21 22:15:30 denkenz: do u still have question for us about the "Type" property for modem interface? Jan 21 22:46:12 denkenz: have you suggest this id field to zhenhua ( if you can remember that) Jan 21 22:46:13 +struct ofono_emulator { Jan 21 22:46:13 + struct ofono_modem *modem; Jan 21 22:46:13 + struct ofono_atom *atom; Jan 21 22:46:15 + unsigned int id; Jan 21 22:46:19 looks pointless to me. Jan 21 23:13:08 padovan: don't remember ever doing so, so might very well be unneeded Jan 21 23:13:14 leiyu: Well I'm still not convinced :) Jan 21 23:27:32 denkenz: have time for to me to try to convince you? :-) Jan 21 23:28:17 always Jan 21 23:28:45 The main reason we introduce this "Type" thing is not for dual-mode case. Jan 21 23:28:48 It is for single mode case. Jan 21 23:29:25 Let's assume we have a single mode device, then how does upper layer will know whether it is CDMA or GSM? Jan 21 23:29:47 whether it has org.ofono.VoiceCallManager vs org.ofono.cdma.VoiceCallManager? Jan 21 23:29:51 Upper layer can look for whether org.ofono.cdma.voicecall exist or org.ofono.voicecall exist, right? Jan 21 23:30:13 But, atom d-bus I/F are optional. Jan 21 23:30:28 What if it is a data card where voice call feature is not at all supported? Jan 21 23:30:47 So, you start with trying to look for voicecallmanger and if none exist, you look for connectionmanager? Jan 21 23:31:12 for instance Jan 21 23:31:22 You have any number of cdma interfaces you can check Jan 21 23:32:10 yes - if they are instantiated Jan 21 23:32:21 but what do we do if they aren;t Jan 21 23:32:27 So, there can also be cases where none of the atom is instantiated but modem is still accessible, right? Jan 21 23:32:38 Same as what dara explained. Jan 21 23:32:41 so you have a modem with just the devinfo atom? Jan 21 23:32:47 That modem is basically useless anyway Jan 21 23:33:00 for an example - but any shared atom Jan 21 23:33:20 We have no shared atoms Jan 21 23:33:21 yes - but do we not still want to transmit the modem capabilities? Jan 21 23:33:26 And I don't deal with hypotheticals ;) Jan 21 23:33:29 not really. Jan 21 23:33:56 Practical case: data card modem without SIM (R-UIM in CDMA world) plugged in yet. Jan 21 23:34:18 Then, connectionmanager atom I/F will not be instantiated, right? Jan 21 23:34:23 then, how you can check that. Jan 21 23:34:39 to see whether it is CDMA or GSM. Jan 21 23:34:48 At this point, why do you care? Jan 21 23:35:22 Upper layer will still like to read modem's information, e.g., MEID to report to customer care for example. Jan 21 23:35:57 So again, doubtful Jan 21 23:36:17 The current gsm design is trending towards including most atoms in the post-sim state Jan 21 23:36:53 So you have this info anyway Jan 21 23:37:01 We definitely have use case/requirement to read modem's information (IMEI or MEID, for example) but that requirement is NOT at all tied to whether the modem is at which state, as long as you can talk to the modem. Jan 21 23:37:49 But going to post-SIM requires SIM plugged in, correct me if I am wrong. Jan 21 23:39:15 Like I said, the requirement we have is that regardless which mode the modem is in (SIM plugged in or not), as long as connection to modem is there (powered-on), modem's info should be able to be read out. Jan 21 23:40:13 Yeah but you guys don't even have a sim Jan 21 23:40:29 So you go straight to post_sim case and instantiate the various interfaces Jan 21 23:40:32 In our world, we call it R-UIM or CSIM. Jan 21 23:40:34 same thing. Jan 21 23:40:48 Sure, but then you probably have a different interface anyway Jan 21 23:41:53 Actually, due to the similarity of R-UIM/CSIM with USIM (GSM), we are thinking to share the same I/F. Jan 21 23:42:30 Lets get there first Jan 21 23:43:13 There's so much GSM specific crap on SimManager right now, it will require serious convincing the interface should be re-used Jan 21 23:52:30 From what I read CDMA's R-UIM and CSIM spec, other than adding a few extra CDMA specific elementary files, they just refer to GSM SIM spec. :-) Jan 21 23:52:37 the R-UIM/CSIM scenario is a similar case to the NAM i.e. non-SIM scenario Jan 21 23:53:03 We agree that we can come up with R-UIM/CSIM proposal first, Jan 21 23:53:25 then, depending how that goes, we can re-visit this "Type" property in modem, sounds good? Jan 21 23:54:28 But, one point I don't like is that without this "type", upper layer will have to do "if this exist, else if that exist, ....." Jan 21 23:54:55 That is still very ugly to me. What you think? Jan 21 23:59:28 If we get to the point where we absolutely need Type, then sure Jan 21 23:59:40 And I can sort of kind of see the point of Type for HFP Jan 22 00:00:23 do you want me to resubmit the patch with hfp/non-hfp types for now? Jan 22 00:00:25 but, do you see the point that if we don't have Type, then just ask upper layer to do this "if this exist, else if that exist, ...." to determine whether it is CDMA or GSM, won't it be too ugly? Jan 22 00:00:36 comparing with having a clear modem type property? Jan 22 00:00:42 I doubt it would be too ugly in the end Jan 22 00:00:44 Put it another way, I don't see why it hurts. Jan 22 00:01:15 Ok, we are working on the code for ofono-cdma plugin for connman, when that happens, we will let you take a look and see if it is too ugly. :-) Jan 22 00:01:21 :) Jan 22 00:01:26 sure Jan 22 00:01:45 I didn't say I was totally against it, just unconvinced Jan 22 00:02:04 Understand, Jan 22 00:02:07 And whenever that happens I automatically invoke the 'Minimial' principle ;) Jan 22 00:02:18 'Minimal' rather Jan 22 00:02:32 I also understand you are invoking minimal principle here. Jan 22 00:02:50 but, I just feel it is ugly that way, of course, it is up to us to show you how ugly it is. :-) Jan 22 00:02:52 Stay tuned. Jan 22 00:04:51 sure ;) **** ENDING LOGGING AT Sat Jan 22 00:48:05 2011 **** BEGIN LOGGING AT Sat Jan 22 00:52:36 2011 **** BEGIN LOGGING AT Sat Jan 22 04:42:16 2011 **** ENDING LOGGING AT Sat Jan 22 11:17:40 2011 **** BEGIN LOGGING AT Sat Jan 22 11:22:22 2011 **** ENDING LOGGING AT Sun Jan 23 02:59:57 2011