Open u27p20 opened 5 months ago
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_**
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:
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.
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!
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 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
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 ?
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.
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:
#!/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
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
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
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
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
iMX93
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
iMX93