SSL connection to NTRIP Caster

[cjmssmd]

Issue details

Mission planner should support SSL connections to NTRIP casters.. For example https://cddis-caster.gsfc.nasa.gov:443 mountpoint GODR2

Contact me @cjmssmd on gitter.im for my credentials to test against that server.

There should probably be some consideration for the SSL certificates; I'm not an expert on the best practice about how to handle them.

p.s. In case it helps, I can connect using Mission Planner to that server using stunnel to create a local (non-SSL) port that connects to that SSL port. The stunnel configuration file I use is: [ntrip] client = yes accept = 127.0.0.1:8080 connect = cddis-caster.gsfc.nasa.gov:443 verifyChain = yes CAfile = ca-certs.pem checkHost = cddis-caster.gsfc.nasa.gov OCSPaia = yes

Version

1.3.70

Platform

[X] All [ ] AntennaTracker [ ] Copter [ ] Plane [ ] Rover [ ] Sub

Airframe type

N/A, doesn't matter

Hardware type

N/A, doesn't matter

Logs

Not applicable

[meee1]

please try the latest beta MP. it should now support a https url

[cjmssmd]

When I connect via https:

Mission planner seems to receive bytes, and a few messages (CAN? I can't see because the text is chopped off...) but doesn't receive all of the messages:

[cjmssmd]

I know that the cddis caster is working, because if I use the same version of mission planner to connect via non-https, i.e. regular sockets (using the method listed above, i.e. a local stunnel 'proxy' port that itself connects to the cddis-caster via SSL) everything works fine.

[meee1]

looks like the mountpoint you picked is RT17 not RTCM. hence Missionplanner does not display stats about it. please try a RTCM mountpoint.

[meee1]

i think i might have been reading that wrong one STR;GODR2;GGAO;RTCM 3.2;1077(1),1087(1),1097(1),1127(1),1006(10),1008(10),1013(10),1033(10),1230(10),1019(30),1020(30),1042(300),1044(300),1045(300),1046(300);2;GPS+GLONASS+GALILEO+BEIDOU;0;USA;39.02;-76.83;0;0;Trimble NetR9;none;B;N;10100;38.98.58.90:2101/GODR2(1)

[meee1]

i found the bug. and new beta in about 20 mins

[cjmssmd]

I tested and it worked successfully. Thanks and congratulations on a terrific application!

[meee1]

Thanks, and glad its working now. ill close this.

[cjmssmd]

Michael I, together with Andrew Tridge, am debugging what I think is a bug in the python rtcm3 parser in mavproxy. The CRC24 that's calculated by the python code doesn't match the CRC24 in the data stream for about 60% of the messages. For example this binary file (captured from the same caster) gives the following output when run through the python rtcm3 parser: "C:\Users\Chris Milner\PycharmProjects\MAVProxy\MAVProxy\venv\Scripts\python.exe" "C:/Users/Chris Milner/PycharmProjects/MAVProxy/MAVProxy/modules/lib/rtcm3_orig.py" --debug "C:\Users\Chris Milner\Documents\RTCM3\bnc.txt_200110" packet len 287 ID 1087 crc fail len=253 crc fail len=403 packet len 287 ID 1087 crc fail len=253 packet len 51 ID 1013 crc fail len=438 crc fail len=21 crc fail len=769 packet len 287 ID 1087

bnc.zip

Would it be hard for you to run that binary file through the c++ RTCM3 parser in mission planner, and print out for each message, the message ID, the message length, the calculated CRC24?

[meee1]

the file you posted appears to have non rtcm data in it. plain text timestamp data. so is not a good log to test against.

check your missionplanner log folder. all gps inject data is saved in files with the date/time and extension gpsdata