Stuck when using certificates

[lock2190]

Hello, i have a problem using CAM application with certificates in tools/socktap. I can correctly send CAM messages via the bin/socktapp-cam -i wlp1s0 --gpsd-port 2947 command, but i get stuck when i execute
bin/socktap-cam -i wlp1s0 --gpsd-port 2947 --certificate root.cert --certificate-key root.key or bin/socktap-cam -i wlp1s0 --gpsd-port 2947 --certificate aa.cert --certificate-key aa.key where certificates and keys were generated following this.

For what i could find, the program freezes in vanetza/common/manual_runtime.cpp at line 67: cb(deadline); the program does't actrually stop or crash, it's like it gets stuck in a loop.

Am i missing something? it's about a wrong usage from my side?

thank you in advance

[kelunik]

@lock2190 You need to use an authorization ticket to send CAMs, see https://github.com/riebl/vanetza/tree/master/tools/certify#generating-authorization-tickets

[riebl]

Either way, no callback invocation should freeze the program. @lock2190 can you identify which callback is blocking (e.g. using gdb "print cb" with breakpoint at manual_runtime.cpp:67)?

[lock2190]

Thank you @kelunik but i cannot see an option in socktap-cam to use the ticket created, how should i use it?

@riebl of course, i will now check which callback is causing the problem

many thanks

[kelunik]

@lock2190 With the --certificate and --certificate-key options you're already using.

[lock2190]

I've just tried, but it gets stuck anyways. I was wondering: do i actually need an infrastructure to send the secured CAM to? otherwise I cannot guess where the problem is, since i've re-cloned and re-built everything from scratch. I've also tried to catch the callback that freezes it all, but gdb seems to cannot find any symbol, even if i tried adding '-g' to CXX flags. Any suggestion?

[riebl]

Set CMAKE_BUILD_TYPE to "Debug" and rebuild socktap for debug symbols in the binaries.

[lock2190]

Thanks, now i can use gdb. Unfortunately, the output is not so easy to understand. This is the output of print cb:

$1 = {<std::_Maybe_unary_or_binary_function<void, std::chrono::time_point<vanetza::Clock, std::chrono::duration<long long, std::ratio<1ll, 1000000ll> > > >> = {<std::unary_function<std::chrono::time_point<vanetza::Clock, std::chrono::duration<long long, std::ratio<1ll, 1000000ll> > >, void>> = {<No data fields>}, <No data fields>}, <std::_Function_base> = {static _M_max_size = 8, static _M_max_align = 4, _M_functor = {_M_unused = { _M_object = 0x7effc4d8, _M_const_object = 0x7effc4d8, _M_function_pointer = 0x7effc4d8, _M_member_pointer = (void (std::_Undefined_class::*)(std::_Undefined_class * const)) 0x7effc4d8, this adjustment 1065345020}, _M_pod_data = "\330\304\377~\370\277\377~"}, _M_manager = 0x8fe37f <std::_Function_base::_Base_manager<vanetza::geonet::Router::reset_beacon_timer(vanetza::Clock::duration)::<lambda(vanetza::Clock::time_point)> >::_M_manager(std::_Any_data &, const std::_Any_data &, std::_Manager_operation)>}, _M_invoker = 0x8fe353 <std::_Function_handler<void(std::chrono::time_point<vanetza::Clock, std::chrono::duration<long long int, std::ratio<1ll, 1000000ll> > >), vanetza::geonet::Router::reset_beacon_timer(vanetza::Clock::duration)::<lambda(vanetza::Clock::time_point)> >::_M_invoke(const std::_Any_data &, <unknown type in /root/vanetza/bin/socktap-cam, CU 0x46dbca, DIE 0x50e4af>)>}

while attached there is a backtrace of the state when the program enters the infinite loop

Can you get any insight from this?

[lock2190]

Update: seems like the real loop is in list.tcc, the while(!empty) loop is never exited. May be that a sort of "popping" from the list is missing? or maybe a bug relative to that library version?

[riebl]

Hm, this infinite loop is entered when the list of header_fields is getting sorted. Which C++ compiler and version are you using? Does std::list::sort(cmp) behave well in other applications/a minimal working example?

[lock2190]

from g++ --version: g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

i've just tried a basic example (this one) and it works. I can try running vanetza on an Ubuntu 16.04 with g++ 5.4.0 (i wanted to avoid it since i'll be struggling with fake gps instead of a real one, but maybe it is worth a try)

UPDATE: with the ubuntu + g++ 5.4 setup everything is working fine. Do you think it is possible to find and fix the problem with g++ 6?

[riebl]

@lock2190 Do I understand you correctly that mylist.sort(compare_nocase) from the referenced example does work on your system with g++ 6?

[lock2190]

correct, it works perfectly

[riebl]

Honestly speaking, I don't know what is going wrong here. You may try to remove lines 62 to 67 from sign_header_policy.cpp and see if the program is still stuck in an infinite loop then. If this cures your problem I might have an idea how to sort the header fields correctly again.

[lock2190]

I commented out those lines and the program still gets stuck, but if i comment out the whole sort block (lines 57 to 72) it runs. Unexpectedly, packets sent are also recognized by wireshark as regular secured CAM, but it may be that headers are just casually in the right order. Do you think it is possible to use a custom sort function instead of using std::list::sort?

[riebl]

std::list::sort with a passed compare function is already a custom sort function. I am reluctant to replace this by something else as long as I don't know why it is failing. std::sort is no option for std::list as it requires random access iterators for sorting.

One possible solution could be the definition of < operator for HeaderField. Then you can simply call header_fields.sort() in sign_header_policy.cpp. If you are willing to give this a try you can move the sort lamba function (lines 58 to 71) to header_field.hpp and transform it to a free-standing function inline bool operator<(const HeaderField& a, const HeaderField& b) { ... lines from lambda function ... }.

[riebl]

Update: It turns out that boost::variant<> provides operator< on its own, i.e. HeaderField also already has this operator. Maybe std::list::sort(cmp) still uses this operator in some cases though it should only use the passed cmp function.

[lock2190]

One possible solution could be the definition of < operator for HeaderField

It worked!

Update: It turns out that boost::variant<> provides operator< on its own, i.e. HeaderField also already has this operator. Maybe std::list::sort(cmp) still uses this operator in some cases though it should only use the passed cmp function.

this is such a strange behavior, but the redefinition of '<' operator seem to override that, so problem solved, i guess :)

[riebl]

@lock2190 Okay, my compiler complained about two candidates regarding operator<… that's really odd.

[lock2190]

Now that i think about it, i had some struggles at the beginning because cmake couldn't find boost libraries. It could be that at the end it didn't include every library i actually needed and then didn't use boost::variant<> as in your project. I'll try to make some test eventually