Hello Johnny,
Thank you for the explanation. That's an important remark so I can
continue the evaluation here.
I was thinking that the issue was related to the MQTT library. But, in
fact, there is something wrong with the TCP connection.
I will post here as soon as I have more news.
Best regard
Something is seriously wrong in your first run.
Maybe a tcpdump would expose something, but basically, tcp_max_wrb_size
should never be 0, but in your first run it appears to be.
As that is the buffer size to use, you end up with a tcp connection with
a buffer size of 0, so of course all write
I'm sorry ... I got the same behavior, but the send function now
started to work non-blocking.
Here is my situation:
* I have 2 mqtt brokers (tcp servers)
- one commercial (Tago.io)
- one personal (Mosquitto)
After a successful connection in both cases, the next step is to send
the mqtt conn
Is there any chance that the broker didn't like the mqtt connect
message and shutdown the connection and leaving my device alone ...
all during send call?
If the peer disconnects, the socket should be marked disconnected and
the send() should fail with an error.
Is there any chance that the broker didn't like the mqtt connect
message and shutdown the connection and leaving my device alone ...
all during send call?
Em sáb., 26 de jun. de 2021 às 11:42, Flavio Castro Alves Filho
escreveu:
>
> Hello Greg,
>
> No. It was not set :-(
>
> I turned on the confi
Hello Greg,
No. It was not set :-(
I turned on the configuration, but the problem persisted. :-(
Best regards,
Flavio
Em sáb., 26 de jun. de 2021 às 10:41, Gregory Nutt
escreveu:
>
> Do you have CONFIG_NET_TCP_WRITE_BUFFERS=y selected? It is required for
> TCP non-blocking send.
>
--
Flav
Do you have CONFIG_NET_TCP_WRITE_BUFFERS=y selected? It is required for
TCP non-blocking send.
