Re-connecting to QDBus server after server has been restarted (Qt C++) - c++

I'm testing out using DBus for inter process communication for an QT C++ project (Linux).
I'm not using the bus daemon and i'm using unix paths / sockets.
After navigating my way through the mysterious world that is QT DBUS all seemed to be going well, until i wanted to test the robustness of one of my interfaces.
After killing the server process en restarting it, the connection times out.. i cleanup the connection objects (client-side) and i try to re-connect to the server.
The client does not seem to be able to reconnect and i get the following errors:
errName: org.freedesktop.DBus.Error.NoServer
errMesage: Failed to connect to socket /tmp/abcd: Connection refused
Ive tried:
- QDBusConnection::disconnectFromPeer(addr);
- cleaning up all related object, so no references to the connection exist.
When i restart the client, it has no problems connecting to the (restarted) server.

Problem found!
Seems to be a bug in Qt 4.8.x:
https://bugreports.qt.io/browse/QTBUG-27973
https://codereview.qt-project.org/#/c/60709/
QDBusConnection::disconnectFromBus and QDBusConnection::disconnectFromPeer does not remove invalid connection

Related

Disconnecting From Qt VNC Server causes Segmentation Fault on Server

I'm running my application with Qt 5.15.10 on Linux with VNC. I'm developing a Qt based VNC client but when disconnecting I encounter a segmentation fault on the server. This does not occur with existing vnc clients such as RealVNC and TightVNC.
Packet captures show I'm sending and receiving the FIN,ACK on the TCP socket and I'm also sending the final ACK same as the other two applications.
I've tried disconnecting using QAbstractSocket::disconnectFromHost() and just QAbstractSocket::close() with the same result.

boost.asio + native windows sockets

We have a framework that communicates via native WinAPI sockets (WSASend , CompletionPorts, etc) via TCP.
Recently, we've added some classes to this framework that also async sends and receives some messages via UDP, but these classes use Boost.ASIO (io_context etc).
Since then, we noticed that WinSocks connect function fails, with the following error:
A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection
failed because connected host has failed to respond. The thread 0x3038
has exited with code 0 (0x0)
This only fails when connecting to a remote computer, not locally.
When reverting to an older version without these Boost classes, everything works fine (ruling out firewall issues)
When the Boost.ASIO classes our used outside of the framework, they work fine.
We are unsure what causes this issue. My hunch is that it is a conflict on OS level between winsock and boost.ASIO.
Did anyone run into something similar? Any ideas or pointers would be really appreciated.
Ben

boost1.62 socket broken after reconnect in docker container

we have a c++ Application with boost1.62 and libssl1.0, that opens a TLS connection to a lighttpd Webserver (remote).
This works fine on any device we already rolled out. Now we are trying to use this application inside a container. The application starts up and everything is fine but.
When the connection gets reset for any reason, the application attempts to reconnect by making a new TCP-Connection with the socket.
Creating a HTTPS-Connection with TLS over that socket fails with EOF. Then the application tries to reconnect and gets the same fault -> endless reconnection loop.
I recorded the traffic and have seen the following:
Everything is alright
A TLS-Alert is recorded, sometimes also a TCP RESET.
Client sends SYN
Server sends SYN ACK
Client sends ACK
Client sends FIN, ACK
Server sends ACK
Server sends FIN, ACK
Client sends ACK
Steps 3 to 7 occur in less than 3 ms.
as soon as Step 7 has passed, a new connection is made starting with step 3.
I'm using an ubuntu 18.04 on host and as base image. (Both x64)
Both host and container use the same libraries. Therefore i think its not an issue with used libraries.
The application runs in production for over a year on several arm32v7 and x64 devices. This error never occurred then.
Oddly, if the application is configured to use plain HTTP instead HTTPS, the error does not occur.
Any suggestions what this might be? Based on my knowledge i can rule out the following:
wrong dependencies
misconfigured Kernel (container and host use the same)
Thanks for your help
After a disconnect, we reused the old socket. This works flawless outside docker. Inside docker it produces the described behaviour.
Workaround: delete the broken socket and create a new one.
This is bad for performance though.

QtApplication in Netbeans: "Not connected to D-Bus server"

I have created simple QtGui Application in QtCreator. it works.
then I have created QtApplication in Netbeans and added files generated in Creator (mainwindow.h,cpp,ui_mainwindow.h) to new Netbeans project.
it compiles, links, builds.
when I try to run executable, the window appears but there is also this message:
root#comp:~/NetBeansProjects/QtApplication_3/dist/Debug/GNU-Linux-x86#
./QtApplication_3 Qt at-spi: error getting the accessibility dbus
address: "Not connected to D-Bus server" Accessibility DBus not
found. Falling back to session bus. Could not connect to DBus. Could
not connect to dbus.
(process:10309): GConf-WARNING **: Client failed to connect to the
D-BUS daemon: Did not receive a reply. Possible causes include: the
remote application did not send a reply, the message bus security
policy blocked the reply, the reply timeout expired, or the network
connection was broken.
** (QtApplication_3:10309): WARNING **: Unable to create Ubuntu Menu Proxy: The connection is closed
root#ubuntuamd:~/NetBeansProjects/QtApplication_3/dist/Debug/GNU-Linux-x86#
how is this related to network connection? this is just window.
is my approach OK to copy the code generated in Creator? maybe then I have to do something additionally?
here I have found some tips regarding these errors

Check remote host state in a nework using Indy comps

I have client server application that works with Firebird server. Everytime when clients connect to the server they(client apps) don't check if there is a network connection to the server so at this time my application sometimes freezes when the server computer is switched off or service has stopped, so first of all I need to check connection if remote host is switched on or at some port anything listening....
Before establishing the connection I need to check it and make sure server and service is running using Indy components.
Any ideas? also I can use IcmpClient to ping remote host and then establish connection but which is the most optimal way ?
If you just want to check if the server computer can be reached, you could do a "ping" to check that. However, if you want to check if a specific TCP port is open, then the only way to find that out is to actually do a proper connect, which leads to the "freezing" program while the connection times out if there is no-one listening on that port.