Unsolved Qt 5.6.1-1: problems with incoming socket connections
-
Hi,
Can you check with a more recent version of Qt ? E.g. 5.7 or even 5.8 beta ?
-
Thank you @SGaist, unfortunately I can't cross-compile any Qt version starting from 5.7.0 because my compiler doesn't meet the requirements (C++11). I guess it only would make sense to try on the target...?
-
Hi,
Are you using threading for the server, if so how? You should make sure you're not blocking the event loop server-side, as this would pretty much result in the described behavior.Kind regards.
-
Hi @kshegunov, thanks, I understand your point, but it's not about threading. The loopback example, which as said doesn't work, doesn't create any secondary threads.
-
Are you running the examples as root ?
-
Yes, examples run as root.
-
Can you run the application with
QT_DEBUG_PLUGINS=1
? That should show if the network plugin fails to load. -
@SGaist said in Qt 5.6.1-1: problems with incoming socket connections:
the network plugin fails to load
There's a network plugin?
-
cross-compiled for an ARM device
Not knowing the details, it might be worth checking if your device has a firewall / iptables running. Its pretty common for those to block incoming connections, while allowing outgoing connections.
Are you able to use a packet sniffer (Wireshark / tcpdump) to verify that he connection requests are indeed arriving?
-
@kshegunov said in Qt 5.6.1-1: problems with incoming socket connections:
@SGaist said in Qt 5.6.1-1: problems with incoming socket connections:
the network plugin fails to load
There's a network plugin?
Yes: bearer plugins but in the case of these examples it's not used so it's a "sword strike in the water".
-
@SGaist said in Qt 5.6.1-1: problems with incoming socket connections:
Yes: bearer plugins but in the case of these examples it's not used so it's a "sword strike in the water".
Yes I know these, but I always thought they were for WiFi.
@robdf said in Qt 5.6.1-1: problems with incoming socket connections:
Yes, examples run as root.
Try running them with a regular user, there might be some security feature in place. Also make sure there's any incoming connection allowed by using something else for a client (e.g.
netcat
). Also withlsof
you should be able to see the socket(s) opened by your program, if there aren't any something with the server's bad. -
Thank you for all the useful inputs. Here all the answers:
Run with QT_DEBUG_PLUGINS=1
The only loaded plugin is libqxcb.so, no problems thereFirewall/iptables
No firewall is active. In any case, if I just substitute the Qt libraries with version 5.5.1, all works (without making any other changes to the system, and without rebooting).Packet sniffer
That would be a good idea indeed, but I don't have such tools on this target and trying to compile them would be an effort.Running as regular user
No difference at all...netcat, lsof
Unfortunately I don't have such tools on the target. But the socket is open, of this I'm sure.netstat
But I can use netstat. Let's say I launch the Fortune Server example. It says it listens on 192.168.0.203:53664. Netstat's output is:netstat -l [...] tcp 0 0 0.0.0.0:53364 0.0.0.0:* LISTEN [...]
Now I start the fortune client and fill in the connection parameters. As I click "Get Fortune", the button remains grayed and nothing happens. This is now netstat's output:
netstat [...] tcp 0 0 localhost:53364 localhost:34420 ESTABLISHED tcp 0 0 localhost:34420 localhost:53364 ESTABLISHED [...]
No activity at all. If I close the server, the client "unlocks" and the "Get Fortune" button becomes again clickable.
Recompiling the Fortune Server with appropriate log messages show that Server::sessionOpened() gets executed at the beginning, but after trying the connection, Server::sendFortune() doesn't get executed at all.
But as it is:
connect(tcpServer, &QTcpServer::newConnection, this, &Server::sendFortune);
it seems that the signal QTcpServer::newConnection doesn not get emitted...
Here's for reference the link to FortuneServer's server.cpp source:
http://doc.qt.io/qt-5/qtnetwork-fortuneserver-server-cpp.html -
@robdf said in Qt 5.6.1-1: problems with incoming socket connections:
No firewall is active. In any case, if I just substitute the Qt libraries with version 5.5.1, all works
It's possibly a regression, or the examples aren't updated or something of the like.
Unfortunately I don't have such tools on the target.
You can still
netcat
from the host, no need to do it from the target. Also is the device wire-connected to the ethernet, what's the distro it's running? -
Hi @kshegunov, thanks for your inputs.
Sorry for the delay, the target is not under my direct control and I can not easily make experiments. I managed to try with
netcat
. So, here's what happens with a working fortuneserver on the target, using Qt 5.5.1:bash-4.1# nc target 9999 -v -v [...].in-addr.ntrnet.it [<ip address>] 9999 (?) open JFYou've got to think about tomorrow. sent 0, rcvd 76
And here's what happens with Qt 5.6.1-1 libraries:
bash-4.1# nc target 9999 -v -v [...].in-addr.ntrnet.it [<ip address>] 9999 (?) open
I restate, as in my last post, that the signal
QTcpServer::newConnection
doesn not get emitted...We reverted to Qt 5.5.1 and have no need anymore to fix this problem. Also, I won't have occasions to make any further experiments, as the target is in a production environment, and it's difficult to arrange such test sessions. I hope nevertheless this experience can be useful to others? Would be nice indeed to understand if there is a regression in Qt 5.6.1-1.
Thanks!
-
If you have the time and resources, it's something you might be able to reproduce with e.g. qemu.