Help form a QByteArray to send it to stun.ekiga.net server in a UDP datagram. The application, written by me on the basis of the kindly provided assistance to me, sends only empty requests and not identified by Wireshark as requests under the STUN protocol, alas .. The package should look like this: right-request-to-stun http: // img-host.org.ua/images/1vlv.png And sent by my application looks like this: my-wrong-request http://img-host.org.ua/images/2hl.png And this happens even when I used. I guess I used it incorrectly. Therefore, I refused functions like qToBigEndian and qFromBigEndian - and began simply to add the necessary fields, having first converted them to a binary form. This is how my code finally began to look like, again, idle:

UdpToStun::UdpToStun(QObject *parent) : QObject(parent) { port = 3478; sock = new QUdpSocket(); lstd = new QUdpSocket(); connect(lstd, SIGNAL(readyRead()), SLOT(read())); lstd->bind(QHostAddress::Any, port); // хочу и ответ же получить, вот и открываю слушающий сокет QByteArray ba; ba.append(0x1); // Тип запроса: 1 - binding request ba.append(0x0); // Тип сообщения: 0 - reguest ba.append(100001000100101010010001000010); // Это бинарное представление magic cookie, они у STUN'а по стандарту всегда равны 0x2112A442 sock->writeDatagram(ba, QHostAddress("217.10.68.152"), port); }
  • The first and second bytes, judging by the pattern on the first screen, are recorded correctly. The problem, it turns out, arises further. Why in QByteArray do you write a huge integer instead of 0x2112A442 ? - alexis031182
  • @ alexis031182, No, unfortunately, the first two bytes are as incorrectly written as all subsequent ones (regarding them: they fall as BITES in the 1st and 2nd position of byte No. 1, and starting from byte No. 2 "stuffing" of the number 0x2112A442). And just need to make it the way you assumed. Over the past day I have already tried many different ways to send a "complete" datagram to a STUN server, but did not succeed in this .. - aversilov

1 answer 1

It seems to me that the problem is in the type of numbers sent. I spied on a githabe one of the projects that was implemented without using Qt and 16-bit unsigned integers are sent there. Did you QDataStream to send data through a QDataStream appropriate type? QDataStream defaults to the data in the Big Endian Order , as required, based on the protocol description.

In theory, the request generation code should look like this:

 QByteArray data; { QDataStream stream(&data, QIODevice::WriteOnly); stream << quint16(0x1) << quint16(0x0) << quint32(0x2112A442); } sock->writeDatagram(data, QHostAddress("217.10.68.152"), port);

If this option does not work, then it probably makes sense to use the QDataStream::writeRawData(const char *s, int len) , converting the numbers on your own, according to the type of implementation, for example, in that project, the link to which I pasted a little higher.

  • Comments are not intended for extended discussion; conversation moved to chat . - Nick Volynkin ♦