Qt 5.6.1-1: problems with incoming socket connections



  • Hi everyone,

    I'm using Qt 5.6.1-1 (cross-compiled for an ARM device, but this shouldn't be important for the topic) and I'm experiencing unexpected problems with Qt applications which (should) accept socket connections. In short, the connection does not get established, but also isn't refused - it's like frozen.

    I compiled the Fortune Client/Server examples, and also the Loopback example. Nothing happens, no connection, no error message. The Secure Socket Client example instead works (when for example connecting to an external server) - suggesting that the problem is about accepting socket incoming connections.

    With Qt 5.5.1, cross-compiled for the same target, all works regularly.

    Any ideas or suggestions? Thanks!


  • Lifetime Qt Champion

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


  • Qt Champions 2016

    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.

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


  • Lifetime Qt Champion

    Are you running the examples as root ?



  • Yes, examples run as root.


  • Lifetime Qt Champion

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


  • Qt Champions 2016

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


  • Lifetime Qt Champion

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


  • Qt Champions 2016

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



  • 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


  • Qt Champions 2016

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


  • Lifetime Qt Champion

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


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.