QTcpSocket::connect behaviour callen from Terminal vs. QtCtreator

Johannes_ADS

Hello,
I have a strange behaviour of my program:
Operating System: Linux Mint, with all updates
Qt5 has been installed according to how to install qt5 in Mint (stackoverlfow)

QTcpSocket tcpSpA;

tcpSpa.connectToHost("192.168.123.80",  5025);

When I execute the program from inside QtCreator (debug and release) the lines above execute correctly. The signal "connected" is emitted immediately.

When I execute the program from a terminal the connectToHost does not return. Also no error is emitted.

In contrary when I try this on OpenSuse (Tumbleweed), there is no difference between QtCreator and Terminal, everything works fine.

Any idea what could cause this strange behaviour? Missing path? Environmentvariable.

JonB

@Johannes_ADS said in QTcpSocket::connect behaviour callen from Terminal vs. QtCtreator:

When I execute the program from a terminal the connectToHost does not return.

This ought not be the case.

Any idea what could cause this strange behaviour? Missing path? Environmentvariable.

Not that I can think of which would affect that behaviour.

Also no error is emitted.

void QAbstractSocket::connectToHost()) does not emit any errors, nor does it return any value or stop on that line. Rather as it says there

At any point, the socket can emit errorOccurred() to signal that an error occurred.

You need to connect a slot to that signal to see if something is reported. (You should always have that anyway in all production code, and of course in development code too; you never know when an error might occur.) Put a qDebug()/cout message immediately above & below your connecttoHost() line to make sure you know it is being called and has continued.

Does your 5025 port accept multiple connections? If not, make sure you do not somehow have an instance of your program still running which has bound to that port.

Johannes_ADS

Hi,
thanks for the fast answer.

When I wrote "no error is emitted", I meant that the signal error() is not emitted. I have connected a slot to this signal.
Unfortunately I have to use Qt 5.12 functions, where errorOccurred() is not yet supported.

I have already followed your proposal to place a "cout" directly after the line and it is not executed when run from the terminal, only when run from inside QtCreator.

We have made sure, that there is only one instance running....

JonB

@Johannes_ADS
OK, if you have indeed put a cout both before & after the connectToHost() that implies it is "hanging/not returning".

I believe that prior to errorOccurred()/Qt 512 you can/should use void QAbstractSocket::stateChanged(QAbstractSocket::SocketState socketState) signal. Attach a slot to that and see what state changes your socket undergoes.

BTW, to check the situation outside of your Qt program, use

telnet 192.168.123.80 5025

from the terminal. Does that tell you anything? (You may have to kill the telnet afterwards.)

Christian Ehrlicher

@JonB said in QTcpSocket::connect behaviour callen from Terminal vs. QtCtreator:

telnet 192.168.123.80 5025

This is not the same since there's no resolving needed here. Maybe telnet "192.168.123.80" 5050 will trigger a dns resolving but I doubt it. Better try host -v 192.168.123.80.
I would guess it's a dns resolver problem. You can try to use tcpSpa.connecToHost(QHostAddress("192.168.123.80"), 5025)) to avoid the resolving and see if I'm correct.

JonB

@Christian-Ehrlicher
I was only using that to check that the port (5025) on that IP address is open/connectable, or whether the OP sees some message. Numerous times my customers say "Your software is not listening on the machine/port, it doesn't work", so I get them to try this and they realise they have the wrong IP, port or aren't running the daemon. Isn't it useful for that?

Is it not useful here? Yes, it's a numeric IP address so there is no host name lookup needed. I don't understand what you are saying in that light, but I'm always interested to understand/be taught?!

Christian Ehrlicher

@JonB QTcpSocket::connectToHost(const QString &hostname, ...) takes a hostname which will be resolved, no matter if you already pass an ip as string here or not whereas QTcpSocket::connectToHost(const QHostAddress &addr, ..) takes a QHostAddress so no resolving is needed. When the first version of connectToHost() 'hangs' it's most likely it's waiting for the dns resolver, at least in my experience.

Johannes_ADS

Hello,
the situation is still the same, starting the program from the terminal, it cannot connect to the remote device. If I start it from within Qt Creator, everything works and connection is established.
What I have done:

made sure that firewall is disbaled
Tested the connection with telnet: connections established, commands can be sent
made sure, that only one program is running so that the port is not blocked
used QHostAddress as proposed above
my code:

        QHostAddress HA("192.168.123,80");
        tcpSpA.connectToHost(HA, Port);

.I have connected to the stateChanged signal and the output is as follows:

from the terminal:

2022-05-05T08:58:37.006Z Connection state: 1
2022-05-05T08:58:37.006Z Connection state: 2

so it hangs while trying to establish connections.

started from within QtCreator:

2022-05-05T08:59:32.412Z Connection state: 1
2022-05-05T08:59:32.413Z Connection state: 2
2022-05-05T08:59:32.418Z Connection state: 3
2022-05-05T08:59:32.419Z Connected to 192.168.123.80 5025

Maybe this is not resolveable from remote. I thought someone might say: "Ahhhh, you have to setup this environment varable..." or change the path variable... :-)