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

Bridge notifications doesn't publish state 0 on local broker when loosing internet #2467

Closed
pod67 opened this issue Feb 25, 2022 · 10 comments
Closed

Comments

@pod67
Copy link

pod67 commented Feb 25, 2022

Hi,

I have seen som reports with similar behaviour when having notification_local_only true, but in my case I have notifications turned on both locally and remote.
When shutting down remote bridge the bridge state 0 is published on local broker, but if I instead break the internet connection the bridge will never publish state 0!
The remote broker will always detect lost connection with bridge and publish state 0.

How to reproduce his:

Set up a local broker and a bridge to for example test.mosquitto.org:1883 and notifications = true.
Verify bridge-state-topic to have value 1.
Disconnect your internet-connection (disconnect WiFi or equivalent)
Expected result is bridge state 0, but is still 1.

Noticed behaviour when this occur:
bridge will restart repeatedly, after timeouts, connecting to local broker and will log an error saying that the remote host is unknown, probably caused by no internet connection.

@pod67
Copy link
Author

pod67 commented Mar 14, 2022

I ran another test using the IP-address, 5.196.95.208 and now the state changes as expected.
So this points to that the bug is that the failed DNS-lookup is the cause for not setting bridge state down!

@jsaak
Copy link

jsaak commented Mar 30, 2022

I have other results.
I use IP instead of hostname, and still no state 0.

@karlp
Copy link
Contributor

karlp commented Mar 31, 2022

See also #1488 that this is probably a dupe of.

@pod67
Copy link
Author

pod67 commented Mar 31, 2022

Actually #1488 is the post I'm referring to in the first sentence of the first post, and also pointing out the differences.

@jsaak
Copy link

jsaak commented Mar 31, 2022

It may be related, but this is not the same.

As I see this bug is present since:
2015-05-16 12:02:18 +0100
commit: a6827df6c
I do not understand this change, i think it is not in the right place.
We expect a notification when the connection breaks.
And mosquitto handles it when it tries to reconnect.
And does it incorrectly.

So there are two possible solutions:

  1. move the notification to the place when we detect that the connection is broken
  2. save the state of the connection, and notify when the state changes, when trying to reconnect

I prefer the first, since that way we get the notification sooner.

I could make the fix, but first i want to hear what the developers say about this. @ralight

@pod67
Copy link
Author

pod67 commented Mar 31, 2022

I second that solution 1 is preferred.
I would also be happy to test the fix in our IoT-device where we hava a problem with this issue.

@ralight
Copy link
Contributor

ralight commented May 25, 2022

Please give the develop branch a try if you are able.

@BubuOT
Copy link

BubuOT commented May 31, 2022

I tried compiling the fixes branch which contains the above mentioned commit but it fails with the following error:

cc  -I. -I.. -I../include -I../../include -DWITH_TLS -DWITH_TLS_PSK -DWITH_THREADING -DWITH_SOCKS -DWITH_UNIX_SOCKETS -I../deps -Wall -ggdb -O2 -Wconversion -Wextra -fPIC -c util_mosq.c -o util_mosq.o
util_mosq.c: In function ‘mosquitto__check_keepalive’:
util_mosq.c:114:2: error: #else without #if
  114 | #else
      |  ^~~~
util_mosq.c:136:2: error: #endif without #if
  136 | #endif
      |  ^~~~~
make[1]: *** [Makefile:222: util_mosq.o] Error 1
make[1]: Leaving directory '/home/marcus/repos/mosquitto/lib'
make: *** [Makefile:66: mosquitto] Error 2

@ralight
Copy link
Contributor

ralight commented Jun 6, 2022

@BubuOT Sorry about that, it's fixed now.

@BubuOT
Copy link

BubuOT commented Jun 10, 2022

Tested again now and this seems to fix the problem for us. Thanks for fixing this! (after it was broken 7 years ago I think? :))

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants