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

Errors after MQTT-SN client reconnection #3

Open
ralight opened this issue Mar 15, 2016 · 4 comments
Open

Errors after MQTT-SN client reconnection #3

ralight opened this issue Mar 15, 2016 · 4 comments
Labels

Comments

@ralight
Copy link
Contributor

ralight commented Mar 15, 2016

migrated from Bugzilla #462795
status UNCONFIRMED severity major in component RSMB for 1.4
Reported in version unspecified on platform PC
Assigned to: Ian Craggs

On 2015-03-22 14:07:00 -0400, Ivan Makeev wrote:

When MQTT-SN client reconnects with same client ID, it gets "transport endpoint not connected" error on any packet sent after CONNECT. Example from RSMB log:

20150322 185455.213 CWNAN0034I Duplicate connection attempt received for client identifier "ENV-02124B00040EF660" from address 127.0.0.1:54113, ending oldest connection
20150322 185455.213 134517200 127.0.0.1:54113 ENV-02124B00040EF660 -> MQTT-S CONNACK returncode 0 (0)
20150322 185455.213 CWNAN0000I Client connected to udp port 1882 from ENV-02124B00040EF660 (127.0.0.1:54113)
20150322 185510.128 CWNAN0075W Socket error 107 (Transport endpoint is not connected) in getpeername for socket 3
20150322 185510.128 CWNAN0023W Connect was not first packet on socket 3, peer address unknown; got SUBSCRIBE

Presumbly, the error caused by not updating the clients table properly.
In MQTTSProtocol.c, function MQTTSProtocol_handleConnects contains block for such a case under
/* have to remove and re-add client so it is in the right order for new socket */
but condition (client->socket != sock) will always evaluate to false as statement
client->socket = sock;
goes few lines before. Seems full address should be compared here before new socket value is assigned. Moreover, inside this block the statement:
TreeRemoveKeyIndex(bstate->mqtts_clients, &client->socket, 0);
should be presumably changed to
TreeRemoveKeyIndex(bstate->mqtts_clients, client->addr, 0);
as index in the tree is over full address, not just socket.

@ralight ralight added the bug label Mar 15, 2016
@elAlexOm
Copy link

День добрый, Иван.
Нашли-ли Вы решение этой проблемы ?
Алексей.

@njh
Copy link
Contributor

njh commented Jul 21, 2016

Translated:

Good morning , Ivan .
Found - if you solve this problem ?
Alexey.

Note that since this issue was migrated from Bugzilla, it is unlikely that Ivan is receiving notifications about this issue.

@elAlexOm
Copy link

Thank you.

@aguegu
Copy link

aguegu commented Oct 22, 2017

This bug is quite annoying.

How to refresh the client list? It seems that even if I restart the broker, the old connection cache is still there and affecting new connections.

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

No branches or pull requests

4 participants