RPi5: Send to peer misses some curl dependencies?
Hakansv opened this issue · comments
Describe the bug
RPi5, Debian, bookworm, X11. (No similar error on RPi4 bullseye)
Send to peer creates an error:
"Curl transfer error. SSL Connect error"
To Reproduce
Steps to reproduce the behavior:
- Install dependencies as of "INSTALL"
- Build and install OCPN from current master.
- Run
- Create a WP. "Send to peer"
- Use one of listed O around - Send
- The error occur.
- Click "Cancel" to exit the error message. "Ok" gives the error again.
- Note. No problem to send to RPi5 from another client.
Expected behavior
No error but "Transfer complete"
Screenshots
See below.
Desktop (please complete the following information if applicable):
- OS: Linux rpi5 6.6.20+rpt-rpi-2712 1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux
More
All servers around are nicely found.
Opened 2 sockets for mDNS query
Sending mDNS query : opencpn-object-control-service PTR
Reading mDNS query replies
192.168.1.87:5353 : answer opencpn-object-control-service. PTR rpi5.opencpn-object-control-service. rclass 0x1 ttl 10 length 7
192.168.1.180:5353 : answer opencpn-object-control-service. PTR HAS-LENO.opencpn-object-control-service. rclass 0x1 ttl 10 length 11
192.168.1.154:5353 : answer opencpn-object-control-service. PTR RPi400.opencpn-object-control-service. rclass 0x1 ttl 10 length 9
192.168.1.67:5353 : answer opencpn-object-control-service. PTR HAS-WIN.opencpn-object-control-service. rclass 0x1 ttl 10 length 10
Read 16 records
Closed sockets
I cannot see missing dependencies in this, all tools are found and linkage is ok.
Have you been able to run curl from the RPI-5 command line as discussed in zulip.to check if this is about the server of the rpi-5 client?
Also, have you checked that the clocks are synchronized i. e., that both server and client has the same idea of current date and time?
Result from test:
rpi5@rpi5:~/builds/OpenCPN/build $ curl --insecure https://192.168.1.67:8443/api/get-version
{ "version": "5.9.0.12" }
(...1.67 is a Win OCPN.
Time:
There's a diff by 3 seconds but I didn't manage to do it simultaneously so I think that's ok.
C:\Builds\OCPN\OpenCPN>date
The current date is: 2024-03-17
Enter the new date: (yy-mm-dd)
C:\Builds\OCPN\OpenCPN>time
The current time is: 19:12:05,04
rpi5@rpi5:~/builds/OpenCPN/build $ date
Sun Mar 17 07:12:08 PM CET 2024
OK, we know that the overall curl connectivity is ok. next step would be to patch the sources and/or run in the debugger.
If you single step through the function SendNavobjects()
in peer_client.cpp around line 443, at which line does it fail? In particular, does it pass GetApiKey()
without errors?
Hmm. Debug by gdb is not done before. First try is in attached file.
If of any help I can't say but please have a look.
It's though clear the status response on row 270 is not 200 but -35
dbg_send_to_peer.txt
Sorry for not being able to follow up yesterday, real life required some attention.
My idea was that as a starter , we should follow the flow in SendNavobjects()
, from your log above it's hard to say in what context you executed GetApiUrl() etc. So, in more detail:
- Put a breakpoint at the SendNavobjects function using break SendNavobjects.
- Start opencpn: run
- Initiate the transfer. This should trigger the breakpoint at peer_client.cpp around line 438
- Use next or n to single step through this function line by line until line 449 which reads
bool apikey_ok = GetApiKey(peer_data, api_key);
- Use next again to single step to next line. Print the value of apikey_ok using print apikey_ok.
- If it is false, we are done in the first step; please report back
- If it is true continue using next and check whether the
peer_data.api_version < SemanticVersion(5, 9) && peer_data.activate)
is true. If true (lines 452 and 453 are executed) , print peer_data usingprint peer_data
and report back. - Continue to the last
return true
line using next and report back.
This should give us the overall understanding about what's going on before diving into ApiGetUrl().
Don't be sorry. It was late and we are truly appreciating your efforts whenever available. "Real life"? Family and food are real and OCPN virtual? Sounds like a healthy prioritization. :)
Thanks for the detailed instructions. I'll come back. Some "real" tasks like wood to split first.
@leamas What I can find out apikey_ok is false at row 449.
Breakpoint 2 at 0x555555c9cba0: file /home/rpi5/builds/OpenCPN/model/src/peer_client.cpp, line 449.
(gdb) n
448 std::string api_key;
(gdb) print apikey_ok
$2 = <optimized out>
(gdb) n
Thread 1 "opencpn" hit Breakpoint 2, std::char_traits<char>::assign (__c2=<optimized out>, __c1=<optimized out>)
at /home/rpi5/builds/OpenCPN/model/src/peer_client.cpp:449
449 bool apikey_ok = GetApiKey(peer_data, api_key);
(gdb) print apikey_ok
No symbol "apikey_ok" in current context.
(gdb) step
[New Thread 0x7fffbef7aa80 (LWP 22413)]
[Thread 0x7fffbef7aa80 (LWP 22413) exited]
GetApiKey (peer_data=..., key="") at /home/rpi5/builds/OpenCPN/model/src/peer_client.cpp:259
259 std::string api_key;
(gdb) n
83 __new_allocator(const __new_allocator&) _GLIBCXX_USE_NOEXCEPT { }
(gdb) n
[New Thread 0x7fffbef7aa80 (LWP 22417)]
[Thread 0x7fffbef7aa80 (LWP 22417) exited]
260 if (peer_data.api_version == SemanticVersion(0, 0)) GetApiVersion(peer_data);
ah... you need to rebuild with CMAKE_BUILD_TYPE=Debug. Sigh. But to make meaningful debugging there no usable work around.
Can't say it's much clearer?
Thread 1 "opencpn" hit Breakpoint 1, SendNavobjects (peer_data=...) at /usr/include/c++/12/bits/stl_iterator.h:1072
1072 __normal_iterator(const _Iterator& __i) _GLIBCXX_NOEXCEPT
(gdb) n
448 std::string api_key;
(gdb) step
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7fffffff9138)
at /usr/include/c++/12/bits/basic_string.h:517
517 : _M_dataplus(_M_local_data())
(gdb) n
448 std::string api_key;
(gdb) step
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (this=0x7fffffff9138)
at /usr/include/c++/12/bits/basic_string.h:517
517 : _M_dataplus(_M_local_data())
(gdb) n
520 _M_set_length(0);
(gdb) n >>>>>>>>>>>>>>> Here I got the "Curl transfer error message
450 if (!apikey_ok) return false;
(gdb) print api_key
$3 = ""
OK, as I suspected.
Now, repeat steps 1..3 in a fresh gdb session. Then set a breakpoint at peer_client.cpp:159 which reads CURLcode result = curl_easy_perform(c);
using break peer_client.cpp:159
Then continue execution using continue. This should bring you to the ApiGet() function. When there, print the url (print url)
Then, in another terminal window use command line curl to get the same url. That is, use curl --insecure <url> where <url> is the same url as printed by print url in gdb above. Please report back the url and the result from the command line curl command
There's no break at peer_client.cpp:159
Before that I get the "Curl transfer errror..." and it stops there.
Weird... It should not be possible, line 159 contains the call which triggers the error: CURLcode result = curl_easy_perform(c);
What if you put the breakpoint at the ApiGet function instead: break ApiGet instead of break peer_client.cpp:159 ?
Yes, hit!
But no curl problem with that url:
Thread 1 "opencpn" hit Breakpoint 2, ApiGet (url="https://192.168.1.154:8443/api/get-version", chunk=chunk@entry=0x7fffffff9290,
timeout=timeout@entry=2) at /home/rpi5/builds/OpenCPN/model/src/peer_client.cpp:148
148 int response_code = -1;
rpi5@rpi5:~ $ curl --insecure https://192.168.1.154:8443/api/get-version
{ "version": "5.9.0.12" }
rpi5@rpi5:~ $
And from above break this until Curl error:
dbg_send_to_peer.txt
As you can see I'm a bit lost here. We need to arrange so I can run this myself. Please stay tuned.
-> zulip PM