Qt 5.6.1-1: problems with incoming socket connections

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