Folks,
I've managed to get a simple program going that sends out a UDP packet
to a broadcast address (an Artnet Poll packet) and my embedded software
is receiving this and sending out a Poll reply. Wireshark confirms that
my embedded device is sending out the correct response, however, my Qt
p
Em seg 23 jun 2014, às 13:03:03, Robert Wood escreveu:
> Folks,
>
> I've managed to get a simple program going that sends out a UDP packet
> to a broadcast address (an Artnet Poll packet) and my embedded software
> is receiving this and sending out a Poll reply. Wireshark confirms that
> my embedd
24 June 2014 12:03 a.m.
To: interest@qt-project.org
Subject: [Interest] Simple UDP listener question
Folks,
I've managed to get a simple program going that sends out a UDP packet to a
broadcast address (an Artnet Poll packet) and my embedded software is receiving
this and sending ou
r())->errorString());
> }
>
> Tom Isaacson
>
> -Original Message-
> From: interest-bounces+tom.isaacson=navico@qt-project.org
> [mailto:interest-bounces+tom.isaacson=navico....@qt-project.org] On Behalf Of
> Robert Wood
> Sent: Tuesday, 24 June 2014 12:03 a.m.
>
On Mon, Jun 23, 2014 at 10:41 AM, Robert Wood
wrote:
> The QHostAddress("192.168.0.18") should be the IP address of my computer
> shouldn't it? I'm not really clear why this is necessary as I would
> assume Qt would automatically pick that up? Or is it in case you have
> more than one NIC and you
Maybe you should only use 1 socket instead of 2.
UDP only needs to bind to receive, but can send without binding as long
as you use sendto( ) calls.
On 6/23/2014 1:45 PM, Ian Monroe wrote:
> On Mon, Jun 23, 2014 at 10:41 AM, Robert Wood
> wrote:
>> The QHostAddress("192.168.0.18") should be the
There does seem to be a sendTo() function within the class. If I don't
bind it and use writeDatagram it doesn't send anything out.
On 23/06/14 19:04, m...@rpzdesign.com wrote:
> Maybe you should only use 1 socket instead of 2.
>
> UDP only needs to bind to receive, but can send without binding as
Em seg 23 jun 2014, às 19:21:21, Robert Wood escreveu:
> There does seem to be a sendTo() function within the class. If I don't
> bind it and use writeDatagram it doesn't send anything out.
writeDatagram() takes a destination address and port. If that doesn't work,
please provide a testcase.
Unf
Sorry, I meant to write there does *not( seem to be a sendTo() function.
Writing out with writeDatagram() works just fine as long as I bind
first; it's the receiving part that just will not work, even if I
faithfully follow the example. I must be missing a fundamental aspect of
this somewhere,
Em seg 23 jun 2014, às 19:50:44, Robert Wood escreveu:
> Sorry, I meant to write there does *not( seem to be a sendTo() function.
>
> Writing out with writeDatagram() works just fine as long as I bind
> first; it's the receiving part that just will not work, even if I
> faithfully follow the examp
It can't be a randomly allocated port though, it has to be port 6454.
On 23/06/14 20:33, Thiago Macieira wrote:
> Em seg 23 jun 2014, às 19:50:44, Robert Wood escreveu:
>> Sorry, I meant to write there does *not( seem to be a sendTo() function.
>>
>> Writing out with writeDatagram() works just fin
On 6/23/2014 4:27 PM, Robert Wood wrote:
> It can't be a randomly allocated port though, it has to be port 6454.
I realize I've come into this conversation late, but something like:
receive_socket = new QUdpSocket(this);
receive_socket->bind(QHostAddress::Any, 6454);
wouldn't work for yo
Em seg 23 jun 2014, às 23:27:58, Robert Wood escreveu:
> It can't be a randomly allocated port though, it has to be port 6454.
The sender port is randomly allocated, if you don't specify one.
If you need it to be sent *from* 6454, then you need to bind before
writeDatagram.
--
Thiago Macieira
Yes, Bob, that's exactly it.
On 192.168.0.18 I have stripped it right down to this this:
udpSocRec = new QUdpSocket(this);
udpSocRec->bind(QHostAddress::Any, 6454);
connect(udpSocRec, SIGNAL(readyRead()),this,
SLOT(processPendingDatagrams()));
processPendingDatagrams() never gets ca
Am 24.06.2014 10:38, schrieb Robert Wood:
Yes, Bob, that's exactly it.
On 192.168.0.18 I have stripped it right down to this this:
udpSocRec = new QUdpSocket(this);
udpSocRec->bind(QHostAddress::Any, 6454);
connect(udpSocRec, SIGNAL(readyRead()),this,
SLOT(processPendingDatagrams(
Hi Rainer,
It says this:
udp0 0 0.0.0.0:64540.0.0.0:*
If I stop my app, that disappears, if I change it to listen on
192.168.0.18 by changing this line:
udpSocRec->bind(QHostAddress("192.168.0.18"), 6454);
I get this:
udp0 0 192.168.0.18:6454
Am 24.06.2014 13:02, schrieb Robert Wood:
It says this:
udp0 0 0.0.0.0:64540.0.0.0:*
If I stop my app, that disappears, [...]
Ok, so your app can create the socket. Just to make sure: You _are_
running an event loop (Q{Core,}Application::exec())!?
Best Regards /
Yes, I'm creating a standard Qt GUI using Qt Creator. With the same app,
I can send out packets over and over again. I've just got that bit
removed at the moment in an attempt to simplify things as much as possible.
On 24/06/14 12:17, Rainer Wiesenfarth wrote:
> Am 24.06.2014 13:02, schrieb Robe
Hmmm, it's an issue with my desktop (192.168.0.18). If I swap things
around and send from my desktop to the laptop, the laptop is working and
seeing the packets. I can use netcat to test things both ways and that
too will acdept nothing into the desktop. Weird. So, it's sack all to do
with Qt a
Em ter 24 jun 2014, às 09:38:22, Robert Wood escreveu:
> I've tried changing the port to 123 to capture incoming NTP packets
> which, again, Wireshark says are present, but to no avail.
You can't bind to port 123. That's a privileged port.
--
Thiago Macieira - thiago.macieira (AT) intel.com
So
Hi,
check the Firewall on this Desktop - most of the time when I have these
kinds of problems it's the firewall's fault. Wireshark usually shows all
packets that arrive at the ethernet card before they are filtered, then
the firewall kicks in and last the program may (or may not) receive
something
Just for the sake of preventing someone banging their head against a
brick wall for ages in the future, this turned out to be the fact that
some of the returning UDP packets were being picket up by the *sending*
socket. If I only open one socket, both sending and receiving on it, the
whole thin
On Wednesday 02 July 2014 14:39:58 Robert Wood wrote:
> I suspect many people haven't come across this before because, I guess,
> normally, you don't send and receive on the same port. Artnet specifies
> you have to and so this issue raises its ugly head.
I think sending and receiving using the
23 matches
Mail list logo
