Server always returning -2

[peterpx]

Hey, I've compiled and run the program with no errors, but the program seems to always returning -2.
This is the setups I have tried so far:
I've set up a currect location with the SUPL_FAKE_POS env, and took the mcc,mnc,lat,cid from my modem which still returned -2.
I tried to play with the configuration in your example which result with the same "SUPL protocol error -2"

It seems that the problem is in supl_ulp_encode fucntion at the supl.c file.
the function at uper_encode_to_buffer returns -1. which in the end result in E_SUPL_ENCODE_START
(which is the -2 error)

[mypiandrew]

Hi

I found this

https://github.com/gnss-sdr/gnss-sdr/tree/master/src/core/libs/supl

Which looks like an updated set of files, but if I drop them in and compile them I just get segmentation fault

Shame, looked a really useful tool

[ZiglioUK]

I use gnss-sdr every day, that bit should compile

[mypiandrew]

I got it (eventually) to compile, I had to install asn1c libgnutls28-dev libssl-dev and edit this line in the make file

supl-client: libsupl.so supl-client.o
        $(CC) -o $@ supl-client.o -L. -lsupl -lssl -lm -lgnutls-openssl

...but even after that I just get "segmentation fault" when I run it.

So I'm missing something, my coding skills on Linux are not super so it may just be me. It's a bit beyond my ability to track down what's wrong and get it working unfortunately,

I just thought it was worth posting about the possibility of dragging over what looks like a newer set of files.

Perhaps someone with more "ninja skills" can look at it

[ZiglioUK]

Oh, that's progress anyway. I've never actually used SUPL in gnss-sdr because I always get to process datasets offline and SUPL is only for real time. Anyway, I did manage to use Google's own SUPL client in Java. That's somewhere here on GitHub

[tajuma]

This code would need some care and love, but anyway it should compile and run without adding gnutls-openssl or something to supl-client when using pre-compiled asn1 files. Newer distribution provided asn1c compiler may generate code that the tool is not prepared for.

Only option -t 0 and 3 actually work with supl.google.com, for others the server just closes the connection (or something).

I committed some small changes so that it should compile, even though it will throw some warnings that should be fixed (but as they come from the asn1c generated files it is a bigger task). At least this worked on my Ubuntu 20.10 (with all required -dev packages installed)

% git clone git@github.com:tajuma/supl.git
% cd supl
% ./configure --precompiled-asn1
% make -j8
% cd src
% LD_LIBRARY_PATH=$PWD ./supl-client -t 0
T 114 1997350 1623702170 28143
U 0 2 18 78 114 137 7 18
L 61.469364 23.820848 48
I 6 2 -1 41 6 -1 -8
E 11
e 2 13303 2055816642 -1592946287 1631982204 658441885 -1033968015 -22803 -83 173503667 -351 429 11614 -481 205 -27 9900 31 9900 -1315032 -26 0 1 0 0 -38 31
e 3 11727 1153036703 -1593004230 -1896552888 662963286 583636924 -21957 -189 30981025 -2774 4690 6922 -3123 -74 14 9900 15 9900 -412363 -94 0 1 0 0 4 31
e 4 12497 -1317870981 -1592927705 -1157932171 656290728 -2000897054 -21915 1031 10771475 -6 4785 6630 23 -54 15 9900 305 9900 -429180 -10 0 1 0 0 -9 31
e 6 12195 2008250910 -1592902005 1683896088 672696257 -660031206 -22939 -62 18442567 -755 1068 11331 -980 18 45 9900 105 9900 57938 41 0 1 1 0 9 31
e 7 13671 1460438933 -1592919447 -459484092 650434763 -1589962905 -22511 -469 129413379 -142 3431 8091 -42 -110 -137 9900 181 9900 382717 86 0 1 1 0 -24 31
e 9 13107 -615961187 -1592909617 -1192794965 651431311 1249025154 -22409 1051 16053441 -119 4838 6408 -101 -22 30 9900 55 9900 -753968 -17 0 1 0 0 3 31
e 16 11241 -298939060 -1592936568 312263619 665637531 465052360 -22068 -624 104663612 1496 5039 6593 1552 42 101 9900 32 9900 -732935 -53 0 1 0 0 -22 31
e 22 13804 -1609834415 -1592883534 -1964973870 639465301 -641706643 -22738 -288 60340211 -2828 4225 6769 -3235 -31 84 9900 75 9900 -1263717 85 0 1 0 0 -38 31
e 26 13303 300816890 -1593008592 220122091 643921977 210663208 -22731 -857 50589999 843 4964 6131 915 36 61 9900 77 9900 211294 42 0 1 0 0 15 31
e 29 11375 -834642184 -1592983401 1016377273 672412330 1488142375 -22121 725 16551824 2617 3305 8922 3057 -10 -14 9900 28 9900 -781980 -55 0 1 0 0 -21 31
e 31 13426 1075472801 -1593026419 -447776819 653389124 179843511 -22726 -745 86113701 149 3382 8279 55 -38 55 9899 28 9899 -264296 -19 0 1 0 0 -28 31

