View Full Version : Nokia N900 A-GPS Not Working Anymore
Hi!
I am in Australia and I found recently that my Nokia N900 GPS is not working, that is, not getting 'locked'. I had this problem 6 months ago but when I changed the server from Nokia to Google (supl.google.com), it started working perfectly. Now the same problem happening again... this time with Google.... Any solution will be very appreciated as I need GPS a lot!
Thanks
Which application you are trying it in? Nokia Maps times out after 10 minutes, even though locking may take up to 20, so Nokia Maps may never get the lock. Try GpsData, GpsJinni or Modrana.
[QUOTE=pichlo;1356991]Which application you are trying it in? Nokia Maps times out after 10 minutes, even though locking may take up to 20, so Nokia Maps may never get the lock. Try GpsData, GpsJinni or Modrana.[/QUOTE
Thanks for your reply. I just installed those applications you mentioned but they didn't work too. I think it has nothing to do with the application that I am running on my phone. Perhaps there is something wrong with the GPS server...
P.S: I'm using Nokia Ovi maps.
peterleinchen
2013-07-05, 09:43
Just check once more in settings, that really supl.google.com is chosen!
I have this often reset to nokia.com after a ungraceful shutdown.
If it os set to google check with your data provider that port(s) 7275/7276 are really open.
I have also noticed that it takes an age to see GPS location.
it used to work perfectly up until last week :(
using supl.google.com
it must be an issue with supl.google.com - my s2 also does it
Do we have the root certificate in place for supl.google.com ?
They used to use Thawte, but now they use Equifax
Perhaps the Equifax Secure Certificate Authority is not installed.
(http://www.geotrust.com/resources/root-certificates/index.html)
peterleinchen
2013-07-05, 11:35
Just tested and got sat fix within seconds (Germany).
I am in Australia and I found recently that my Nokia N900 GPS is not working, that is, not getting 'locked'.
Actually Nokia N900 GPS does not need any server for getting GPS "lock". These servers (supl.nokia.com etc and the service name is Assisted GPS or AGPS) are only used to accelerate getting the lock. GPS satellites send position signals after every 12.5 minutes, so it takes maximum that time to get a GPS fix in the conditions that there is unobstructed view to the sky. Go to the open landscape an you should get the fix. If not, then... probably hardware failure...
Actually Nokia N900 GPS does not need any server for getting GPS "lock". These servers (supl.nokia.com etc and the service name is Assisted GPS or AGPS) are only used to accelerate getting the lock. GPS sattelites send position signals after every 12.5 minutes, so it takes maximum that time to get a GPS fix in the conditions that there is unobstructed view to the sky. Go to the open landscape an you should get the fix. If not, then... probably hardware failure...
No GPS with A-GPS needs the A-GPS. But, it will make the lock happen faster.
The mechanism is a bit complicated. Shortly, it downloads 'most recent information' from the area you are located, which it finds using GSM towers and triangulation. A lock will happen really fast, but a precise lock will happen far later, perhaps half an hour, when the GPS have recieved a complete set of data.
http://en.wikipedia.org/wiki/Assisted_GPS
don_falcone
2013-07-05, 11:53
Tha's basically what he already said.
A lock will happen really fast, but a precise lock will happen far later, perhaps half an hour, when the GPS have recieved a complete set of data.
http://en.wikipedia.org/wiki/Assisted_GPS
Well, everything is explained in your cited wiki page and here:
http://en.wikipedia.org/wiki/Time_to_first_fix
I myself do not use AGPS at all (usually there is no network connectin where I use GPS) and I get fix during some minutes. If it is "cold" or "factory fix" then the time could be up to 12.5 minutes, otherwise less. And it is "anywhere on or near the Earth where there is an unobstructed line of sight to four or more GPS satellites" :) How many satellites are visible are shown for example in a program "GPS Recorder" ;)
glo-worm
2013-07-24, 10:40
I have same problem, Just turning on Skype with location setting enabled, used to work. I sometimes had problems overseas using supl.nokia.com so changed to supl.google.com for satisfaction. But now, neither work and GPS fix just says 'searching...'
I am using CSSU thumb which was recently updated, so first suspect is did the update break something?
supl.nokia and supl.google are both confirmed not working with N900 now. one has to find another free supl server, or just disable AGPS, and rely on the GPS to work on its own.
I have same problem, Just turning on Skype with location setting enabled, used to work. I sometimes had problems overseas using supl.nokia.com so changed to supl.google.com for satisfaction. But now, neither work and GPS fix just says 'searching...'
I am using CSSU thumb which was recently updated, so first suspect is did the update break something?
No, it has nothing to do with any update, CSSU, or Thumb. It doesn't work anywhere, even PC (not sure about Androids)
peterleinchen
2013-07-25, 21:49
supl.nokia and supl.google are both confirmed not working with N900 now.
Unfortunately I need to confirm this (despite my first post in this thread from beginning of July).
Could definitely have something to do with latest Google changes regarding their CAs...
https://pki.google.com
Using Skype with location setting enabled, I noticed the constantly blinking dish icon just some weeks ago. So I'd rather doubt that probs are caused by Googles PKI. Last root certificate changes for supl.google.com were in mid 2011 (from Thawte to Equifax/Geotrust).
As supl.google.com has stopped working with N900 I started searching for other supl servers, unfortunatly there are not many around. I found
supl.vodafone.com
supl.sonyericsson.com
sls1.sirf.com
seemingly to be active. With supl.vodafone.com my dish icon stopped blinking after some minutes, so I'm fine with this. Didn't check the others for location data, just for propper TLS responses .
@disappear: I've never used Sygic. I only use the stock Maps application which is good enough for my needs. I'm not a heavy maps/GPS user anyway.
I do have Mappero, but have never really needed to use it.
hmm, i just found this interesting post on Meego forum here on TMO: http://talk.maemo.org/showpost.php?p=1363686&postcount=9
disappear
2013-07-30, 13:56
Originally Posted by qhubekela
@disappear: I've never used Sygic. I only use the stock Maps application which is good enough for my needs. I'm not a heavy maps/GPS user anyway.
I do have Mappero, but have never really needed to use it.
This response was not expecting,most of users(n900) with pleasure used sygic,because with sygic we don't need from wifi or 3g connection,but if you have no limited network traffic,yes i see reason why nokia maps is alternative,however
regards
This response was not expecting,most of users(n900) with pleasure used sygic,because with sygic we don't need from wifi or 3g connection,but if you have no limited network traffic,yes i see reason why nokia maps is alternative,however
regards
Did you read earlier posts? No network connection is needed to get a GPS fix. It can only accelerate it. ;)
Just tested and got sat fix within seconds (Germany).
But when was your last fix and how far did you move since then?
eccerr0r
2013-07-30, 15:24
For T-mobile usa, lbs.geo.t-mobile.com apparently is also a SUPL server, but it does not work on my n900. Oddly enough this does seem to work on my Nokia 5230 Nuron, as it can get a really fast assisted GPS lock (as in 5 seconds).
I want my N900 to lock that fast :(
Should this be technical support for T-mobile? I should be allowed to use this SUPL server as I'm a subscriber to their wireless service...
FWIW, the only thing with stock Maps that needs an active Internet connection is Search. Everything else, including route calculation, doesn't need an Internet connection, unless of course you are suddenly zooming in more, or attempting to display an area for which maps are not already cached on-device.
Stock Maps will try to establish an Internet connection automatically, but you can always refuse to do so, or use dummy connections (see Wiki).
eccerr0r
2013-07-30, 18:10
I don't know why there's so many people saying AGPS is not needed. Well it is true, it isn't truly needed - GPS indeed will get a lock on its own, but it can take more than 10 minutes... This long time to lock may make people think it's not working.
Things that would be great to have a quick lock:
- Geotagging photos. Though geotagging has been a privacy issue if not handled properly, it makes it easier for someone to remember where they took a particular picture if they didn't label them.
- Location based services like Gasbuddy.com Mobile web page. If you're out of gas and don't want to spend 10 minutes to find a close (and possibly even cheap) gas station in a town you don't know.
- Power saving. Being able to just get a quick lock via AGPS when you switch on your map and turn it off to save power. The alternative is to keep the GPS running all the time... If only it didn't take a minute or so to even get a warm lock (and the power burn while waiting for the lock.)
I guess one does get spoiled when AGPS works as it should.
peterleinchen
2013-07-30, 21:07
But when was your last fix and how far did you move since then?
Good question, did not really think about before posting. Cannot remember now anymore, but most probably it was a long time ago, as I mainly use GPS functionality with my N9 nowadays. But probably almanch data was already up-to-date. So ...
... So I'd rather doubt that probs are caused by Googles PKI. Last root certificate changes for supl.google.com were in mid 2011 (from Thawte to Equifax/Geotrust).
Yep, true!
I also invested some time and tried to invetigate. But only thing I could find out, it has nothing to do with certificates. openssl revealed full access to supl. google.com. But as well as to supl.nokia.com. So only thing I can imagine is, closed binary GPS blob may still use ssl v2 (I could not establish ssl2 conn to those servers)?
...
... As supl.google.com has stopped working with N900 I started searching for other supl servers, unfortunatly there are not many around. I found
supl.vodafone.com
supl.sonyericsson.com
sls1.sirf.com
seemingly to be active. With supl.vodafone.com my dish icon stopped blinking after some minutes, so I'm fine with this. Didn't check the others for location data, just for propper TLS responses .
Thanks for sharing.
vodafone needs more testing, as my GPS is locked right now ...
sonyericsson would need some sony self-signed certificate, which I could not find
similar applies to sirf.com (do you have those certificates?).
Anybody out there needs to know that!!!
It is impossible that the whole internet/world community does not know why we are doomed :(
So -please- any one knowledged step up and speak out.
peterleinchen
2013-08-01, 19:23
...
Anybody out there needs to know that!!!
It is impossible that the whole internet/world community does not know why we are doomed :(
So -please- any one knowledged step up and speak out.
At least I would like to know why! :(
eccerr0r
2013-08-07, 00:09
Woah. I think I may have AGPS working again, at least it *looks* like it.
Note: This is for T-Mobile USA customers only. I suspect a lot of US users use their N900s on T-Mobile USA anyway because their 3G bands works with the N900. If you're not a T-Mobile USA customer, sorry this will not work as T-Mobile has this SUPL behind their firewall, so you have to use your data plan to use this server (and not wifi).
1. Goto http://dp.t-mobile.com/pki/ - download and install these certificates:
T-Mobile USA Root CA.crt
T-Mobile USA Issuer CA 05 v1.crt
T-Mobile USA Intermediate CA 01.crt
Details later
2. Set your SUPL server to lbs.geo.t-mobile.com
3. Reboot (not sure why this is needed, but somehow it started working after reboot)
Now I can't totally vouch all these steps are needed but somehow, after doing these things, I turned my "10 minute blinking satellite icon" to "blink twice and stable" and get a lock that's within 2 miles even without satellite information. This is very indicative of some sort of AGPS lock I think.
Edit: I do have to admit, the "locks" I got were worse than what I got when supl.google.com was working - they're like 3 km instead of ~1.5km with google.
If someone could verify this as good that would be nice too.
DfLo1913
2013-08-07, 01:24
My GPS is working with supl.google.com just takes awhile to get going. I usually get it working with GPSData and GPSJinni both running at the same time.
eccerr0r
2013-08-07, 02:46
Before I was getting the AGPS lock with supl.google.com within 30 seconds (even indoors, as long as I'm on GSM) - but as of recent it would have to fall back to standard GPS lock (or never getting a lock if indoors). 30 second is longer than the little satellite dish blinking 8 times, so if it blinks longer than 10 times, likely AGPS lock wasn't successful.
I am fairly certain supl.google.com does not work for me. Previously a fix sequence in Mapsi/Modrana went generic country location, cell mast location, position, the first 2 being agps. Now I don't get the second, or so it seems.
Further on testing the gps, I remind folk of the tool location-test-gui (http://repository.maemo.org/pool/maemo5.0/non-free/l/location-test-gui/).
I do not know about the differences if any between versions in the repo folder.
Tool allows to test 4 location methods (see README available from gui dropdown), assuming that both gps and agps are enabled under settings:
CWP- country / cellular base positioning
ACWP - the above using external location server.
GNSS - standalone GPS
AGNSS - assisted GPS using external location server.
Should settle once and for all what is or is not working.
For me, supl.google.com is not working. This tool shows that fact and so does cellnet-info. The latter identifies my location but the area and lat/longsare wrong. I guess cellnet-info uses whatever server is entered under settings rather than some independant database via the internet.
So, is there anyone with supl.google.com working under location-test-gui? If so, what country? Are there any open supl servers working? If so, what country?
I have been using location-test-gui all this time. believe me.. supl.google.com doesn't work for anyone, not even DfLo1913 a few posts before.
If you want to see the full reason, turn on location-test-gui, and also check syslog. location-test-gui clearly shows that supl.google.com closes the connection as soon as it is established.
For me, supl.google.com is not working. This tool shows that fact and so does cellnet-info. The latter identifies my location but the area and lat/longsare wrong. I guess cellnet-info uses whatever server is entered under settings rather than some independant database via the internet.
Cellnet-info does not use an AGPS Server like supl.google.com. It finds the location by searching the coordinates of the celltower on OpenCellID (which is an independent database). This coordinates are then used to find a postal address on maps.googleapis.com. This works fine on my devices, tested in various countries. If the data is not accurate, I presume the data on OpenCellID has to be blamed ;)
If we are talking about getting gps locks itself: I am also having a lot of trouble with that lately.
DfLo1913
2013-08-07, 21:56
I have been using location-test-gui all this time. believe me.. supl.google.com doesn't work for anyone, not even DfLo1913 a few posts before.
If you want to see the full reason, turn on location-test-gui, and also check syslog. location-test-gui clearly shows that supl.google.com closes the connection as soon as it is established.
Right now I have my GPS on and its locked in on me. I have supl.google.com in the settings.
Right now I have my GPS on and its locked in on me. I have supl.google.com in the settings.
Luckily, a lock will happen eventually even if the supl server fails. The point of agps is enhanced lock speed. Does your gps get a fix in ca. 30 secs? Prolly not.
DfLo1913
2013-08-07, 22:34
Luckily, a lock will happen eventually even if the supl server fails. The point of agps is enhanced lock speed. Does your gps get a fix in ca. 30 secs? Prolly not.
Nope. I never said it did. Should rename this thread to AGPS not working then.
peterleinchen
2013-08-07, 22:46
Right now I have my GPS on and its locked in on me. I have supl.google.com in the settings. Dont speak on my behalf.
Right now I switched off the engine of my aircraft. But I am still flying! How comes?
Cmon. Check it out correctly as suggested by handaxe. And do not speak (nonsense) on your behalf.
A GPS lock does not say AGPS is working! The GPS may get a lock on its own. Especially if there has not been a long time or distance between a previous lock.
supl.nokia.com is NOT working since long time
supl.google.com is NOT working anymore
supl.vodafone.com is NOT working on N900 ( whereas it may work on N9 )
Next guess I have is the certificates are not read from cert store, but that Nokia has hard-coded them in the closed binary blob. That would mean we will never get a solution (or someone will disassemble and put new certs or make it read from cert store). Again, just a guess...
DfLo1913
2013-08-07, 22:51
Right now I switched off the engine of my aircraft. But I am still flying! How comes?
Cmon. Check it out correctly as suggested by handaxe. And do not speak (nonsense) on your behalf.
A GPS lock does not say AGPS is working! The GPS may get a lock on its own. Especially if there has not been a long time or distance between a previous lock.
supl.nokia.com is NOT working since long time
supl.google.com is NOT working anymore
supl.vodafone.com is NOT working on N900 ( whereas it may work on N9 )
Next guess I have is the certificates are not read from cert store, but that Nokia has hard-coded them in the closed binary blob. That would mean we will never get a solution (or someone will disassemble and put new certs or make it read from cert store). Again, just a guess...
Need to rename this thread.
Need to rename this thread.
Yes you are right it is misleading.
Is the ssl version suggestion still not a possibility as to cause?
I remember someone posting info about successfully using middle-man to "sanitize" AGPS request to supl.nokia.com, so it was working on N900. Not very convenient, still it work(ed) - I can't find reference, right now.
OTOh, I wonder what mugols from "do only evil" G company did to limit availability? What they use to identify non-google device, so supl.google.com drops connection, and how we can get around it easily? ;)
/Estel
nokiabot
2013-08-08, 03:04
supl.google.com : supl.nokia.com and voda and few others are working fine for me any device india:) it takes just 5 to 10 seconds for lock:)
peterleinchen
2013-08-08, 06:52
supl.google.com : supl.nokia.com and voda and few others are working fine for me any device india:) it takes just 5 to 10 seconds for lock:)
:rolleyes: :facepalm: :and more: :rolleyes:
Yes, of course. And you tested all of them AFTER you had already a successful lock and you did it in a short time period and at the same location! Very impressive and investigative.
By the way, this thread is not about any device (which of course may work with known supl servers), but about inability of the N900 to establish a secured connection from built-in AGPS functionality to those servers.
supl.google.com : supl.nokia.com and voda and few others are working fine for me any device india:) it takes just 5 to 10 seconds for lock:)
The problem is that a successfu fix gets cached and called upon the next time positioning is needed within a certain time-period. So try rebooting and see if you get a quick fix.
nokiabot
2013-08-08, 09:00
i checked now is 40kms and 2 reeboots sufficent :) on the first try it took 15 to 20 seconds with gps jinni:)
sondjata
2013-08-08, 12:05
I'm a T-Mo customer and AGPS is dead, dead, dead. Not happy about that. Downloaded the certs. rebooted. Nada.
And why would Nokia block Nokia devices. That's just stupid.
And why would Nokia block Nokia devices. That's just stupid.
Not just stupid but if I read the FCC 911 enhancement requirement (http://en.wikipedia.org/wiki/Enhanced_911#Location) correctly, also illegal, at least in the US of A.
IANAL though so what do I know.
i checked now is 40kms and 2 reeboots sufficent :) on the first try it took 15 to 20 seconds with gps jinni:)
That is pretty fast for a cold fix. If you used location-test-gui after a reboot with ACWP positioning I wonder if you get anything?
glo-worm
2013-08-08, 20:15
Hi there,
Just changed SUPL to vodafone after hard reboot, indoors with poor GPS skyview. Two flashes of the GPS icon after i change skype state to online,and i get coarse accuracy lock.
So for me it looks like both nokia and google SUPL dont work, but vodafone does.
Interestingly when i was testing with google SUPL, i never achieved GPS lock when using skype location as a trigger. I left the phone on the table outside with clear view of the sky and after 30 mins still searching.
If i ran the nokia maps app, i would get GPS fix in few minutes.
My skype location is set to city level, so pure AGPS would alway be enough for this, could it be that GPS is not used to save battery power???
sondjata
2013-08-08, 20:39
Is that supl.vodafone.com?
I just put that in my 9000 and still not working.
Temporal
2013-08-08, 21:02
If my experience is of any value, I have just traveled around 600km(300+300) and the GPS, though slow(it was always slow, takes 20 secs+- to lock) always locked and I was able to track, and see the speed and etc. Unfortunately I have only used supl.google one, (and just to be sure, I changed batteries several times while traveling, so yes, I did reboot).
But, as I'm in Brazil, my experience might be useless.
Next guess I have is the certificates are not read from cert store, but that Nokia has hard-coded them in the closed binary blob. That would mean we will never get a solution (or someone will disassemble and put new certs or make it read from cert store). Again, just a guess...
Why did it used to work since at least may of 2013 then? I may be wrong stating that it was indeed working, I didn't test for the A of AGPS functionality ...
The reason why I came to this thread was, that I noticed in June that Skype location status wasn't working any more . The satelite icon next to the green Skype status icon was blinking constantly. But when starting Nokia maps app, after some minutes I got a fix and the Skype location was shown and kept updated as long Nokia maps was running. Without Nokia maps the dish icon started blinking again after some minutes. I used supl.google.com since 2011 .
But since I switched to supl.vodafone.com , Skype location status is working again as I was used to (without having to start Nokia maps). So my problem is solved somehow ...
But I got curious about the A for GPS and checked location-test-gui, together with syslogs. I wonder what would be spit out by the logs if AGPS *is working*. I get a lot of satelites in view, but never in use.
Can someone outline a scenario, how to use location-test-gui without any misleading side effects like cached data and so on? Like
- set supl.xxx.com in settings
- shut down
- travel some kilometers (?)
- start up N900
- start location-test-gui, choose AGNSS
- wait 1 (?) min
- If you see your right position then, AGPS is working (?)...
- What shows location-test-gui if it fails (?) ...
- What do the log files look like when OK or failure (?)
I mean some easy steps to do, to get comparable results. Instead of just "I got a fix in my country xyz" or "No it doesnt work here" ...
Thank you.
Side note: Skype location status on N900 might be a questionable feature nowadays, but still the only mobile Skype implementation with that functionality ... thats why I love it.
eccerr0r
2013-08-09, 00:04
For those of you who are posting success, please indicate country and your carrier (or ISP if you're using wifi). Reports seem to contradict with each other including my success with lbs.geo.t-mobile.com on T-Mobile USA and others' experiences... This is most troubling in my opinion. This is because if I switch on wifi, AGPS fails. Go back to 3G, it works, like a light switch. (Then again it's super annoying to have to switch networks if I happen to be using wifi at the time.)
Please, stop posting useless and miss-leading "success stories". No one cares if it took 10, 20, or 324574375463 seconds for you to get fix - the one and only *meaningful* of testing AGPS is as per this post, earlier in this thread:
http://talk.maemo.org/showpost.php?p=1365615&postcount=31
Otherwise, it's just a guesswork. Meanwhile, testing it *properly* isn't hard, at all.
/Estel
What's the expected outcome from that tool?
Seems like all four tests are responding with a position. Allthough not precise location on my device.
Carrier Telia Denmark
WiFi tried with on/off
the one and only *meaningful* of testing AGPS is as per this post, earlier in this thread:
http://talk.maemo.org/showpost.php?p=1365615&postcount=31
So I tried again location-test-gui tool, right after reboot. Test method AGNSS with supl.vodafone.com
I got 4 satellites within about 20 secs standing next to a window.
http://talk.maemo.org/attachment.php?attachmentid=32979&stc=1&d=1376061861
Then, after another restart of N900, I tried AGNSS again. Same effect . got 4 satellites after some seconds.
http://talk.maemo.org/attachment.php?attachmentid=32980&stc=1&d=1376061861
Both locations about 150m away from my real position. But guess what: Before reboot for second test I changed location server to supl.nokia.com (which is known not to work).
So obviously if you got a fix before, just a reboot is not enough for helpful results with location-test-gui and proving if AGPS is reliably working.
Folks, I believe to test agps you need to use the method acwp after a reboot. That takes the gps receiver out of the equation and relies on the supl server to derive cell based location.
Now, there are many flavours of agps (refer wikipedia) but I believe my n900 was getting cell location while the gps and the supl. server were doing things to get an accurate fix. That cell location has definitely disapeared for me.
Doing a cell loc. first also makes sense as cellphone gps do not store sat. almanacs as do handhelds. Providing that is the job of the supl server and to do that it needs to know broadly where you are. That info saves the need for a sky search for sats and is one of the speedups made by agps
One can also test without location-test-gui by disabling the gps under settings - location but keeping network location enabled. Again a reboot is needed to flush the cache.
Phew - long, sorry.
peterleinchen
2013-08-09, 22:29
So many posts, so many knowledge.
But all "half-knowledge"!
I have to admit I do not know exactly the working of location-test-gui, so I did not post. But for sure is it has different methods and we need the last one. AGNSS (AGPS).
This will give the receiver the desired satellite info like position of current location where are those satellites and their sky posititon (almanach, who says this is not stored on cell phone?).
We may also use the ACWP method, but this will give only ground location based on cell tower info (and/or SIM info, MCC).
For real testing you will need to reset the receiver cache by rebooting. No other chance to reset the GPS chip (afaik).
BUT, this is not enough. Before rebooting you need to reset the stored (not cached) last known position and timestamp.
gconftool --recursive-unset /system/nokia/location
This is the crudest way, but you will also see the GPS usage disclaimer again?
Happy testing...
And let us know that it will work for you! :rolleyes:
For me none of nokia/google/vodafone worked.
P.S.: you may start to try with AGNSS.
I stop after 30/60 sec, that is definitely enough time for AGPS.
If you wanna try the cell tower/provider solution (ACWP), you may see that this method will just fetch the SIM/provider country code and position you in the middle of your currently located country (try it with DISabled SIM and you will see!). If it would fetch supl data it would locate you approximately 150m-1500m off your real position.
Again, happy testing...
DfLo1913
2013-08-10, 04:21
Hey guys which location-test deb file should I install? Thanks
supl.google.com works for me
those with issues, try
test.supl.svc.ovi.com port 7276
How do I set the port?
you shouldt need to, its the same port as other supl providers.
Sorry, should propaly not even have mentioned port ;)
peterleinchen
2013-08-10, 08:14
supl.google.com works for me
Yeah sure. And the tower of Pisa belongs to Mona Lisa.
those with issues, try
test.supl.svc.ovi.com port 7276
Where did you get that information from?
you shouldt need to, its the same port as other supl providers.
Sorry, should propaly not even have mentioned port ;)
And the "half-knowledge" goes on ...
Standard port(s) for supl is/are 7275/7276. And they may go up to 7278.
But on N900 it is pre-configured to 7275.
How do I set the port?
gconftool -s /system/nokia/location/supl/port -t int 7276
@peterleinchen
Why do you need to be rude?
Perhaps the *half knowledge* is just that half that is missing.
And, I dont give a rats *** if you believe google is working for me or not. fYI.
the test.supl.ovi.com info.is from.the knowledge I have from the PEAK FirefoxOS phone.
peterleinchen
2013-08-10, 11:15
@peterleinchen
Why do you need to be rude?
THAT: Yeah sure. And the tower of Pisa belongs to Mona Lisa. was rude?
Then you really wont like to meet me in real life! ;)
Sorry, if you felt offended.
Perhaps the *half knowledge* is just that half that is missing.
And, I dont give a rats *** if you believe google is working for me or not. fYI.
Yeah, that IS rude.
And believe me, I do know that it is not working. As you (besides nokiabot) would be our super heroes.
Please, test once again with above described procedure. And tell us again...
the test.supl.svc.ovi.com info.is from.the knowledge I have from the PEAK FirefoxOS phone.
Thanks for that info.
And I tested it and also that supl does not work on N900.
From that PEAK Firefox OS phone otoh your experience may be that supl.google.com is working. As well as for all android phones. And maybe other devices.
But we are talking about supl/AGPS on N900.
peterleinchen
2013-08-10, 11:21
Hey guys which location-test deb file should I install? Thanks
~ $ apt-cache showpkg location-test-gui
Package: location-test-gui
Versions:
0.93-1+0m5 (/var/lib/apt/lists/repository.maemo.org_dists_fremantle_tools_non-free_binary-armel_Packages) (/var/lib/dpkg/status)
Description Language:
File: /var/lib/apt/lists/repository.maemo.org_dists_fremantle_tools_non-free_binary-armel_Packages
MD5: 06ca30f437d8fde1cc09907d75cdf5e8
This is located in the tools repo of fremantle. So first add this to your catalogues (and disable after installation).
nokiabot
2013-08-10, 11:35
forgive me :( i dont know much but it is working for me as i get a fix in 15 seconds and if i turn of agps it takes 15 to 20 minuts to get a fix:) i flashed and checked also:D
Ok,
just did the gconftool reset, poweroff, poweron (had to set supl.google.com.again after poweron).
the disclaimer came up.
set to test AGNSS with locationtest-gui. (latest version from previous linked ones)
Got a fix in ~20 seconds, inside.
just for a note, iam on
2.6.28.10power46-w11 kernel
carrier is Telia
location Denmark
and yes, It is an n900 ;)
the supl from peak, was just another source for ppl to try.
both nokia servers are not working here, but, googles does work
forgive me :( i dont know much but it is working for me as i get a fix in 15 seconds and if i turn of agps it takes 15 to 20 minuts to get a fix:) i flashed and checked also:D
:) so we are official SuperHeroes
Can somebody confirm that ACWP relies on the supl server? Because if it does, I can confirm that supl.vodafone.com works: reliable ACWP positioning (error +/- 300m). Also quite fast GPS fix, though I know this isn't proof ;)
Bump... Any workaround on this ?
king Ralphred
2013-08-14, 21:13
Just found this thread. GPS has taken 5 mins to lock on, or so long I got bored.Tried changing from nokia to google. It locked on straight away or near as damn it. 3Ireland, 2g, GPSjinni, n900.
Thanks.
I'm not a superhero though.
Just tried it again after this post. It's hard to work out but it's seconds.
Tried changing from nokia to google. It locked on straight away or near as damn it. 3Ireland, 2g, GPSjinni, n900.
If you read in.this thread about position caching you might forgive my doubts about your report.
nokiabot
2013-08-15, 18:37
my gps still locked in seconds using google !
Can somebody confirm that ACWP relies on the supl server? Because if it does, I can confirm that supl.vodafone.com works: reliable ACWP positioning (error +/- 300m). Also quite fast GPS fix, though I know this isn't proof ;)
Yes, ACWP uses the supl server or it should. Yours is an interesting and surprising result provided that it followed a reboot. I get nothing usable (no reset just following a reboot) - generic country or nothing at all - and that is why I suggested ACWP over AGNSS as a test as it relies on a position server alone.
Any obvious reason re ISP (wifi/gprs?) as to why Vodafone might allow you to use the service?
my gps still locked in seconds using google !
Using ACWP method following a reboot?
Yes, ACWP uses the supl server or it should. Yours is an interesting and surprising result provided that it followed a reboot. I get nothing usable (no reset just following a reboot) - generic country or nothing at all - and that is why I suggested ACWP over AGNSS as a test as it relies on a position server alone.
Any obvious reason re ISP (wifi/gprs?) as to why Vodafone might allow you to use the service?
No reboot done, but I use ZapLoc in non-GPS mode with my own Latitude replacement hack, and it updates location nicely. So it works.
supl.vodafone.com gives me another location than google used to, also more stable and always the same place when I'm stationary (home, work, ...)
I should switch back to google to see if it works too.
My ISP is MobileVikings, which uses Base as network, which is family of KPN, not related to Vodafone AFAIK.
EDIT: switched to supl.google.com + reboot -> got only center of country as location. Switched back to supl.vodafone.com and location is back close to where I am (<400m)
My ISP is MobileVikings, which uses Base as network, which is family of KPN, not related to Vodafone AFAIK.
EDIT: switched to supl.google.com + reboot -> got only center of country as location. Switched back to supl.vodafone.com and location is back close to where I am (<400m)
Excellent, I am convinced. But why vodafone works for you and not some/many others is a mystery. Some agreement between providers? If you can try with another ISP over wifi. I want you to fail
:p
If you can try with another ISP over wifi. I want you to fail
:p
Why didn't I think of that... I'll switch to wifi and check things out :)
supl.vodafone.com also worked via wifi, ISP = telenet.be
Learned some things, though: clearing the location stored in system.nokia.location does not clear the caching, only a reboot helped.
To test, I've hacked one of the old update scripts to only use ACWP and only print results, not try to update latitude or whatever... - script attached.
so, in short:
supl.google.com + wifi or 2G: mode 1 location, center of country
supl.vodafone.com + wifi or 2G: mode 2 location, accuracy 188m
supl.vodafone.com also worked via wifi, ISP = telenet.be
To test, I've hacked one of the old update scripts to only use ACWP and only print results, not try to update latitude or whatever... - script attached.
so, in short:
supl.google.com + wifi or 2G: mode 1 location, center of country
supl.vodafone.com + wifi or 2G: mode 2 location, accuracy 188m
Thanks for script. I believe your evidence is unequivocal. But why it works is another thing (I wonder if using a tor proxy with exit nodes can be used to test country effect?). And you confirm that supl.google is a goner.
So, it would be inteesting for others to test with petur's script after a reboot. what supl works and where are you?
peterleinchen
2013-08-18, 07:10
supl.vodafone.com also worked via wifi, ISP = telenet.be
so, in short:
supl.google.com + wifi or 2G: mode 1 location, center of country
supl.vodafone.com + wifi or 2G: mode 2 location, accuracy 188m
Yep, confirmed from my previous tests using test-location AFTER
gconftool --recursive-unset /system/nokia/location
AND a
reboot
and reconfiguring supl server in settings (sorry for delay, had to sort some other things out).
Funny is:
it works with WiFi and vodafone network 2G/3G, but NOT with O2-de GPRS/UMTS. So it is proven (google dead, vodafone works for some ...)
Learned some things, though: clearing the location stored in system.nokia.location does not clear the caching, only a reboot helped.
Yep. ONLY after above procedure (both clearing and reboot) you will get reliable results (or using petur's py)!
To test, I've hacked one of the old update scripts to only use ACWP and only print results, not try to update latitude or whatever... - script attached.
Did not know about these script(s). Mind telling us the source?
Nevertheless, now we have one supl server left delivering location cell tower based position. :)
Better than nothing, but it is not real assisted GPS. And we do not know the reason for nokia/google failing yet :(
so, in short:
supl.google.com + wifi or 2G: mode 1 location, center of country
supl.vodafone.com + wifi or 2G: mode 2 location, accuracy 188m
Same here in the Netherlands. With supl.google.com I get the location of the city of Baarn, which is indeed in the center of the country. And supl.vodafone.com provides me accurate info.
Did not know about these script(s). Mind telling us the source?
There's a Google Latitude thread somewhere on the forum here (*) that contains several iterations of the script, the hard part for them was to get Google Latitude to update (and it doesn't work anymore), but the location part was pretty good, I just changed the method from AGNSS to ACWP to make it NOT use GPS.
This helped too:
http://wiki.maemo.org/PyMaemo/Using_Location_API
(*) http://talk.maemo.org/showthread.php?t=38542
(edited to add URL of relevant forum topic)
Funny is:
it works with WiFi and vodafone network 2G/3G, but NOT with O2-de GPRS/UMTS. So it is proven (google dead, vodafone works for some ...)
After using gconftool and rebooting I can confirm that vodafone does not work with either Tele2 or Tre(3) Sweden.
I guess from other info in peterleinchen's post that agreements between ISPs or lack thereof, are playing a role here. Something else in the case of google...
Is info from syslog why you don't think supl.vodafone is providing a full supl service?
peterleinchen
2013-08-18, 12:43
Is info from syslog why you don't think supl.vodafone is providing a full supl service?
Nope, just a simple implication from test-location-gui providing cell based location (acwp), but not returning data for agnss.
Maybe I should enable syslog again and try once more? But I do not expect to see anything more ...
For me supl.google.com started working again via 3G/T-mobile germany, the last days i never got gps-fix, today in the car 150km from home i started nokia maps and got the fix in some seconds (maybe just luck?)
I can confirm that supl.vodafone.com work with Telkomsel carrier in Indonesia
Nope, just a simple implication from test-location-gui providing cell based location (acwp), but not returning data for agnss.
...
I have wondered what that info would be: the exchanges between n900 and the supl server? As I assume u don't mean the gps coords that do eventually pitch up
:)
Very peculiar that a supl server provides acwp but not 'full-house'.
same thing here with supl.google.com - started working again about 2 weeks ago via 3G (malaysia, on Maxis). it used to take about anywhere from 1 minute upwards to get a lock. i now get one in about 10 seconds max (actually, it used to be much faster like 3-5 seconds, but 10 seconds is fine by me).
Again. I repeat. Supl.google.com IS working here.
Dont know why some insists im faking it. I never do.
Might be a carrier/country whatever deal I have no idea, but it gives a good location in ~15 secs.
Again. I repeat. How fast you get a lock means nothing. When I set it to supl.google.com I get cr*p ACWP support, if I enable GPS I get a lock in <30 seconds.
It's *very* hard to reliably test what is going on, I'm using ACWP only as a measure because I can see clear differences between selected servers:
- set desired server
- reboot
- run acwp script I posted
Maybe I should wireshark the connection between n900 and supl.* to show what is going on.
i actually dont really care if supl.google.com is working or not. what's more important to me is the end result i.e. accurate gps lock is achieved in a short time - which is what i am experiencing now. as for the agps cache - no such issue since my phone has a scheduled reboot task that runs everyday.
Fine, but this thread isn't about your ends results (sorry ;) ), but about *real* A-GPS. Not to mention that you *won't* get such good results *if* real A-GPS support would be needed to gain it (quickly) in the first place, but frankly, we don't care about you results. We care about A-GPS (in this thread, at least).
---
Now, about the real things:
Maybe I should wireshark the connection between n900 and supl.* to show what is going on.
Very good idea. As said earlier, I remember someone respectable to mention, that even supl.nokia.com works *fully*, if A-GPS request is passed through a middle-man A-GPS server installed on N900 (the way, that local server "ask" supl.nokia.com, instead of N900 "asking" directly).
I can find the source quote for a life of mine, but it would be very interesting to RE it - after all, supl.nokia.com works for recently released Nokia devices. I bet, that they're filtering out requesting devices on purpose.
Knowing WTF is going on and what they use to identify, we could implement a way to mimic other device for our trusty N900 (and even implement possibility to do it from control panel, via CSSU, just like browser allow to change user agent).
/Estel
eccerr0r
2013-08-19, 22:34
Has someone packaged the proxy software at http://www.tajuma.com/supl/ somewhere?
Has someone packaged the proxy software at http://www.tajuma.com/supl/ somewhere?
I believe this is what Estel is referring to. Nice find...
woody14619
2013-08-20, 15:15
Knowing WTF is going on and what they use to identify, we could implement a way to mimic other device for our trusty N900
It could also give us a way to simply push the data ourselves. More often than not when people use GPS they know roughly where they are (city, state, etc). Even if the AGPS guess is off by a good distance, it doesn't change the satellite constellation the GPS is looking for that much. If one could even set/enter rough default coordinates, as long as you're in the ball park (+/- a degree) it will cut the time needed for GPS to lock dramatically.
While the GPS code is closed (preventing us from directly injecting a guess at a starting point), this may be a good way to fake it. A local supl server that computes a rough guess and feeds it to the closed source that then injects the right data.
Would be a popular project if someone's willing to take it up. :D
It could also give us a way to simply push the data ourselves. More often than not when people use GPS they know roughly where they are (city, state, etc). Even if the AGPS guess is off by a good distance, it doesn't change the satellite constellation the GPS is looking for that much. If one could even set/enter rough default coordinates, as long as you're in the ball park (+/- a degree) it will cut the time needed for GPS to lock dramatically.
While the GPS code is closed (preventing us from directly injecting a guess at a starting point), this may be a good way to fake it. A local supl server that computes a rough guess and feeds it to the closed source that then injects the right data.
Would be a popular project if someone's willing to take it up. :D
not quite that simple. The location servers return with a limited information, cached, making a near - but not complete set of location data. This data is cached. And the difference I believe. Is that the set of data is a bit late. Not real time. But, ofcourse we could cache similat response
Has someone packaged the proxy software at http://www.tajuma.com/supl/ somewhere?
So what is the consensus, would this intermediate proxy still work? Seems odd that supl.nokia allows the n9 et al but not the n900 yet would allow some arbitrary proxy supl. Or is it a certificate /ssl issue? Wireshark did not show ssl packets to supl.vodafone on my n900. It showed sslv3 for imap traffic.
But I am on one tenth knowledge here :) so someone smart with both an n9 and a n900 should sniff both supl'ing away...
eccerr0r
2013-08-21, 00:42
I was trying the supl proxy on my server and pointing my N900 to it. However results were inconclusive, I wasn't sure if my N900 was even happy with my supl server's certificates, making it tough to see what the real problem was...
I definitely did see some wireshark activity on port 7275 however, but didn't pursue it further after getting T-Mobile's server working... Granted a public server would be better as then it would also work on wifi...
Though I am happy with supl.vodafone.com I took some time today fiddling around with supl-proxy from tajuma.com .
I checked against all working supl-server I know of:
sls1.sirf.com
supl.google.com
supl.nokia.com
supl.sonyericsson.com
supl.vodafone.com
Everytime with preceeding steps in N900:
- gconftool --recursive-unset /system/nokia/location
- reboot
- setting location server to my server with running supl-proxy (pointed to the next supl server from the five mentioned above)
- running location test tool with method ACWP (with OK to supl usage terms)
To my surprise I got a quick (less than 10sec) location result within some hundred meters around with three of the five servers:
sls1.sirf.com
supl.nokia.com
supl.vodafone.com
With the others I got quite more data exchanged, but didn't get a location result.
If anyone is interested, see my proxy logfiles attached.
Without supl-proxy , just pointing my N900 to the five servers directly (with all the preceeding steps), the only server working for me is supl.vodafone.com .
I set up supl-proxy on my own network gateway and when I was rechecking without proxy my N900 was on wifi in my own network. So all request from same IP to the supl servers.
Okay, this could mean that N900 has probs with the data coming from google and sonyericsson, but for sirf and nokia(!) the only cause for failing - left to see to me - is certificate issues.
peterleinchen, seems you where quite right with your assumptions ...
I verified certificate chain on N900 (should have done earlier):
[2|user@Nokia-N900|/] cmcli -T common-ca -v supl.vodafone.com:7275
f73d6238917bbaeb04235d2219a1da31b4b68f4d supl.vodafone.com
trust chain(1):
f18ab43c6a02bfd8228c7965cf88f4abbc180aa6 Thawte Server CA
Verified OK
And for Nokia:
[2|user@Nokia-N900|/] cmcli -T common-ca -v supl.nokia.com:7275
1ad16dd494e161abd39bd94ed94bf8eafe4ede28 supl.nokia.com
Verification failed: self signed certificate
Too bad.
Checking the chain:
openssl s_client -connect supl.nokia.com:7275
I already had a short look into the cert chain , replacing VeriSign certs in certificate manager (via cmcli). But with no luck.
One can find all VeriSign root certs at http://www.symantec.com/page.jsp?id=roots .
Maybe someone has more abilities to digg deeper into it. Would be nice to have supl.nokia.com usable again. Until then supl.vodafone.com is good enough for my needs.
Cheers, Ulle
Superb research Ulle!
Could and should maemo.org run supl-proxy for us?
Was it easy to build? (for linux?).
How much traffic (kb/mb) in an exchange?
If you're going the (local or remote) supl-proxy route, which I intended to try as soon as I can get a Maemo dev environment set up, I strongly suggest you have a look at the open databases of cell IDs and wireless APs at http://openbmap.org/ and http://www.opencellid.org/ - I think prehaps with ephemeris data added, these could make a much better, more accurate, and open, SUPL server than we can currently get.
I think the Maemo app CellNet-info uses one of those sites to provide lat/long info for a cell, but I'm not entirely sure at the moment.
An open SUPL server would benefit not only the N900, but virtually any modern phone.
freemangordon
2013-08-28, 07:05
openssl s_client -connect supl.nokia.com:7275 -CApath /etc/certs/common-ca/
.
.
.
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: ..................
Session-ID-ctx:
Master-Key: ...................
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1377673374
Timeout : 300 (sec)
Verify return code: 0 (ok)
peterleinchen
2013-08-28, 07:10
I know that (and openssl returns also error when not pointed to /etc/certs/common-ca).
But why on earth does cmcli return an error even when pointed explicitly to common-ca???
That made me thinking of hard-coded certs in GPS blob.
And why supl.nokia.com returns result for N900 when using proxy?
freemangordon
2013-08-28, 07:19
I know that (and openssl returns also error when not pointed to /etc/certs/common-ca).
But why on earth does cmcli return an error even when pointed explicitly to common-ca???
That made me thinking of hard-coded certs in GPS blob.
And why supl.nokia.com returns result for N900 when using proxy?
hmm, seems you have misread my post, if given
"-CApath /etc/certs/common-ca/", it does not fail
peterleinchen
2013-08-28, 07:34
No no, I read and understood correctly.
As I made same experience.
openssl fails when not pointed to common-ca
openssl succeeds when pointed to common-ca
cmcli fails when not pointed to common-ca
cmcli fails also even when pointed to common-ca
So that means we have all needed certs aboard, but mabe they are not used or ... ?
At least Nokia and Google changed their cert paths in the past.
And the proxy acts as a proxy? Or initiates a completely new connection to supl? In first case it would not work afaik as ssl/cert communication is just forwarded?
freemangordon
2013-08-28, 07:40
...
So that means we have all needed certs aboard, but mabe they are not used or ... ?
...we have a bug in /usr/bin/location-proxy
I am thinking to RE that, it is not that big, but before I start, could someone try to confirm(somehow?) this is the binary to blame
EDIT: seems like it is libmaemosec.so to blame
EDIT2: microb doesn't have any problem connecting to supl.nokia.com:7275
peterleinchen
2013-08-28, 07:54
Oh man you are the man!
Why we did not contact you directly? Maybe because I did not want to put everything on your shoulder.
Eagerly waiting for a result. Be it positive or negative.
BIG thanks in advance.
How to do you a favour (already declined donations)?
freemangordon
2013-08-28, 08:03
How to do you a favour (already declined donations)?
Find why "cmcli fails also even when pointed to common-ca" :)
peterleinchen
2013-08-28, 08:32
:rolleyes: Yeah, sure! ;):D
joerg_rw
2013-08-28, 12:48
I know that (and openssl returns also error when not pointed to /etc/certs/common-ca).
But why on earth does cmcli return an error even when pointed explicitly to common-ca???
That made me thinking of hard-coded certs in GPS blob.
And why supl.nokia.com returns result for N900 when using proxy?
caveat: afaik supl.nokia.com is geo-ip, and just _some_ (most?) of the boxen are broken. You however may pick a good one at random
jr@saturn:~> host supl.nokia.com
supl.nokia.com is an alias for nokia.supl.svc.ovi.com.
nokia.supl.svc.ovi.com is an alias for nokia.supl.geo.geodns.fi.
nokia.supl.geo.geodns.fi is an alias for de.nokia.supl.geodns.fi.
de.nokia.supl.geodns.fi has address 213.157.72.147
jr@saturn:~>
/j
May I add:
# host supl.nokia.com
supl.nokia.com is an alias for nokia.supl.svc.ovi.com.
nokia.supl.svc.ovi.com is an alias for nokia.supl.geo.geodns.fi.
nokia.supl.geo.geodns.fi is an alias for dk.nokia.supl.geodns.fi.
dk.nokia.supl.geodns.fi has address 83.150.75.211
Could and should maemo.org run supl-proxy for us?
I was thinking of this too (okay, more have it running on my dyndns linux box). Main issue is: supl-proxy stops after each request/session.
Someone would have to extend the code to a forked mode or sth ...
How much traffic (kb/mb) in an exchange?
See my logfiles. About 3kB for sirf, nokia and vodafone (with result) . 40-50kB for google and sonyericsson (no usable result). Of course double each at proxy server.
Was it easy to build? (for linux?).
For the ones still interested:
Installation of supl-* from tajuma.com is fairly easy linux standard. The software package has pretty good documentation i.e. a README which is definitely worth the name.
I didn't try building it for N900, I wouldn't know where to start for that.
I recommend installing it on a linux machine in your local network with
./configure --precompiled-asn1 --prefix=/usr/ && make && sudo make install
Generate the required certificates with included supl-cert prog. Instead of a fqdn as the first param just give the ipaddress of your linux machine. Then scp the file ca-cert.pem to your N900 and install it as a common certification authority with (as root)
cmcli -c common-ca -a /path/to/ca-cert.pem
Then do the preceeding steps from my previous post, setting location server in N900 to your linux box ip address.
nokia.supl.geo.geodns.fi is an alias for de.nokia.supl.geodns.fi.
de.nokia.supl.geodns.fi has address 213.157.72.147
nokia.supl.geo.geodns.fi is an alias for dk.nokia.supl.geodns.fi.
dk.nokia.supl.geodns.fi has address 83.150.75.211
Thats interesting!
So we need to find a working nokia.supl box (maybe from nokiabot in india?) and put that ip into /etc/hosts on our N900 ...
Edit: That probably doesn't solve the cert issues :(
Edit2: There seem to be just 4 ip addresses around for supl.nokia.com:
211.151.53.216
213.157.72.147
213.157.79.103
83.150.75.211
Whilst there is yet no solution, this thread has expanded knowledge!
If supl.nokia is geo variable yet actually works for some (does it? Nokiabot did not report back on a reboot scenario with ACWP) then certs may not be a critical factor.
There seem to be just 4 ip addresses around for supl.nokia.com:
211.151.53.216
213.157.72.147
213.157.79.103
83.150.75.211
That may well be so.
This is from my machine at work:
$ host supl.nokia.com
supl.nokia.com is an alias for nokia.supl.svc.ovi.com.
nokia.supl.svc.ovi.com is an alias for nokia.supl.geo.geodns.fi.
nokia.supl.geo.geodns.fi is an alias for us.nokia.supl.geodns.fi.
us.nokia.supl.geodns.fi has address 213.157.72.147
$
...and this is from home:
$ host supl.nokia.com
supl.nokia.com is an alias for nokia.supl.svc.ovi.com.
nokia.supl.svc.ovi.com is an alias for nokia.supl.geo.geodns.fi.
nokia.supl.geo.geodns.fi is an alias for uk.nokia.supl.geodns.fi.
uk.nokia.supl.geodns.fi has address 213.157.72.147
$
Note the us versus uk but the IP addresses are the same.
FWIW, none of the 5 URLs from post #101 nor the nieldk's IP address (83 etc) worked for me. I am in the UK, tested with ACWP on a home WiFi network. My last lock was one reboot and about a week ago and about 100 km away so caching is out of the equasion.
freemangordon
2013-08-28, 21:02
Hmm, this is getting more weird:
Nokia-N900:~# cmcli -T common-ca -v cert.pem -e
trust chain:
7fd365a7c2ddecbbf03009f34339fa02af333133 VeriSign Class 3 Public Primary Certification Authority - G5
+->0d445c165344c1827e1d20ab25f40163d8be79a5 VeriSign Class 3 Secure Server CA - G3
+->1ad16dd494e161abd39bd94ed94bf8eafe4ede28 supl.nokia.com
Verified OK
Nokia-N900:~# cmcli -T common-ca -v supl.nokia.com:7275 -e
1ad16dd494e161abd39bd94ed94bf8eafe4ede28 supl.nokia.com
Verification failed: self signed certificate
freemangordon
2013-08-28, 21:42
Nokia-N900:~# cmcli -T common-ca -v supl.nokia.com:7275
1ad16dd494e161abd39bd94ed94bf8eafe4ede28 supl.nokia.com
trust chain(1):
00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 Class 3 Public Primary Certification Authority/VeriSign, Inc./US
Verified OK
Aug 29 00:41:53 Nokia-N900 [1412]: GLIB DEBUG default - location-sb: fix status changed: 0->1
Aug 29 00:41:53 Nokia-N900 location-daemon[22482]: GLIB DEBUG default - :1.65 now having 1 connections
Aug 29 00:41:53 Nokia-N900 location-daemon[22482]: GLIB DEBUG default - Starting a new LAS session with method = 0xa, interval = 0x0, reason = 0
Aug 29 00:41:53 Nokia-N900 location-daemon[22482]: GLIB DEBUG default - Tracking ongoing, status: 1, npe_id: 9
Aug 29 00:41:53 Nokia-N900 location-proxy[22480]: GLIB DEBUG default - Socket to supl.nokia.com opened, fd=10, verify_res=0
Aug 29 00:41:53 Nokia-N900 location-proxy[22480]: GLIB DEBUG default - Socket fd=10 closed on request
Aug 29 00:41:54 Nokia-N900 location-daemon[22482]: GLIB DEBUG default - GPS STATE: search
Aug 29 00:41:54 Nokia-N900 camera-ui[1415]: GLIB WARNING ** default - got fix
Aug 29 00:42:14 Nokia-N900 location-daemon[22482]: GLIB DEBUG default - GPS STATE: fix
:P
(Seems we have a broken .pem/invalid certificate in /etc/certs/common-ca)
joerg_rw
2013-08-29, 00:24
hmm, could you please explain to me what I see in post above, and what I conclude from that. I'm probably not into this cert stuff enough to even interprete the cmcli commands and their diagnostic output, the less I see how we're going to fix this stuff now.
/j
peterleinchen
2013-08-29, 05:04
I believe he inserted/refreshed a cert in our store and then the cmcli also succeeded, which failed previously (and if I interprete it right, he succeeded in getting supl data from Nokia?). As I played also with a lot of certs/adding/deleting from common-ca and did not succeed at all, I am waiting eagerly for more details ...
freemangordon
2013-08-29, 06:59
Well I actually removed one :)
The certificate in question is 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1. Not that there is something wrong with that certificate, but it seems maemo certman has a bug.
There are 2 verisign root certificates with the same public key:
00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 and 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1. certificate chain of supl.nokia.com cert ends up with 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61, but it seems certman tries to use 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1 instead. So the verification fails.
I didn't debug it, so the actual thing that happens could be a slightly different, however, removing both 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 and 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1 and reimporting 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61 workarounds the problem.
seems https://gitorious.org/community-ssu/maemo-security-certman/commit/5b66292b9d705f9e9613490aafc074bfeef6a622 is not enough for multiple-keys-same-public to work on Fremantle. I'll debug the whole mess when I have some free time. Wouldn't try to stop anyone to do the same ofc :)
Hmm, I have created a PEM certificate file of the root certificate indicated when connecting to supl.nokia com, also in the zip, is the original crt file.
root@bt:~# openssl s_client -connect supl.nokia.com:7275 CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=FI/ST=Espoo/O=Nokia/CN=supl.nokia.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFWTCCBEGgAwIBAgIQHpGupbIVFaSG2r4A10yDuzANBgkqhk iG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbm MuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZX JtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMD EvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRz MwHhcNMTIwNDE2
MDAwMDAwWhcNMTUwNDE2MjM1OTU5WjBGMQswCQYDVQQGEwJGST EOMAwGA1UECBMF
RXNwb28xDjAMBgNVBAoUBU5va2lhMRcwFQYDVQQDFA5zdXBsLm 5va2lhLmNvbTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN+Ge5eqh6 8YHvnlvwvJTX36
MJbIvxyqljUarJldINPbp2d2aabRFzr7B7GVbITFLC94djgUKj 0TNFpHfTpffmSo
uSWYp8WYNQHCeNO2yezAOVvWhFwFixp2e3/hWi6bmVt+A7jfDN8pOnugZRIkgHxz
6czndRqDAWA/zIi8w5sBPRqQGKS8QnPqcYhtmqh8nVbzCp2JweV8sdg9SnvCyR 1a
jIPjqiDXl6hjZQ1w0vckXivr0vB88tmm8ReTvP3plhZXub1ggL 2wB7O+jHmRslJF
nlcRQMHc6vVwMWJobjzp8audHxZOX1sCKGVJCLC40MGnyIxIOO bPizT3dHLfcQEC
AwEAAaOCAdEwggHNMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgWgME UGA1UdHwQ+MDww
OqA4oDaGNGh0dHA6Ly9TVlJTZWN1cmUtRzMtY3JsLnZlcmlzaW duLmNvbS9TVlJT
ZWN1cmVHMy5jcmwwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAz AqMCgGCCsGAQUF
BwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMB0GA1 UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAfBgNVHSMEGDAWgBQNRFwWU0TBgn 4dIKsl9AFj2L55
pTB2BggrBgEFBQcBAQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly 9vY3NwLnZlcmlz
aWduLmNvbTBABggrBgEFBQcwAoY0aHR0cDovL1NWUlNlY3VyZS 1HMy1haWEudmVy
aXNpZ24uY29tL1NWUlNlY3VyZUczLmNlcjBuBggrBgEFBQcBDA RiMGChXqBcMFow
WDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9 BSOJsprEsHiyEF
GDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS 5naWYwDQYJKoZI
hvcNAQEFBQADggEBABx2tb0EQch660oL98RMtEXCQtkCOLPfFQ O5X2YS29Tw9a/f
xi/RcmyUN+XuCScgFzvT7tmnaCmuxd6SNqUo/cSF1XRx1m+23RNgA9APVm8uEZ5/
GSswd8DTKU0Gkh2xS8UDS6mqMtST8oFzWiQlinSlfiOvr51PZt QEiQZUzFqKJlbF
yC1BnlIyGokHTt3Izh4CXFrGbZRo4WZSybmu9O/+ziI1smArNIRnMdeinP8mi/y3
atok31Rw1+/qi3142GTVYilfvuJB5zVJu2lnvU7gSSaQr7tuerk47An5rZddM Duf
uzc0MT9HOXlAdTCyqhxEc7ymsSeRFmFGTyIap58=
-----END CERTIFICATE-----
subject=/C=FI/ST=Espoo/O=Nokia/CN=supl.nokia.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 4857 bytes and written 631 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 8FB277CE00000000000000000000000000003570521EF96500 0000008F0240C0
Session-ID-ctx:
Master-Key: 5061BB36F33A7171F87DB1541E127EE58905A40D8463FE672B 4349F1097DFD717D5E6DFED58E515A614719CAF8EEBF1F
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1377760865
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
I will test later (my N900 needs a reflash :/)
freemangordon
2013-08-29, 07:40
@nieldk: there is one more certificate on top of the one you bolded, do:
cmcli -s -T common-ca -v supl.nokia.com:7275
(this will save the whole certificate chain as .pem files) and you'll see there are 4 .pems saved, not 3.
EDIT: nevermind, seems I misread your post
peterleinchen
2013-08-29, 07:41
YEP!
A THOUSAND THANKS !!!
One mistake above: it iks the second one (with the "-1") that needs to be readded.
And I needed a reboot to make location library aware.
I never thought of removing that one (verisign), actually both and reinstalling only the second one. I fiddled with exactly that cert, but failed miserable due to missing cert experience.
Will do now a second reboot for verification.
freemangordon
2013-08-29, 07:43
@peterleinchen: "the mistake" could be related to the order of the hashes.
EDIT:
don't forget to "perl /usr/bin/c_rehash /etc/certs/common-ca" after every change to the certificate store
peterleinchen
2013-08-29, 07:56
@peterleinchen: "the mistake" could be related to the order of the hashes.
Could be, as I failed with reinserting both certs, but in reversed order!
Nevertheless:
after the second clearing cache (gconftool/reboot), I got a fix within 5-10 seconds from supl.nokia.com.
We ARE back, Nokia!
Thank you freemangordon
EDIT:
don't forget to "perl /usr/bin/c_rehash /etc/certs/common-ca" after every change to the certificate store
edit to your edit:
WHAT?
Never knew/did that. What is this about?
It worked for without that rehashing (some kind of aegis here? ;))
--edit
Another edit aimed to nieldk
What PR version do you have?
Is it possibly "only" PR1.3 and not PR1.3.1 (with some cert updates/revocations)?
Idk when this problem arised, but could it be due to that one?
freemangordon
2013-08-29, 07:59
Could be, as I failed with reinserting both certs, but in reversed order!
Nevertheless:
after the second clearing cache (gconftool/reboot), I got a fix within 5-10 seconds from supl.nokia.com.
We ARE back, Nokia!
Thank you freemangordon
edit to your edit:
WHAT?
Never knew/did that. What is this about?
It worked for without that rehashing (some kind of aegis here? ;))
--edit
Another edit aimed to nieldk
What PR version do you have?
Is it possibly "only" PR1.3 and not PR1.3.1 (with some cert updates/revocations)?
Idk when this problem arised, but could it be due to that one?
http://www.tin.org/bin/man.cgi?section=1&topic=c_rehash
Another edit aimed to nieldk
What PR version do you have?
I have pr1.3 (flashes too often and never bothers to do the 1.3.1)
With, KP52 as kernel.
Wow, I almost can't believe it: Nokia N900 can use supl.nokia.com again!!!
Anyway, I didn't have a file/cert 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem , just the one without the -1 .
What was workin for me was (as root):
mkdir /tmp/supl/ ; cd /tmp/supl/ ; cmcli -s -T common-ca -v supl.nokia.com:7275 ; for CERT in `ls -1 *.pem` ; do cmcli -c common-ca -r ${CERT%%.*} ; cmcli -c common-ca -r ${CERT%%.*}-1 ; cmcli -c common-ca -a ${CERT} ; done
With
cmcli -T common-ca -v supl.nokia.com:7275
I got a "Verified OK".
Setting location server to supl.nokia.com then gave me the nearby fix within 5 secs. Yey!
@freemangordon: Where did you find the -s flag for cmcli ? It is not shown as an option when called without any param.
Edit: typo ...
freemangordon
2013-08-29, 11:00
@Ulle - in cmcli source code
sixwheeledbeast
2013-08-29, 11:09
So can/will this be fixed in upcoming CSSU versions?
freemangordon
2013-08-29, 11:47
This is CSSU material, that's for sure. But we need to find the bug first:). Anyway, I'll look at it when I find some spare time
sixwheeledbeast
2013-08-29, 11:51
This is CSSU material, that's for sure. But we need to find the bug first:). Anyway, I'll look at it when I find some spare time
Sorry, I was under the impression the bug was located.
Thanks again. :)
peterleinchen
2013-08-29, 12:04
Hey freemangordon,
besides 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61
I have another one with a "-1 extension", named
f3a27298eeb81b82801c4db69a3027990a2f72e2
And this one I do not get named, when printing
cmcli -T common-ca -L
My guess is really that this was introduced via a OTA update from PR1.3 to 1.3.1
To verify:
@nieldk and Ulle
Please give us your current PR (1.3 or 1.3.1) number and how you got there (direct flash, OTA or CSSU). CSSU is important to know, as that latest update is already integrated.
@freemangordon, just a wild guess. But maybe worth to check...
http://www.tin.org/bin/man.cgi?section=1&topic=c_rehash
Thanks, learned something more. and now I know what these symlinks were/are for. And why I had some dead symlinks (removed fraudulent certs from TÜRK and other).
I have another one with a "-1 extension", named
f3a27298eeb81b82801c4db69a3027990a2f72e2
And this one I do not get named, when printing
cmcli -T common-ca -L
This one I also had with -1 . It is for the root/highest certificate in the certificate chain for supl.nokia.com. It doesn't have CN (common name) in it and therefor cmcli might not show it with cmcli -T common-ca -L ... (bug or feature ;) ).
As supl.nokia.com has stopped working years ago (was it 2011?), I think the cert store was already wrong before CSSU.
To verify:
@nieldk and Ulle
Please give us your current PR (1.3 or 1.3.1) number and how you got there (direct flash, OTA or CSSU). CSSU is important to know, as that latest update is already integrated.
I currently have
Version: 21.2011.38-1Smaemo6.1 (Flavor: Stable)
Haven't looked for that for ages. Can't say exactly how I came to this. Probably Flashing Nokia stuff than CSSU OTA.
From wiki http://wiki.maemo.org/Community_SSU/ChangelogStable :
21.2011.38-1 is the latest official Nokia version. The number after it indicates the Community SSU release version.
And I played quite much with the VeriSign certs in the last days. Hard to say how their state was before that.
My firmware is flashed using maemo_flasher-3.5_2.5.2.2_i386.deb from tablets-dev.nokia.com
Flashing the images:
RX-51_2009SE_10.2010.13-2.VANILLA_PR_EMMC_MR0_ARM.bin
RX-51_2009SE_20.2010.36-2_PR_COMBINED_MR0_ARM.bin
from
http://skeiron.org/tablets-dev/nokia_N900/
Now that supl.nokia.com issues are teared down to TLS / certificates flaws inside N900, what about supl.google.com?
My tests with supl-proxy where showing that during (s)UPL sessions with google and sonyericsson much more data was exchanged (compared to nokia and vodafone). With no success at the end.
See my attached log files in post #101 http://talk.maemo.org/showpost.php?p=1369745
Why can't N900 use the data coming from supl.google.com for A-GPS / ACWP?
Now that supl.nokia.com issues are teared down to TLS / certificates flaws inside N900, what about supl.google.com?
My tests with supl-proxy where showing that during (s)UPL sessions with google and sonyericsson much more data was exchanged (compared to nokia and vodafone). With no success at the end.
See my attached log files in post #101 http://talk.maemo.org/showpost.php?p=1369745
Why can't N900 use the data coming from supl.google.com for A-GPS / ACWP?
Like stated before, Google's fine on my device.
Nokias, didnt work - until now.
I know nokiabot also at least seem to have a working google supl. Perhaps its related to firmware releases ?
michaaa62
2013-08-29, 13:25
Any suggestions, what i am doing wrong???
Removing the certificates does not work, adding fails because the files exist...Nokia-N900:/tmp/supl# cmcli -c common-ca -r 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem
Nokia-N900:/tmp/supl# cmcli -c common-ca -r 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem
Nokia-N900:/tmp/supl# perl /usr/bin/c_rehash /etc/certs/common-ca | grep 00d8
00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem => 7651b327.0
00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem => 7651b327.1
My PRNokia-N900:/tmp/supl# apt-cache policy mp-fremantle-community-pr
mp-fremantle-community-pr:
Installed: 21.2011.38-1Tmaemo8.2+thumb1
Candidate: 21.2011.38-1Tmaemo8.2+thumb1
freemangordon
2013-08-29, 13:33
Sorry, I was under the impression the bug was located.
Thanks again. :)
No, we found what the real problem is and which is the package to blame. The code chunk that is misbehaving is yet to be found ;) .
freemangordon
2013-08-29, 13:34
Any suggestions, what i am doing wrong???
Removing the certificates does not work, adding fails because the files exist...Nokia-N900:/tmp/supl# cmcli -c common-ca -r 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem
Nokia-N900:/tmp/supl# cmcli -c common-ca -r 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem
Nokia-N900:/tmp/supl# perl /usr/bin/c_rehash /etc/certs/common-ca | grep 00d8
00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem => 7651b327.0
00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61.pem => 7651b327.1
My PRNokia-N900:/tmp/supl# apt-cache policy mp-fremantle-community-pr
mp-fremantle-community-pr:
Installed: 21.2011.38-1Tmaemo8.2+thumb1
Candidate: 21.2011.38-1Tmaemo8.2+thumb1
it is cmcli -c common-ca -r 00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1 - without .pem extension
Any suggestions, what i am doing wrong???
Removing the certificates does not work, adding fails because the files exist...
Or consider using my bash one-liner in http://talk.maemo.org/showpost.php?p=1370357
peterleinchen
2013-08-29, 16:26
No, we found what the real problem is and which is the package to blame. The code chunk that is misbehaving is yet to be found ;) .
freemangordon,
here you refer to the google problem, or?
As I see the Nokia problem solved due to mixed up certs!?
I noticed that I can only get ACWP data, but not AGNSS data from Nokia server (also Vodafone). Should nokia provide that info also?
If yes, there is still above mentioned code chunk to be found (either for Google or Nokia).
Only thing I may think of causing this is some change in Google supl data still in the specification, but not correctly handled in N900 (like it was for tinymail).
Do you have another idea?
--edit
Okay, just reread.
And of course you refer with your code chunk to some problem in libmaemosec not handling the presence of two certificates with same fingerprint, right?
Nevertheless above problem with Google is still present, but not that urgent anymore (still I'd like to know/solve ...)
--editedit
Or, another thought:
could it be that Google changed their supl server to deliver only AGNSS data and no ACWP data anymore. And our N900 is only able to collect/use ACWP? This would explain the SSL-trusty successful (and bigger) data exchange with Google and Sirf supl servers.
I noticed that I can only get ACWP data, but not AGNSS data from Nokia server (also Vodafone).
...
could it be that Google changed their supl server to deliver only AGNSS data and no ACWP data anymore. And our N900 is only able to collect/use ACWP? This would explain the SSL-trusty successful (and bigger) data exchange with Google and Sirf supl servers.
Thank you peterleinchen, for bringing this up! I actually have no clue whats going on with ACWP and AGNSS, but it could be the difference in what the servers are delivering.
So following this:
ACWP is returned from nokia, vodafone and sirf with just a pair of long/lat data (or kind of),
AGNSS ist returned from google and sonyericsson (not sirf) with quite some PDU/RLP and ephemeris data.
Both in XML-like style.
joerg_rw
2013-08-29, 17:04
wireshark is your friend ;-)
If someone wants to test supl.sonyericsson.com with N900 there is still the first show stopper to solve: Certificate verification fails due to missing issuer cert.
I found this http://pastebin.com/2dNbJ79L , which was mentioned in an android gps discussion somewhere, and copied line 8. to 28. (the content of cacert.txt) into a file on my N900 .
Then after
cmcli -c common-ca -a /path/to/that/file
I get with
cmcli -T common-ca -v supl.sonyericsson.com:7275
a nice "Verified OK".
Edit: I couldn't find the root/issuer cert for sls1.sirf.com and sls2.sirf.com . I sent an email to slssupport@sirf.com (does not exist anymore) and webmaster@csr.com, asking for that. No answer so far ...
wireshark is your friend ;-)
wiresharky is my friend, indeed :) ! But doesn't help much with TLS encrypted data ...
wiresharky is my friend, indeed :) ! But doesn't help much with TLS encrypted data ...
Are you saying about a certificate or about the actual data exchanged with server-side location software? I recently came across this (http://www.gironda.org/2013/02/25/digging-in-the-vineyard-part-1.html) article while acomplishing something at work, maybe mitmproxy could be used to "fool" N900 that your computer is location server (may require fake certificate generation via mitmproxy and installation on N900) and passing all traffic through your set-up proxy? That could help in debugging the internals of raw unciphered data exchanged between N900 and location server... I hope that's helpful (but I'm awake for 20-something-th hour now, so please excuse me if I got you wrong).
maybe mitmproxy could be used to "fool" N900
Thanks for sharing, but I already tried to "proxy" with socat until eccerr0r was pointing to supl-* at tajuma.com. Thats the only practicable way for watching TLS encrypted SUPL data exchange.
The tool is just exellent. Deploying MITM a big waste of time (for that).
joerg_rw
2013-08-29, 19:39
ok, strace then? ;-)
If someone wants to test supl.sonyericsson.com with N900 there is still the first show stopper to solve: Certificate verification fails due to missing issuer cert.
I found this http://pastebin.com/2dNbJ79L , which was mentioned in an android gps discussion somewhere, and copied line 8. to 28. (the content of cacert.txt) into a file on my N900 .
Then after
cmcli -c common-ca -a /path/to/that/file
I get with
cmcli -T common-ca -v supl.sonyericsson.com:7275
a nice "Verified OK".
Edit: I couldn't find the root/issuer cert for sls1.sirf.com and sls2.sirf.com . I sent an email to slssupport@sirf.com (does not exist anymore) and webmaster@csr.com, asking for that. No answer so far ...
Probably because they use self signed certificates
~ root# openssl s_client -connect sls2.sirf.com:7275
CONNECTED(00000003)
depth=0 /C=US/ST=California/L=San Jose/O=SiRF Technology Inc/OU=ISBU/CN=sls2.sirf.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=San Jose/O=SiRF Technology Inc/OU=ISBU/CN=sls2.sirf.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=San Jose/O=SiRF Technology Inc/OU=ISBU/CN=sls2.sirf.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=San Jose/O=SiRF Technology Inc/OU=ISBU/CN=sls2.sirf.com
i:/C=US/ST=California/L=San Jose/O=SiRF Technology Inc./OU=ISBU/emailAddress=slssupport@sirf.com
---
freemangordon
2013-08-30, 13:11
A fix is on it's way to CSSU, please test: http://talk.maemo.org/showpost.php?p=1370631&postcount=222
Those of you that have changed their certificates, make sure to revert to "stock" state, otherwise installation may fail/be incomplete, the files in /etc are treated by apt/dpkg as config files and are not auto overwritten on a new package version installed.
freemangordon
2013-08-30, 15:26
@peterleinchen - followup to http://talk.maemo.org/showpost.php?p=1370652&postcount=225
Not sure what you mean by "stock" but if it is PR1.3.1 I guess it makes sense to install everything *certman* , there are a couple of certificate fixes in CSSU not present in PR1.3.1.
Not to say I strongly recommend to install CSSU, be it -stabe, -testing or -thumb ;)
peterleinchen
2013-08-30, 16:23
@peterleinchen - followup to http://talk.maemo.org/showpost.php?p=1370652&postcount=225
Not sure what you mean by "stock" but if it is PR1.3.1 I guess it makes sense to install everything *certman* , there are a couple of certificate fixes in CSSU not present in PR1.3.1.
Thanks, just wanted to be sure you did not code anything into a lib or similar.
I checked packages and yeah they seem to be installable to non-CSSU devices (I know I know).
Furthermore I have seen you exchanged the certs, so content of one into the other file (seen by sha1sum). It is a bit late now, but I began to play with order also and I found that the c_rehash is the one to "blame" :( (not that I am good in reading/understanding perl)
It fetches all pem/crt from directory, but not in any order. That is the reason why the link 7651b327.0 points to the newer cert, while 7651b327.1 should do so. (That is also reason why f3a27298eeb81b82801c4db69a3027990a2f72e2-1.pem works, as the symlink *.1 points to newer cert.
I checked it by just re-symlinking *.0 to older and *.1 to newer cert. And it worked.
--EDIT
Checked once more. And it is really weird/confusing/erroneous ! :rolleyes:
Now I added certs again. First old one, then new one (as before). And guess what? It worked without changing anything! When checking the symlinks they showed to the correct locations *.0 to *-1.pem (without manually re-symlinking).
Conclusio? IDK. Seems like it could work on some devices and on some not. Just regarding the order of $flist...
--editedit
Okay, now I am confused. Strike above.
It seems after 'c_rehash /etc/certs/common-ca' everything is fine.
I removed, inserted (in different orders) and more. But it is working always.
So easiest is to
make a backup of 00d85*.pem and 00d85*-1.pem
remove 0085*, cmcli -c common-ca -r 00d85*
remove 7651*.*, rm 7651*
reinsert 00d85* (and 00d85*-1) in exactly this order
cmcli -c common-ca -a backup_of_00d85*.pem
cmcli -c common-ca -a backup_of_00d85*-1.pem
this should be enough.
If it is not working for you, then do a
c_rehash /etc/certs/common-ca
If still not working, then start all over, but readd in reversed order (first 00d85*-1.pem and then 00d85*.pem)
Or just use fmg's patch (before messing around!).
Not to say I strongly recommend to install CSSU, be it -stabe, -testing or -thumb ;)I know I know, and the next device -be it a N900 from drawer or Neo900- will have for sure. But this device is so nicely running and customized, I just do not want to "spoil" it. ;)
My GPS is not working for about a month. I use supl.google.com and tried a few others.
Ran this command to reset cache :
gconftool --recursive-unset /system/nokia/location
Reflash done(emmc+rootfs), still no help. It's keep on searching and never locks in. Please let me know how to fix this. Could this be a possible hardware issue?
Thanks
sixwheeledbeast
2013-09-24, 16:48
My GPS is not working for about a month. I use supl.google.com and tried a few others.
Ran this command to reset cache :
gconftool --recursive-unset /system/nokia/location
Reflash done(emmc+rootfs), still no help. It's keep on searching and never locks in. Please let me know how to fix this. Could this be a possible hardware issue?
Thanks
If you read the thread carefully you will see that there is a patch in cssu-devel to fix this issue
My GPS is not working for about a month. I use supl.google.com and tried a few others.
Ran this command to reset cache :
gconftool --recursive-unset /system/nokia/location
Reflash done(emmc+rootfs), still no help. It's keep on searching and never locks in. Please let me know how to fix this. Could this be a possible hardware issue?
Thanks
AGPS makes acquiring a fix much faster than just using the gps receiver and doing a sky search. Without agps you will eventually get a fix. sO, if your n900 does not get a fix AT ALL (leave it for 20\30 mins using something besides Nokia Maps) then your device has a hw fault.
(Edit: thanks pichlo for the heads up. Never use Nokia Maps so who would know.....)
The problem is that the built-in Nokia Maps application times out after just 10 minutes - even though the time it takes to receive the full almanac under ideal conditions with no retries is 12.5 minutes - which means it will never acquire a lock without help.
This has been discussed countless times, just do a search. Nokia was aware of that and they marked it as "won't fix" ("10 minutes ought to be enough for everybody!").
Get a third-party GPS application such as Location Test discussed in this thread to help Nokia Maps with the lock. It will not make it any faster - for that you need the patch that sixwheeledbeast mentioned - but it will not time out and hence get the lock eventually without the supl server assistance.
Thanks a lot sixwheeledbeast, handaxe and pichlo. I read about that fix(I think maemo-security-certman ??), but i believe it's a fix with CSSU. I don't use CSSU for some reasons. I would like to know whether it's possible to use that fix without CSSU installed. I don't use Nokia maps, i'm happy using the Marble maps which was so convenient for me.
Thank you
It's in CSSU-Dev which I don't use either (I use CSSU-Thumb). So what I've done is, temporarily add CSSU-Dev repo to Fapman, tap Upgrade applications, select everything with certman in the name and 0.2.3 in the version number, ignore everything else, run the update, remove CSSU-Dev from repos, close, reboot. It might or might not be the recommended way but it worked fine for me.
I don't know about Marble (I tried it once but could not get my head around its UI), but e.g. modRana works and does not time out like Nokia Maps.
sixwheeledbeast
2013-09-25, 11:15
It's in CSSU-Dev which I don't use
CSSU-Devel is only a repo to pull development updates. It should definitely not be used as a day to day update repo. The correct way to use CSSU-Devel is enable repo "apt-get foopackage" and then disable repo as per CSSU-Devel thread.
http://talk.maemo.org/showthread.php?t=84292
peterleinchen explained that the packages are compatible on PR1.3.1.
As usual I have to remind everyone CSSU is highly recommended to fix security issues and bugs.
http://wiki.maemo.org/CSSU
I will give it a try tonight when i get back home.
But some features/enhancement makes me avoid installing CSSU, like the camera-ui2. Cannot remove just the camera-ui without removing CSSU.
peterleinchen
2013-09-25, 13:32
You do not need to install CSSU!
Just install all maemo-certman stuff.
And what about reading the post (http://talk.maemo.org/showpost.php?p=1370673&postcount=155) just before your first one in this thread? It is for 'advanced' users (and might be destroying, so do not ask for 'where do I have to enter that code' or 'cannot find file blabla*' ;)
CSSU-Devel is only a repo to pull development updates.
...which is why I don't use it on a daily basis. But what can I do if a crucial patch with a known content is released only in CSSU-Devel, with no indication of a plan to ever release it anywhere else?
Temporary inclusion and selective upgrade, here I come!
But some features/enhancement makes me avoid installing CSSU, like the camera-ui2. Cannot remove just the camera-ui without removing CSSU.
You can. Just install CSSU-Stable, not CSSU-Testing and not CSSU-Thumb. I'm using CSSU-Stable on my daily device and can tell you it doesn't replace any stock components (well, maybe some are rewritten to be open source, but you cannot spot the difference as a user), it's meant to keep feature parity and 100% compatibility with PR1.3. CSSU-Testing, however, is a bit more adventerous and installs stuff like camera-ui2.
By the way (I'm asking here, as I know freemangordon and pali visit this thread sometimes), is this fix going to propagate from devel to testing and stable anytime soon? And, as far as I remember someone (afaik freemangordon? but I could be wrong) mentioned that to install the certman fix, one should revert the earlier changes... I did as described in http://talk.maemo.org/showpost.php?p=1370357 (or maybe I used the longer method... But that posts states basically what I did) - do I understand it correctly that I need to readd the faulty deprecated certificate again before installing the package from cssu-devel, otherwise I will cause a nuclear holocaust on my device?
I added the CSSU-Devel repo, installed all the *certman* updates using Fapman. During installation it was showing it is removing 'mp-fremantle-pr' and upgrading other packages selected. I continued and did reboot. The map started working fine. But not able to get the internet connections. The internet connection pop-up is not showing up and when I try to edit my Mobile Internet Connection in Settings>Internet Connections, the Settings window crashes showing the error "Internal Application Error Settings Closed'
I even tried this command in X-Term, but nothing happened:
dbus-send --system --type=method_call --dest=com.nokia.icd_ui /com/nokia/icd_ui com.nokia.icd_ui.show_conn_dlg boolean:false
Thanks
I added the CSSU-Devel repo, installed all the *certman* updates using Fapman. During installation it was showing it is removing 'mp-fremantle-pr' and upgrading other packages selected...
Well, it should not remove any packages. At least here it did not, but I upgraded these 4 packages using terminal & apt-get.
Are you sure you installed only these 4 certman packages?
Well, it should not remove any packages. At least here it did not, but I upgraded these 4 packages using terminal & apt-get.
Are you sure you installed only these 4 certman packages?
I think so, yes. Anyway I'll retry in the evening as i've taken a backup
I think so, yes. Anyway I'll retry in the evening as i've taken a backup
Great you have a backup :) What I can suggest is: try it one more time, but note which packages exactly it wants to upgrade and which it wants to remove, answer "no" and post the lists here along with the exact command you were running, so we'll be able to help you and tell you whether it looks ok or something's broken :)
Great you have a backup :) What I can suggest is: try it one more time, but note which packages exactly it wants to upgrade and which it wants to remove, answer "no" and post the lists here along with the exact command you were running, so we'll be able to help you and tell you whether it looks ok or something's broken :)
Forgot to mention, along with all '*certman*' upgrades, i included the 'libcurl3' as well. There was a fix for libcurl3 for using the FB in maemo.
Thank you!
Please see the screenshot attached.
Same issue happened again. GPS worked but Internet connection pop-up did not open and e-mail program keeps on closing.
What i did was disabled CSSU-Devel
ran apt-get update/ apt-get upgrade.
Issue was fixed
later installed CSSU-Stable.
The issue started with marble maps. It was showing wrong routes like for less than 30KM distance, it gave around 173KM route. Thought something wrong with GPS then i think most of my checks happened indoors which also was a bad idea.
Marble still got issues i'll have to check in its official thread. Modrana looking good now. I never use Nokia maps :D
Thank you all of you. :)
[...]
Internet connection pop-up did not open and e-mail program keeps on closing.
What i did was disabled CSSU-Devel
ran apt-get update/ apt-get upgrade.
[...]
I think your problem is different. Did you mean "disabled" or "enabled" cssu-devel? If you've run "apt-get upgrade" with cssu-devel enabled, you pretty much installed (along with this certificates fix) loads of unstable stuff which broke your email client and internet connection pop-up.
edit: and it seems you removed the pr metapackage which could probably autoremove some stuff later and that might nuke your system.
I enabled CSSU-Devel and installed the certman packages. Fapman gave me the confirmation as in the posted screenshot in my previous post. pr metapackage was removed, i believe. Did a reboot, saw the same problem. Disabled the CSSU-Devel then i did apt-get update and apt-get upgrade.
Later installed the stable CSSU. All is working well as of now :)
I enabled CSSU-Devel and installed the certman packages.
No, you did not! ;) According to your screenshot you also installed hildon-desktop-background-settings-002... And that package probably caused the removal of mp-fremantle-002-pr ;)
I just enabled cssu-devel; then in terminal:
apt-get install libmaemosec0 libmaemosec-certman0 maemosec-certman-common-ca maemosec-certman-tools
then disabled cssu-devel. I'm at cssu-testing level btw...
No, you did not! ;) According to your screenshot you also installed hildon-desktop-background-settings-002... And that package probably caused the removal of mp-fremantle-002-pr ;)
I just enabled cssu-devel; then in terminal:
apt-get install libmaemosec0 libmaemosec-certman0 maemosec-certman-common-ca maemosec-certman-tools
then disabled cssu-devel. I'm at cssu-testing level btw...
I did not mark hildon-desktop-background-settings-002 to install, thought it must be some dependency.
I was worried something may go wrong when i saw that 'mp-fremantle-002-pr' was marked to remove. But no issues till now.. It just runs well. Amen :)
rootytooty
2013-11-26, 06:30
Ok my friends I am on the suggested tread. I am trying to update to the CSSU-Thumb and I get to the part that says to continue---but I looked at the description and the problems this time to see what the installaton problem seems to be, why I cannot install it. Here is what the problem says: Conflict with application packages Kernel-maemo, kernel-modules-maemo,kernel-maemo and Kernel-modules-maemo. I am not sure what that says or means.
Sorry but that seems to be where I seem to be stuck. I think it was sixwheelbeast that said that I should be trying CSSU-Training. I will look at that too.
Thanks,
Bobby
@rootytooty,
Your post is not related to A-GPS problems and as such it is off-topic in this thread. Also, please do not cross-post, it is considered bad manners. For your CSSU installation issues, please follow the advice given to you in the other thread (http://talk.maemo.org/showthread.php?p=1389053#post1389053).
any idea how to fix supl.google.com ?
any idea how to fix supl.google.com ?
I don't believe you can. The way forward is sort out certificate issues (CSSU etc) and use supl.nokia.com.
Or do you face some other issue?
joerg_rw
2014-12-19, 10:59
The way forward is sort out certificate issues (CSSU etc) and use supl.nokia.com.
I frown on that one too, quite possible it gets shut down sooner rather than later
I frown on that one too, quite possible it gets shut down sooner rather than later
Did that Finnish server stay with what still functions as Nokia, rather than passing with the phone business to Microsoft?
joerg_rw
2014-12-19, 12:06
Did that Finnish server stay with what still functions as Nokia, rather than passing with the phone business to Microsoft?
well, who knows. Nokia has a record of simply forgetting servers and then they run for a few months or years unattended until they finally get rooted or break down on var/log/* overflow or a broken harddisk or whatever
Actually they forgot a complete Akamai server farm that been tabletsdev.nokia.com, and they went all panic when we eventually re-enabled the stage where that content deployment system pulled its data from, which happened to be tablets-dev.maemo.org ;-P. Another fine example is the http://www.wirelessmodemapi.com box that ran for years on a IP without URL (the http://www.wirelessmodemapi.com DNS eventually got redirected to elsewhere) but was basically dead and didn't answer to any port 80 requests.
PS: I just tested my N900 indoor next to window with "Location Test" app, and cold TTFF been ~10s. I am quite sure this can only get accomplished by RRLP (http://en.wikipedia.org/wiki/Radio_resource_location_services_protocol) over UMTS from my "SIM" on O2 Germany. Means: as long as you got a SIM in your phone, you may easily get away with excellent GPS without ever using a SUPL server
/j
I frown on that one too, quite possible it gets shut down sooner rather than later
What are the alternatives? Do OSM or someone similar have a SUPL server we can use? The last time I tried searching for such an alternative I failed miserably.
If the current situation is to use Google or Nokia then I'd rather share my location with the one that's less associated with hoarding data. I believe Mozilla are using Nokia for A-GPS in Firefox OS so I would hope it won't be shut down anytime soon.
peterleinchen
2014-12-20, 14:33
I also failed completely :(
But sonyericsson one was the best try out. Iirc I could not extract/install certificate that time. Maybe another one?
sixwheeledbeast
2015-04-21, 10:56
For those unaware it has been reported on IRC that supl.nokia.com server certificate has expired on the 16th.
This may cause your device to take longer to get a GPS fix.
nokiabot
2015-04-21, 11:36
supl.google.com is working fine
supl.google.com is working fine
If correct, that is news indeed, as many of us moved back to the Nokia server because google stopped accepting connections. Guess it is time to test afresh.
Here are more to test.
Google
supl.google.com
PORT=7276
Nokia
supl.nokia.com
PORT=7275
Sony/Ericsson
supl.sonyericsson.com
PORT=7275
T-mobile
lbs.geo.t-mobile.com
PORT=7275
AT&T
h-slp.mnc410.mcc310.pub.3gppnetwork.org
PORT=7275
Sony
supl.sonymobile.com
LGE
lge.glpals.com
Misc
dcm-supl.com : 7275
supl.skyhook.com : 7278
suplcn.sirf.com:7276
sls1.sirf.com:7275
sls2.sirf.com:7276
supl.vodafone.com:7275
Thank you Halftux , interesting list!
I would like to add
Vodafone
supl.vodafone.com
PORT=7275
Thats the one I use now (switched from supl.nokia.com). And it gives me a quite quick fix.
Still most servers from the list are not accessable (from Germany) and some not even have a corresponding IP address in DNS.
Back in 2013 supl.google.com and supl.sonyericsson.com were responding with different data than supl.nokia.com (and supl.vodafone.com) so that N900 could not work with it.
So I see nokia and vodafone as the only options.
And I expect Nokia to refresh their certificate soon, as the server is not only used by N900s, but quite a lot of other devices.
And peterleinchen was looking for the certificate for supl.sonyericsson.com:
Head over to http://pastebin.com/829KdpUs
and search for "C=SE, L=Lund, O=Sony Ericsson Mobile Communications AB, OU=Sony Ericsson Secure E2E".
Next lines from (including) Begin to End Certificate should be copied into a pem-file. Thats the certificate for the issuer of the supl.sonyericsson.com certificate.
Cheers, Ulle
freemangordon
2015-04-21, 17:46
supl.google.com is working fine
Not anymore, it seems
peterleinchen
2015-04-21, 19:16
Not anymore, it seems
Confirmed for N900.
Neither nokia nor google deliver fast GPS fix (be it GPRS, only connection to work, or WLAN).
But:
my N9 seems to get a fast fix (supl.google.com, WLAN). Needs to be tested/confirmed once more ...
freemangordon
2015-04-21, 19:23
Confirmed for N900.
Neither nokia nor google deliver fast GPS fix (be it GPRS, only connection to work, or WLAN).
But:
my N9 seems to get a fast fix (supl.google.com, WLAN). Needs to be tested/confirmed once more ...
I was wondering why n9/50 owners do not complain. Any idea?
Well. Do the N900 have the current Google Internet Authority G2 installed ?
$ openssl s_client -connect supl.google.com:7275
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHgzCCBmugAwIBAgIIOQH9s8eHezYwDQYJKoZIhvcNAQEFBQ AwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHE dvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUwNDA4MTQxNjE3WhcNMT UwNzA3MDAwMDAw
WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYT EWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEVMB MGA1UEAwwMKi5n
b29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg KCAQEA0YXDdpu5
Gy+qZXYWVVlEabFybjJB5qPt4Sd7jt03ZTbGTjRK6oyLTMlHtQ rjOYfbM/T5ErF3
XEy6Ky7RNldJ7gGTsjTb/Chs0bRHoj+FgMCvvPzraltegNBTRQA6qVfWyHFw/oTj
kC7M/EgV5R2d8ua70Jp5vJNwNyj/U40hcUollKsOKUZQ/xBBR6YzoJOd9+awYKmb
E1Ff+Ni5mCALZcLSMgpPN3mGOhIxQPOa2Al5zRClfflz2T4BRG JmTuNz5kd922z+
z6D95L1PWGnRENev0OlbHHMio9xDOEWlKMW7zdWXQbc60LnKYY VgUoIhTuOisOHy
RvAZ9ZDkm0EwTQIDAQABo4IEUDCCBEwwHQYDVR0lBBYwFAYIKw YBBQUHAwEGCCsG
AQUFBwMCMIIDJgYDVR0RBIIDHTCCAxmCDCouZ29vZ2xlLmNvbY INKi5hbmRyb2lk
LmNvbYIWKi5hcHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC 5nb29nbGUuY29t
ghYqLmdvb2dsZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYY ILKi5nb29nbGUu
Y2yCDiouZ29vZ2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi 5nb29nbGUuY28u
dWuCDyouZ29vZ2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg 8qLmdvb2dsZS5j
b20uYnKCDyouZ29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm 14gg8qLmdvb2ds
ZS5jb20udHKCDyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZG WCCyouZ29vZ2xl
LmVzggsqLmdvb2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2 xlLml0ggsqLmdv
b2dsZS5ubIILKi5nb29nbGUucGyCCyouZ29vZ2xlLnB0ghIqLm dvb2dsZWFkYXBp
cy5jb22CDyouZ29vZ2xlYXBpcy5jboIUKi5nb29nbGVjb21tZX JjZS5jb22CESou
Z29vZ2xldmlkZW8uY29tggwqLmdzdGF0aWMuY26CDSouZ3N0YX RpYy5jb22CCiou
Z3Z0MS5jb22CCiouZ3Z0Mi5jb22CFCoubWV0cmljLmdzdGF0aW MuY29tggwqLnVy
Y2hpbi5jb22CECoudXJsLmdvb2dsZS5jb22CFioueW91dHViZS 1ub2Nvb2tpZS5j
b22CDSoueW91dHViZS5jb22CFioueW91dHViZWVkdWNhdGlvbi 5jb22CCyoueXRp
bWcuY29tggthbmRyb2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb2 9nbGUtYW5hbHl0
aWNzLmNvbYIKZ29vZ2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY2 9tggp1cmNoaW4u
Y29tggh5b3V0dS5iZYILeW91dHViZS5jb22CFHlvdXR1YmVlZH VjYXRpb24uY29t
MGgGCCsGAQUFBwEBBFwwWjArBggrBgEFBQcwAoYfaHR0cDovL3 BraS5nb29nbGUu
Y29tL0dJQUcyLmNydDArBggrBgEFBQcwAYYfaHR0cDovL2NsaW VudHMxLmdvb2ds
ZS5jb20vb2NzcDAdBgNVHQ4EFgQUrFWn4lvMNeG7qEo62BCSvL HctWwwDAYDVR0T
AQH/BAIwADAfBgNVHSMEGDAWgBRK3QYWG7z2aLV29YG2u2IaulqBLz AXBgNVHSAE
EDAOMAwGCisGAQQB1nkCBQEwMAYDVR0fBCkwJzAloCOgIYYfaH R0cDovL3BraS5n
b29nbGUuY29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQUFAAOCAQ EAb9iyLqUQ7knP
KiJeEhJjSnNmnr+dF3cg2rogXyd7a0FmU5VtgjZwMUeVmr/B/PwucecejJ1CFCoj
b3W892OfD4E8Cm5naQYkDnDa1asnSTWPSm9bZrTen3P1Uga6eW uGq18hd8aw3QmM
9Ln+5dd/I9B6y/+mHQfyMX2D+SeO1eAkGiTj1vZ4aN5+y57U3t4GLac0coILxJ52
D+RjToGOsoY+hbcb8d3X+QG6aHthAf7IE3Dg3kJ2+erTIhR6Oc K7pAcGeSjuZ7Ng
0bs7Lcd2gYmEO9lUmMD2Qbk7XTr9x8SsvFl+4kxetC9lNgEcif ZrrzuXbm/9CP1t
XnODZt+19g==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
peterleinchen
2015-04-21, 20:46
Well. Do the N900 have the current Google Internet Authority G2 installed ?
Nope.
But also N9 does not have it in common-ca. Both have GeoTrust Global installed.
Output looks pretty similar on both devices (below from N900)
~# openssl s_client -connect supl.google.com:7275
CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHgzCCBmugAwIBAgIIOQH9s8eHezYwDQYJKoZIhvcNAQEFBQ AwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHE dvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUwNDA4MTQxNjE3WhcNMT UwNzA3MDAwMDAw
WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYT EWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEVMB MGA1UEAwwMKi5n
b29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg KCAQEA0YXDdpu5
Gy+qZXYWVVlEabFybjJB5qPt4Sd7jt03ZTbGTjRK6oyLTMlHtQ rjOYfbM/T5ErF3
XEy6Ky7RNldJ7gGTsjTb/Chs0bRHoj+FgMCvvPzraltegNBTRQA6qVfWyHFw/oTj
kC7M/EgV5R2d8ua70Jp5vJNwNyj/U40hcUollKsOKUZQ/xBBR6YzoJOd9+awYKmb
E1Ff+Ni5mCALZcLSMgpPN3mGOhIxQPOa2Al5zRClfflz2T4BRG JmTuNz5kd922z+
z6D95L1PWGnRENev0OlbHHMio9xDOEWlKMW7zdWXQbc60LnKYY VgUoIhTuOisOHy
RvAZ9ZDkm0EwTQIDAQABo4IEUDCCBEwwHQYDVR0lBBYwFAYIKw YBBQUHAwEGCCsG
AQUFBwMCMIIDJgYDVR0RBIIDHTCCAxmCDCouZ29vZ2xlLmNvbY INKi5hbmRyb2lk
LmNvbYIWKi5hcHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC 5nb29nbGUuY29t
ghYqLmdvb2dsZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYY ILKi5nb29nbGUu
Y2yCDiouZ29vZ2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi 5nb29nbGUuY28u
dWuCDyouZ29vZ2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg 8qLmdvb2dsZS5j
b20uYnKCDyouZ29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm 14gg8qLmdvb2ds
ZS5jb20udHKCDyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZG WCCyouZ29vZ2xl
LmVzggsqLmdvb2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2 xlLml0ggsqLmdv
b2dsZS5ubIILKi5nb29nbGUucGyCCyouZ29vZ2xlLnB0ghIqLm dvb2dsZWFkYXBp
cy5jb22CDyouZ29vZ2xlYXBpcy5jboIUKi5nb29nbGVjb21tZX JjZS5jb22CESou
Z29vZ2xldmlkZW8uY29tggwqLmdzdGF0aWMuY26CDSouZ3N0YX RpYy5jb22CCiou
Z3Z0MS5jb22CCiouZ3Z0Mi5jb22CFCoubWV0cmljLmdzdGF0aW MuY29tggwqLnVy
Y2hpbi5jb22CECoudXJsLmdvb2dsZS5jb22CFioueW91dHViZS 1ub2Nvb2tpZS5j
b22CDSoueW91dHViZS5jb22CFioueW91dHViZWVkdWNhdGlvbi 5jb22CCyoueXRp
bWcuY29tggthbmRyb2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb2 9nbGUtYW5hbHl0
aWNzLmNvbYIKZ29vZ2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY2 9tggp1cmNoaW4u
Y29tggh5b3V0dS5iZYILeW91dHViZS5jb22CFHlvdXR1YmVlZH VjYXRpb24uY29t
MGgGCCsGAQUFBwEBBFwwWjArBggrBgEFBQcwAoYfaHR0cDovL3 BraS5nb29nbGUu
Y29tL0dJQUcyLmNydDArBggrBgEFBQcwAYYfaHR0cDovL2NsaW VudHMxLmdvb2ds
ZS5jb20vb2NzcDAdBgNVHQ4EFgQUrFWn4lvMNeG7qEo62BCSvL HctWwwDAYDVR0T
AQH/BAIwADAfBgNVHSMEGDAWgBRK3QYWG7z2aLV29YG2u2IaulqBLz AXBgNVHSAE
EDAOMAwGCisGAQQB1nkCBQEwMAYDVR0fBCkwJzAloCOgIYYfaH R0cDovL3BraS5n
b29nbGUuY29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQUFAAOCAQ EAb9iyLqUQ7knP
KiJeEhJjSnNmnr+dF3cg2rogXyd7a0FmU5VtgjZwMUeVmr/B/PwucecejJ1CFCoj
b3W892OfD4E8Cm5naQYkDnDa1asnSTWPSm9bZrTen3P1Uga6eW uGq18hd8aw3QmM
9Ln+5dd/I9B6y/+mHQfyMX2D+SeO1eAkGiTj1vZ4aN5+y57U3t4GLac0coILxJ52
D+RjToGOsoY+hbcb8d3X+QG6aHthAf7IE3Dg3kJ2+erTIhR6Oc K7pAcGeSjuZ7Ng
0bs7Lcd2gYmEO9lUmMD2Qbk7XTr9x8SsvFl+4kxetC9lNgEcif ZrrzuXbm/9CP1t
XnODZt+19g==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3999 bytes and written 435 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: A7E8414ECDB2BF239AF1352CB1E4C4B5B388FDFDBD00155956 ABBE9F808F68FB
Session-ID-ctx:
Master-Key: 520D6FBFCB6FC0E077B38F7FB8F9F3C79E9DE10DFB34643350 565EE05429C7F185B005A59972C7C9F638317A2BA3133B
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1429649116
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Certs was also my first thought. But iirc I could not spot it down to a missing cert.
--
just thinking loud:
ssl3 / tls (not enabled for supl requests)? Even we see good results with OpenSSL, could it be the location service uses only ssl3 where google switched supl to tls?
nokiabot
2015-04-22, 05:15
Not anymore, it seems
just checked took only 14 seconds to fix so its working definately
I vaguely recall having this discussion before. Google not working for anyone except nokiabot. I don't think we ever got to the bottom of it.
freemangordon
2015-04-22, 06:01
@nieldk, peterleinchen - you are missing -CApath /etc/certs/common-ca/ openssl parameter
Nokia-N900:~# openssl s_client -connect supl.google.com:7275 -CApath /etc/certs/common-ca/
CONNECTED(00000003)
depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
verify return:1
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify return:1
depth=1 /C=US/O=Google Inc/CN=Google Internet Authority G2
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHgzCCBmugAwIBAgIIOQH9s8eHezYwDQYJKoZIhvcNAQEFBQ AwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHE dvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUwNDA4MTQxNjE3WhcNMT UwNzA3MDAwMDAw
WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYT EWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEVMB MGA1UEAwwMKi5n
b29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg KCAQEA0YXDdpu5
Gy+qZXYWVVlEabFybjJB5qPt4Sd7jt03ZTbGTjRK6oyLTMlHtQ rjOYfbM/T5ErF3
XEy6Ky7RNldJ7gGTsjTb/Chs0bRHoj+FgMCvvPzraltegNBTRQA6qVfWyHFw/oTj
kC7M/EgV5R2d8ua70Jp5vJNwNyj/U40hcUollKsOKUZQ/xBBR6YzoJOd9+awYKmb
E1Ff+Ni5mCALZcLSMgpPN3mGOhIxQPOa2Al5zRClfflz2T4BRG JmTuNz5kd922z+
z6D95L1PWGnRENev0OlbHHMio9xDOEWlKMW7zdWXQbc60LnKYY VgUoIhTuOisOHy
RvAZ9ZDkm0EwTQIDAQABo4IEUDCCBEwwHQYDVR0lBBYwFAYIKw YBBQUHAwEGCCsG
AQUFBwMCMIIDJgYDVR0RBIIDHTCCAxmCDCouZ29vZ2xlLmNvbY INKi5hbmRyb2lk
LmNvbYIWKi5hcHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC 5nb29nbGUuY29t
ghYqLmdvb2dsZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYY ILKi5nb29nbGUu
Y2yCDiouZ29vZ2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi 5nb29nbGUuY28u
dWuCDyouZ29vZ2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg 8qLmdvb2dsZS5j
b20uYnKCDyouZ29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm 14gg8qLmdvb2ds
ZS5jb20udHKCDyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZG WCCyouZ29vZ2xl
LmVzggsqLmdvb2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2 xlLml0ggsqLmdv
b2dsZS5ubIILKi5nb29nbGUucGyCCyouZ29vZ2xlLnB0ghIqLm dvb2dsZWFkYXBp
cy5jb22CDyouZ29vZ2xlYXBpcy5jboIUKi5nb29nbGVjb21tZX JjZS5jb22CESou
Z29vZ2xldmlkZW8uY29tggwqLmdzdGF0aWMuY26CDSouZ3N0YX RpYy5jb22CCiou
Z3Z0MS5jb22CCiouZ3Z0Mi5jb22CFCoubWV0cmljLmdzdGF0aW MuY29tggwqLnVy
Y2hpbi5jb22CECoudXJsLmdvb2dsZS5jb22CFioueW91dHViZS 1ub2Nvb2tpZS5j
b22CDSoueW91dHViZS5jb22CFioueW91dHViZWVkdWNhdGlvbi 5jb22CCyoueXRp
bWcuY29tggthbmRyb2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb2 9nbGUtYW5hbHl0
aWNzLmNvbYIKZ29vZ2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY2 9tggp1cmNoaW4u
Y29tggh5b3V0dS5iZYILeW91dHViZS5jb22CFHlvdXR1YmVlZH VjYXRpb24uY29t
MGgGCCsGAQUFBwEBBFwwWjArBggrBgEFBQcwAoYfaHR0cDovL3 BraS5nb29nbGUu
Y29tL0dJQUcyLmNydDArBggrBgEFBQcwAYYfaHR0cDovL2NsaW VudHMxLmdvb2ds
ZS5jb20vb2NzcDAdBgNVHQ4EFgQUrFWn4lvMNeG7qEo62BCSvL HctWwwDAYDVR0T
AQH/BAIwADAfBgNVHSMEGDAWgBRK3QYWG7z2aLV29YG2u2IaulqBLz AXBgNVHSAE
EDAOMAwGCisGAQQB1nkCBQEwMAYDVR0fBCkwJzAloCOgIYYfaH R0cDovL3BraS5n
b29nbGUuY29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQUFAAOCAQ EAb9iyLqUQ7knP
KiJeEhJjSnNmnr+dF3cg2rogXyd7a0FmU5VtgjZwMUeVmr/B/PwucecejJ1CFCoj
b3W892OfD4E8Cm5naQYkDnDa1asnSTWPSm9bZrTen3P1Uga6eW uGq18hd8aw3QmM
9Ln+5dd/I9B6y/+mHQfyMX2D+SeO1eAkGiTj1vZ4aN5+y57U3t4GLac0coILxJ52
D+RjToGOsoY+hbcb8d3X+QG6aHthAf7IE3Dg3kJ2+erTIhR6Oc K7pAcGeSjuZ7Ng
0bs7Lcd2gYmEO9lUmMD2Qbk7XTr9x8SsvFl+4kxetC9lNgEcif ZrrzuXbm/9CP1t
XnODZt+19g==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3999 bytes and written 402 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: B726BF106A5559DF010D4BBA491EEF82E15FC111DDE3F58C25 7BB553BCD2A639
Session-ID-ctx:
Master-Key: 527C700E669437A1EF659EAF94AEC2C21358CD32C6F134C6F2 F517D3EBFF2773FA0EC72DB54DF9CC1400390498A399A8
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1429682003
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
read:errno=0
Nokia-N900:~#
However:
Apr 22 08:58:56 Nokia-N900 location-proxy[1510]: GLIB DEBUG default - LAS configured for supl-server
Apr 22 08:59:13 Nokia-N900 [1421]: GLIB DEBUG default - location-sb: fix status changed: 0->1
Apr 22 08:59:14 Nokia-N900 location-daemon[6205]: GLIB DEBUG default - :1.64 now having 1 connections
Apr 22 08:59:14 Nokia-N900 location-daemon[6205]: GLIB DEBUG default - Starting a new LAS session with method = 0xa, interval = 0x0, reason = 0
Apr 22 08:59:14 Nokia-N900 location-daemon[6205]: GLIB DEBUG default - Tracking ongoing, status: 1, npe_id: 9
Apr 22 08:59:14 Nokia-N900 location-proxy[1510]: GLIB DEBUG default - Socket to supl.google.com opened, fd=12, verify_res=0
Apr 22 08:59:14 Nokia-N900 location-proxy[1510]: GLIB WARNING ** default - ssl_read_data: SSL_ERROR=5, ret=0, errno: Success
Apr 22 08:59:14 Nokia-N900 location-proxy[1510]: GLIB WARNING ** default - error:00000000:lib(0):func(0):reason(0)
Apr 22 08:59:14 Nokia-N900 location-proxy[1510]: GLIB WARNING ** default - Couldn't close socket: 12
Apr 22 08:59:15 Nokia-N900 location-daemon[6205]: GLIB DEBUG default - GPS STATE: search
Apr 22 08:59:17 Nokia-N900 location-proxy[1510]: GLIB DEBUG default - Socket to supl.google.com opened, fd=12, verify_res=0
Apr 22 08:59:17 Nokia-N900 location-proxy[1510]: GLIB WARNING ** default - ssl_read_data: SSL_ERROR=5, ret=0, errno: Success
Apr 22 08:59:17 Nokia-N900 location-proxy[1510]: GLIB WARNING ** default - error:00000000:lib(0):func(0):reason(0)
Apr 22 08:59:17 Nokia-N900 location-proxy[1510]: GLIB WARNING ** default - Couldn't close socket: 12
Apr 22 08:59:29 Nokia-N900 location-daemon[6205]: GLIB DEBUG default - GPS STATE: fix
Apr 22 08:59:29 Nokia-N900 [1421]: GLIB DEBUG default - location-sb: fix status changed: 1->3
I got fix in 6 seconds, but I doubt it is because google supl works
peterleinchen
2015-04-22, 06:35
just checked took only 14 seconds to fix so its working definitely
Before stating such thing, make sure your gps chip is reset completely: power down, battery out for 30s (not even sure this is enough). Or wait at least 12/24 hours or even better move a looong distance with disabled gps. And only then check again.
--edit
iirc also resetting this gconftool settings help:
/system/nokia/location/lastknown:
longitude = 0.0
latitude = 0.0
peterleinchen
2015-04-22, 06:54
@nieldk, peterleinchen - you are missing -CApath /etc/certs/common-ca/ openssl parameter
Absolutely right. Just used same command as Niel for better comparison.
Output of N9:
~ # openssl s_client -CApath /var/lib/aegis/certs/common-ca/ -connect s
upl.google.com:7275
WARNING: can't open config file: /etc/ssl/openssl.cnf
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN= *.google.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHgzCCBmugAwIBAgIIOQH9s8eHezYwDQYJKoZIhvcNAQEFBQ AwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHE dvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUwNDA4MTQxNjE3WhcNMT UwNzA3MDAwMDAw
WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYT EWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEVMB MGA1UEAwwMKi5n
b29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg KCAQEA0YXDdpu5
Gy+qZXYWVVlEabFybjJB5qPt4Sd7jt03ZTbGTjRK6oyLTMlHtQ rjOYfbM/T5ErF3
XEy6Ky7RNldJ7gGTsjTb/Chs0bRHoj+FgMCvvPzraltegNBTRQA6qVfWyHFw/oTj
kC7M/EgV5R2d8ua70Jp5vJNwNyj/U40hcUollKsOKUZQ/xBBR6YzoJOd9+awYKmb
E1Ff+Ni5mCALZcLSMgpPN3mGOhIxQPOa2Al5zRClfflz2T4BRG JmTuNz5kd922z+
z6D95L1PWGnRENev0OlbHHMio9xDOEWlKMW7zdWXQbc60LnKYY VgUoIhTuOisOHy
RvAZ9ZDkm0EwTQIDAQABo4IEUDCCBEwwHQYDVR0lBBYwFAYIKw YBBQUHAwEGCCsG
AQUFBwMCMIIDJgYDVR0RBIIDHTCCAxmCDCouZ29vZ2xlLmNvbY INKi5hbmRyb2lk
LmNvbYIWKi5hcHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC 5nb29nbGUuY29t
ghYqLmdvb2dsZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYY ILKi5nb29nbGUu
Y2yCDiouZ29vZ2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi 5nb29nbGUuY28u
dWuCDyouZ29vZ2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg 8qLmdvb2dsZS5j
b20uYnKCDyouZ29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm 14gg8qLmdvb2ds
ZS5jb20udHKCDyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZG WCCyouZ29vZ2xl
LmVzggsqLmdvb2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2 xlLml0ggsqLmdv
b2dsZS5ubIILKi5nb29nbGUucGyCCyouZ29vZ2xlLnB0ghIqLm dvb2dsZWFkYXBp
cy5jb22CDyouZ29vZ2xlYXBpcy5jboIUKi5nb29nbGVjb21tZX JjZS5jb22CESou
Z29vZ2xldmlkZW8uY29tggwqLmdzdGF0aWMuY26CDSouZ3N0YX RpYy5jb22CCiou
Z3Z0MS5jb22CCiouZ3Z0Mi5jb22CFCoubWV0cmljLmdzdGF0aW MuY29tggwqLnVy
Y2hpbi5jb22CECoudXJsLmdvb2dsZS5jb22CFioueW91dHViZS 1ub2Nvb2tpZS5j
b22CDSoueW91dHViZS5jb22CFioueW91dHViZWVkdWNhdGlvbi 5jb22CCyoueXRp
bWcuY29tggthbmRyb2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb2 9nbGUtYW5hbHl0
aWNzLmNvbYIKZ29vZ2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY2 9tggp1cmNoaW4u
Y29tggh5b3V0dS5iZYILeW91dHViZS5jb22CFHlvdXR1YmVlZH VjYXRpb24uY29t
MGgGCCsGAQUFBwEBBFwwWjArBggrBgEFBQcwAoYfaHR0cDovL3 BraS5nb29nbGUu
Y29tL0dJQUcyLmNydDArBggrBgEFBQcwAYYfaHR0cDovL2NsaW VudHMxLmdvb2ds
ZS5jb20vb2NzcDAdBgNVHQ4EFgQUrFWn4lvMNeG7qEo62BCSvL HctWwwDAYDVR0T
AQH/BAIwADAfBgNVHSMEGDAWgBRK3QYWG7z2aLV29YG2u2IaulqBLz AXBgNVHSAE
EDAOMAwGCisGAQQB1nkCBQEwMAYDVR0fBCkwJzAloCOgIYYfaH R0cDovL3BraS5n
b29nbGUuY29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQUFAAOCAQ EAb9iyLqUQ7knP
KiJeEhJjSnNmnr+dF3cg2rogXyd7a0FmU5VtgjZwMUeVmr/B/PwucecejJ1CFCoj
b3W892OfD4E8Cm5naQYkDnDa1asnSTWPSm9bZrTen3P1Uga6eW uGq18hd8aw3QmM
9Ln+5dd/I9B6y/+mHQfyMX2D+SeO1eAkGiTj1vZ4aN5+y57U3t4GLac0coILxJ52
D+RjToGOsoY+hbcb8d3X+QG6aHthAf7IE3Dg3kJ2+erTIhR6Oc K7pAcGeSjuZ7Ng
0bs7Lcd2gYmEO9lUmMD2Qbk7XTr9x8SsvFl+4kxetC9lNgEcif ZrrzuXbm/9CP1t
XnODZt+19g==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 4500 bytes and written 643 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 1AC99472C286DADAA7587F9E1DCA11F3EE4B92B6BCE67C3109 2F5EB0A09B8E50
Session-ID-ctx:
Master-Key: 7C61000D13F8BCC90E01E89F6D6AF576585CBCC51E9E58442B 7EB06C0FBB21E811CEB3205343F1618A602170F034BCB9
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 42 e8 93 36 2a 55 fd bf-8a dd 32 5b 4c 6e 95 a9 B..6*U....2[Ln..
0010 - 57 c8 63 bf ad a2 95 1a-b6 e7 3b 8b 83 8e 3e e9 W.c.......;...>.
0020 - 76 dd 68 04 57 2f cd 03-69 d9 5c ed 12 39 d8 88 v.h.W/..i.\..9..
0030 - c3 4e 1d 26 2e 2a 97 81-7d f3 22 fd 5e e7 19 ac .N.&.*..}.".^...
0040 - 1f 6c 77 9b 96 58 ab f2-90 c1 a7 e7 8f 40 7f 88 .lw..X.......@..
0050 - 76 e3 6a 88 e1 bb 26 be-f2 4c 18 61 53 37 6a 8d v.j...&..L.aS7j.
0060 - 93 db fd 42 de 04 49 51-76 5c 6e 8b 20 b4 37 95 ...B..IQv\n. .7.
0070 - 81 65 01 d6 24 12 0a 36-94 03 7d 36 9d 86 5e 74 .e..$..6..}6..^t
0080 - da be b6 51 95 02 f5 59-c7 ae 1c 40 0e d1 c8 42 ...Q...Y...@...B
0090 - 85 49 41 d0 f8 35 c4 85-73 35 b4 55 82 47 80 47 .IA..5..s5.U.G.G
00a0 - d2 0d 06 82 ....
Start Time: 1429685473
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
sixwheeledbeast
2015-04-22, 07:08
As per peterleinchen, I confirm I only noticed an issue after a reboot.
freemangordon
2015-04-22, 07:30
Absolutely right. Just used same command as Niel for better comparison.
Output of N9:
SSL-Session:
Protocol : TLSv1.2
Wait, what? What version is openssl on N9?
nokiabot
2015-04-22, 08:16
I vaguely recall having this discussion before. Google not working for anyone except nokiabot. I don't think we ever got to the bottom of it.
well tell me what to post also how to
i ll be travelling at least 100 kms tmorrow from my current position
i ll turn off my phone take the battrey out put it to charge and use modrana at a diff location
will that suffice ?
wi
nokiabot
2015-04-22, 08:19
Nope.
But also N9 does not have it in common-ca. Both have GeoTrust Global installed.
Output looks pretty similar on both devices (below from N900)
~# openssl s_client -connect supl.google.com:7275
CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHgzCCBmugAwIBAgIIOQH9s8eHezYwDQYJKoZIhvcNAQEFBQ AwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHE dvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTUwNDA4MTQxNjE3WhcNMT UwNzA3MDAwMDAw
WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYT EWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEVMB MGA1UEAwwMKi5n
b29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg KCAQEA0YXDdpu5
Gy+qZXYWVVlEabFybjJB5qPt4Sd7jt03ZTbGTjRK6oyLTMlHtQ rjOYfbM/T5ErF3
XEy6Ky7RNldJ7gGTsjTb/Chs0bRHoj+FgMCvvPzraltegNBTRQA6qVfWyHFw/oTj
kC7M/EgV5R2d8ua70Jp5vJNwNyj/U40hcUollKsOKUZQ/xBBR6YzoJOd9+awYKmb
E1Ff+Ni5mCALZcLSMgpPN3mGOhIxQPOa2Al5zRClfflz2T4BRG JmTuNz5kd922z+
z6D95L1PWGnRENev0OlbHHMio9xDOEWlKMW7zdWXQbc60LnKYY VgUoIhTuOisOHy
RvAZ9ZDkm0EwTQIDAQABo4IEUDCCBEwwHQYDVR0lBBYwFAYIKw YBBQUHAwEGCCsG
AQUFBwMCMIIDJgYDVR0RBIIDHTCCAxmCDCouZ29vZ2xlLmNvbY INKi5hbmRyb2lk
LmNvbYIWKi5hcHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC 5nb29nbGUuY29t
ghYqLmdvb2dsZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYY ILKi5nb29nbGUu
Y2yCDiouZ29vZ2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi 5nb29nbGUuY28u
dWuCDyouZ29vZ2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg 8qLmdvb2dsZS5j
b20uYnKCDyouZ29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm 14gg8qLmdvb2ds
ZS5jb20udHKCDyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZG WCCyouZ29vZ2xl
LmVzggsqLmdvb2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2 xlLml0ggsqLmdv
b2dsZS5ubIILKi5nb29nbGUucGyCCyouZ29vZ2xlLnB0ghIqLm dvb2dsZWFkYXBp
cy5jb22CDyouZ29vZ2xlYXBpcy5jboIUKi5nb29nbGVjb21tZX JjZS5jb22CESou
Z29vZ2xldmlkZW8uY29tggwqLmdzdGF0aWMuY26CDSouZ3N0YX RpYy5jb22CCiou
Z3Z0MS5jb22CCiouZ3Z0Mi5jb22CFCoubWV0cmljLmdzdGF0aW MuY29tggwqLnVy
Y2hpbi5jb22CECoudXJsLmdvb2dsZS5jb22CFioueW91dHViZS 1ub2Nvb2tpZS5j
b22CDSoueW91dHViZS5jb22CFioueW91dHViZWVkdWNhdGlvbi 5jb22CCyoueXRp
bWcuY29tggthbmRyb2lkLmNvbYIEZy5jb4IGZ29vLmdsghRnb2 9nbGUtYW5hbHl0
aWNzLmNvbYIKZ29vZ2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY2 9tggp1cmNoaW4u
Y29tggh5b3V0dS5iZYILeW91dHViZS5jb22CFHlvdXR1YmVlZH VjYXRpb24uY29t
MGgGCCsGAQUFBwEBBFwwWjArBggrBgEFBQcwAoYfaHR0cDovL3 BraS5nb29nbGUu
Y29tL0dJQUcyLmNydDArBggrBgEFBQcwAYYfaHR0cDovL2NsaW VudHMxLmdvb2ds
ZS5jb20vb2NzcDAdBgNVHQ4EFgQUrFWn4lvMNeG7qEo62BCSvL HctWwwDAYDVR0T
AQH/BAIwADAfBgNVHSMEGDAWgBRK3QYWG7z2aLV29YG2u2IaulqBLz AXBgNVHSAE
EDAOMAwGCisGAQQB1nkCBQEwMAYDVR0fBCkwJzAloCOgIYYfaH R0cDovL3BraS5n
b29nbGUuY29tL0dJQUcyLmNybDANBgkqhkiG9w0BAQUFAAOCAQ EAb9iyLqUQ7knP
KiJeEhJjSnNmnr+dF3cg2rogXyd7a0FmU5VtgjZwMUeVmr/B/PwucecejJ1CFCoj
b3W892OfD4E8Cm5naQYkDnDa1asnSTWPSm9bZrTen3P1Uga6eW uGq18hd8aw3QmM
9Ln+5dd/I9B6y/+mHQfyMX2D+SeO1eAkGiTj1vZ4aN5+y57U3t4GLac0coILxJ52
D+RjToGOsoY+hbcb8d3X+QG6aHthAf7IE3Dg3kJ2+erTIhR6Oc K7pAcGeSjuZ7Ng
0bs7Lcd2gYmEO9lUmMD2Qbk7XTr9x8SsvFl+4kxetC9lNgEcif ZrrzuXbm/9CP1t
XnODZt+19g==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3999 bytes and written 435 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: A7E8414ECDB2BF239AF1352CB1E4C4B5B388FDFDBD00155956 ABBE9F808F68FB
Session-ID-ctx:
Master-Key: 520D6FBFCB6FC0E077B38F7FB8F9F3C79E9DE10DFB34643350 565EE05429C7F185B005A59972C7C9F638317A2BA3133B
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1429649116
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Certs was also my first thought. But iirc I could not spot it down to a missing cert.
--
just thinking loud:
ssl3 / tls (not enabled for supl requests)? Even we see good results with OpenSSL, could it be the location service uses only ssl3 where google switched supl to tls?
how you manage output thease gibberish ? i want to post too :D
peterleinchen
2015-04-22, 08:28
Wait, what? What version is openssl on N9?
OpenSSL 1.0.1g 7 April 2014
(against 0.9.8gn 24 Mar 2010 on N900)
--edit
Which seems far to new for stock OpenSSL, right? ;)
So someone else with stock N9 please may also post output of
openssl
version
freemangordon
2015-04-22, 09:48
OpenSSL 1.0.1g 7 April 2014
(against 0.9.8gn 24 Mar 2010 on N900)
well, in CSSU it is 0.9.8zf 19 Mar 2015 :P
--edit
Which seems far to new for stock OpenSSL, right? ;)
So someone else with stock N9 please may also post output of
openssl
version
What I still miss is if supl.google.com works on n9.
peterleinchen
2015-04-22, 10:05
What kind of proof you like? ;)
I rebooted my N9 this morning, went to cellar and did not get a fix with WLAN connection. Then went to work and got a fix within seconds with GPRS and near to a window.
openssl s_client -connect supl.google.com:7275 -CApath /etc/certs/common-ca
Edit:
Oops.. i missed last freemangordon post.
peterleinchen
2015-04-22, 18:24
@xes, please see above ;)
@freemangordon
I did some more (intensive) tests (during lunch time/walk ;) under clear sky).
And I am sure N9 and google's supl do like it each other. :)
Rebooted, no data connection, no fix within 30 seconds.
Rebooted, GPRS data connection, got fix within a few seconds,
And to be on the safe side:
Rebooted again, no data connection, again no fix within 30 seconds.
I remember now. How I was able to use google, while others Reported fail.
Back then, one diff was - actually - I was using my own build of openssl. Which I still have a copy of.
In case. Its worth a try.
http://talk.maemo.org/showpost.php?p=1385926&postcount=1
freemangordon
2015-04-23, 06:20
ok, I made some tests with supl-client (http://www.tajuma.com/supl/) and I think I am getting near - supl.nokia.com returns almanac even not requested, while supl.google.com does not return it unless requested.
That might explain why is "ssl_read_data: SSL_ERROR=5, ret=0, errno: Success" error spit - location proxy expects almanac, but server closes the connection. I will setup supl-proxy when I have some time, to see what request location-proxy sends to the supl server.
EDIT:
If someone wants to take it from here, I will publish the pre-compiled binaries on my webserver
Hi freemangordon, thanks for looking into supl-proxy from tajuma.
Using the supl-client tool is one relatively easy way for showing that google an sonyericsson respond differently to SUPL requests (compared to nokia and vodafone). And thats the reason why some servers dont work with Maemo/N900 and others do work - if there are no cert issues. Other operation system obviously don't have that limitations for the responded data and work with all of the mentioned servers.
Deploying supl-proxy as a real MITM is a bit more advanced, my results for this are in this earlier post
http://talk.maemo.org/showpost.php?p=1369745&postcount=101
(see attached zip there for logs) and
http://talk.maemo.org/showpost.php?p=1370099&postcount=114
May be you (or anyone else) are able to extend the supl-proxy source code to make it work as kind of a service, i.e. so it doesn't stop after each connection?
That would make it possible to use it as a private proxy without any certificate trouble (maybe even locally on N900).
Unfortunately I can't do it by myself with reasonable effort.
I uploaded supl (supl-client, supl-proxy, ...) for fremantle to extras-devel for those who want to use it on device.
@xes, please see above ;)
@freemangordon
I did some more (intensive) tests (during lunch time/walk ;) under clear sky).
And I am sure N9 and google's supl do like it each other. :)
Rebooted, no data connection, no fix within 30 seconds.
Rebooted, GPRS data connection, got fix within a few seconds,
And to be on the safe side:
Rebooted again, no data connection, again no fix within 30 seconds.
How did you change the supl server on Harmattan? Unlike on the N900, I couldn't find an option to configure it anywhere. I even grepped through a recursive listing of the gconf tree but I still couldn't find it.
peterleinchen
2015-04-24, 05:33
How did you change the supl server on Harmattan? ...
/etc/xdg/nokia/location-settings.conf
It took longer than expected, but since today I get a new certificate for supl.nokia.com
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Secure Server CA - G3
Validity
Not Before: May 14 00:00:00 2015 GMT
Not After : May 14 23:59:59 2016 GMT
Subject: C=NL, ST=Noord-Brabant, L=Veldhoven, O=HERE Global BV, CN=supl.nokia.com
Hope to see you all here again in a year!
With Neo900 of course <wish>,running Maemo</wish> ;)
peterleinchen
2015-05-15, 17:44
It took longer than expected, but since today I get a new certificate for supl.nokia.com
And A-GPS is working again on N900 (and older Symbians)! :)
Even there is a slef-signed cert error in the chain.
Hope to see you all here again in a year!
With Neo900 of course <wish>,running Maemo</wish> ;)For sure. About Neo, we will see...
--edit
Offtopic question:
Any chance or contact for activating the navigation license on N95 once more? That one did not fall under the lifetime free navigation promise and it needed a 10€-fee each year paid by CC inside the navigation app itself.
MS? na.
Nokia? not anymore
Here?
glo-worm
2016-03-10, 14:09
Does anyone else seem to have lost A-GPS from supl.nokia.com once again, or is it just me?
UPDATE:- Its working now? I opened GPSdata app and it locked on immiediately. Prior to that both camera geolocate and Ovi maps would not get a lock no matter what I tried? Bizarre
chilango
2016-03-10, 15:31
oh. pinging today supl.nokia.com is working again. few days before supl.nokia.com was not responding
glo-worm
2016-03-10, 15:55
oh. pinging today supl.nokia.com is working again. few days before supl.nokia.com was not responding
Yeah, I tested it with a ping, when playing around, so I knew there was something there. Just wouldnt work for some reason until I used the gpsapp.
I started to use the N900 again after one year, upgraded to latest cssu stable 21.2011.38-1Smaemo8 (10.06.2016) but no A-gps fix with supl.nokia.com , certificate expired ?
supl.nokia.com is dead, just like nokia itself. Change the value to:
supl.google.com
But I still can't figure out what is it all about? Mine n900 got fix under a minute everytime, with no cellular data, only gps, even when I only stick it through the window.
With google supl it's doing the same, mostly under 5 seconds.
But yes, my previous n900 had problems with fixing, no matter if cellular data was enabled. It got partially broken stick on motherboard and broken antena (After hitting the ground really hard).
dead? afaik it is NOT dead and still resolves to a valid address. On the other hand, I seem to remember N900 had problems with supl.google.com after the certificate problem was fixed for supl.nokia.com ... anyway, stopped using supl.google after supl.nokia started working again
as for the quick fixes on yours ... likely the result of ACWP and other variables (ephemeris data?). Take that N900 a long distance away, and not have a working SIM card ... and you'll probably be waiting for a fix for a long time too.
@gianko - supl.nokia.com still gives me near-instant fixes. i am on CSSU-T however, although I believe the certificate fix was incorporated in Stable as well
dead? afaik it is NOT dead and still resolves to a valid address. On the other hand, I seem to remember N900 had problems with supl.google.com after the certificate problem was fixed for supl.nokia.com ... anyway, stopped using supl.google after supl.nokia started working again
Ok, not dead, but I'm not sure about the functionality of supl.nokia. Just tested, with cellular data fix takes about a minute, like with no gsm at all. After switching to supl.google got fix in few second in slightly different position.
as for the quick fixes on yours ... likely the result of ACWP and other variables (ephemeris data?). Take that N900 a long distance away, and not have a working SIM card ... and you'll probably be waiting for a fix for a long time too
If I got fix when staying in one spot, then I can turn off the gsm and will have it fixed, even traveling 100km (Checked few days ago) with proper directions and so.
supl.nokia.com still gives me near-instant fixes. i am on CSSU-T however, although I believe the certificate fix was incorporated in Stable as well
I'm on CSSU Stable, there is no problems with supl.google.com on this platform
I'm not sure how it is all working, but it seems that slightly different configuration works differently on many devices. For now(and for me at least), if everything is fine with hardware there is only few if non problems at all
very strange indeed. i also tried supl.google a few minutes ago, and because the gps data was mostly valid, the location was correct but 'coarse accuracy' - it didn't lock in 3 minutes. changed it back to 'supl.nokia' and as always, lock was done in less than 20s...
must be that your "it seems that slightly different configuration works differently on many devices" comment is correct, which actually sucks, haha
EDIT: have to add i did these tests indoors
It took longer than expected, but since today I get a new certificate for supl.nokia.com
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Secure Server CA - G3
Validity
Not Before: May 14 00:00:00 2015 GMT
Not After : May 14 23:59:59 2016 GMT
Subject: C=NL, ST=Noord-Brabant, L=Veldhoven, O=HERE Global BV, CN=supl.nokia.com
Hope to see you all here again in a year!
With Neo900 of course <wish>,running Maemo</wish> ;)
According to this post the cert for Nokia is expired. I have no indoor fix with only wifi and A-gps. Tried both Google and Nokia supl but no fix. Btw if I ping supl.google.com I have replies but if I ping supl.nokia.com I got 100% packet lost but resolve the IP 54.93.209.220
Hi gianko, the current cert of supl.nokia.com is not expired. It has been renewed in February.
This is the bash oneliner I use to check:
/usr/bin/openssl s_client -connect supl.nokia.com:7275 2>&1 | /bin/grep -A40 BEGIN | /usr/bin/openssl x509 -noout -text | /bin/grep -i -A1 -B3 "Not After"
Works on N900 and most linux boxes.
For looking after other certificate problems see this post:
https://talk.maemo.org/showpost.php?p=1369745&postcount=101
Try the cmcli commands with your N900 and see if you get "Verified OK".
And for proper GPS-testing I suggest seeing the posts on this page:
https://talk.maemo.org/showthread.php?t=90651&page=6
and this post:
http://talk.maemo.org/showpost.php?p=1365615&postcount=31
I dont have any issues with GPS here currently. Using supl.nokia.com with fingers crossed ...
Anyway, glad to see some of you still using their "Apparat" here ;)
Cheers, Ulle
Hmm, noticed yesterday that I have problems with supl.nokia.com lately:
Feb 4 14:32:01 fremantle location-proxy[1297]: GLIB DEBUG default - Socket to supl.nokia.com opened, fd=12, verify_res=19
Feb 4 14:32:01 fremantle location-proxy[1297]: GLIB WARNING ** default - host: supl.nokia.com not verified, result: 19
Feb 4 14:32:01 fremantle location-proxy[1297]: GLIB WARNING ** default - Connection to h-slp.mnc002.mcc655.pub.3gppnetwork.org:7275 failed
Feb 4 14:32:01 fremantle location-proxy[1297]: GLIB WARNING ** default - error:2006A066:BIO routines:BIO_get_host_ip:bad hostname lookup
Feb 4 14:32:01 fremantle location-proxy[1297]: GLIB DEBUG default - Socket fd=12 closed on request
The device has CSSU-Thumb with openssl 0.9.8zh-1+maemo1+0m5+0cssu0
My other N900, with openssl 0.9.8zf-1+maemo1+0m5+0cssu0 gets quick fix, with exactly the same settings. Here's the log:
Feb 4 22:11:42 Nokia-N900 location-proxy[1300]: GLIB DEBUG default - Socket to supl.nokia.com opened, fd=12, verify_res=0
Feb 4 22:11:43 Nokia-N900 location-proxy[1300]: GLIB DEBUG default - Socket to supl.nokia.com opened, fd=13, verify_res=0
Feb 4 22:11:43 Nokia-N900 location-proxy[1300]: GLIB DEBUG default - Socket fd=12 closed on request
Feb 4 22:11:43 Nokia-N900 location-proxy[1300]: GLIB DEBUG default - Socket fd=13 closed on request
An interesting thing is - the 2nd N900 never tries to contact h-slp.mncXXX.mccXXX.pub.3gppnetwork.org, whereas the 2nd one does. XXX depends on the operator whose SIM is in the device
cmcli output for both N900 is the same
cmcli -T common-ca -v supl.nokia.com:7275
1ad16dd494e161abd39bd94ed94bf8eafe4ede28 supl.nokia.com
Verification failed: self signed certificate
and with both,
openssl s_client -connect supl.nokia.com:7275 -CApath /etc/certs/common-ca/
...
...
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: ...
Session-ID-ctx:
Master-Key: ...
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1486242237
Timeout : 300 (sec)
Verify return code: 0 (ok)
Found the problem
Downgraded all *maemosec* packages to versions 0.1.4+0m5 (had 0.1.5 from devel), and 0.2.3 (had 0.2.7 from devel, and my 2nd N900 has 2.4, but doesn't seem to be in any repos)
Instant fix on my 1st N900 and no attempts to contact 3gppnetwork.org
Can you update *maemosec-certman-applet* back to 0.1.5 and verify if those packages are not problematic?
Can you update *maemosec-certman-applet* back to 0.1.5 and verify if those packages are not problematic?
Ok .. no problem with *maemosec-certman-applet* .. even with 0.1.5 I still have fix.
I cant seem to get a fix on my N900 GPS at all.
If I try "GNSS" or "AGNSS" in location-test-gui neither works. location-test-gui shows up to 5 satellites as "visible" but none as "in use" Tried rebooting the phone. Tried pulling the battery for a few minutes. Tried offline mode (with "GNSS"). Tried multiple versions of maemosec-certman-common-ca (including the 0.2.3 version with the "Fixes supl server not working." change in it). Tried the clear-gps-cache tool multiple times. Tried multiple SUPL servers (supl.nokia.com, supl.google.com, supl.vodafone.com). Tried going outside away from obstructions. Nothing works.
Anyone got any suggestions on what else to try? I dont see anything in syslog (but maybe I dont have it configured properly to capture useful logs)
The "sats" button in location-test-gui shows a bunch of SNR values for various satellites (up as high as 6 when I was standing further away from any buildings etc) with values ranging from high 20s through to 40 or more.
So its clearly actually talking to satellites in space (it woudn't be giving me SNR values if it wasn't) but for whatever reason it isn't working. Anyone know what SNR values I should be looking for and whether bigger or smaller values are good?
ok, wtf, now it got a lock somehow. I dont know what I did but it got a lock in location-test-GUI and now a lock in nokia-maps.
No ideas what might be going on now. Anyone got any ideas on what to try to figure out why it isn't getting a lock or why its taking so long or whatever? Being able to get reliable lock when I open maps app or whatever would be usefull :)
Looks like we do need to figure out what certificates are missing from the current maemo-security-certman root CA store (which matches the current mozilla root CA set) that are needed for the SUPL server and why they are missing. Or if they are there but the ordering is wrong, we need to figure out why and find a way to correct it by fixing the tools in maemo-security-certman somehow (even if it means adding some sort of hardcoded "these certificates need to be in this order" feature to the relavent tools or some changes to the instructions to manually add the correct certificate back)
cmcli -T common-ca -v supl.nokia.com:7275
1ad16dd494e161abd39bd94ed94bf8eafe4ede28 supl.nokia.com
Verification failed: self signed certificate
Running the following can fix this issue by installing a missing certificate:
cmcli -c common-ca -a /etc/certs/common-ca/00d85a4c25c122e58b31ef6dbaf3cc5f29f10d61-1.pem
The cert should be on your device unless it was removed.
The cert was removed in this commit:
https://github.com/community-ssu/maemo-security-certman/commit/1c393d887e3ad9ad755ff9c4390033bde5b16535
Can you try get a lock with the latest maemo-security-certman and the above cert?
It looks like we need to figure out why supl.nokia.com needs that specific old certificate (one that the smart people at Mozilla have stopped including for presumably good reasons) and whether we really need that cert or whether there is some other issue going on.
Oh and installing a random cert without understanding what cert it is and why its needed and why Mozilla don't ship it anymore and etc is a stupid idea (the set of certs distributed by Mozilla is chosen very carefully)
Oh and installing a random cert without understanding what cert it is and why its needed and why Mozilla don't ship it anymore and etc is a stupid idea (the set of certs distributed by Mozilla is chosen very carefully)
Yes agreed.
With that said everyone with a n900 besides the people running the cssu-devel version of maemo-security-certman are using this cert and since sicelo has reverted back to the previous version to fix his issue he will be using that cert anyway.
Ok so it seems the real problem here is that supl.nokia.com has 2 obsolete VeriSign certificates in its chain, one with
Subject: "CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US"
and one with
Subject: "OU=Class 3 Public Primary Certification Authority,O="VeriSign, Inc.",C=US"
The current mozilla root CA store (and by extention the current maemo-security-certman git which I updated earlier) contains a newer certificate that matches
Subject: "CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU="(c) 2006 VeriSign, Inc. - For authorized use only",OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US"
and will correctly validate the certificate
Subject: "CN=Symantec Class 3 Secure Server CA - G4,OU=Symantec Trust Network,O=Symantec Corporation,C=US"
which in turn will correctly validate the certificate
Subject: "CN=supl.nokia.com,O=HERE Global BV,L=Veldhoven,ST=Noord-Brabant,C=NL"
I have an idea how to fix this without security risk to other things (e.g. browser) involving the fact that location-proxy will read from a private certificate store named location-proxy. This will require a binary patch to location-proxy (to correct a bug in the code that accesses the private certificate store) and installing the necessary root certificate into the private certificate store via cmcli. Both should be fairly easy to do I suspect (we do binary patches for the cell broadcast SMS stuff, I see no reason we cant do the same for location-proxy)
The fix is working on my own N900 (I am running the modified location-proxy and with the relavent certificate installed, I cleared all the GPS caches, rebooted the phone to flush out anything in RAM and got a GPS fix in no time with a dozen or so satellites returning signal levels in location-test-gui)
With the current contents of maemo-security-certman Git plus the 2 byte change to location-proxy plus the extra certificate stored in the private certificate store, AGPS with supl.nokia.com will work and work great.
We just need to figure out how best to package up the fix :)
jonwil: Cannot we just include "0 s:/C=NL/ST=Noord-Brabant/L=Veldhoven/O=HERE Global BV/CN=supl.nokia.com" cert into storage and establish connection without checking whole certificate chain?
That cert has CN=supl.nokia.com so is valid only for supl.nokia.com. And once you trust some certificate in chain, you do not have to validate other in chain...
Anyway, on Ubuntu 12.04 verification to supl.nokia.com:7275 pass:
$ openssl s_client -connect supl.nokia.com:7275 -CAfile /etc/ssl/certs/ca-certificates.crt
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
verify return:1
depth=0 C = NL, ST = Noord-Brabant, L = Veldhoven, O = HERE Global BV, CN = supl.nokia.com
verify return:1
---
Certificate chain
0 s:/C=NL/ST=Noord-Brabant/L=Veldhoven/O=HERE Global BV/CN=supl.nokia.com
i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGWzCCBUOgAwIBAgIQNUQLMS6rnzbNIfXt19aBADANBgkqhk iG9w0BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG 9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBA MTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE2MD IxODAwMDAwMFoX
DTE3MDUxNTIzNTk1OVowazELMAkGA1UEBhMCTkwxFjAUBgNVBA gMDU5vb3JkLUJy
YWJhbnQxEjAQBgNVBAcMCVZlbGRob3ZlbjEXMBUGA1UECgwOSE VSRSBHbG9iYWwg
QlYxFzAVBgNVBAMMDnN1cGwubm9raWEuY29tMIIBIjANBgkqhk iG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA34Z7l6qHrxge+eW/C8lNffowlsi/HKqWNRqsmV0g09unZ3Zp
ptEXOvsHsZVshMUsL3h2OBQqPRM0Wkd9Ol9+ZKi5JZinxZg1Ac J407bJ7MA5W9aE
XAWLGnZ7f+FaLpuZW34DuN8M3yk6e6BlEiSAfHPpzOd1GoMBYD/MiLzDmwE9GpAY
pLxCc+pxiG2aqHydVvMKnYnB5Xyx2D1Ke8LJHVqMg+OqINeXqG NlDXDS9yReK+vS
8Hzy2abxF5O8/emWFle5vWCAvbAHs76MeZGyUkWeVxFAwdzq9XAxYmhuPOnxq50 f
Fk5fWwIoZUkIsLjQwafIjEg45s+LNPd0ct9xAQIDAQABo4IC5j CCAuIwGQYDVR0R
BBIwEIIOc3VwbC5ub2tpYS5jb20wCQYDVR0TBAIwADAOBgNVHQ 8BAf8EBAMCBaAw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGEGA1UdIA RaMFgwVgYGZ4EM
AQICMEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb2 0vY3BzMCUGCCsG
AQUFBwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMB8GA1 UdIwQYMBaAFF9g
z2GQVd+EQxSKYCqy9Xr0QxjvMCsGA1UdHwQkMCIwIKAeoByGGm h0dHA6Ly9zcy5z
eW1jYi5jb20vc3MuY3JsMFcGCCsGAQUFBwEBBEswSTAfBggrBg EFBQcwAYYTaHR0
cDovL3NzLnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL3 NzLnN5bWNiLmNv
bS9zcy5jcnQwggF/BgorBgEEAdZ5AgQCBIIBbwSCAWsBaQB2AN3rHSt6DU+mIIuB
rYFocH4ujp0B1VyIjT0RxM227L7MAAABUvXU0HQAAAQDAEcwRQ IhALnrb8gmpKob
6WD6R2NfNUDdxmEry6PbLdAgrYxoxd7YAiAq5oaIjTWuS7VvGO l7aSfxLxXKoX/H
afFyFY759kv4RQB3AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuO N3zQ7IDdwQAAAB
UvXU0LUAAAQDAEgwRgIhAIcx1pylH31cUgbUvXDu/Ue5DJwx2P187DQmxnPQIUmz
AiEA7oNhaU1u9jf27FbMQAAnpMuNV1MNy1XCLNUyr9vmTQEAdg Bo9pj4H2SCvjqM
7rkoHUz8cVFdZ5PURNEKZ6y7T0/7xAAAAVL11NCOAAAEAwBHMEUCIQCKc7VKuFgM
RW3bUVUFZNlBxAh7GBZmK5MDQSe4twwewwIgPbZiWohxrz2Kme bNq2aXBL6hZL4Q
uDFi2mjHrB5Ddp0wDQYJKoZIhvcNAQELBQADggEBAAskbpaa0l zIpXoYRqemUzsd
SWnzfTEIanTIpuXUUfYdtKvcPlJ496f+W9eR2nNv0W3+iNIdYU Z9Kua0v6iOw+s/
kL81zFBlDELXRjzVmMr5z0qC3i61aCAwhpWwQcp9PtrnSObxCs 0I41oUoQt47H+L
KJfIQQCPxHRNC0Szv6Q61vXbrGRiGOIlZKGXfWGTY4mtzrQoWe zkL62uU1LCp2RM
yIu3hgHTT8rJEAnPrgsZtK34gteKhjrVQwBFki0ewUZoC2/wyxCUYRiEVl+St1Rv
Gi2Cz9WI6B5oycD+qMkWfjl4nMw3tREPxTX1mAQE9cvh5j+8b1 cjEV+rUCwhxyA=
-----END CERTIFICATE-----
subject=/C=NL/ST=Noord-Brabant/L=Veldhoven/O=HERE Global BV/CN=supl.nokia.com
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
---
No client certificate CA names sent
---
SSL handshake has read 5304 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: FA31BE7E16B88AA4065D88CF78256C136596EFEA30667A7773 FD7AF6403A4DE1
Session-ID-ctx:
Master-Key: 11D4F52DEA6E4324BD9276717F90F26FE76AE54F8FE6573224 4C22E080D11BFF537884DE502187F91FEA23580261842B
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1486306871
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
On Debian 8 too:
$ openssl s_client -connect supl.nokia.com:7275 -CAfile /etc/ssl/certs/ca-certificates.crt
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
verify return:1
depth=0 C = NL, ST = Noord-Brabant, L = Veldhoven, O = HERE Global BV, CN = supl.nokia.com
verify return:1
---
Certificate chain
0 s:/C=NL/ST=Noord-Brabant/L=Veldhoven/O=HERE Global BV/CN=supl.nokia.com
i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGWzCCBUOgAwIBAgIQNUQLMS6rnzbNIfXt19aBADANBgkqhk iG9w0BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG 9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBA MTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE2MD IxODAwMDAwMFoX
DTE3MDUxNTIzNTk1OVowazELMAkGA1UEBhMCTkwxFjAUBgNVBA gMDU5vb3JkLUJy
YWJhbnQxEjAQBgNVBAcMCVZlbGRob3ZlbjEXMBUGA1UECgwOSE VSRSBHbG9iYWwg
QlYxFzAVBgNVBAMMDnN1cGwubm9raWEuY29tMIIBIjANBgkqhk iG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA34Z7l6qHrxge+eW/C8lNffowlsi/HKqWNRqsmV0g09unZ3Zp
ptEXOvsHsZVshMUsL3h2OBQqPRM0Wkd9Ol9+ZKi5JZinxZg1Ac J407bJ7MA5W9aE
XAWLGnZ7f+FaLpuZW34DuN8M3yk6e6BlEiSAfHPpzOd1GoMBYD/MiLzDmwE9GpAY
pLxCc+pxiG2aqHydVvMKnYnB5Xyx2D1Ke8LJHVqMg+OqINeXqG NlDXDS9yReK+vS
8Hzy2abxF5O8/emWFle5vWCAvbAHs76MeZGyUkWeVxFAwdzq9XAxYmhuPOnxq50 f
Fk5fWwIoZUkIsLjQwafIjEg45s+LNPd0ct9xAQIDAQABo4IC5j CCAuIwGQYDVR0R
BBIwEIIOc3VwbC5ub2tpYS5jb20wCQYDVR0TBAIwADAOBgNVHQ 8BAf8EBAMCBaAw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGEGA1UdIA RaMFgwVgYGZ4EM
AQICMEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb2 0vY3BzMCUGCCsG
AQUFBwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMB8GA1 UdIwQYMBaAFF9g
z2GQVd+EQxSKYCqy9Xr0QxjvMCsGA1UdHwQkMCIwIKAeoByGGm h0dHA6Ly9zcy5z
eW1jYi5jb20vc3MuY3JsMFcGCCsGAQUFBwEBBEswSTAfBggrBg EFBQcwAYYTaHR0
cDovL3NzLnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL3 NzLnN5bWNiLmNv
bS9zcy5jcnQwggF/BgorBgEEAdZ5AgQCBIIBbwSCAWsBaQB2AN3rHSt6DU+mIIuB
rYFocH4ujp0B1VyIjT0RxM227L7MAAABUvXU0HQAAAQDAEcwRQ IhALnrb8gmpKob
6WD6R2NfNUDdxmEry6PbLdAgrYxoxd7YAiAq5oaIjTWuS7VvGO l7aSfxLxXKoX/H
afFyFY759kv4RQB3AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuO N3zQ7IDdwQAAAB
UvXU0LUAAAQDAEgwRgIhAIcx1pylH31cUgbUvXDu/Ue5DJwx2P187DQmxnPQIUmz
AiEA7oNhaU1u9jf27FbMQAAnpMuNV1MNy1XCLNUyr9vmTQEAdg Bo9pj4H2SCvjqM
7rkoHUz8cVFdZ5PURNEKZ6y7T0/7xAAAAVL11NCOAAAEAwBHMEUCIQCKc7VKuFgM
RW3bUVUFZNlBxAh7GBZmK5MDQSe4twwewwIgPbZiWohxrz2Kme bNq2aXBL6hZL4Q
uDFi2mjHrB5Ddp0wDQYJKoZIhvcNAQELBQADggEBAAskbpaa0l zIpXoYRqemUzsd
SWnzfTEIanTIpuXUUfYdtKvcPlJ496f+W9eR2nNv0W3+iNIdYU Z9Kua0v6iOw+s/
kL81zFBlDELXRjzVmMr5z0qC3i61aCAwhpWwQcp9PtrnSObxCs 0I41oUoQt47H+L
KJfIQQCPxHRNC0Szv6Q61vXbrGRiGOIlZKGXfWGTY4mtzrQoWe zkL62uU1LCp2RM
yIu3hgHTT8rJEAnPrgsZtK34gteKhjrVQwBFki0ewUZoC2/wyxCUYRiEVl+St1Rv
Gi2Cz9WI6B5oycD+qMkWfjl4nMw3tREPxTX1mAQE9cvh5j+8b1 cjEV+rUCwhxyA=
-----END CERTIFICATE-----
subject=/C=NL/ST=Noord-Brabant/L=Veldhoven/O=HERE Global BV/CN=supl.nokia.com
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
---
No client certificate CA names sent
---
SSL handshake has read 5304 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 7B20D6346EE3595B55010B4DEAC1AF886A55CD48F0E7B38076 7E0D15B23F9DB0
Session-ID-ctx:
Master-Key: 3D9D14E0642329844E5FBDB5B0F95E915FB844C00A99BA1E70 BA66CD33D24C58B38D52035DA67960429BDA0399941711
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1486306958
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
So... it is really problem with certificates?
freemangordon
2017-02-05, 17:01
Anyway, on Ubuntu 12.04 verification to supl.nokia.com:7275 pass:
...
So... it is really problem with certificates?
Yes, it is problem with certificates, Ubuntu and Debian seem to provide outdated certs.
I found a different fix that doesn't need any patches to location-proxy.
The latest maemo-security-certman tree contains that fix which is now working just fine on the N900 sitting in front of me.
Nice fast GPS lock.
The fix involves putting the old insecure VeriSign certificate into a separate certificate store that location-proxy will load but that microb and other things wont.
This is with supl.nokia.com btw.
Yes, it is problem with certificates, Ubuntu and Debian seem to provide outdated certs.
Ah... thats not good.
I found a different fix that doesn't need any patches to location-proxy.
The latest maemo-security-certman tree contains that fix which is now working just fine on the N900 sitting in front of me.
Nice fast GPS lock.
The fix involves putting the old insecure VeriSign certificate into a separate certificate store that location-proxy will load but that microb and other things wont.
This is with supl.nokia.com btw.
How do you force location-proxy load certs from that new store?
location-proxy already has code in there that loads from the new store (added by Nokia for reasons unknown).
we might have reached the end. supl.nokia.com resolves to 127.0.0.1 at this time :-(
Google brought up this link showing the IP details for supl.nokia.com:
http://supl.nokia.com.ipaddress.com/
If I add 35.157.6.107 supl.nokia.com to /etc/hosts on my N900, it seems to work (nokia maps works and finds accurate location, location-test gets fast connection to satellite etc)
So until/unless the SUPL server running on the Amazon AWS instance answering at that IP address goes away, this should be a good short term fix.
That IP address is probably the best one to use since its the actual last known IP address of supl.nokia.com.
Going forward, maemo should run its own SUPL server as recently suggested by DocScrutinizer05 and freemangordon...
EDIT:
I found this other link
http://www.ip-tracker.org/locator/ip-lookup.php?ip=Supl.nokia.com
which lists an IP address of 52.22.201.16 (also an AWS instance)
along with https://www.robtex.com/dns-lookup/supl.nokia.com that lists a bunch of IP addresses.
The first one I found seems to work though so I will stick with it until something else happens (supl.nokia.com DNS returns a valid IP again, alternative SUPL server is set up or whatever)
EDIT 2:
Its possible the different IP addresses all point to different instances running the same SUPL code (i.e. distributing the load over multiple Amazon AWS instances) or something (I dont know how Amazon AWS works)
...
along with https://www.robtex.com/dns-lookup/supl.nokia.com that lists a bunch of IP addresses.
Via http://geoip.ubuntu.com/lookup/?ip=52.22.201.16 and the others listed in that bunch I got the following result:
35.157.6.107 : <TimeZone>Europe/Berlin
52.213.194.13 : <TimeZone>Europe/Dublin
52.220.245.140 : <TimeZone>Asia/Singapore
52.22.201.16 : <TimeZone>America/New_York
52.3.37.45 : <TimeZone>America/New_York
52.74.234.216 : <TimeZone>Asia/Singapore
54.171.105.63 : <TimeZone>Europe/Dublin
So everyone could set the one next to its main location in /etc/hosts with a new line like for example
52.22.201.16 supl.nokia.com
EDIT:
I can't ping none of the above except the one from Berlin 35.157.6.107 .
52.213.194.13 , 52.220.245.140 , 52.74.234.216 don't seem to answer supl requests. So the remaining list should be
35.157.6.107 : <TimeZone>Europe/Berlin
52.22.201.16 : <TimeZone>America/New_York
52.3.37.45 : <TimeZone>America/New_York
54.171.105.63 : <TimeZone>Europe/Dublin
No Asia anymore ...
EDIT 2:
And unfortunately the certificate for supl.nokia.com ist only valid until May 15 23:59:59 2017 GMT . Hope it will be renewed again ...
Cheers, Ulle
random_user
2017-04-25, 19:33
Hi,
I added into my /etc/hosts
52.3.37.45 supl.nokia.com
However, it doesn't work for me. If I try supl.google.com, GPS doesn't work too. Why?
I am just a common ubuntu user from Czech Rep., not Maemo expert.
Quick check:
~$ openssl s_client -connect 52.3.37.45:7275
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 Secure Server CA - G4
verify return:1
depth=0 C = NL, ST = Noord-Brabant, L = Veldhoven, O = HERE Global BV, CN = supl.nokia.com
verify return:1
---
Certificate chain
0 s:/C=NL/ST=Noord-Brabant/L=Veldhoven/O=HERE Global BV/CN=supl.nokia.com
i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGWzCCBUOgAwIBAgIQNUQLMS6rnzbNIfXt19aBADANBgkqhk iG9w0BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG 9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBA MTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE2MD IxODAwMDAwMFoX
.
.
.
How this issue can be easily fixed?
vBulletin® v3.8.8, Copyright ©2000-2025, vBulletin Solutions, Inc.