Skip to content
  • 0 Votes
    13 Posts
    550 Views
    artwawA

    @jeremy_k said in TCP connection with changing IP addresses:

    You guys are seriously pessimistic about the state of end-to-end connectivity!

    I am sysadmin with over 20y of experience. "I've seen things you people wouldn't believe", to quote a classic.
    Serious note aside - the fact that something is possible doesn't mean one should try it. There's lots of "it depends on the use case" but I've had large enough share of commercial products with design compromising network security. That "pessimism" is perfectly warranted.

    More to the topic - I personally think the OP's design is abysmal in terms of security. Can they make it work? But of course. Would I allow such a solution in the network I manage? Under no circumstances.
    My advice here would be for the clients to report to the server's API at certain intervals, doing push-pull (so server would need a queue). Let's leave p2p connections for the LAN games.

    Other than that I think one can make it using UPNP, where target IP is safely obtained from the server's API together with a shortlived key used to validate incoming connection on the other end, but that's borderline already.

  • 0 Votes
    6 Posts
    413 Views
    T

    Oh well. I am calling wget to get things accomplished. Nice work around that also takes care of redirects and all that.

  • 0 Votes
    3 Posts
    298 Views
    C

    If something else sends a UDP datagram to the sub-net IP broadcast address (e.g. 192.168.1.255 on IP subnet 192.168.1.0/24) then any device connected to, and configured for, that IP sub-net should receive the datagram. You need to know the port that the UDP datagram was sent to also.

    Assuming your listeneing device is connected to the relevant physical network and has suitable IP address/subnet mask, then all you should need is to QUdpSocket::bind() to your IP and port.

  • 0 Votes
    13 Posts
    1k Views
    JoeCFDJ

    @MEsc Check Archive and then press Filtern button. You will get all the stuff of 6.4.0. Sorry. you are doing on Windows. Things could be different.

  • 0 Votes
    5 Posts
    597 Views
    SGaistS

    AFAIK, if this does happen you likely have other bigger issues. The signal is not related to the success of the request.

  • 0 Votes
    5 Posts
    1k Views
    S

    @SGaist I didn't in fact ( and I can't in the short term).

    Just to clarify I'll mention the documentation related to this 'bearer stack removal' : Qt Network in Qt 6.
    It also leads to QTBUG-86966 where QNetworkInformation is presented as solution for "Reachability" device state checks!!

    However I still can't find anything that tells me how to overcome my "NoInternetAccess" device state related problem.

    But that's great news!!
    Maybe my problem has already been taken care of.

    Thanks!!

  • 1 Votes
    4 Posts
    641 Views
    piseprashanthP

    Basically you missed to add addHostSideConnection on server side. Here is below code snippet.

    // server side
    void onNewServerConnection()
    {
    qDebug() << "onNewServerConnection";
    bool newConn = false;
    if(auto tcpServer = qobject_cast<QTcpServer*>(sender()))
    {
    while(tcpServer->hasPendingConnections())
    {
    newConn = true;
    m_pHost->addHostSideConnection(tcpServer->nextPendingConnection());
    }
    }
    }
    // Use standard tcp url for the registry
    const QUrl registryUrl = QUrl(QStringLiteral("tcp://127.0.0.1:65212"));
    // Use "exttcp" for the "external" interface
    const QUrl extUrl = QUrl(QStringLiteral("exttcp://127.0.0.1:65213"));

    // Create the server and listen outside of QtRO // QTcpServer tcpServer; auto tcpServer = new QTcpServer(this); auto host = extUrl.host(); // We only know how to handle tcp:// and local: bool res = false; res = tcpServer->listen(QHostAddress(extUrl.host()), extUrl.port()); if(res) { // m_servers.insert(url, server); connect(tcpServer, &QTcpServer::newConnection, this, &YourClass::onNewServerConnection); } else { qWarning().nospace() << "server could not listen on URL: " << extUrl.toString() << ". Error type: " << tcpServer->serverError() << ", message: " << tcpServer->errorString(); delete tcpServer; } // We need a registry for everyone to connect to QRemoteObjectRegistryHost registry(registryUrl); // Finally, we create our host node and register "exttcp" as our schema. // We need the AllowExternalRegistration parameter to prevent the node from // setting a hostUrlInvalid error. m_pHost = new QRemoteObjectHost(extUrl, registryUrl, QRemoteObjectHost::AllowExternalRegistration); // From now on, when we call enableRemoting() from this node, the registry // will be updated to show the Source object at extUrl.

    ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
    OnClient side
    // Use standard tcp url for the registry
    const QUrl registryUrl = QUrl(QStringLiteral("tcp://127.0.0.1:65212"));

    // This time create the node connected to the registry QRemoteObjectNode repNode(registryUrl); // Create the RemoteObjectSchemaHandler callback QRemoteObjectNode::RemoteObjectSchemaHandler setupTcp = [&repNode](QUrl url) -> void { QTcpSocket *socket = new QTcpSocket(&repNode); connect(socket, &QTcpSocket::connected, [socket, &repNode]() { qDebug() << "Added client side connection"; repNode.addClientSideConnection(socket); }); connect(socket, &QSslSocket::errorOccurred, [socket](QAbstractSocket::SocketError error) { qDebug() << "Deleted socket"; delete socket; }); qDebug() << "Connected to host with URL: " << url.host() <<":" << url.port(); socket->connectToHost(url.host(), url.port()); }; // Once we call registerExternalSchema, the above method will be called // whenever the registry sees an object we are interested in on "exttcp" repNode.registerExternalSchema(QStringLiteral("exttcp"), setupTcp); // local replica // QRemoteObjectNode repNode; // create remote object node // m_pHost = new QRemoteObjectHost(QUrl(ss.str().c_str())); // repNode.connectToNode(QUrl(ss.str().c_str())); //QUrl(QStringLiteral("local:replica"))); auto ptr = repNode.acquireDynamic("something");
  • 0 Votes
    8 Posts
    924 Views
    SGaistS

    Great !

    The patch submission is a really good idea. Do not hesitate :-)

  • 0 Votes
    17 Posts
    7k Views
    I

    @Christian-Ehrlicher Thanks dear. I will use this

  • 0 Votes
    18 Posts
    2k Views
    JonBJ

    @Sprezzatura
    I think this looks better :)

    Your code as it stands presumably leaks QNetworkRequest *request = new QNetworkRequest(url); and QNetworkAccessManager *nam = new QNetworkAccessManager;. You could put these on the stack (no pointers, no new). And I think you're supposed to deleteLater() the QNetworkReply *reply = nam->post(*request, content);.

    You can get away without, but one day when you want examine your code for memory leaks with e.g. valgrind it will be better.

  • 1 Votes
    1 Posts
    535 Views
    No one has replied
  • 0 Votes
    3 Posts
    1k Views
    lopeztelL

    @sierdzio thanks a lot for the pointer and example document, I will look into this

  • 0 Votes
    4 Posts
    1k Views
    JonBJ

    @beecksche said in QFileSystemModel doesn't support the network paths and external drives?:

    I think the easiest way is to write your own file system model.

    Or, presumably extend QFileSystemModel by subclassing it.

    @jeanmilost
    I just don't think you can access network, as per https://stackoverflow.com/a/33856139/489865 and @beecksche's comment above.

  • 0 Votes
    1 Posts
    687 Views
    No one has replied
  • 0 Votes
    9 Posts
    3k Views
    QjayQ

    hey i didn't fixed it . i downloaded Qt5.12.4 and then upgraded my openssl lib to 1.1.1b

    so i am good now
    thanks !!

  • 0 Votes
    10 Posts
    2k Views
    Pablo J. RoginaP

    @NeuroSamuel said in Connecting to secondary WLAN interface:

    My problem is that I see no way to open a QNetworkSession from one of those configurations choosing the hardware interface.

    Is not something you (or your sysadmin) did already when configuring the networking devices for your system?
    Not that I have that much experience with QNetworkSession, but it looks that behavior to be fine, given that you are setting one WLAN interface to one SSID at OS level. Thinking of wpa_supplicant on Linux for instance:
    wpa_supplicant.conf

    network={ ssid="home" scan_ssid=1 key_mgmt=WPA-PSK psk="very secret passphrase" }

    and then command line:

    wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -d

    Because at the end it'll be a question of OS routing, won't it?

  • 0 Votes
    4 Posts
    1k Views
    aha_1980A

    @ClingerWinger Glad you figured it out and thanks for the feedback :)

  • 0 Votes
    6 Posts
    39k Views
    I

    In our efforts trying to authenticate our Qt app with Google SSO, we had to use http://127.0.0.1:1234/ as our redirect URI, ignoring the documented advice. If we pick the first URL that Google provides, our app never hears back from the login flow.

  • 0 Votes
    8 Posts
    3k Views
    C

    @VRonin said in Need Help with getting a slot executed in the correct thread:

    the default implementation of QThread::run starts an event loop so if you use the method described in that link everything will work out of the box

    Indeed it does! Thanks!