> So it's carrier specific ? yuck :( > Worse. It's APN specific. So carrier A (or MVNO B which sits on carrier A) has a APN of a.com. This works. but mobile.a.com doesn't. (it works for everything else, and I suspect it's one of the ones which is recompressing all images etc on the way thru)
> Is it hard to reproduce ? No point in asking pretty complex (and long) > stuff if it takes hours to dupe. Trivial. I hit a button in my app, it breaks. 100% of the time with these settings. Atleast it was last night. (that said, I'm working all weekend, so I'll not have time to look at it until next week) > The first step would be to get me the device log around the time of > the crash (quite a bit before and a bit after) to see if any other > service is complaining (e.g. network retries...). OK, is this just the bit from xcode's console? > Please open a bug report so we can track the data and mark this one > (attachment) as private in case there's sensitive data, like > passwords, the the logs. Thanks - as soon as I can make a device log, I'll make a bug ticket Thanks! Nic > On Thu, May 31, 2012 at 6:02 PM, Nic Wise <[email protected]> wrote: >> Hi Sebastien >> >> OK, I finally got my SIM for this carrier (yay, I own my phone, I can >> change carriers. 5 GBP isn't bad for 500meg of data for the month, no >> contract).. >> >> I can reproduce it perfectly on my device now. >> >> Any ideas how I could get more logging out of the app? Find out what >> the issue is? >> >> Ta >> >> N >> >> >> >> On Mon, May 28, 2012 at 2:07 PM, Nic Wise <[email protected]> wrote: >>> Yup, it's always on one carrier. I've only had 2 people report it - >>> one is on O2 (the carrier), the other one GiffGaff, which is a MVNO >>> which sits on top of O2. >>> >>> I'm also on O2, but never had a problem. >>> >>> Very odd. I'll try them with a build of 5.3.3 of MT, see if that makes >>> any difference. >>> >>> On Mon, May 28, 2012 at 2:02 PM, Sebastien Pouliot >>> <[email protected]> wrote: >>>> Maybe some devices / ISP / cell providers are more likely to have >>>> networking issues. Try to get keep track of the data maybe some >>>> pattern will emerge and allow us to pinpoint the root cause (first >>>> step toward a resolution, if possible). >>>> >>>> On Mon, May 28, 2012 at 8:59 AM, Nic Wise <[email protected]> wrote: >>>>> thanks Sebastien - that makes sense. It appears to only happen with a >>>>> small number of my customers - a VERY small number. I wonder if it's a >>>>> device issue.... >>>>> >>>>> On Mon, May 28, 2012 at 1:52 PM, Sebastien Pouliot >>>>> <[email protected]> wrote: >>>>>> Hello Nic, >>>>>> >>>>>> On Mon, May 28, 2012 at 8:30 AM, Nic Wise <[email protected]> wrote: >>>>>>> This is a bit of an oddball one, and not one I can reproduce. >>>>>>> >>>>>>> 20120528/113316: URL: https://bbsc.freeagent.com/verify >>>>>>> 20120528/113317: Ex in Verify: Error getting response stream (Write: >>>>>>> The authentication or decryption has failed.): SendFailure >>>>>>> 20120528/113317: Exception: System.Net.WebException: Error getting >>>>>>> response stream (Write: The authentication or decryption has failed.): >>>>>>> SendFailure ---> System.IO.IOException: The authentication or >>>>>>> decryption has failed. ---> Mono.Security.Protocol.Tls.TlsException: >>>>>>> The authentication or decryption has failed. >>>>>>> at Mono.Security.Protocol.Tls.RecordProtocol.ReadRecordBuffer (Int32 >>>>>>> contentType, System.IO.Stream record) [0x00000] in <filename >>>>>>> unknown>:0 >>>>>>> at >>>>>>> Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback >>>>>>> (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0 >>>>>>> --- End of inner exception stack trace --- >>>>>>> at Mono.Security.Protocol.Tls.SslStreamBase.AsyncHandshakeCallback >>>>>>> (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0 >>>>>>> --- End of inner exception stack trace --- >>>>>>> at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult >>>>>>> asyncResult) [0x00000] in <filename unknown>:0 >>>>>>> at System.Net.HttpWebRequest.GetResponse () [0x00000] in <filename >>>>>>> unknown>:0 >>>>>>> at System.Net.WebClient.GetWebResponse (System.Net.WebRequest >>>>>>> request) [0x00000] in <filename unknown>:0 >>>>>>> at System.Net.WebClient.ReadAll (System.Net.WebRequest request, >>>>>>> System.Object userToken) [0x00000] in <filename unknown>:0 >>>>>>> at System.Net.WebClient.DownloadDataCore (System.Uri address, >>>>>>> System.Object userToken) [0x00000] in <filename unknown>:0 >>>>>>> 20120528/113317: StackTrace: at >>>>>>> System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) >>>>>>> [0x00000] in <filename unknown>:0 >>>>>>> at System.Net.HttpWebRequest.GetResponse () [0x00000] in <filename >>>>>>> unknown>:0 >>>>>>> at System.Net.WebClient.GetWebResponse (System.Net.WebRequest >>>>>>> request) [0x00000] in <filename unknown>:0 >>>>>>> at System.Net.WebClient.ReadAll (System.Net.WebRequest request, >>>>>>> System.Object userToken) [0x00000] in <filename unknown>:0 >>>>>>> at System.Net.WebClient.DownloadDataCore (System.Uri address, >>>>>>> System.Object userToken) [0x00000] in <filename unknown>:0 >>>>>>> 20120528/113317: In complete. success is False >>>>>>> >>>>>>> The user said that all/most other traffic was flowing well. He's on >>>>>>> the same carrier (in the same city) as me, and a lot of other people. >>>>>>> >>>>>>> I'm using the "accept all SSL certs" thing, if that helps: >>>>>>> >>>>>>> ServicePointManager.ServerCertificateValidationCallback = (sender, >>>>>>> cert, chain, ssl) => true; >>>>>> >>>>>> You should not - but the exception points to transmission, i.e. well >>>>>> after the certificates validations. >>>>>> >>>>>>> Any thoughts? Anywhere to look? I think this is using an older version >>>>>>> of MonoTouch, >>>>>> >>>>>> SSL/TLS are, by design, difficult to debug since they don't tell you >>>>>> much about what (or when) things fails. That makes attacks harder and >>>>>> debugging (near) impossible. >>>>>> >>>>>> Now at the stage this occurs we know that SSL negotiation was done. >>>>>> IOW client/server decided on a common cipher suite, certificate were >>>>>> accepted... and that the request was sent. >>>>>> >>>>>> (More likely) a network glitch. SSL/TLS ensure integrity of the data. >>>>>> One single bad bit will result in an error - and since the internal >>>>>> state becomes invalid the whole SSL session must be restarted (i.e. >>>>>> there's no low-level try it again). If this is not something that can >>>>>> be duplicated again then it's a likely culprit. >>>>>> >>>>>> (Unlikely) the server asked for a renegotiation. That can occurs (it's >>>>>> optional) after a large amount of data was sent. It's very uncommon* >>>>>> (for HTTPS) so it's less tested than the general code (but bugs were >>>>>> fixed years ago and not reported again). If that's the case then it >>>>>> should be possible to duplicate the same issue with the same web site >>>>>> (same server configuration). >>>>>> >>>>>> * it's more common in long sessions, e.g. with a database, than for HTTPS >>>>>> >>>>>>> before the recent crypto changes that Sebastian blogged >>>>>>> about. >>>>>> >>>>>> The recent changes should not affect how SSL/TLS behave. It should be >>>>>> faster (I/O are predominant in this case so it might not show off a >>>>>> lot) but not different. More than 2000 test cases were ported to >>>>>> ensure this :-). >>>>>> >>>>>> Sebastien >>>>> >>>>> >>>>> >>>>> -- >>>>> Nic Wise >>>>> t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise >>>>> b. http://www.fastchicken.co.nz/ >>>>> >>>>> Earnest: Self-employed? Track your business expenses and income. >>>>> http://earnestapp.com >>>>> Nearest Bus: find when the next bus is coming to your stop. >>>>> http://goo.gl/Vcz1p >>>>> mobileAgent (for FreeAgent): get your accounts in your pocket. >>>>> http://goo.gl/IuBU >>>>> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa >>>>> London Bike App: Find the nearest Boris Bike, and get riding! >>>>> http://goo.gl/Icp2 >>> >>> >>> >>> -- >>> Nic Wise >>> t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise >>> b. http://www.fastchicken.co.nz/ >>> >>> Earnest: Self-employed? Track your business expenses and income. >>> http://earnestapp.com >>> Nearest Bus: find when the next bus is coming to your stop. >>> http://goo.gl/Vcz1p >>> mobileAgent (for FreeAgent): get your accounts in your pocket. >>> http://goo.gl/IuBU >>> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa >>> London Bike App: Find the nearest Boris Bike, and get riding! >>> http://goo.gl/Icp2 >> >> >> >> -- >> Nic Wise >> t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise >> b. http://www.fastchicken.co.nz/ >> >> Earnest: Self-employed? Track your business expenses and income. >> http://earnestapp.com >> Nearest Bus: find when the next bus is coming to your stop. >> http://goo.gl/Vcz1p >> mobileAgent (for FreeAgent): get your accounts in your pocket. >> http://goo.gl/IuBU >> Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa >> London Bike App: Find the nearest Boris Bike, and get riding! >> http://goo.gl/Icp2 -- Nic Wise t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise b. http://www.fastchicken.co.nz/ Earnest: Self-employed? Track your business expenses and income. http://earnestapp.com Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p mobileAgent (for FreeAgent): get your accounts in your pocket. http://goo.gl/IuBU Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2 _______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
