The Following 15 Users Say Thank You to Ulle For This Useful Post: | ||
|
2013-08-27
, 20:53
|
Posts: 1,378 |
Thanked: 1,604 times |
Joined on Jun 2010
@ Göteborg, Sweden
|
#102
|
|
2013-08-27
, 23:48
|
Posts: 3 |
Thanked: 10 times |
Joined on Feb 2011
|
#103
|
The Following User Says Thank You to LjL For This Useful Post: | ||
|
2013-08-28
, 07:05
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#104
|
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)
The Following 4 Users Say Thank You to freemangordon For This Useful Post: | ||
|
2013-08-28
, 07:10
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#105
|
|
2013-08-28
, 07:19
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#106
|
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?
|
2013-08-28
, 07:34
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#107
|
The Following 2 Users Say Thank You to peterleinchen For This Useful Post: | ||
|
2013-08-28
, 07:40
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#108
|
...
So that means we have all needed certs aboard, but mabe they are not used or ... ?
|
2013-08-28
, 07:54
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#109
|
|
2013-08-28
, 08:03
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#110
|
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):
Checking the chain:
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