No communication between the Ubuntu PC and IMX93 devices #735

u27p20 · 2024-07-03T12:11:08Z

vSomeip Version

v3.3.8

Boost Version

Ubuntu PC : 1.71 and iMX93 : 1.81

Environment

Ubuntu 20.04 and Embedded linux (IMX BSP 6.1.55.2.2 - mickledore)

Describe the bug

I want to establish SomeIP communication between an Ubuntu PC and an iMX93 EVK. To achieve this, I used the request-sample and response-sample from the examples folder. After running the applications, the communication doesn't start between the PC and the iMX93. From the logs, I can see the network interface is up, but there is no routing. I added a route for the multicast IP address with "route add -host 224.224.224.245 dev ", but the issue persists.

However, when testing the same examples between two Ubuntu PCs, the communication works. I don't understand why communication fails between the iMX93 and the Ubuntu PC despite using the same SomeIP version and examples.

Reproduction Steps

Installation

On Ubuntu PC : I have followed installation steps mentioned in https://github.com/COVESA/vsomeip/tree/master
On iMX93 : I have used the yocto recipe, to install someip on the target. (https://git.openembedded.org/meta-openembedded/tree/meta-networking/recipes-protocols/vsomeip/vsomeip_3.3.8.bb?h=nanbield)

Running application
Ubuntu PC

export VSOMEIP_CONFIGURATION=../../config/vsomeip-local.json
export VSOMEIP_APPLICATION_NAME=service-sample
./response-sample

iMX93

export VSOMEIP_CONFIGURATION=../../config/vsomeip-local.json
 VSOMEIP_APPLICATION_NAME=client-sample
./request-sample

IP address are changed in the json file.

Expected behaviour

Need to establish a communication between IMX93 and Ubuntu PC by using request-response example

Logs and Screenshots

Ubuntu PC

024-07-03 11:40:18.018424 [warning] Reliability type for event [1234.5678.777] was not configured Using : RT_UNRELIABLE
2024-07-03 11:40:18.019476 [warning] Reliability type for event [1234.5678.778] was not configured Using : RT_UNRELIABLE
2024-07-03 11:40:18.019663 [warning] Reliability type for event [1234.5678.779] was not configured Using : RT_UNRELIABLE
2024-07-03 11:40:18.021444 [info] Using configuration file: "../../config/vsomeip-local.json".
2024-07-03 11:40:18.021630 [info] Parsed vsomeip configuration in 1ms
2024-07-03 11:40:18.021819 [info] Configuration module loaded.
2024-07-03 11:40:18.022006 [info] Initializing vsomeip (3.3.8) application "service-sample".
2024-07-03 11:40:18.022312 [info] Instantiating routing manager [Host].
2024-07-03 11:40:18.023222 [info] create_routing_root: Routing root @ /tmp/vsomeip-0
2024-07-03 11:40:18.024164 [info] Service Discovery enabled. Trying to load module.
2024-07-03 11:40:18.027628 [info] Service Discovery module loaded.
2024-07-03 11:40:18.028144 [info] Application(service-sample, 1277) is initialized (11, 100).
Static routing OFF
2024-07-03 11:40:18.028456 [info] Starting vsomeip application "service-sample" (1277) using 2 threads I/O nice 255
2024-07-03 11:40:18.029316 [info] Client [1277] routes unicast:192.168.172.90, netmask:255.255.255.0
2024-07-03 11:40:18.029311 [info] shutdown thread id from application: 1277 (service-sample) is: 7f7f0613d700 TID: 6040
2024-07-03 11:40:18.029567 [info] main dispatch thread id from application: 1277 (service-sample) is: 7f7f0693e700 TID: 6039
2024-07-03 11:40:18.030565 [info] Watchdog is disabled!
Application service-sample is registered.
2024-07-03 11:40:18.031131 [info] io thread id from application: 1277 (service-sample) is: 7f7f07a48ec0 TID: 6036
2024-07-03 11:40:18.031149 [info] io thread id from application: 1277 (service-sample) is: 7f7f0513b700 TID: 6042
2024-07-03 11:40:18.031410 [info] OFFER(1277): [1234.5678:0.0] (true)
2024-07-03 11:40:18.032576 [info] vSomeIP 3.3.8 | (default)
2024-07-03 11:40:18.032679 [info] create_local_server: Listening @ /tmp/vsomeip-1277
2024-07-03 11:40:18.033048 [info] OFFER(1277): [1235.5678:0.0] (true)
2024-07-03 11:40:18.033294 [info] Network interface "enp0s31f6" state changed: up
2024-07-03 11:40:18.034082 [info] Route "default route (0.0.0.0/0) if: enp0s31f6 gw: 192.168.172.1" state changed: up
2024-07-03 11:40:18.034656 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30490
2024-07-03 11:40:18.034870 [debug] Joining to multicast group 224.244.224.245 from 192.168.172.90
2024-07-03 11:40:18.035489 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30509
2024-07-03 11:40:18.035618 [info] udp_server_endpoint_impl<multicast>: SO_RCVBUF is: 212992 (1703936) local port:30490
2024-07-03 11:40:18.035732 [info] Port configuration missing for [1235.5678]. Service is internal.
2024-07-03 11:40:18.035853 [info] SOME/IP routing ready.
2024-07-03 11:40:28.037730 [info] vSomeIP 3.3.8 | (default)
2024-07-03 11:40:28.059129 [info] STOP OFFER(1277): [1234.5678:0.0] (true)
2024-07-03 11:40:28.061572 [info] STOP OFFER(1277): [1235.5678:0.0] (true)
2024-07-03 11:40:38.041671 [info] vSomeIP 3.3.8 | (default)
2024-07-03 11:40:38.085626 [info] OFFER(1277): [1234.5678:0.0] (true)
2024-07-03 11:40:38.089305 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30509
2024-07-03 11:40:38.090735 [info] OFFER(1277): [1235.5678:0.0] (true)
2024-07-03 11:40:38.091508 [info] Port configuration missing for [1235.5678]. Service is internal.
2024-07-03 11:40:48.046003 [info] vSomeIP 3.3.8 | (default)
2024-07-03 11:40:48.123925 [info] STOP OFFER(1277): [1234.5678:0.0] (true)
2024-07-03 11:40:48.125886 [info] STOP OFFER(1277): [1235.5678:0.0] (true)
2024-07-03 11:40:58.048156 [info] vSomeIP 3.3.8 | (default)
2024-07-03 11:40:58.157241 [info] OFFER(1277): [1234.5678:0.0] (true)
2024-07-03 11:40:58.160765 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 (1703936) local port:30509
2024-07-03 11:40:58.162141 [info] OFFER(1277): [1235.5678:0.0] (true)
2024-07-03 11:40:58.162861 [info] Port configuration missing for [1235.5678]. Service is internal.
^C2024-07-03 11:41:01.604315 [info] Stopping vsomeip application "service-sample" (1277)

iMX93

2023-03-12 03:15:04.145318 [info] Using configuration file: "/etc/vsomeip/vsomeip-local.json".
2023-03-12 03:15:04.145659 [info] Parsed vsomeip configuration in 2ms
2023-03-12 03:15:04.146227 [info] Configuration module loaded.
2023-03-12 03:15:04.146461 [info] Initializing vsomeip (3.3.8) application "client-sample".
2023-03-12 03:15:04.147375 [info] Instantiating routing manager [Host].
2023-03-12 03:15:04.151107 [info] create_routing_root: Routing root @ /tmp/vsomeip-0
2023-03-12 03:15:04.152641 [info] Service Discovery enabled. Trying to load module.
2023-03-12 03:15:04.165303 [info] Service Discovery module loaded.
2023-03-12 03:15:04.166667 [info] vsomeip tracing not enabled. . vsomeip service discovery tracing not enabled.
2023-03-12 03:15:04.166977 [info] Application(client-sample, 1344) is initialized (11, 100).
Client settings [protocol=UDP:quiet=false:cycle=1000]
2023-03-12 03:15:04.167734 [info] Starting vsomeip application "client-sample" (1344) using 2 threads I/O nice 255
2023-03-12 03:15:04.171129 [info] Client [1344] routes unicast:192.168.172.5, netmask:255.255.255.0
2023-03-12 03:15:04.174946 [info] Watchdog is disabled!
2023-03-12 03:15:04.177335 [info] io thread id from application: 1344 (client-sample) is: ffffb882e020 TID: 1749
2023-03-12 03:15:04.179598 [info] vSomeIP 3.3.8 | (default)
2023-03-12 03:15:04.181042 [info] Network interface "eth1" state changed: up
2023-03-12 03:15:04.184641 [info] io thread id from application: 1344 (client-sample) is: ffffb441f0a0 TID: 1757
2023-03-12 03:15:04.187133 [info] shutdown thread id from application: 1344 (client-sample) is: ffffb543f0a0 TID: 1755
2023-03-12 03:15:04.188911 [info] main dispatch thread id from application: 1344 (client-sample) is: ffffb5c4f0a0 TID: 1754
Service [1234.5678] is NOT available.
Service [1235.5678] is NOT available.
2023-03-12 03:15:04.190832 [info] REQUEST(1344): [1234.5678:255.4294967295]
2023-03-12 03:15:04.191187 [info] Avoid trigger SD find-service message for local service/instance/major/minor: 1234/5678/255/4294967295
2023-03-12 03:15:04.193008 [info] create_local_server: Listening @ /tmp/vsomeip-1344
2023-03-12 03:15:14.180737 [info] vSomeIP 3.3.8 | (default)
2023-03-12 03:15:24.182464 [info] vSomeIP 3.3.8 | (default)
2023-03-12 03:15:34.184150 [info] vSomeIP 3.3.8 | (default)
2023-03-12 03:15:44.186081 [info] vSomeIP 3.3.8 | (default)

The text was updated successfully, but these errors were encountered:

biggoldenbee · 2024-07-04T01:59:53Z

Did you set multi-cast address of SD in you json configuration file? And did you added multi-cast address in your routing table both on Ubuntu and iMX93 board?
SD option just likes as below:
"service-discovery": {
"enable": "true",
"multicast": "224.224.224.245",
"port": "30490",
...
}
And you must add "224.224.224.245" on your unicast ethernet card(E.G. it is eth0), issue CMD as below:
$sudo route add -nv 224.224.224.245 eth0

Finally please check your routing tables
$ route
Kernel IP routing table
...
224.224.224.245 0.0.0.0 255.255.255.255 UH 0 0 0 eth0_**

biggoldenbee · 2024-07-04T02:12:58Z

https://github.com/COVESA/vsomeip/wiki/vsomeip-in-10-minutes
Almost everybody rarely read this part carefully when test vsomeipd on different network node in a real ethernet environment , snapshot is shown as below:

u27p20 · 2024-07-04T09:47:43Z

Yes, I have set the multicast address of SD in your JSON configuration file. Additionally, I have added the multicast address to your routing table on both Ubuntu and the iMX93 board.

On Ubuntu, the command 'sudo route add -nv 224.224.224.245 enp0s31f6' works fine. However, on the iMX93, the command 'route add -nv 224.224.224.245 eth1' doesn't work and returns an error because the iMX93, which uses BusyBox version 1.36.1, doesn't support the '-v' option. I changed the command to 'route add -v 224.224.224.245 eth1,' and the command worked.

root@imx93-11x11-lpddr4x-evk-ov2311-10:/# route add -nv 224.224.224.245 eth1
route: invalid option -- 'v'
BusyBox v1.36.1 () multi-call binary.

Usage: route [-ne] [-A inet[6]] [{add|del} [-net|-host] TARGET [netmask MASK]
        [gw GATEWAY] [metric N] [mss BYTES] [window BYTES] [reject] [IFACE]]
root@imx93-11x11-lpddr4x-evk-ov2311-10:/#
root@imx93-11x11-lpddr4x-evk-ov2311-10:/#
root@imx93-11x11-lpddr4x-evk-ov2311-10:/#
root@imx93-11x11-lpddr4x-evk-ov2311-10:/# route add -n 224.224.224.245 eth1
root@imx93-11x11-lpddr4x-evk-ov2311-10:/#
root@imx93-11x11-lpddr4x-evk-ov2311-10:/# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.172.0   *               255.255.255.0   U     0      0        0 eth1
224.224.224.245 *               255.255.255.255 UH    0      0        0 eth1
root@imx93-11x11-lpddr4x-evk-ov2311-10:/# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.172.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
224.224.224.245 0.0.0.0         255.255.255.255 UH    0      0        0 eth1

I have tested the application before by adding the multicast address in the JSON file and the routing table, but the communication did not work. I tried again and observed the same behavior as before.

biggoldenbee · 2024-07-05T00:12:38Z

I attached my samples, you may have a reference. In my test environment, the ip address of Ubuntu.x86 is "10.68.128.155" and the ip address of Ubuntu.aarch64 is "10.68.128.159"
HelloWorld.155.tar.gz
HelloWorld.159.tar.gz

And please check following key points:
1.Address of InstanceId what is defined in fdepl file.
For example, in my sample it defines as below:
InstanceId = "commonapi.HelloWorld"
When resisters stub the code is as below:
runtime->registerService("local", "commonapi.HelloWorld", myService);
When builds proxy the code is as below:
std::shared_ptr<HelloWorldProxy<>> myProxy = runtime->buildProxy<HelloWorldProxy>("local", "commonapi.HelloWorld");

2."unicast" in vsomeip-service.json of my samples, you may read it and compare the configuration file of "10.68.128.155" in HelloWorld.155.tar.gz with the configuration file of "10.68.128.159" in HelloWorld.159tar.gz

3.test stub and proxy of my samples
on "10.68.128.155", issues following shell cmd:

$cd build
$source ../env.sh
$./HelloWorldService

on "10.68.128.159", issues following shell cmd:

$cd build
$source ../env.sh
$ env VSOMEIP_APPLICATION_NAME=client-sample ./HelloWorldClient

Of course, on my test environment the samples run very well!

If you still have this running problems, you may use Wireshark to capture SOME/IP packages online to check the stub and proxy of your test environment run result and analyze the exact root cause of this running problem.

By the way, if you still can't solve this issue you may use tcpdump to grab a pcap file of both your Ubuntu and IMX93, and use Wireshark do a off-line check and analysis.

Good luck！

pradeepanbumani-dev · 2024-07-15T16:55:23Z

biggoldenbee Thanks a lot for the sample application you had shared! I was able to run the HelloWorld client server application in two docker containers running on a Ubuntu VM.

Is there a way to configure the Ubuntu VM as a router so that the two docker containers can join the multicast group, which would help me to test the event scenarios also.

Your help is very much appreciated. Thanks in advance!

biggoldenbee · 2024-07-15T23:38:56Z

biggoldenbee Thanks a lot for the sample application you had shared! I was able to run the HelloWorld client server application in two docker containers running on a Ubuntu VM.

Is there a way to configure the Ubuntu VM as a router so that the two docker containers can join the multicast group, which would help me to test the event scenarios also.

Your help is very much appreciated. Thanks in advance!

you have to be aware of how to configure Ubuntu router parameters correctly, as below:
1.if your one docker container is running on A ip address segment and another docker container is running on B ip address segment, so you have to set the different ip address segments may forward ethernet packages each other and this includes forward ethernet packages from multi-cast ip address of the different ip address segments, I have no this experiences.
2.you may reference to http://www.bonsaiframework.com/wiki/display/bonsai/5.1+LXC+Advanced+Networking+-+Exposing+Containers+to+the+Network#id-5.1LXCAdvancedNetworking-ExposingContainerstotheNetwork-macvlanwithAdditionalIP, this tells you how to set LXC container to get ip address from the same ip address segment with Ubuntu host and other LXC container, and then the conters and Unbuntu host are in the same ip address segment, and I tested it on my project all things of vsomeip run very well. You may reference my paper of WeChat public account, but unfortunately it's Chinese :-), https://mp.weixin.qq.com/s?__biz=Mzg3NTgxMzk4Ng==&mid=2247484375&idx=1&sn=6fd3d1a99682d2a51d33689cbde925bf&chksm=cf3a8edaf84d07cc1f10fb046b4f60101b9fb90140ea96ba1bbe58c7dd83eba4f286b85b8bb3&token=706146867&lang=zh_CN&poc_token=HEaylWajEJAdgOvaf8Gt3SyzdNVYyTa9A-P4lXsW

pradeepanbumani-dev · 2024-07-16T10:40:33Z

Both the dockers are getting the IP address on the same network. Eg: 172.18.0.2 and 172.18.0.3. The clarity needed is who will handle the Multicast messages to 224.0.0.22 and 224.224.224.245 ?

biggoldenbee · 2024-07-16T23:31:35Z

1.Your two dockers have the same IP address segment, it's ok.
2.About multicast IP address: the routing manager daemon of vsomeip of someip stub will join it and send all SD message to multicast IP address, the routing manager daemon of vsomeip of someip proxy will join it and receive all SD message from multicast IP address, so proxy can know the services and functions what the stub offer. And after version 3.0.0 of vsomeip, the routing manager daemon is a embedded thread of first launched vsomeip application or you may appoint which application will to be as the routing manager daemon in json file. So the routing manager daemon will handle all raw ethernet messages of vsomeip including sent and received messages. In source code of vsomip it use boost unicast and multicast technic to do this task.

By the way, why you need two multicast IP addresses? All applications of vsomeip what are running on different dockers or other network nodes in the same IP address segment set conversation on the appointed same multicast IP addresses. The different multicast IP addresses they don't know each other, unless you may let "224.0.0.22" communicate with "224.224.224.245" freely and with no gap. Of course you may modify source code of vsomeip to join over two different multicast IP addresses and handle all message, then you will achieve the goal, this will be a vsomeip hybrid version.

biggoldenbee · 2024-07-17T01:03:46Z

Is there a way to configure the Ubuntu VM as a router so that the two docker containers can join the multicast group, which would help me to test the event scenarios also.

Maybe you have to study iptables and route, I may share you my some experiences on doing a demo:

On Ubuntu216, issues following CMD:

#!/bin/sh
sudo ifconfig enp0s3:0 192.168.216.11 netmask 255.255.255.0 broadcast 192.168.216.255 up
sudo route del default
sudo route add default gw 192.168.216.1

On Ubuntu217, issues following CMD:

sudo ifconfig enp0s3:1 192.168.217.11 netmask 255.255.255.0 broadcast 192.168.217.255 up
sudo route del default
sudo route add default gw 192.168.217.1

On Ubuntu216217 to be as a router for forwarding message between "192.168.216.11" and "192.168.217.11" , issues following CMD:

ifconfig enp0s3:0 192.168.216.1 netmask 255.255.255.0 broadcast 192.168.216.255 up
ifconfig enp0s3:1 192.168.217.1 netmask 255.255.255.0 broadcast 192.168.217.255 up
sudo sysctl -w net.ipv4.ip_forward=1

On Ubuntu216217 to be as a router for forwarding message from "192.168.216.11" and "192.168.217.11" to access internet, issues following CMD:

dhclient -4 enp0s8 // Ubuntu216217 will get IP address "172.20.10.8" from external router, my iphone to be as this external router
route del default
route add default gw 172.20.10.1
iptables -t nat -F
iptables -t nat -A PREROUTING -d 172.24.12.125/32 -j DNAT --to-destination 172.20.10.1
iptables -t nat -A POSTROUTING -s 192.168.216.0/24 -o enp0s8 -j SNAT --to-source 172.20.10.8
iptables -t nat -A POSTROUTING -s 192.168.217.0/24 -o enp0s8 -j SNAT --to-source 172.20.10.8

Hope upon may give you some help

u27p20 added the bug label Jul 3, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No communication between the Ubuntu PC and IMX93 devices #735

No communication between the Ubuntu PC and IMX93 devices #735

u27p20 commented Jul 3, 2024

biggoldenbee commented Jul 4, 2024

biggoldenbee commented Jul 4, 2024

u27p20 commented Jul 4, 2024

biggoldenbee commented Jul 5, 2024

pradeepanbumani-dev commented Jul 15, 2024

biggoldenbee commented Jul 15, 2024

pradeepanbumani-dev commented Jul 16, 2024

biggoldenbee commented Jul 16, 2024 •

edited

Loading

biggoldenbee commented Jul 17, 2024

No communication between the Ubuntu PC and IMX93 devices #735

No communication between the Ubuntu PC and IMX93 devices #735

Comments

u27p20 commented Jul 3, 2024

vSomeip Version

Boost Version

Environment

Describe the bug

Reproduction Steps

Expected behaviour

Logs and Screenshots

biggoldenbee commented Jul 4, 2024

biggoldenbee commented Jul 4, 2024

u27p20 commented Jul 4, 2024

biggoldenbee commented Jul 5, 2024

pradeepanbumani-dev commented Jul 15, 2024

biggoldenbee commented Jul 15, 2024

pradeepanbumani-dev commented Jul 16, 2024

biggoldenbee commented Jul 16, 2024 • edited Loading

biggoldenbee commented Jul 17, 2024

biggoldenbee commented Jul 16, 2024 •

edited

Loading