Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

client.publish fails #216

Open
gilmntg opened this issue Dec 3, 2016 · 2 comments
Open

client.publish fails #216

gilmntg opened this issue Dec 3, 2016 · 2 comments

Comments

@gilmntg
Copy link

gilmntg commented Dec 3, 2016

Hi,
I'm using publish() method from within an os_timer callback
Return value of the publish is false as if publish failed - however message does arrive to broker.
After few minutes of operation, system crashes...
What am I doing wrong?
Thanks
Gil

@adaszek
Copy link

adaszek commented Dec 4, 2016

I have the same problem. Data is published successfully, but publish() returns false although state() returns MQTT_CONNECTED. Error occurrence is rather random.

Here is my implementation where error occures.

It seems, that in line 462 of PubSubClient.cpp, write returns different size than size of data prepared to transfer over client:
rc = _client->write(buf+(4-llen),length+1+llen);

When I print out value of rc, it looks like in error cases rc is equal to size of currently sending buffer + size of previous buffer. An example:

Publish attempt 1 		raw/sensor/ardClient1/temperature
rc=41
bufsize=41
Success				connected
----
Publish attempt 1 		raw/sensor/ardClient1/humidity
rc=79
bufsize=38
Failed to publish		connected
Publish attempt 2 		raw/sensor/ardClient1/humidity
rc=38
bufsize=38
Success				connected
----
Publish attempt 1 		raw/sensor/ardClient1/voltage
rc=75
bufsize=37
Failed to publish		connected
Publish attempt 2 		raw/sensor/ardClient1/voltage
rc=37
bufsize=37
Success				connected
----
Publish attempt 1 		raw/sensor/ardClient1/temperature
rc=41
bufsize=41
Success				connected
----

if I understood properly, _client is actually an instance of RF24Client if I use RF24, isn't it?

@adaszek
Copy link

adaszek commented Dec 18, 2016

I did a TCP dump from tun interface where my arduino is connected to and there is a correlation between failed publish() and TCP ACK for MQTT PING RESPONSE sent from broker:

...
"15","17.495376","10.10.3.30","10.10.3.13","MQTT","71","Ping Request, Publish Message"
"16","17.496005","10.10.3.13","10.10.3.30","TCP","40","1883 → 1025 [ACK] Seq=1 Ack=244 Win=28859 Len=0"
"17","17.496099","10.10.3.13","10.10.3.30","MQTT","42","Ping Response"
"18","17.519380","10.10.3.30","10.10.3.13","TCP","40","[TCP ZeroWindow] 1025 → 1883 [ACK] Seq=244 Ack=3 Win=0 Len=0"
"19","17.815883","10.10.3.30","10.10.3.13","MQTT","69","[TCP ZeroWindow] , Publish Message"
"20","17.856177","10.10.3.13","10.10.3.30","TCP","40","1883 → 1025 [ACK] Seq=3 Ack=273 Win=28830 Len=0"
...

10.10.3.30 is my arduino. TCP Zero Window means "give me a break" so for some reason arduino is overloaded. From wireshark wiki:

This means that a client is not able to receive further information at the moment, and the TCP transmission is halted until it can process the information in its receive buffer.

Any idea what can be the reason or how to debug it further?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants