RoboCup-SSL / ssl-simulation-setup

Documentation and sources for a virtual tournament setup
GNU General Public License v3.0
5 stars 26 forks source link

Error when running the update_guacamole script #4

Closed Bollos00 closed 3 years ago

Bollos00 commented 3 years ago

System information:

Note: If anything else is needed, please tell me.

I was following the instructions to startup the setup and got stuck on the part that I should run the update_guacamole.py script. Even when I try to run with root permission I get this issue:

~$ sudo ./config/guacamole/update_guacamole.py

/usr/lib/python3.9/site-packages/urllib3/connectionpool.py:1013: InsecureRequestWarning: Unverified HTTPS request is being made to host 'vnc.field-a.localhost'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
  warnings.warn(
Traceback (most recent call last):
  File "/home/robofei/Repository/ssl-simulation-setup/./config/guacamole/update_guacamole.py", line 169, in <module>
    init_field(field)
  File "/home/robofei/Repository/ssl-simulation-setup/./config/guacamole/update_guacamole.py", line 94, in init_field
    client.retrieve_auth_token(guacamoleAdminUser, guacamoleAdminStandardPassword)
  File "/home/robofei/Repository/ssl-simulation-setup/config/guacamole/GuacamoleClient.py", line 29, in retrieve_auth_token
    raise GuacamoleException("Could not authenticate: " + response.text)
GuacamoleClient.GuacamoleException: Could not authenticate: {"message":"Unexpected internal error","translatableMessage":{"key":"APP.TEXT_UNTRANSLATED","variables":{"MESSAGE":"Unexpected internal error"}},"statusCode":null,"expected":null,"type":"INTERNAL_ERROR"}

I am using my forked repository on https://github.com/Bollos00/ssl-simulation-setup. I followed this exactly steps:

sudo ./config/docker/init.sh
export COMPOSE_PROJECT_NAME=field-a
sudo docker-compose up
sudo docker-compose -f docker-compose-teams.yaml up team-robofei
cd caddy
sudo docker-compose up
cd .. # To go back to the main directory
sudo ./caddy/install_local_CA.sh
./config/guacamole/update_guacamole.py

Running it on my Linux Mint 20 virtual machine everything worked and I could startup my team strategy software, but on Manjaro I got the issue mentioned.

I did not get why this happened.

Thanks in advance.

g3force commented 3 years ago

Have a look at the logs from docker-compose up. It might yield more information on why the permission error happens. Also, did you see any errors in the previous scripts?

Have you tried deleting everything ('docker-compose down -v` for everything, maybe even checking the repository out again.

Also, running the scripts with sudo is not ideal. You will have some generated files owned by root. Better give your user permission for executing docker.

I'm using Manjaro 21.0.4 with 5.4.116-1 kernel successfully.

Bollos00 commented 3 years ago

Also, running the scripts with sudo is not ideal. You will have some generated files owned by root. Better give your user permission for executing docker.

Oh. I thought it was the opposite.

Anyway, I did all the things you said and it worked. I will put here the step by step in case it helps anyone.

# Go to the repository directory
cd .../ssl-simulation-setup

# Delete everything of `docker-compose.yaml` and `docker-compose-teams.yaml` files
sudo docker-compose down -v --remove-orphans

# Delete everything of `caddy/docker-compose.yaml` file
cd caddy
sudo docker-compose down -v --remove-orphans

# Grant user permisson to use docker and reboot
sudo usermod -aG docker $USER
reboot

After rebooting I follow the steps to run the simulation and everything worked.

Thank you.

Bollos00 commented 3 years ago

By the way, I am not able to vision or referee messages. I thought it was expected behaviour, but then I saw that the erforece autoreferee was connected... Do you know what can maybe be the cause of this?

g3force commented 3 years ago

You mean, you do not receive vision or referee messages?

A common issue is, that you listen on the wrong network interface. You have two, one for the 'match' network, one for the 'guacamole' network. You need to receive on the 'match' network explicitly. If you do not specify the network interface explicitly, the system will choose one for you and it seems like in our setup, this will always be the 'guacamole' one.

For example, for QT, make sure that you call the method with the iface parameter: https://doc.qt.io/qt-5/qudpsocket.html#joinMulticastGroup-1

Bollos00 commented 3 years ago

I have three network interface available: eth0, eth1 and lo. I presume that eth0 is the network interface for match, while eth1 is the network interface for guacamole (or the other way around).

Either way, I tried both and they did not work.

Can it be the HostAdress? I am using 224.5.23.1 for the referee and 224.5.23.2 for the vision.

g3force commented 3 years ago

The host addresses are correct. The ports are 10006 for vision and 10003 for referee.

Are you using the example client from ssl-vision? https://github.com/RoboCup-SSL/ssl-vision/blob/master/src/shared/net/robocup_ssl_client.cpp#L54

You should receive messages, when you pass in the IP of the correct network interface there. You can determine the IP with running ip addr in the container. I've added the required Ubuntu package to the ubuntu-vnc base image just recently, so make sure you rebuild your own image first.

Bollos00 commented 3 years ago

The exact piece of code is similar to this:

    QUdpSocket* udpSSLVision = new QUdpSocket(this);

    udpSSLVision->bind(QHostAddress::AnyIPv4, 10006, QUdpSocket::ShareAddress);
    udpSSLVision->setMulticastInterface(interface);
    udpSSLVision->joinMulticastGroup(QHostAddress("224.5.23.2"));

    connect(udpSSLVision, &QUdpSocket::readyRead, this, &Vision::receiveVisionMessages);

The interface parameter comes from a combo box on the GUI and receiveVisionMessages is the slot that handles the data coming from the socket.

Debugging, I have compared the interface of the socket and the one showed with the command ip addr and concluded that they are the same.

We also tried to change the code showed above to:

    QUdpSocket* udpSSLVision = new QUdpSocket(this);

    udpSSLVision->bind(QHostAddress("224.5.23.2"), 10006, QUdpSocket::ShareAddress);
    udpSSLVision->setMulticastInterface(interface);

    connect(udpSSLVision, &QUdpSocket::readyRead, this, &Vision::receiveVisionMessages);

We were still not able to receive any messages.

g3force commented 3 years ago

I'm not very familiar with QT, but based on the docs, I'd rather pass the interface through the bind method. Because for setMulticastInterface, the docs say "Sets the outgoing interface for multicast datagrams to the interface iface".

Something like:

    QUdpSocket* udpSSLVision = new QUdpSocket(this);

    udpSSLVision->bind(QHostAddress("192.168.1.1"), 10006, QUdpSocket::ShareAddress);
    udpSSLVision->joinMulticastGroup(QHostAddress("224.5.23.2"));

    connect(udpSSLVision, &QUdpSocket::readyRead, this, &Vision::receiveVisionMessages);

where 192.168.1.1 would be the network address for the interface.

Bollos00 commented 3 years ago

Thanks for the support. I tried it, but it also did not work 😕

Bollos00 commented 3 years ago

For record, I found the solution and here it is:


   QUdpSocket* socket = new QUdpSocket(this); 

    if(socket->bind(QHostAddress::AnyIPv4, 10006, QUdpSocket::ShareAddress) &&
       socket->joinMulticastGroup(QHostAddress("224.5.23.2"), QNetworkInterface::interfaceFromName("eth1")))
    {
        connect(socket, &QUdpSocket::readyRead, this, &Class::slot_deal_with_socket;
    }
    else
    {
        qCritical() << "Error trying to connect with socket:\n"
                    << qPrintable(socket->errorString());
    }

This piece of code can successfully receive packets from vision. The referee is basically the same thing.