vSTING / Network Degradation Support Thread

The vSTING module developed by the TU Dortmund can be used to simulate the effects of wireless network degradation like latency, bandwidth limit or packet loss.
The setup instructions for the vSTING module can be found on Github: GitHub - tudo-cni/vsting-sa

Please post your questions regarding the setup instructions here.

The TU Dortmund will host a live support meeting where teams can ask their questions and receive help for setup via screen sharing. The meeting will be scheduled in April together with participating teams. Please post here or send me a message, if you are interested in participating.

Hi!
I’m Wenbang Deng from team NuBot-rescue.We had some problems installing vsting. We followed the installation instructions,but were unable to open localhost after running vsting.sh start. Some running results are as follows:


It would be great if there is any solution.Thanks!

Best regard!

Wenbang Deng

Hi @wbdeng.

Thanks for you feedback!

Could you please provide the output of the following command:
sudo journalctl -fu drz-vsting-ui
as well?

This could provide us additional insight on the nature of the problem.

Kind regards
Manuel Patchou

Hi!
Thank you for your help. The running result of the command is shown in the figure below:


It would be great if there is any solution.Thanks!

Best regard!

Wenbang Deng

Hi,
thanks for the input. It gave me some insight on the problem.
It seems your user does not have sufficient permissions to run the docker-compose executable located at /usr/local/bin/docker-compose.

Can you please check what are the permissions of the docker-compose executable with the following command:
ls -l /usr/local/bin/docker-compose.

Based on that i will be able to propose a quick solution such as adding your user the group with executable permissions on the file.

Kind regards
Manuel

Hi,
Thank you for your help. The command output is as follows:


I tried sudo usermod -aG docker $USER and logged out the account, but there was no effect.
It would be great if there is any solution.Thanks!

Best regard!

Wenbang Deng

Hi,

thanks for the input.
Since the command to add the current user to the docker group was already issued:

  • can you check if the user is now a member of the docker group? (use ‘groups’ to print the current user groups)
  • the docker documentation mentions that a system restart might be required after the user group update, in case logging in and out does not solve the problem. Has the system been restarted since? If not, could you please try that too?

Finally if none of the above works, i would suggest a short zoom session for a live debugging of the problem.

Kind regards
Manuel

Hi,
in the meantime a possible workaround you could try would be to edit the file /etc/systemd/system/drz-vsting-ui.service as follows:
replace the line: User=adrz
with: User=root
and run:
sudo systemctl daemon-reload && sudo service drz-vsting-ui restart.
Freely let me know if there is any update on this.

Kind regards
Manuel

Hi,
I modified the corresponding file and ran the following instructions. The result is no update. Some of the results are as follows:

Hi,

i suggest an live troubleshooting session to look deeper into the issue you are facing.
We could meet here to discuss it: Jitsi Meet
Would Friday 28.04.23 at 11:00 CET be feasible for you?
If not, feel free to suggest an alternative time.

Kind regards,
Manuel

Hi Manuel,

We tried to deploy vSting in the other personal computer and it worked! I guess it was the reason of docker installation that caused the failure. Now we can open the interface in the website and communicate the robot with the operator via vSting. Thanks for your help!

However, there is still one problem: the built vSting network connection can only last for about one minute. After that, the connection doses not work, and the network setttings of the two virtual ports are cancelled automatically and changed back to the real physical network configuraion. We have to use the “nmcli connection up vsting-bridge vsting-br-operator vsting-br-robot” command to set up the virtual connection again to make vSting work normally. However, the connection will still be automatically changed after a while. The automatic chages of network cofnfiguration can be seen in the pictures. The vSting worked well in first picture and it didn’t work in the second picture. Is there any related parameter controlling the time of connection? Or is there any solution for this problem?

If this problem can be solved, we think that we will be able to use vSting successfully and we don’t need to waste your time for the live meeting.

Best regards!

Wenbang Deng


Hi Wenbang,

Glad to learn you could find a workaround to the initial problem.

For the current issue: There is no timeout for the vsting-bridge connection, as far as i know. A possible reason why the connections disappears a while after being setup can be that there are other connections using the network devices meant for vsting-operator and vsting-robot.

You can check this by running the command: nmcli connection show
and find out in the right column named DEVICE which connections use the devices meant for vsting.

As an example, from the screenshots i can gather that the network device meant for the connection vsting-robot is enp4s0.
After running the command mentioned above and finding out which connection is using the network device enp4s0, you can bring down that connection by running:
nmcli connection down <connection-name>
and disable its auto-activation by running:
nmcli connection modify <connection-name> connection.autoconnect false

After this you can try bringing up the vsting-bridge connections again.

Let me know if this helps.

Kind Regards
Manuel

Hi,
I followed your suggestion, but it didn’t work.After that,I tried deleting the real physical network configuraion,but it still didn’t work.vSting network connection can only last for about a moment.More details are as follows.




The IP of the robot is 192.168.1.21, the IP of the host side is 192.168.1.20, and the mask is 255.255.255.0.

It would be great if there is any solution.Thanks!

Best regard!

Wenbang Deng

Hi @patchou @oehler

We still can not solve the short-time connection problem. Can you please provide some instructions? Thanks!

Best regard!

Wenbang Deng

Hi Wenbang,

first of all sorry for the late reply. I was absent from the office for a critical testfield demo event.
As i haven’t encountered the issue you are facing during the dry-runs we carried out on different test platforms, i would surmise it is a system specific issue.
Therefore, i would suggest a live troubleshooting session. What would be your availability for such a session and what is your timezone? (mine is GMT+2)

Greetings
Manuel

Hi Manuel,

I think it will be great to implement a live troubleshooting session. Our time zone is GMT+8, and we are available from 9 am GMT+8 (3am GMT+2) to 10pm GMT+8 (4 pm GMT+2) these days until the competition begins. Our time is adjustable according to your schedule. Thanks in advance!

Best regards!

Wenbang Deng

Hi Wenbang,

Would a session scheduled as follows:

  • on Wednesday 28/06/203
  • from 8 am GMT+2 (2 pm GMT+8)
  • to 10am GMT+2 (4 pm GMT+8)
    work for you?

Kind regards
Manuel

Hi Manuel,

The time is OK for us. What platform are we going to have this session on? It seems Zoom would be a good option, but we can only join a meeting, rather than initiating one (due to the failure of registration in Zoom). So is it possible for you to initiate a Zoom meeting at that time?

Best regards!

Wenbang Deng

Hi Wenbang,

This works fine, as i was thinking the same. I will plan and host a Zoom meeting. do you have a preferred way for me to send you the invitation, or can it be done here?

Kind regards,
Manuel