covesa / capicxx-someip-runtime Goto Github PK

According to the documentation, a negative wait time means that the request should wait indefinitely for the response:

typedef int Timeout_t; // in ms, -1 means "forever"

However, it looks like a negative value is ignored in https://github.com/COVESA/capicxx-someip-runtime/blob/master/src/CommonAPI/SomeIP/Connection.cpp#L593 and in https://github.com/COVESA/capicxx-someip-runtime/blob/master/src/CommonAPI/SomeIP/Connection.cpp#L606 sendAndBlockCondition_ waits for a time_point in the past.

[Issue copied from capicxx-someip-tools#49 - I will close it there if this is a better place for it]

I have a method defined in .fidl that works OK, taking a UInt32 input parameter and returning a 4 byte data structure, e.g.

SOME/IP Protocol (Service ID: 0x433f, Method ID: 0x0103, Length: 12)
    Service ID: 0x433f
    Method ID: 0x0103
    Length: 12
    Client ID: 0x0000
    Session ID: 0x0001
    SOME/IP Version: 0x01
    Interface Version: 0x01
    Message Type: 0x80 (Response)
    Return Code: 0x00 (Ok)
    Payload: 00000000

I now want to do extend my code to do some validity checking on the input parameter and insert a non-zero return code into the SOME/IP reply header if the checking fails.

I have naiively added an error clause to my .fidl and updated my implementation to fill in the error code, but all that seems to do is to insert my error code byte into the start of the data, i.e. returning 5 bytes of user data instead of 4 bytes.

SOME/IP Protocol (Service ID: 0x433f, Method ID: 0x0103, Length: 13)
    Service ID: 0x433f
    Method ID: 0x0103
    Length: 13        <--- Was 12
    Client ID: 0x0000
    Session ID: 0x0001
    SOME/IP Version: 0x01
    Interface Version: 0x01
    Message Type: 0x80 (Response)
    Return Code: 0x00 (Ok)   <--- Not what I want
    Payload: 3000000000

Note the change to the Length field and the extra "30" byte at the start of the data.

Here is my method specification with the new error section:

package commonapi.examples

interface Test {

  version {major 1 minor 0}

  enumeration eErrorCode {
    E_NO_ERROR=0x00                     /* No error */
    E_INVALID_INDEX=0x30                /* The requested index is out of range. */
  }

  struct sData {
    UInt32          Data1
  }

  method getData {
    in {
        UInt32 dataIndex
    }
    out {
        sData data
    }
    error eErrorCode
  }
}

My stub implementation is as follows:

#include "TestStubImpl.hpp"
#include <v1/commonapi/examples/Test.hpp>

using namespace v1::commonapi::examples;

TestStubImpl::TestStubImpl()
{
}

TestStubImpl::~TestStubImpl()
{
}

void TestStubImpl::getData(const std::shared_ptr<CommonAPI::ClientId> _client,
                                                uint32_t _dataIndex,
                                                getDataReply_t _reply)
{
    (void)_client;
    Test::eErrorCode error = Test::eErrorCode::E_INVALID_INDEX;
    Test::sData data = {};

    if (_dataIndex == 0UL)
    {
        error = Test::eErrorCode::E_NO_ERROR;
    }
    _reply(error, data);
}

In CommonAPI-SOMEIP_deployment_spec.fdepl I can see that SomeIpErrorCoding defaults to 'Header', but there does not appear to be another option - I don't know if that is relevant to this issue.

It looks to me like either I am missing a call into the SOME/IP stack to tell it that there has been an error, or alternatively that I am missing some configuration that tells the SOME/IP stack that the stub implementation of this method is providing the return code.

[Edited to display complete .fidl file, to show trace outputs straight from WireShark and to include stub implementation.]

Any ideas?

Are there plans to update this project for vsomeip3?

The following errors appear when I try to compile:

/home/gabriel/git/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp: In member function ‘virtual bool CommonAPI::SomeIP::ClientId::operator==(CommonAPI::ClientId&)’:
/home/gabriel/git/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:35:95: **error**: invalid cast to abstract class type ‘CommonAPI::SomeIP::ClientId’
         ClientId clientIdToCompareSomeIp = ClientId(dynamic_cast<ClientId&>(clientIdToCompare));
                                                                                               ^
In file included from /home/gabriel/git/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:8:0:
/home/gabriel/git/capicxx-someip-runtime/include/CommonAPI/SomeIP/ClientId.hpp:29:39: note:   because the following virtual functions are pure within ‘CommonAPI::SomeIP::ClientId’:
 class COMMONAPI_EXPORT_CLASS_EXPLICIT ClientId : public CommonAPI::ClientId{
                                       ^~~~~~~~
In file included from /home/gabriel/git/capicxx-someip-runtime/include/CommonAPI/SomeIP/ClientId.hpp:16:0,
                 from /home/gabriel/git/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:8:
/home/gabriel/git/ascgit017.CommonAPI/include/CommonAPI/Types.hpp:112:25: note: 	virtual std::__cxx11::string CommonAPI::ClientId::getEnv() const
     virtual std::string getEnv() const = 0;
                         ^~~~~~
/home/gabriel/git/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:35:18: **error**: cannot declare variable ‘clientIdToCompareSomeIp’ to be of abstract type ‘CommonAPI::SomeIP::ClientId’
         ClientId clientIdToCompareSomeIp = ClientId(dynamic_cast<ClientId&>(clientIdToCompare));
                  ^~~~~~~~~~~~~~~~~~~~~~~
CMakeFiles/CommonAPI-SomeIP.dir/build.make:107: recipe for target 'CMakeFiles/CommonAPI-SomeIP.dir/src/CommonAPI/SomeIP/ClientId.cpp.o' failed
make[2]: *** [CMakeFiles/CommonAPI-SomeIP.dir/src/CommonAPI/SomeIP/ClientId.cpp.o] Error 1
CMakeFiles/Makefile2:122: recipe for target 'CMakeFiles/CommonAPI-SomeIP.dir/all' failed
make[1]: *** [CMakeFiles/CommonAPI-SomeIP.dir/all] Error 2
Makefile:148: recipe for target 'all' failed
make: *** [all] Error 2

Hi,

Currrently, I am using the helloworld application from the commonapi-someip wiki page. With that application I tested in both Linux and Windows locally it was working. Now, my next stage is to run the client in Windows and the service in the Linux. Currently, the service application is using the below configuration.

helloworld-service.json (in Linux):

{
"unicast":"192.168.56.107",
"logging":
{
    "level":"debug",
    "console":"true",
            "file":{"enable":"true", "path":"/tmp/vsomeip.log"},
            "dlt":"false"
},

"applications":
[
    {
        "name":"HelloWorldService",
        "id":"0x1277"
    }
],

"services":
[
    {
        "service":"0x1234",
        "instance":"0x5678",
        "reliable" : { "port" : "30509", "enable-magic-cookies" : "false" }
    }
],

"routing":"HelloWorldService",
"service-discovery":
{
    "enable":"true",
    "multicast":"224.0.0.1",
    "port":"30490",
    "protocol":"udp"
}
}

This is my helloworld-client.json (in Windows):

{
"unicast":"192.168.56.1",
"netmask":"255.255.255.0",
"logging":
{
    "level":"debug",
    "console":"true",
	"file":{"enable":"true", "path":"vsomeip.log"},
	"dlt":"false"
},

"applications":
[
    {
        "name":"HelloWorldClient",
        "id":"0x1343"
    }
],
"clients" :
[
    {
        "service" : "0x1234",
        "instance" : "0x5678",
        "reliable" : "30509"
    }
],
"routing":"HelloWorldClient",
"service-discovery":
{
    "enable":"true",
	"multicast":"224.0.0.1",
	"port":"30490",
	"protocol":"udp"
}
}

At the moment, the client is able to detect the service but its not able to get the message from the service. In this case it should print out "Got message: 'Bob'". But for me it showing "Got message: ' ' ". And over at the client side it shows as:

2020-08-19 12:15:45.517289 [info] vSomeIP 2.14.16 | (default)
Available...
2020-08-19 12:15:48.836873 [error] Routing info for remote service could not be found! (1343): [1234.5678.007b] 0001
Got message:
Got Status: 4
2020-08-19 12:15:53.837955 [info] RELEASE(1343): [1234.5678]

Can someone guide me through this process. Is the configuration is wrong ? How can I run client in windows and service in Linux separately. Both are using the same address range.

Following the latest update (d346e0f) the compilation does not work on windows (msvc 2019)
I got compilation errors on include/CommonAPI/SomeIP/OutputStream.hpp (_BYTE_ORDER not defined)
d346e0f#diff-4c81b6e7390e799245076afd2b9125066fb6b2c4f727949f4bc5cc46f633c0bfR570-R595

For some reason, code has been factorised and is now not compiling.
gcc seems to allow usage of compiler definition in normal if/else condition, but msvc does not allow it.

The compilation works fine after reverting lines 570-595 of OutputStream.hpp (same functional behaviour)

I have a attribute in service，i want to decide whether the client can use get of Attribute according to the conditions,
If the conditions are not met, then ignore get of Attribute from client; if the conditions are met,
the return get value of attribute to client 。
But，see generate code:
COMMONAPI_EXPORT virtual const int32_t &getXAttribute(const std::shared_ptrCommonAPI::ClientId _client) {
(void)_client;
return getXAttribute();
}
it must return value No matter condition。
What should I do?

I try to build the latest version and got the following error,

I followed the instructions given in SOMEIP in 10 (https://genivi-oss.atlassian.net/wiki/spaces/COMMONAPICPP/pages/5472320/CommonAPI+C+SOME+IP+in+10+minutes) and it is working fine on one machine.
But it is not working when I am trying to do it on two ubuntu machines.
I used the same json files as in the tutorial with unicast changed according to my machines.
Routing information has been added：
sudo route add -host 224.244.224.245 dev eth1

Please change the link
[https://genivi.github.io/capicxx-core-tools/]
to
[https://genivi.github.io/capicxx-someip-tools/]

It cost me a long time to find the built binary someip code generator in this repository,
and finally I tried to change the address manually and succeeded.

Hi,
There are no steps for QNX compilation. I'd like to know if there is going to be support for compilation of this library in qnx?

Since currently there are no steps for compilation for QNX, I made a common.mk file and Makefile, and added vsomeip's .so files (https://github.com/COVESA/vsomeip) and capicxx-core-runtime's .so file( https://github.com/COVESA/capicxx-core-runtime) as its dependencies in the common.mk. BTW I was able to compile vsomeip and capicxx-core-runtime in QNX.

1)

When I compiled it, at first I got these several similar types of errors:

capicxx-someip-runtime/include/CommonAPI/SomeIP/OutputStream.hpp:571:18: error: '__BYTE_ORDER' was not declared in this scope
             if ((__BYTE_ORDER == __LITTLE_ENDIAN) != isLittleEndian_) {
                  ^~~~~~~~~~~~
/home/saurabh.m22/project/cccmx/sources/qnx/kernel/src/hardware/camera/capicxx-someip-runtime/include/CommonAPI/SomeIP/OutputStream.hpp:571:34: error: '__LITTLE_ENDIAN' was not declared in this scope
             if ((__BYTE_ORDER == __LITTLE_ENDIAN) != isLittleEndian_) {
                                              ^~~~~~~~~~~~~~~

I resolved these by replacing "BYTE_ORDER " in place of "__BYTE_ORDER" and "ORDER_LITTLE_ENDIAN " in place of "__LITTLE_ENDIAN".

2)

Next, now that I compile this library, I get the error:

capicxx-someip-runtime/src/CommonAPI/SomeIP/Watch.cpp:19:10: fatal error: sys/eventfd.h: No such file or directory
 #include <sys/eventfd.h>
          ^~~~~~~~~~~~~~~
compilation terminated.

This eventfd seems to be linux specific package. Any clue how to circumvent this error for successful compilation in QNX?

P.S. - I need the compilation to be successful for arm architecture and not for x86.

Hi, I am not able to compile the commonapi-someip-runtime library.
This is my current setup:

VM: Apertis Pro
vsomeip: 3.1.7.1
commonapi-runtime: 3.2.0

When I tried to execute the make command after cmake, it shows error in the Types.hpp

capicxx-someip-runtime-3.2.0/include/CommonAPI/SomeIP/Types.hpp:37:18: error: ‘event_type_e’ in namespace ‘vsomeip’ does not name a type
typedef vsomeip::event_type_e event_type_e;
^~~~~~~~~~~~
capicxx-someip-runtime-3.2.0/include/CommonAPI/SomeIP/Types.hpp:37:9: note: suggested alternative: ‘offer_type_e’
typedef vsomeip::event_type_e event_type_e;
^~~~~~~
offer_type_e
capicxx-someip-runtime-3.2.0/include/CommonAPI/SomeIP/Types.hpp:38:18: error: ‘reliability_type_e’ in namespace ‘vsomeip’ does not name a type
typedef vsomeip::reliability_type_e reliability_type_e;
^~~~~~~~~~~~~~~~~~
capicxx-someip-runtime-3.2.0/include/CommonAPI/SomeIP/Types.hpp:38:9: note: suggested alternative: ‘message_type_e’
typedef vsomeip::reliability_type_e reliability_type_e;
^~~~~~~
message_type_e
capicxx-someip-runtime-3.2.0/include/CommonAPI/SomeIP/Types.hpp:45:18: error: ‘uid_t’ in namespace ‘vsomeip’ does not name a type
typedef vsomeip::uid_t uid_t;
^~~~~
capicxx-someip-runtime-3.2.0/include/CommonAPI/SomeIP/Types.hpp:46:18: error: ‘gid_t’ in namespace ‘vsomeip’ does not name a type
typedef vsomeip::gid_t gid_t;
^~~~~

I am not sure what error is this, but when I run cmake command, it selects vsomeip3.1.7.1.

Version 3.1.12.17
I am referring to Version 3.0 of the Open Alliance document

I have defined a service with franca/CommonAPI which matches the API defined in this document for the Enhanced Testability Service.

Most of the APIs are defined such that the service returns the input data

1. Fixed UTF16 strings are not returned at all - the payload is empty. (SOMEIP_ETS_046_echoUTF16FIXED)
2. Fixed UTF8 and UTF16 strings. If I send a string shorter than specified, the message response is Ok rather than Malformed. This works fine if the strings are longer than indicated. (SOMEIP_ETS_064_String_UTF16FIXED_too_short, SOMEIP_ETS_066_String_UTF8FIXED_too_short)
3. Fixed Array - sending a string longer than allowed crashes the service in InputStream. The response should be a malformed message. (SOMEIP_ETS_001_Array_Length_longer_as_message_length_allows_it)
4. Sending a Fixed Array that is too short produces an error rather than stripping the payload. (SOMEIP_ETS_003_Array_Length_too_short_strips_Payload)

The getStubFunctor_ returns a reference to the value to be serialized. This reference is protected by the critical section of the mutex.
However, by unlocking the mutex before the serialization isn´t there the possibility of the value being changed unintentionally, even if the user locks the mutex first?
If the user even goes so far as to delete the object, the serialization would cause UB right?

https://github.com/GENIVI/capicxx-someip-runtime/blob/0ad2bdc1807fc0f078b9f9368a47ff2f3366ed13/include/CommonAPI/SomeIP/StubAdapterHelper.hpp#L856-L863

Why not unlock it after the outputStream << deployable;?

The de-initializer is missing in:

https://github.com/GENIVI/capicxx-someip-runtime/blob/64f0cb0133b23ff13c48c377546cdaef45b3d9ce/src/CommonAPI/SomeIP/Factory.cpp#L23

Adding to "Types.hpp" fixes the issue:

#define DEINITIALIZER(f) \ static void f(void) __attribute__((destructor)); \ static void f(void)

I do not know if this is the correct approach though.

I try to build the 3.2.3-r8 and get errors below:
/home/lijiejiang/github/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp: In constructor 'CommonAPI::SomeIP::ClientId::ClientId(CommonAPI::SomeIP::client_id_t, const vsomeip_sec_client_t*, const string&)':
/home/lijiejiang/github/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:37:40: error: 'const struct vsomeip_sec_client_t' has no member named 'user'
37 | uid_ {_sec_client ? sec_client->user : 0xffffffff},
| ^~~~
/home/lijiejiang/github/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:38:40: error: 'const struct vsomeip_sec_client_t' has no member named 'group'
38 | gid {_sec_client ? sec_client->group : 0xffffffff},
| ^~~~~
/home/lijiejiang/github/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:39:16: error: cannot convert '' to 'CommonAPI::SomeIP::uid_t' {aka 'unsigned int'} in initialization
39 | env(env) {
| ^
/home/lijiejiang/github/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:39:16: error: cannot convert '' to 'CommonAPI::SomeIP::gid_t' {aka 'unsigned int'} in initialization
/home/lijiejiang/github/capicxx-someip-runtime/src/CommonAPI/SomeIP/ClientId.cpp:42:53: error: 'const struct vsomeip_sec_client_t' has no member named 'host'
42 | hostAddress = addressToString(_sec_client->host);
| ^~~~

https://github.com/GENIVI/capicxx-someip-runtime/blob/92ece2f78f5e71ba3dbe4a27e9ba61d3565bd72f/src/CommonAPI/SomeIP/Watch.cpp#L157

I understand using eventfd is less overhead than using pipe. However, the eventfd is more linux specific and is not POSIX compliant.

Could we not fallback to pipe on POSIX variants ? What overhead is being seen on using eventfd as to the pipe ? I see that in the past pipe2 is used for O_NONBLOCK. Unfortunately pipe2 is non POSIX as well.

So the question is, if we use a POSIX OS (be it Linux, BSD, or any other POSIX compliant), does the capicxx-someip-runtime and the core-runtime compile ? I am not sure if it would, given that parts of the code is Linux specific. And are there any plans in moving to use more POSIX friendly calls ?

Thanks

Everything you need to know about this, I have mentioned here - https://stackoverflow.com/questions/78560075/buildproxy-of-commonapi-gives-memory-fault.

Infact if I use Dbus, ie, if I remove /etc/commonapi.ini file, then no mem fault occurs, but when /etc/commonapi.ini is present and it uses binding=someip, only then this issue is oberved. In short -> D-bus = no error, someip = error.

Environment - QNX local server and client.

Json file used :
vsomeip-local.json

Please point out all possible reasons for this issue.

Example how to use CommonAPI via SOME/IP in Android application for communication between two services from native (C/C++) parts.
Project: https://github.com/nkh-lab/ndk-capi-hello-world

Hello,

I am trying to communicate the SOME/IP from native machine to a Qemu (running on the same native machine). Below is the details:

Qemu:

Qemu IP: 192.168.7.2

Vsomeip.json file:

{                                    
  "logging": {                       
    "dlt": "false",                  
    "console": "false",              
    "file": {                        
      "path": "/var/log/vsomeip.log",
      "enable": "false"              
    },                               
    "level": "debug"                 
  },                                 
  "unicast": "192.168.7.2",                
  "applications": [],                
  "netmask": "255.255.255.0",        
  "routing": "vsomeipd",             
  "services": [                      
    {                                
      "service": "0x63",             
      "instance": "19",              
      "eventgroups": [               
        {                            
          "threshold": "1",          
          "eventgroup": "1",         

          "events": [                
            "1"                      
          ],                         
          "multicast": {             
            "port": "30303",         
            "address": "230.0.0.1"   
          }                          
        },                           
        {                            
          "eventgroup": "2",         
          "events": [                
            "2"                      
          ]                          
        },                           
        {                            
          "eventgroup": "3",         
          "events": [                
            "3000"                   
          ]                          
        }                            
      ],                             
      "secure_channel": "0x1111",    
      "unreliable": "5000",          
      "events": [                    
        {                            
          "is_reliable": "true",     
          "event": "3000",           
          "is_field": "true"         
        },                           
        {                            
          "is_reliable": "false",    
          "event": "2",              
          "is_field": "false"        
        },                           
        {                            
          "secure_channel": "0x2222",
          "is_reliable": "false",    
          "event": "1",              
          "is_field": "false"        
        }                            
      ]                              
    }                                
  ],                                 
  "service-discovery": {    
   "enable": "true",                
    "multicast": "224.244.224.245",  
    "protocol": "udp",               
    "port": "30491",                 
    "secure_channel": "0x3333"       
  },                                 
  "secure_channels": [               
    {                                
      "psk": "fefe",                 
      "pskid": "radar-fusion",       
      "id": "0x1111",                
      "level": "plain"               
    },                               
    {                                
      "is_multicast": "true",        
      "id": "0x2222",                
      "level": "plain"               
    },                               
    {                                
      "is_multicast": "true",
      "id": "0x3333",                
      "level": "plain"               
    } 
 ]

Native machine:

Native machine IP: 192.168.43.64

vsomeip.json:

{ 
    "logging" :
    {
        "level" : "debug",
        "console" : "true",
        "file" : { "enable" : "false" },
        "dlt" : "false"
    },
    "unicast" : "192.168.43.64",
    "applications" :
    [
        {
            "name" : "vsomeipd",
            "id" : "0x1343"
        }
    ],
    "netmask": "255.255.255.0",
    "routing" : "vsomeipd",
    "servicegroups" :
    [
        {
            "name" : "default",
            "unicast" : "local",
            "services" :
            [
                {
                    "service" : "0x1234",
                    "instance" : "0x5678",
			"eventgroups": [               
			{                    
			  "threshold": "1",          
			  "eventgroup": "1", 
			  "events": [                
			    "1"                      
			  ],                 
			  "multicast": {    
			    "port": "30303", 
			    "address": "230.0.0.1"
			  }                       
			},                        
			{                    
			  "eventgroup": "2",      
			  "events": [             
			    "2"             
			  ]                       
			},                        
			{                         
			  "eventgroup": "3",      
			  "events": [       
			    "3000"                
			  ]
			  }                            
		      ],      
                    "secure_channel": "0x1111",
                    "unreliable" : "5000",
                     "events": [                    
        			  {                            
         				 "is_reliable": "true", 
        				  "event": "3000",        
          				"is_field": "true"      
       				  },                        
       				  {                         
         				 "is_reliable": "false", 
        				  "event": "2",          
         				  "is_field": "false"     
     				   },                        
     				   {                        
      				         "secure_channel": "0x2222",
          				 "is_reliable": "false",    
          				 "event": "1",              
         				 "is_field": "false"        
        				}                            
    			      ]  
                }
            ]
        }
    ],
    
    "service-discovery" :
    {
        "enable" : "true",
        "multicast" : "224.244.224.245",
        "port" : "30491",
        "protocol" : "udp",
        "secure_channel": "0x3333"   
    },
"secure_channels": [             
    {                                
      "psk": "fefe",               
      "pskid": "radar-fusion",       
      "id": "0x1111",                
      "level": "plain"               
    },                               
    {                                
      "is_multicast": "true",        
      "id": "0x2222",                
      "level": "plain"               
    },                               
    {                                
      "is_multicast": "true",        
      "id": "0x3333", 
      "level": "plain"               
    }                                
  ] 
}  

But the service discovery is also not happening and they are connecting. Can anybody give some pointers here what wrong I am doing please?

Regards,
Siddhartha V

I haven't been able to narrow down the exact cause yet, but with 3.2.3-r8 I'm seeing seserialization issues. Not 100% of the time, but 100% reproducible. I'm trying to build a minimal example now that exposes the issue.

Has any one else seen this?

In this hard to read log where I filled the serialization/deserialization with debug:

foo      main   [foo.tokenUpdateProxy] readCpToken(): (154) m_pProxy->transferRequestFromApp(ETransferMessageId(uint16) msgId=ReadInitRequest=65333 (65333 <= 65535), UInt16 transactionIdentifier=55, ByteBuffer requestData=[])
foo commonapi   OutputStream.hpp:97 writeValue<uint8_t>
foo commonapi   OutputStream.hpp:487 _writeBitValue(val=0x5=5, nbits=8, is_signed=0)
foo commonapi   OutputStream.hpp:107 writeValue<uint16_t>
foo commonapi   OutputStream.hpp:487 _writeBitValue(val=0x37=55, nbits=16, is_signed=0)
foo commonapi   OutputStream.hpp:487 _writeBitValue(val=0x0=0, nbits=32, is_signed=0)
foo commonapi   callMethodWithReply REMOTE_ERROR!

bar commonapi   InputStream.cpp:144 readValue<uint16_t>
bar commonapi   InputStream.hpp:546 _readBitValue(65332, 16, 0), isLittleEndian=false
bar commonapi   deserialize (2)
bar commonapi   InputStream.cpp:144 readValue<uint16_t>
bar commonapi   InputStream.hpp:546 _readBitValue(0, 16, 0), isLittleEndian=false
bar commonapi   deserialize (2)
bar commonapi   InputStream.cpp:337 readValue
bar commonapi   InputStream.cpp:197 readValue
bar commonapi   InputStream.hpp:546 _readBitValue(337, 32, 0), isLittleEndian=false
bar commonapi   InputStream.hpp:559 _readBitValue failed sanity check: _bits = 32, remaining_ = 3 <? size_t(((_bits - 1) >> 3) + 1)=4
bar commonapi   deserialize (1)
bar commonapi   MethodWithReplyStubDispatcher (someip): deserialization failed! [0413:<bar.TokenUpdate>.22155.15500:<m:transferRequestFromApp>.64]

You can see that the 65333 is written as 5

This happens 100% at this call, but there are other calls where serialization/deserialization is fine.

One particular pattern that coordinates with this is when proxy calls are in callbacks (which emits a BLOCKING CALL AVAILABLITY vsomeip warning)

i.e.

proxy->getProxyStatusEvent().subscribe(
    [](auto const& /* availability_status */) {
       proxy->someOtherCall();
    }
);

this is a bad pattern and I'm trying to get rid of it anyways, BUT:

1. This didn't cause problems with 3.2.0
2. Fixing this doesn't resolve the deserialization issues, but my gut feeling is that it is somewhat related.

In the mean time, I've had to modify 3.2.0 to be compatible with vsomeip 3.4.10 and the 3.1.14 generators (basically change uid/gid for sec_client_t)

Remove dllexport of deleted methods (clang_cl complains)

Is fixed by #28

In Android Automotive OS 13, we attempted to use Capicxx-someip-runtime 3.2.0 with vsomeip 3.3.0 but encountered compilation problems.
It displays a use of deprecated VSOMEIP_DEPRECATED_UID_GID api error.
Could you please available the working version of capicxx-someip-runtime with latest version of vsomeip.

I am trying to connect to a CommonAPI Service that is running on an embedded device.

I am basically following the guide SomeIP in 10 minutes, but also tried several settings from the SomeIP User Guide without any success.

The SomeIP configuration at the client side (Linux Host) is similar to the following:

{
  "unicast" : "192.168.1.8",
  "logging":
  {
    "level" : "debug",
    "console" : "true"
  },
  "applications":
  [
    {
      "name" : "Client",
      "id" : "0x2000"
    }
  ],
  "clients":
  [
    {
      "service" : "0x000A",
      "instance" : "0x0014",
      "unreliable" : 
      [
        "30509"
      ],
      "reliable" :
      [
        "30600"
      ]
    }
  ],
  "routing" : "Client",
  "service-discovery":
  {
    "enable" : "true",
    "multicast" : "224.224.224.245"
    "port" : "30490",
    "protocol" : "udp"
  }
}

The SomeIP configuration at the service side (Linux Embedded Device) is similar to the following:

{
  "unicast" : "192.168.1.4",
  "logging":
  {
    "level" : "debug",
    "console" : "true"
  },
  "applications":
  [
    {
      "name" : "Service",
      "id" : "0x1000"
    }
  ],
  "services":
  [
    {
      "service" : "0x000A",
      "instance" : "0x0014",
      "unreliable" : "30509",
      "reliable" : { 
        "port" : "30600", 
        "enable-magic-cookies" : "false" 
      }
    }
  ],
  "routing" : "Service",
  "service-discovery":
  {
    "enable" : "true",
    "multicast" : "224.224.224.245"
    "port" : "30490",
    "protocol" : "udp"
  }
}

The problem is, although setting the logging level to trace there is almost no useful output that could point me to the actual issue. It would be helpful to get something like Could not connect to socket ... or something like that. It would be really helpful to have a guide like CommonAPI SomeIP for Dummies (:grin:). So this issue is not just particular to my problem but also the occasion for providing a thorough introductory guide that is a low burden for new developers. CommonAPI provides a high level of abstraction and ease of use but the complex deployment makes it little bit harder. :wink:

So some of my questions are:

• Why there is the possibility to provide the port settings and unicast address in the deployment file when it is not used in the generated code (at least I cannot see any reference to it)?
• What exactly is the matter of the service discovery? How exactly does it work?
• The 10 minutes SomeIP guide says that the services field is not necessary on the client side. But in the user guide they are providing an example that explicitly list the services and provide a unicast address. Why (service discovery)?
• Does the application id matter or can I randomly choose an identifier? As far as I understood they must be unique across the whole network. This means I must know all my clients in advance?

If you need further logging output I can provide it.

Logging output from the client:

[CAPI][DEBUG] Adding proxy mapping: local:Callbacks:v1_0:test --> libCallbacksProxy.so
[CAPI][DEBUG] Adding proxy mapping: local:Request:v1_0:test --> libRequestProxy.so
[CAPI][INFO] Loading configuration file '/etc/commonapi-client.ini'
[CAPI][INFO] Using default binding 'someip'
[CAPI][INFO] Using default shared library folder '/usr/local/lib/commonapi'
[CAPI][DEBUG] Loading library for local:Request:v1_0:test proxy.
[CAPI][DEBUG] Added address mapping: local:Callbacks:v1_0:test <--> [001e.0028(0.0)]
[CAPI][DEBUG] Added address mapping: local:Request:v1_0:test <--> [000a.0014(0.0)]
[CAPI][VERBOSE] Registering function for creating "Request:v1_0" proxy.
[CAPI][DEBUG] Loading interface library "libRequestProxy.so" succeeded.
[CAPI][VERBOSE] Creating proxy for "local:Request:v1_0:test"
[info] Parsed vsomeip configuration in 0ms
[info] Using configuration file: "/etc/someip_config.json".
[info] Configuration module loaded.
[info] Initializing vsomeip application "Client".
[info] Instantiating routing manager [Host].
[info] create_local_server Routing endpoint at /tmp/vsomeip-0
[info] Service Discovery enabled. Trying to load module.
[info] Service Discovery module loaded.
[info] Application(Client, 2000) is initialized (11, 100).
[info] Starting vsomeip application "Client" (2000) using 2 threads I/O nice 255
[info] main dispatch thread id from application: 2000 (Client) is: 7ff446ffd700 TID: 32450
[info] shutdown thread id from application: 2000 (Client) is: 7ff4467fc700 TID: 32451
[info] REQUEST(2000): [000a.0014:0.4294967295]
[info] Watchdog is disabled!
[info] io thread id from application: 2000 (Client) is: 7ff4477fe700 TID: 32449
[info] io thread id from application: 2000 (Client) is: 7ff4457fa700 TID: 32453
[info] Listening at /tmp/vsomeip-2000
Checking availability of the service...
[info] vSomeIP 3.1.20.3 | (default)
[info] Network interface "eno2" state changed: up
[info] Route "224.224.224.245/32 if: eno2 gw: n/a" state changed: up
[info] udp_server_endpoint_impl: SO_RCVBUF is: 212992
[debug] Joining to multicast group 224.224.224.245 from 192.168.1.8
[info] udp_server_endpoint_impl: SO_RCVBUF (Multicast) is: 212992
[info] SOME/IP routing ready.
[info] vSomeIP 3.1.20.3 | (default)
[info] Stopping vsomeip application "Client" (2000).

Logging output from the server:

[CAPI][INFO] Loading configuration file '/data/commonapi-server.ini'
[CAPI][INFO] Using default binding 'someip'
[CAPI][INFO] Using default shared library folder '/usr/local/lib/commonapi'
[CAPI][DEBUG] Loading library for local:Request:v1_0:test stub.
[CAPI][DEBUG] Added address mapping: local:Callbacks:v1_0:test <--> [001e.0028(0.0)]
[CAPI][DEBUG] Added address mapping: local:Request:v1_0:test <--> [000a.0014(0.0)]
[CAPI][DEBUG] Added address mapping: local:Request:v1_0:Request <--> [000a.0014(1.0)]
[CAPI][INFO] Registering function for creating "Request:v1_0" stub adapter.
[CAPI][DEBUG] Loading interface library "librequest-stub.so" succeeded.
[CAPI][INFO] Registering stub for "local:Request:v1_0:test"
[info] Parsed vsomeip configuration in 7ms
[info] Using configuration file: "/data/someip_config.json".
[info] Configuration module loaded.
[info] Initializing vsomeip application "serverapp".
[info] Instantiating routing manager [Host].
[info] create_local_server Routing endpoint at /tmp/vsomeip-0
[info] Service Discovery enabled. Trying to load module.
[info] Service Discovery module loaded.
[info] Application(serverapp, 1000) is initialized (11, 100).
[info] OFFER(1000): [000a.0014:0.0] (true)
[info] Listening at /tmp/vsomeip-1000
[CAPI][DEBUG] Loading library for local:Callbacks:v1_0:test stub.
[info] Starting vsomeip application "serverapp" (1000) using 2 threads I/O nice 255
[info] Watchdog is disabled!
[info] io thread id from application: 1000 (serverapp) is: abfc7450 TID: 3787
[info] vSomeIP 3.1.20.3 | (default)
[info] main dispatch thread id from application: 1000 (serverapp) is: b03ac450 TID: 3788
[info] shutdown thread id from application: 1000 (serverapp) is: b1bcd450 TID: 3789
[info] io thread id from application: 1000 (serverapp) is: ab7a9450 TID: 3791
[CAPI][DEBUG] Added address mapping: local:Callbacks:v1_0:Callbacks <--> [001e.0028(1.0)]
[CAPI][[info] Network interface "bridge0" state changed: up
[error] netlink_connector::receive_cbk received error message: 2 seq 3
[CAPI][INFO] Registering function for creating "Callbacks:v1_0" stub adapter.
[CAPI][DEBUG] Loading interface library "libcallbacks-stub.so" succeeded.
[CAPI][INFO] Registering stub for "local:Callbacks:v1_0:test"

As it can be seen in the logging output there isn't much going on, but I am seeing that there is a REQUEST on the client side and an OFFER on the server side. So something is happening. But no connection attempt. What looks suspicious to me is that the client requests the SomeIP address 000a.0014:0.4294967295 whereas the server offers the address 000a.0014:0.0 which indicates that the minor version is different. Can this be a problem here?

Help is really appreciated 😉 I don't know how to proceed 😅

Hi team,

Newly I started working on this application, so I followed the steps which is provided by the group [ https://github.com/COVESA/capicxx-someip-tools/wiki/CommonAPI-C---SomeIP-in-10-minutes and https://github.com/COVESA/capicxx-dbus-tools/wiki/CommonAPI-C---D-Bus-in-10-minutes]. Once after the execution of HelloworldService and HelloworldClient application I'm getting an error like 1 Configuration module could not be loaded! and the command prompt stops responding so any suggestions or supports would be helpful.

Thanks!

Hi,

My current setup is using:

boost: 1.67
vsomeip3

I am not able to compile the commonapi-someip application using vsomeip3. I am not sure whether are there any dependencies issues? Or the current commonapi-someip doesnt support vsomeip3? Because when i tried to compile using vsomeip2 it works fine.