If you do get some weird errors, one option is to turn on all -enable-*-debug options in configure and then make clean all. Now it should spit out a ton of asn1 related en/decoding stuff, searching there for Fail would indicate where the asn1c en/decodig went wrong and maybe that would give some hints what to fix or change.

Hope this helps ;-)

[mypiandrew]

Wow, that's great work!

I still get an error when I follow your procedure mind you, so not entirely sure where the bug is there :-(

at+cops=0,2
OK
at+cops?
+COPS: 0,2,"23415",7

OK
at+creg=2
OK
at+creg?
+CREG: 2,1,FFFE,AE314

OK

MCC = 234
MCN = 15
LAC = 0xFFFE
CI = 0xAE314

root@raspberrypi:~# supl-client -f human  --cell=gsm:234,15:0xfffe,0xAE314
SUPL protocol error -2

But this at comes back with a result :

root@raspberrypi:~# supl-client -d 4 -f human  --cell=gsm:244,5:0x59e2,0x31b0
Reference Location:
  Lat: 61.469364
  Lon: 23.820848
  Uncertainty: 48 (960.2 m)
<snip>

[tajuma]

Buidling with configure --enable-asn1-debug (now it actually builds) and running your command supl-client --cell=gsm:234,15:0xfffe,0xAE314
will show ton of debug from asn1 encoding and near the end of there is

About to encode INTEGER (constr_SEQUENCE.c:1373)
Encoding GsmCellInformation->refCI (constr_SEQUENCE.c:1395)
Encoding NativeInteger INTEGER 713492 (UPER) (NativeInteger.c:282)
Value 713492 (0a/3) lb 0 ub 65535 ext (INTEGER.c:712)
Failed to encode element INTEGER (INTEGER.c:722)

That is, the value 713492 (i.e. 0xAE314) for CI is out of range. Nothing much to do here as in supl-common.asn it is declared as

GsmCellInformation ::= SEQUENCE {
  refMCC  INTEGER(0..999), -- Mobile Country Code
  refMNC  INTEGER(0..999), -- Mobile Network Code
  refLAC  INTEGER(0..65535), -- Location area code
  refCI   INTEGER(0..65535), -- Cell identity
  nMR     NMR OPTIONAL,
  tA      INTEGER(0..255) OPTIONAL, --Timing Advance
  ...}

But running it as ./supl-client --cell=wcdma:234,15,0xAE314 seem to work just fine.

[mypiandrew]

--cell=wcdma

Well don't I feel stupid..

Yes it's on a LTE cell of course!

Doh!

Thanks for your patience

[tajuma]

No worries ;-) Closing the ticket.

[artem78]

SUPL protocol error -2

Have the same problem. Is it fixed or not?