[Workaround]Strange udp socket when interchanging messages between Linux and Windows Box



  • Hi,
    I have a very strange behavior with a UDP socket. I have an application running on a Windows box that send a message via UDP Broadcast. A second application on another Windows box receives this message and answers. The first box (the one that sends the broadcast) receives the answer. So far so good and nothing strange.

    BUT: If I run the second application on a Linux box (Linux Mint 17.2 or Ubuntu 15.4) the Linux system gets the broadcast message and reply's, but the Windows box doesn't get the answer. I installed Wireshark on the Windows box and it shows that the answer from the Linux box is received by the windows box, but the readyRead signal is not emitted.

    Here is the send routine of the Windows box:

        QString data = "AutodetectRequest"
        QByteArray buffer;
        buffer.append(data);
       
        return socket->writeDatagram(buffer, QHostAddress::Broadcast, 40102);
    

    This is the routine that receives the broadcast on the Linux box (same source code as the working windows version)

    void MainWindow::onUdpAutoDetectBytesAvailable(QString data, QHostAddress sender, quint16 port)
    {
        qint64 ires;
        QString res;
        if(data == "AutodetectRequest")
        {
            ui->lblLog->append("[UDP AutoDetect] " + data + " from " + sender.toString() + " on port " + QString::number(port));
            res = "Bonjour\tName\tRole\t0";
    
            ires = udp_AutoDetect.writeData(res,sender);
            ui->lblLog->append("Send Data, result = " + QString::number(ires));
        }
    }
    

    I captured both answers (from Windows and Linux box, but cant find anything unusual.

    Here is a screenshot of the wireshark capture that shows the answer from the Windows box. This one is processed correct by the Windows box that initially send the broadcast.
    AnswerFromWindowsBox

    Here is a screenshot of the wireshark capture that shows the answer from the Linux box. This one is **not **processed correct by the Windows box that initially send the broadcast.
    AnswerFromLinuxBox

    Hope my problem is not to confusing. A short conclusion: I have application A that sends a UDP broatcast message that is received by application B. Application B answers to this message to application A. This Scenario is working is Application A and application B are running on Windows. This scenario also works if both applications running on Linux. But, it doesn't work if application A runs on Windows and Application B on Linux.


  • Qt Champions 2016

    Hi
    +1 for good problem description.

    That is really strange.

    (stupid question)
    And its not just Linux \n, Windows \r\n. line endings so it
    never considered fully read when mixing OSes. ?

    And both Qt on win/linux is same version so its not something there?



  • Both QT versions are 5.5.
    \n and \r\n is not used, only \t to have a field separator. BTW: the application that sends the broadcast message only send "AutodetectRequest" without any line ending characters. And this mesage is received by application B.
    Nevertheless I tried your suggestion and add \n and \r\n to the answer, but this does not change anything.



  • Maybe it has something to do with the binding? On both systems I use
    socket->bind(40102);
    I also tried
    socket->bind(QHostAddress::Any, 40102);
    and
    socket->bind(QHostAddress::AnyIPv4, 40102);

    but this doesn't solve the problem as well.


  • Qt Champions 2016

    @vman
    Hmm.
    And since you already have used WireShark, im kinda out of ideas for now.

    It cannot be linux firewall as that would also block linux <->linux, I assume.

    maybe try something like netcat
    https://eternallybored.org/misc/netcat/

    to see if other apps can do cross udp ?



  • Hi mrjj,

    I'm now sure it has something to do with the broadcast message. I modified application B a little bit and add a push button that sends exactly the same message that is sent as answer to the broadcast. And, surprisingly, this message is received by application A.

    Just to make clear what happens.

    I bind the udp socket on app A this way:

    socket->bind(40102);
    If I send messages from the Linux box to the Windows Box, these messages are received.

    Then I send a broadcast message from app A to app B using
    socket->writeDatagram(buffer, QHostAddress::Broadcast, 40102);
    From now on, neither the answer message from app B nor the message that was sent by push button from app B is received any more.
    So it seems that sending the broadcast message blocks the port for receiving.


  • Qt Champions 2016

    @vman said:

    sending the broadcast message blocks the port for receiving

    But why would it do that ?
    Sorry I couldn't be more helpful.



  • Well, to be precise, sending the broadcast message seems to prevent the socket from receiving messages from the Linux box. If the second app runs on windows then everything works as expected. So I'm still not 100% sure that the problem is in App A (the broadcasting app). It could be on app B as well.


  • Qt Champions 2016

    @vman
    and we 100% rule out both build-in firewalls ?



  • and we 100% rule out both build-in firewalls ?

    I think yes, otherwise I would not see the udp messages in wireshark.

    AND

    if I replace
    socket->writeDatagram(buffer, QHostAddress::Broadcast, 40102);
    with

    QHostAddress ip;
    ip.setAddress("192.168.1.7") // The IP of the box running App B
    socket->writeDatagram(buffer, ip, 40102);
    

    then it works correct. But as soon as I send a broadcast message app A can not receive any packages (again, only the the answer comes from a Linux box, the problem disappears if both are windows or both are linux)



  • OK, I use two sockets now.
    On App A I have one socket for sending the broadcast message, and a second one on another port for receiving the answer.
    Same on App B. One socket for receiving the broadcast message and a second one for sending the answer on a different port.

    Still would be very happy if someone can find a solution for this using only one udp socket.


Log in to reply
 

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