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

[pod67]

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]

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]

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

[karlp]

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

[pod67]

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

[jsaak]

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]

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]

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

[BubuOT]

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]

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

[BubuOT]

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? :))