Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for serial UART and local domain socket protocolInterfaces #150

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from

Conversation

lhoward
Copy link

@lhoward lhoward commented Apr 5, 2024

WIP – support for serial UART and local domain socket protocolInterfaces

@lhoward lhoward force-pushed the serial-local-pi branch 2 times, most recently from 5e1a15c to dcfb508 Compare April 5, 2024 10:51
include/la/avdecc/internals/protocolInterface.hpp Outdated Show resolved Hide resolved
CMakeLists.txt Outdated
@@ -30,6 +30,10 @@ option(BUILD_AVDECC_INTERFACE_PCAP_DYNAMIC_LINKING "Pcap protocol interface uses
option(BUILD_AVDECC_INTERFACE_MAC "Build the macOS native protocol interface (macOS only)." TRUE)
option(BUILD_AVDECC_INTERFACE_PROXY "Build the proxy protocol interface." FALSE)
option(BUILD_AVDECC_INTERFACE_VIRTUAL "Build the virtual protocol interface (for unit tests)." TRUE)
if(NOT WIN32)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's best to hide the options for Windows, or always expose the option and filter out windows a little bit down in the file (where other PI checks are done), with auto-disable on windows + message maybe.

I'm afraid of getting cmake errors if passing an option that do not exist on windows (vs auto-disable for unsupported platforms). Actually maybe it can be supported on windows later as well (at least the unix socket)

include/la/avdecc/internals/protocolInterface.hpp Outdated Show resolved Hide resolved
include/la/avdecc/internals/typedefs.h Outdated Show resolved Hide resolved
src/CMakeLists.txt Show resolved Hide resolved
@lhoward lhoward force-pushed the serial-local-pi branch 2 times, most recently from 5a10187 to c3f021a Compare April 5, 2024 21:12
@lhoward lhoward marked this pull request as ready for review April 10, 2024 07:37
@lhoward
Copy link
Author

lhoward commented Apr 30, 2024

I am seeing an assertion failure – no doubt this is triggered by a hardware or far-end issue, but I'm not sure if it should be assert failing when a malformed packet is received, as this could be a DoS issue even with Ethernet? Are asserts only enabled in debug builds?

File: /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/src/protocol/protocolAdpdu.cpp
Line: 77

	Adpdu::deserialize error: Not enough data in buffer

💣 Program crashed: Aborted at 0x000003e80004c347

Thread 0 crashed:

 0 0x0000ffff84fa53f8 __pthread_kill_implementation + 312 in libc.so.6
 1 0x0000ffff84f5b6ac gsignal + 27 in libc.so.6
 2 0x0000ffff84f46ec0 abort + 243 in libc.so.6
 3 la::avdecc::utils::displayAssertDialog(char const*, unsigned int, char const*, std::__va_list) + 623 in libla_avdecc_cxx-d.so.4.0.0.11 at /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/src/utils.cpp:302:3
 4 bool la::avdecc::utils::avdeccAssert<bool>(char const*, unsigned int, bool, char const*, ...) + 199 in libla_avdecc_cxx-d.so.4.0.0.11 at /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/include/la/avdecc/utils.hpp:96:4
 5 la::avdecc::protocol::Adpdu::deserialize(la::avdecc::Deserializer&) + 91 in libla_avdecc_cxx-d.so.4.0.0.11 at /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/src/protocol/protocolAdpdu.cpp:77:7
 6 void la::avdecc::protocol::deserialize<la::avdecc::protocol::Adpdu, la::avdecc::Deserializer&>(la::avdecc::protocol::EtherLayer2*, la::avdecc::Deserializer&) + 31 in libla_avdecc_cxx-d.so.4.0.0.11 at /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/include/la/avdecc/internals/protocolAvtpdu.hpp:278:34
 7 la::avdecc::protocol::EthernetPacketDispatcher<la::avdecc::protocol::ProtocolInterfaceSerialImpl>::dispatchAvdeccMessage(unsigned char const*, unsigned long, la::avdecc::protocol::EtherLayer2 const&) const + 363 in libla_avdecc_cxx-d.so.4.0.0.11 at /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/src/protocolInterface/ethernetPacketDispatch.hpp:81:6
 8 la::avdecc::protocol::ProtocolInterfaceSerialImpl::processRawPacket(la::avdecc::MemoryBuffer&&) const::{lambda()#1}::operator()() const + 291 in libla_avdecc_cxx-d.so.4.0.0.11 at /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/src/protocolInterface/protocolInterface_serial.cpp:601:32
 9 void std::__invoke_impl<void, la::avdecc::protocol::ProtocolInterfaceSerialImpl::processRawPacket(la::avdecc::MemoryBuffer&&) const::{lambda()#1}&>(std::__invoke_other, la::avdecc::protocol::ProtocolInterfaceSerialImpl::processRawPacket(la::avdecc::MemoryBuffer&&) const::{lambda()#1}&) + 27 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:61:14
10 std::enable_if<is_invocable_r_v<void, la::avdecc::protocol::ProtocolInterfaceSerialImpl::processRawPacket(la::avdecc::MemoryBuffer&&) const::{lambda()#1}&>, void>::type std::__invoke_r<void, la::avdecc::protocol::ProtocolInterfaceSerialImpl::processRawPacket(la::avdecc::MemoryBuffer&&) const::{lambda()#1}&>(la::avdecc::protocol::ProtocolInterfaceSerialImpl::processRawPacket(la::avdecc::MemoryBuffer&&) const::{lambda()#1}&) + 27 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:111:2
11 std::_Function_handler<void (), la::avdecc::protocol::ProtocolInterfaceSerialImpl::processRawPacket(la::avdecc::MemoryBuffer&&) const::{lambda()#1}>::_M_invoke(std::_Any_data const&) + 27 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/std_function.h:290:9
12 std::function<void ()>::operator()() const + 51 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/std_function.h:590:9
13 la::avdecc::utils::closure_traits<std::remove_reference<std::function<void ()> const&>::type>::result_type la::avdecc::utils::invokeProtectedHandler<std::function<void ()> const&>(std::function<void ()> const&) + 39 in libla_avdecc_cxx-d.so.4.0.0.11 at /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/include/la/avdecc/utils.hpp:925:5
14 la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}::operator()() const + 567 in libla_avdecc_cxx-d.so.4.0.0.11 at /home/lukeh/CVSRoot/padl/inferno/control/AVDECCSwift/Sources/CAVDECC/avdecc/src/executor.cpp:161:8
15 void std::__invoke_impl<void, la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}>(std::__invoke_other, la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}&&) + 27 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:61:14
16 std::__invoke_result<la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}>::type std::__invoke<la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}>(la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}&&) + 27 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:96:14
17 void std::thread::_Invoker<std::tuple<la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) + 31 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/std_thread.h:259:13
18 std::thread::_Invoker<std::tuple<la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}> >::operator()() + 27 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/std_thread.h:266:11
19 std::thread::_State_impl<std::thread::_Invoker<std::tuple<la::avdecc::ExecutorWithDispatchQueueImpl::ExecutorWithDispatchQueueImpl(std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, la::avdecc::utils::ThreadPriority)::{lambda()#1}> > >::_M_run() + 27 in libla_avdecc_cxx-d.so.4.0.0.11 at /usr/lib/gcc/aarch64-linux-gnu/11/../../../../include/c++/11/bits/std_thread.h:211:13
20 0x0000ffff853eb1cc <unknown> in libstdc++.so.6.0.32
21 0x0000ffff84fa37d0 start_thread + 703 in libc.so.6

@christophe-calmejane
Copy link
Contributor

Hi Like,
Yes they are only going to abort in DEBUG build. But you are right nonetheless that some asserts in the code might be changed to message only, especially this one that is already protected anyway by a fallback in RELEASE build.

FYI, I'll soon be merging your branches, so if you have fixes to push now would be a good time ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants