**** BEGIN LOGGING AT Sat Feb 04 03:00:03 2017 Feb 04 04:10:32 ~memory Feb 04 04:10:33 The memory smacks of usage!, or vulnerable, see http://abcnews.go.com/Technology/story?id=98195&page=1 Feb 04 05:38:04 hmm Feb 04 10:37:59 Pali: ping Feb 04 10:48:39 freemangordon: pong Feb 04 10:50:27 Pali: check your mail. in short - hildon-status-manu crashing is because of your changes to HAM Feb 04 10:50:35 saw Feb 04 10:50:46 about https://github.com/community-ssu/hildon-application-manager/commit/3edbb49dc6c2ee66917c8f165f6a52ee10df1984 Feb 04 10:50:53 provider is stored in provider Feb 04 10:51:10 this one should be OK Feb 04 10:51:11 problem is probably in commit 03ed723f3b2439764d3224ef051c6853fd2ebd85 Feb 04 10:51:20 see my latest mail Feb 04 10:52:31 yes, double free Feb 04 10:52:53 those commits bring support for "New update" notification Feb 04 10:53:14 on repository.maemo.org should be already present file about new CSSU update Feb 04 10:53:31 ham needs to be configured to use that file instead on downloads.maemo.nokia.com Feb 04 10:53:39 aah, I see Feb 04 10:53:43 and it checks it once per day, even apt-get is not running Feb 04 10:53:52 ok, got it now Feb 04 10:53:54 so user get information about new SSU update Feb 04 10:54:23 Pali: also, see my note re killing h-d on update Feb 04 10:54:32 yes looking on iy Feb 04 10:54:40 I think this should be reverted, at least partially Feb 04 10:55:18 killing h-d is not a problem Feb 04 10:55:23 an hour ago, when installing testing-testing, I got a dialog asking me about whether to flash cssu-kernel Feb 04 10:55:34 it is already done by HAM Feb 04 10:55:37 via dsme Feb 04 10:55:44 but, it was like on 2/3 of the screen, in the upper-left corner Feb 04 10:55:55 I just added another kill_all to make sure even if dsme fails Feb 04 10:55:55 hmm, another problem then Feb 04 10:56:15 in some cases dsme can fail Feb 04 10:56:18 this is fallback Feb 04 10:56:48 I just added kill_all for every process which is stopped by dsme (look at that code) Feb 04 10:56:58 what is the problem if dsme fails? device cannot be rebooted? Feb 04 10:57:11 dsme stop can fail Feb 04 10:57:27 that is to ensure that all needed processes are stopped Feb 04 10:57:31 ok Feb 04 10:57:37 because in the process of upgrade they do not work Feb 04 10:57:47 as libraries in system are changing Feb 04 10:58:14 e.g. hildon-status-menu can reload plugins if they appear in VFS Feb 04 10:58:26 ah, I see Feb 04 10:58:27 and so it must be not runinng when doing update Feb 04 10:58:34 ok, this is clear now Feb 04 10:58:39 and I saw some situation when dsme did not stopped hildon-status-menu Feb 04 10:58:51 even dsme though hildon-status-menu is already stopped Feb 04 10:59:12 ideally fix that double free Feb 04 10:59:23 and I will try to find where is URL for that SSU notify Feb 04 10:59:29 seems we do not have it in HAM yet :-( Feb 04 10:59:32 still, I wonder why I got that ugly dialog. looks like a bug in that piece of SW that shows the dialog Feb 04 10:59:49 new URL should be in next CSSU release Feb 04 11:00:03 Pali: so, HAM should not be included in the new -testing, right? Feb 04 11:00:22 should be, but with fix for double free Feb 04 11:00:39 (12,59,25) Pali: seems we do not have it in HAM yet :-( Feb 04 11:00:44 ^^^ ? Feb 04 11:00:52 we do not have new URL in HAM Feb 04 11:01:03 so still is using old downloads.maemo.... Feb 04 11:01:09 like all versions before Feb 04 11:01:39 then why include it if the functionality is the same as before those changes? Feb 04 11:02:06 because of killing of the processes? Feb 04 11:02:36 there are other changes too Feb 04 11:02:42 ok, going to fix that double-free Feb 04 11:02:50 e.g. include PR1.3 HAM in CSSU Feb 04 11:02:56 Pali: unless you want to do it? Feb 04 11:03:10 I'm going to find that URL... Feb 04 11:03:13 ok Feb 04 11:05:14 ok, got it Feb 04 11:05:18 old was: http://tableteer.nokia.com/application-notices/notice-${HARDWARE}-fremantle Feb 04 11:05:26 new is: http://repository.maemo.org/application-notices/notice-${HARDWARE}-fremantle.html Feb 04 11:09:20 Pali: you're going to change something? Feb 04 11:09:28 yes, just Makefile.am Feb 04 11:09:35 ok Feb 04 11:13:55 Pali: done Feb 04 11:14:41 Pali: please, add entries in changelog as well, so the package to be ready for ilew to build and push it Feb 04 11:14:51 ok Feb 04 11:57:57 freemangordon: done package is in cssu-devel Feb 04 11:58:05 and also in git on github Feb 04 12:01:12 freemangordon: do you have access to that notice-${HARDWARE}-fremantle.html file? Feb 04 12:01:29 thanks for all your work. :-) Feb 04 12:02:15 it should be updated every time when new CSSU stable is released Feb 04 12:28:19 am in the only one having problem with supl.nokia.com? Feb 04 12:31:26 openssl connects to it, but Ovi Maps doesn't seem to succeed getting A-GPS info Feb 04 12:35:02 https://talk.maemo.org/showpost.php?p=1522819&postcount=228 Feb 04 12:43:26 ~supl Feb 04 12:43:26 supl.nokia.com known to be broken, use alternatives like supl.google.com! Adjusting this detail is via settings screen Feb 04 12:52:26 but maybe it's just slow Feb 04 12:52:57 or your device missing the cert patch once published and afaik included to CSSU Feb 04 12:55:18 http://paste.opensuse.org/97725536 Feb 04 13:19:22 Pali: on which server, r.m.o? Feb 04 13:19:35 http://repository.maemo.org/application-notices/notice-${HARDWARE}-fremantle.html Feb 04 13:19:45 I guess yes, lemme check Feb 04 13:21:02 Pali: yes, I have access Feb 04 13:21:06 ok Feb 04 13:21:19 Pali: wait, what kind of access? Feb 04 13:21:22 ssh? Feb 04 13:21:26 edit that file Feb 04 13:21:59 Pali: who put it there? Feb 04 13:22:11 do not remember Feb 04 13:23:06 what to edit? Feb 04 13:23:41 Pali: ^^^ Feb 04 13:23:45 chanlog told me that xes! Feb 04 13:24:01 maybe it is better to ask him then Feb 04 13:24:15 or it is CSSU that "owns" that file Feb 04 13:24:18 ? Feb 04 13:24:31 yes, CSSU stable should own that file Feb 04 13:24:45 ok Feb 04 13:24:51 every time when new CSSU stable is released, that file content should be updated Feb 04 13:25:03 so, what needs to be edited? Feb 04 13:25:14 updated how? Feb 04 13:25:15 so ideally include version number or something Feb 04 13:25:27 content of file needs to be changed Feb 04 13:25:37 to that will trig HAM to show update Feb 04 13:26:29 Pali: http://pastebin.com/FsBvYe18 Feb 04 13:27:01 Pali: but, this is for -stable, right? Feb 04 13:27:21 when content of that file is changed then HAM show update Feb 04 13:27:27 yes that points to stable Feb 04 13:27:31 and updated HAM is not in -stable Feb 04 13:27:55 Pali: what about changing Includes latest fixes for Maemo 5 system by Maemo Community to: Feb 04 13:28:08 Includes latest fixes for Maemo 5 system by Maemo Community - $VERSION? Feb 04 13:28:14 it can be changed as you wish Feb 04 13:28:20 just content needs to be changed Feb 04 13:28:29 text is shown in that ham notifier Feb 04 13:28:36 Pali: ok, but should I do it now? Feb 04 13:28:43 no need Feb 04 13:28:45 there is no new CSSU afaik Feb 04 13:28:48 ah, ok Feb 04 13:28:57 after HAM will be in cssu-stable Feb 04 13:29:04 and after new cssu-stable will be released Feb 04 13:29:18 I guess it is merlin1991 who is supposed to do it, right? Feb 04 13:29:51 yes Feb 04 13:30:58 Pali: ok, if after issuing new -stable merlin1991 is not willing to edit that file, I will do it :) Feb 04 13:31:15 but lets first make him issue a new -stable Feb 04 15:53:08 I thought supl server issues where fixed? It was a cert IIRC not an issue with supl.nokia.com. Is your system time correct? Feb 04 16:55:58 sixwheeledbeast: at least here it works fine. And yes, there were certificate issues fixed in CSSU Feb 04 16:59:24 :nod: Sicelo? Feb 04 17:55:00 supl.nokia.com working here also Feb 04 18:21:02 Includes latest fixes for Maemo 5 system by Maemo Community - $VERSION $(date +%Y-%m-%d) Feb 04 18:25:21 sixwheeledbeast: yes, all is well with my time and cert (i'm on cssu-thumb) Feb 04 18:41:30 both location-test-gui and ovi maps seem to make a request to h-slp.mnc002.mcc655.pub.3gppnetwork.org .. which doesn't resolve Feb 04 18:41:42 no idea where it gets that from Feb 04 18:43:00 655-02 would be my network operator of course, but i don't know how N900 gets to know about this hostname Feb 04 18:43:22 you've got a virus Feb 04 18:44:48 :p Feb 04 18:44:56 stop being dramatic :) Feb 04 18:51:22 sounds like ~gsm-agps Feb 04 18:53:19 aka RRLP Feb 04 18:54:26 yes that's what i think .. but i'm specifying AGNSS in location-test-gui Feb 04 18:55:00 log of an A-GPS session: https://talk.maemo.org/showpost.php?p=1522819&postcount=228 Feb 04 18:57:35 wow .. my 2nd N900 got A-GPS fix in just 3s Feb 04 18:58:11 never contacted anything else besides supl.nokia.com Feb 04 19:04:57 that still works? Feb 04 19:07:28 yes, always worked Feb 04 19:08:07 Sicelo: that should get resolved by your MNO afaik. do you have SIm card in that device? Feb 04 19:08:40 yes, i do Feb 04 19:08:44 KotCzarny: https://forum.xda-developers.com/showpost.php?p=9533067&postcount=10 Feb 04 19:09:32 yes, 3s is RRLP, standard on 3G nowadays Feb 04 19:10:05 ~gsm-agps Feb 04 19:10:06 rumour has it, rrlp is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP Feb 04 19:11:03 DocScrutinizer05: my main N900 is the one coming up with this address, and no fix. the 2nd N900 is the one with quicker fix, and no attempt to contact this address. 2nd N900 has different operator's SIM though Feb 04 19:11:03 since GPS is integral component of BB5 modem, it's totally opaque to userland *how* the fix got established Feb 04 19:11:36 Sicelo: do I realy need to suggest the onvious? ;-) Feb 04 19:11:44 obvious* Feb 04 19:11:53 swap SIMs Feb 04 19:12:30 use airplane mode. (though now you got ephem/alm in cache, so it's pointless anyway) Feb 04 19:12:36 i'm going to do that of course Feb 04 19:13:48 I did similar tests a maybe 6 years ago, and it turned out: 3G *and* correct system time allow a TTFF<5s Feb 04 19:30:33 tested 3 SIM cards now .. the 1st N900 always considers the 3gppnetwork.org address, of course with the corresponding MCC/MNC in the hostname. no fix Feb 04 19:42:58 2nd N900 .. with any of the SIM cards .. quick fix. no 3gpp address looked up at all Feb 04 19:43:34 i'll reinstall location-proxy on 1st N900 .. no idea if it will help Feb 04 19:48:52 i'll add that 2nd N900 has not been used for GPS in a very long time .. so has the least 'knowledge' about my location compared to 1st Feb 04 20:03:34 you know http://repository.maemo.org/pool/maemo5.0/non-free/l/location-test-gui/ I'm sure Feb 04 20:05:05 DocScrutinizer05: Hi Doc, are you active on the 05 or 51 nickname? Feb 04 20:05:39 none, I'm inactive on IRC, and my flu is active on me Feb 04 20:06:08 DocScrutinizer05: Oh, that is a shame. Did you read my quickly sent direct message? Feb 04 20:06:27 DocScrutinizer05: I hope that you'll get rid of that nasty flu Feb 04 20:06:46 I will send you a quick question if you do not mind? Feb 04 20:06:56 go ahead Feb 04 20:07:50 DocScrutinizer05: 20:55 < Sicelo> yes that's what i think .. but i'm specifying AGNSS in | location-test-gui Feb 04 20:30:52 * DocScrutinizer05 idly muses how much a N900 would cost and weigh when built with technology of 1980 Feb 04 20:33:45 in 1980 Feb 04 20:34:24 prolly needs two dozen Z80, a 50 to 100 bucks each? just to start with Feb 04 20:41:40 Or a few m68ks Feb 04 20:42:06 or a bunch of sticks and stones Feb 04 21:19:21 but the n900 is basically 80s technology 🤔 Feb 04 21:20:16 <3 n900 Feb 04 21:27:10 lol 80s Feb 04 21:46:31 hehe Feb 04 21:50:12 70s technology at best Feb 04 21:50:17 i'm sure i've spotted some valves in it Feb 04 21:56:09 ;o Feb 04 23:08:57 freemangordon, DocScrutinizer05 ... 'solved' the problem with AGPS - *maemosec* packages from devel have problem of some sort. will report on devel thread Feb 04 23:12:36 hmm Feb 04 23:12:47 some certificate problem again I guess Feb 04 23:13:42 possibly, but 2nd N900 using CSSU-T (no devel) worked perfectly the whole time. no idea what's up with the devel ones Feb 04 23:14:45 Sicelo: https://github.com/community-ssu/maemo-security-certman/commits/master Feb 04 23:15:02 we should wait fo jonwil to appear Feb 04 23:15:19 but yeah, report the problem on cssu-devel thread Feb 04 23:15:58 i've done, https://talk.maemo.org/showpost.php?p=1522850&postcount=510 :-) Feb 04 23:19:21 Sicelo: could you try to connect with openssl instead of cmcli? Feb 04 23:20:25 ah, you already did it Feb 04 23:20:27 i did both Feb 04 23:20:29 yeah Feb 04 23:21:12 weird thing is .. exactly the same output for both devices for cmcli and openssl Feb 04 23:21:29 mhm Feb 04 23:21:58 I wonder why cmcli gives self-signed error Feb 04 23:24:16 Sicelo: are you sure you did cmcli on both devices? Feb 04 23:24:26 as it does not fail on mine Feb 04 23:24:52 "Verified OK" Feb 04 23:24:58 for the same command as yours Feb 04 23:25:11 yes, yes Feb 04 23:25:40 but now that i've downgraded maemosec-certman-tools one the one to 0.2.3, it verifies ok Feb 04 23:26:11 Sicelo: what is the version on your second device? Feb 04 23:26:22 the 2nd N900 (which has had consisted quick fixes), has 0.2.4 .. didn't downgraded, and that ones still 'sees' self-signed Feb 04 23:26:30 weird Feb 04 23:26:56 0.2.4 doesn't seem to be in any repo now though :-/ Feb 04 23:27:04 what version do you have? Feb 04 23:27:22 0.2.3 Feb 04 23:34:17 Sicelo: what is the output from dpkg -L maemosec-certman-common-ca | grep 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 Feb 04 23:34:27 on that device with 0.2.4 Feb 04 23:37:31 /etc/certs/common-ca/00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem Feb 04 23:37:31 /etc/certs/common-ca/00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem Feb 04 23:37:43 problem is the duplicate? Feb 04 23:37:58 no, most probably it is in the order Feb 04 23:38:18 yes .. by the way the 0.2.4 device is 'fine' :) Feb 04 23:38:37 what do you mean? Feb 04 23:38:50 if cmcli fails to verify, it is not fine Feb 04 23:39:09 see https://github.com/community-ssu/maemo-security-certman/commit/2cbd96e89d7529e1ce25801824fb76f39b05b836 Feb 04 23:39:14 ah yes .. meant from the POV of A-GPS Feb 04 23:39:18 I suspect same/similar problem Feb 04 23:39:45 i remember those fixes back then Feb 04 23:39:45 Sicelo: but then, why cmcli fails? Feb 04 23:40:26 i really have no idea about that Feb 04 23:40:39 maybe jonwil will have idea, but Feb 04 23:41:21 not sure if this is related .. https://talk.maemo.org/showthread.php?t=96433 .. seems to be the only place 0.2.4 is mentioned Feb 04 23:41:56 yep, lets wait for him to appear. If not, tomorrow I'll install the latest from -devel and will check Feb 04 23:42:07 the thread seems to have ended without anything specific Feb 04 23:42:24 * freemangordon goes afk Feb 04 23:42:27 night Feb 04 23:42:28 sure .. at least you'll probably be able to understand it better than I Feb 04 23:42:33 night Feb 05 00:07:15 jonwil: we were just talking about you :) Feb 05 00:07:21 hi Feb 05 00:07:32 * jonwil reads logs Feb 05 00:08:34 see last two posts in cssu devel thread .. a-gps problem that can be attributed to maemosec-certman packages Feb 05 00:08:34 ok, what exactly is the problem? Feb 05 00:09:13 So the problem is what exactly? Feb 05 00:09:44 maybe supl format changed and results in modem GPS engine hanging now? Feb 05 00:09:46 that the new set of root CAs doesn't work properly for AGPS? Feb 05 00:09:51 a-gps does not work with maemo-security-certman (0.2.7) Feb 05 00:09:56 yes Feb 05 00:10:14 which version is the last one that works? Feb 05 00:10:14 i downgraded to 0.2.3 and i get instant fix Feb 05 00:10:36 0.2.4 gets good fix too .. but fails cmcli verification Feb 05 00:11:03 0.2.3 has good fix, and cmcli verifes supl.nokia.com OK Feb 05 00:16:10 sorry now that sounds like bogus heissenbug, aka unrelated Feb 05 00:18:32 you're aware BB5 probably stores ephem/alm internally too? there been even a tiny tool to clear that stuff in modem, back when. sorry can't spot it anymore, I *think* it was an attachment by our Nokia FOSS ambassador to tmo Feb 05 00:20:37 DocScrutinizer05: when it works - Socket to supl.nokia.com opened, fd=13, verify_res=0 Feb 05 00:20:58 when it doesn't, Socket to supl.nokia.com opened, fd=12, verify_res=19 Feb 05 00:22:02 meh, gimme tcpdump/whireshark! Feb 05 00:22:49 even tshark Feb 05 00:24:38 anyway, you clarified that now, so it looks less unrelated Feb 05 00:24:56 Could it be that the " Feb 05 00:25:11 the " Change the order of VerSign root certificates, so "newer" certificate to appear first. Fixes supl server not working." change in maemo-security-certman is related Feb 05 00:25:16 That change was made in 0.2.3 Feb 05 00:25:33 Its possible my total reimport of the certificates in later versions caused the order to change again somehow Feb 05 00:25:45 most likely, yes Feb 05 00:25:49 I have no real way to verify that though Feb 05 00:25:49 yes Feb 05 00:26:36 speaking of which, I need to update maemo-security-certman to the latest set of mozilla root certificates, haven't done it for a while :) Feb 05 00:26:43 :) Feb 05 00:26:55 of course >>Fixes supl server not working."<< is related ;-D Feb 05 00:30:25 * DocScrutinizer05 has absulute faith in Ivo fixing that Feb 05 00:31:33 I think cert management is your daily warmup, freemangordon. Right? ;-) Feb 05 00:32:21 ~trump Feb 05 00:32:26 well, trump is NULL Feb 05 00:32:27 wow Feb 05 00:32:46 ~factinfo trump Feb 05 00:32:46 trump -- created by fungus at Tue Aug 9 22:29:09 2016 (179 days); it has been requested 5 times, last by DocScrutinizer05, 20s ago. Feb 05 00:39:50 https://www.youtube.com/watch?v=zP7RbhfcV7o Feb 05 00:50:37 ok, the root CA store is updated Feb 05 00:51:33 please keep in mind that it took quite some investigation and WTF-moments to make a _working_ cert store back when patching it Feb 05 00:52:54 I think there are some undocumented non-intuitive (aka flaw) sequence/sortorder issues with the cert store Feb 05 00:52:59 iirc Feb 05 00:53:53 took the one who meddled with it (fmg?) quite a bit of trial&error to 'fix a perfectly correct cert store' so it works with some broken apps/libs in maemo Feb 05 00:54:10 in that case we should modify the maemosec-certman tools and stuff to correctly order the certs rather than try and manually patch the store every time. Feb 05 00:54:39 I think if that option had existed, it would have been taken back when Feb 05 00:55:17 anyhow, let me see what I get now with maemo-security-certman 0.2.8 on my phone when I try to access the various supl servers out there... Feb 05 00:56:29 when a closed process fails on your absolutely corect data, based on mystery criteria (moon phase and md5sum of all words with a prime number of chars) then you can't fix much Feb 05 00:56:54 note that certs are not only relevant for supl Feb 05 00:57:05 you have quite a few apps to check Feb 05 00:57:33 I suggest you read the historical tickets and tmo threads regarding that stuff Feb 05 00:57:55 or wait for fmg (and/or pali?) to chime in Feb 05 00:59:01 I really can't recall details Feb 05 00:59:15 only kbnow it been a PITA Feb 05 00:59:16 ok, so location-test-gui can definatly see satellites but it cant get a lock Feb 05 00:59:46 I wish it displayed more info about the actual connections to the supl server Feb 05 01:00:06 hmm, such a statement is pretty generic. Did you make sure the signal of sats is OK? Feb 05 01:00:14 wireshark logs wont help since you cant wireshark an SSL connection unless you can peek into memory and get the keys Feb 05 01:00:19 did you make sure you have correct system time? Feb 05 01:00:27 did you reset BB5 GPS? Feb 05 01:00:57 (SSL) right :-/ Feb 05 01:01:53 system time is comming from network so it should be correct Feb 05 01:02:17 it says ept, eph, epv, epd, eps and epc are all NAN Feb 05 01:02:40 I am connected to both 3G and WiFi here Feb 05 01:02:52 as for resetting bb5 GPS I dont know how Feb 05 01:03:13 'not getting a fix' might be everything from cloudy sky to hickup in hardware that needs power down & battery out for 60s, to wrong system time, to Trolland Dump deciding not to share GPS to Europe anymore Feb 05 01:03:35 If there was a problem with GPS here in Australia I would have heard of it Feb 05 01:03:49 About to go outside and see if that makes a difference :) Feb 05 01:04:29 ohmy, you expected a GPS fix indoors? :-o Feb 05 01:04:43 I have gotten such fixes before in this place Feb 05 01:05:03 prolly not, most like was no first fix and maybe no GPS fix at all Feb 05 01:05:07 see Feb 05 01:05:11 maybe Feb 05 01:05:16 ~gsm-ahps Feb 05 01:05:20 ~gsm-agps Feb 05 01:05:21 i guess rrlp is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP Feb 05 01:05:42 ok, let me try this outside and see what I get. Feb 05 01:05:59 U-TDOA is more accurate and faster than any (A)GPS Feb 05 01:06:42 and works indoors, as long as you got a network signal Feb 05 01:06:57 ~u-tdoa Feb 05 01:06:58 well, u-tdoa is http://en.wikipedia.org/wiki/U-TDOA Feb 05 01:07:21 standard on pretty much all 3G nowadays Feb 05 01:11:14 note that RRLP is network layer and thus totally opaque to userland Feb 05 01:12:01 going outside didn't get me a lock even though I could see the sats Feb 05 01:12:20 did they have signal? Feb 05 01:12:40 location-test-gui didn't show me anything to suggest they did one way or the other Feb 05 01:12:56 It said there were lots of sats visible but none in use Feb 05 01:13:03 as high as 5 visible Feb 05 01:13:09 "sats in sight" only means what almanach tells you are supposed to be able to see under optimal conditions Feb 05 01:14:29 it suggests you received somewhat working almanach data Feb 05 01:14:48 *if* the sats shown as "visible" are actually correct Feb 05 01:14:57 No idea then why its not working if I select either "GNSS" or "AGNSS" in location-test-gui Feb 05 01:15:28 maybe because it has a totally off idea where you are? Feb 05 01:15:44 ok, sounds like a reset of bb5 might help Feb 05 01:16:15 should I try this bb5 data reset thing or should I just try a power down and reboot? Feb 05 01:16:21 to guess what sats are visible (and thus search for them) the algo needs your position first. To some +-few 100s of miles Feb 05 01:16:23 i.e. power down for a minute then reboot? Feb 05 01:16:53 try both. Did you find that reset thing? where? Feb 05 01:16:58 I didn't find the reset thing Feb 05 01:17:11 powered down my phone now, will wait a minute or two then power up again Feb 05 01:17:25 remove battery Feb 05 01:17:28 I did Feb 05 01:17:36 if I get the "enter date/time" screen then I will know its reset the bb5 I guess Feb 05 01:17:43 so modem definitely doesn't store shit in RTC or cmos storage Feb 05 01:19:35 ok, that should be long enough, lets try it now Feb 05 01:19:51 see if it resets any stuff the bb5 might be confused about Feb 05 01:20:37 ok, I got welcome screen so that means things got reset Feb 05 01:23:55 although that didn't help Feb 05 01:24:11 I strongly suspect its a certificate problem talking to the SUPL server Feb 05 01:26:09 cmcli says "verification failed, self signed certificate" Feb 05 01:36:47 downgrading maemosec-certman-common-ca to the version with the fix in it didn't help either Feb 05 01:36:49 still no lock Feb 05 01:37:00 Nothing I do seems to get a GPS lock on my N900 Feb 05 01:39:25 even without any connectivity, GPS should get a fix after 15min the latest, as long as there's a strong enough sat signal Feb 05 01:40:53 actually should be faster since every sat sends its own orbit data faster than the complete almanac/ephemeral Feb 05 01:41:44 but you need a iirc 30dB higher signal than needed to *keep* a fix Feb 05 01:42:33 and correct system time and at least country you're in will prolly also help a lot Feb 05 01:43:07 system time is easily obtained from SAT data. Location not that easily Feb 05 01:43:31 the better your initial guess of location, the faster TTFF Feb 05 01:43:35 basically Feb 05 01:44:01 and that's partially what A in AGPS is all about Feb 05 01:44:38 ok so the only explanations I have are bogus data being held somewhere (e.g. bb5), that I cant see any sats even when outside (for some reason, there are clouds but they are light clouds and not the heavy stuff that gets in the away) or that the n900 is doing something wrong somewhere (e.g. wrong library version being a problem). Feb 05 01:44:48 when you get bogus assistance data, I'm pretty sure you're better off with none at all Feb 05 01:45:22 This is after trying it for ages with "GNSS" selected in location-test-gui and disconnected from wifi/cellular data to make sure its not trying to download anything Feb 05 01:45:31 My gut says bogus stored data is the likely answer Feb 05 01:45:54 you got a SIM? Feb 05 01:46:03 Yep, I have a sim in the phone Feb 05 01:46:08 and it returns the correct country code Feb 05 01:46:10 see RRLP!!! Feb 05 01:46:14 and I am connected to 3G voice Feb 05 01:47:02 "CWP" seems to have given me a lock Feb 05 01:47:22 although I think that's just cell tower positioning and nothing to do with GPS Feb 05 01:47:51 yes, and cell towers send "supl" Feb 05 01:48:10 I think I need to find that tool to remove whatever crap bb5 is holding Feb 05 01:48:28 you need to remove SIM first of all Feb 05 01:48:50 or at least go airplane mode Feb 05 01:49:11 though I'm still not sure if it *receives* RRLP nevertheless Feb 05 01:49:19 gone to offline mode Feb 05 01:50:43 offline mode plus GNSS in location-test-gui should mean it uses 100% no cellmo works-like-standalone-GPS offline mode to get a lock Feb 05 01:50:59 with nothing taken from the cellmo or networks of any kind Feb 05 01:52:52 Looks like finding that tool to erase stored GPS data in bb5 would help Feb 05 02:01:02 https://bugs.maemo.org/show_bug.cgi?id=7026#c35 Feb 05 02:01:04 04Bug 7026: Can't get a GPS lock with several satellites at view Feb 05 02:01:43 "should mean" HAHA Feb 05 02:02:13 please read about RRLP Feb 05 02:02:24 ~gsm-agps Feb 05 02:02:24 from memory, rrlp is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP Feb 05 02:02:56 BB5 prolly has not even a means to NOT use RRLP when it's available Feb 05 02:03:23 RRLP is 911-related and completely outside of user control Feb 05 02:04:02 and obviously not even the Nokia maemo gurus knew about that when they made maemo5 Feb 05 02:04:22 BB5 is largely opaque to them as well Feb 05 02:06:04 o_O Feb 05 02:07:01 please understand that CWP and SUPL etc is basically only userland, with a defined API to send the SUPL data to modem aka GPS chip. But that modem-GPS-chip has its own "SUPL" (called RRLP) and maemo devels didn't know Feb 05 02:09:07 FFS! Feb 05 02:09:23 ~literal gsm-agps Feb 05 02:09:23 "gsm-agps" is "see rrlp" Feb 05 02:09:32 ~literal rrlp Feb 05 02:09:32 "rrlp" is "the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP" Feb 05 02:11:26 infobot: no, rrlp is RRLP is the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://osmocom.org/projects/security/wiki/RRLP Feb 05 02:11:27 DocScrutinizer05: okay Feb 05 02:12:32 >>In all known phones, RRLP operation is completely invisible to the user of the phone<< Feb 05 02:13:38 >> Contrary to the user-plane based SUPL, RRLP works entirely in the signaling plane of the network. As such, the RRLP protocol level is not accessible to user applications on a phone.<< Feb 05 02:14:42