Qt 5.6.1-1: problems with incoming socket connections

robdf

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...?

kshegunov

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.

robdf

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.

http://doc.qt.io/qt-5/qtnetwork-loopback-example.html

SGaist

Are you running the examples as root ?

robdf

Yes, examples run as root.

SGaist

Can you run the application with QT_DEBUG_PLUGINS=1 ? That should show if the network plugin fails to load.

kshegunov

@SGaist said in Qt 5.6.1-1: problems with incoming socket connections:

the network plugin fails to load

There's a network plugin?

Paul Colby

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?

SGaist

@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".

kshegunov

@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 with lsof you should be able to see the socket(s) opened by your program, if there aren't any something with the server's bad.

robdf

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 there

Firewall/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

kshegunov

@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?

robdf

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!

SGaist

If you have the time and resources, it's something you might be able to reproduce with e.g. qemu.