No keepalive (0) still allowed with max_keepalive set

[dnadlinger]

Even if max_keepalive is set in the config file, clients are still allowed to connect using 0 (i.e. no keepalive) without a Server Keep Alive being sent in the connect ack.

I'm not sure whether this is a bug, but it was certainly unexpected behaviour to me after reading the v5 spec and mosquitto documentation.

[ralight]

Agreed, it should apply to keepalive=0 as well.

[DavidAntliff]

I'm not sure if what I'm seeing is related to this, but I'll report my observations anyway.

With mosquitto 2.0.11 my C++ clients connect without errors. But with mosquitto 2.0.12 or 2.0.13 I am getting error 2: identifier rejected, and no connection established. Rolling back to 2.0.11 makes it all start working.

mosquitto_{sub,pub} seems to connect OK to any version.

Note: I came across this in a telegraf discussion and it referred me back to this issue. Incidentally I am using telegraf but I see the fault even when telegraf is not running so I've isolated it to just mosquitto. I believe the other discussion is using telegraf to connect as a publisher to mosquitto (as am I), so perhaps that explains why they are seeing this issue.

[DavidAntliff]

I'm still working my way through this, trying to figure out where the problem lies. It is not clear to me what should happen when a client tries to connect with keep-alive = 0. Can someone please explain the expected behaviour? Is this a bug with mosquitto or new behaviour that requires all clients to conform?

I am using 2.0.13 with mqtt_cpp (commit 29f93bc0c0cb82979840318e49fcce710f07ec88) and if I set the client keep-alive to a non-zero value, I can get a basic connection, but if I set it to zero (which is also the library's default), the connection is rejected with Bad socket read/write on client mqtt_client: Invalid arguments provided..

[DavidAntliff]

For anyone else coming across this:

Mosquitto 2.0.12 is broken for connections from clients that specify a keepalive of zero. This may be the case with many third-party clients, although most of the popular ones use a value of 30 or 60 or something similar. For some clients, the default value of 0 will not connect and you'll get an "identifier rejected" response from the broker.

This is fixed in 2.0.13, but you'll still get the same response from the broker until you change the mosquitto configuration to allow such clients. In the default mosquitto.conf for 2.0.13, there is a new comment:

# Set to 0 to allow clients to set keepalive = 0, which means no keepalive
# checks are made and the client will never be disconnected by the broker if no
# messages are received. You should be very sure this is the behaviour that you
# want.

Previous versions have stated "Do not set [max_keepalive] below 10", which may be confusing if you have an older config file and haven't seen the new comment!

Therefore, if you want your clients to be able to connect to 2.0.13 with a keepalive of 0, then you will need to set max_keepalive 0 in the mosquitto config file.

Hopefully this summary will save at least one other person a couple of days of bewilderment.

[dnadlinger]

It's been a while since I read the spec, but I'm a bit surprised to hear that keepalive 0 leads to connections being rejected. Shouldn't the broker just send the configured max_timeout as server keepalive in CONNACK (and then disconnect the client later if this is not respected)? Or is this a v3 vs. v5 issue?

[DavidAntliff]

I'm a bit surprised to hear that keepalive 0 leads to connections being rejected

@dnadlinger sorry if I was unclear. What I'm saying is that if max_keepalive is not set to zero, then client connections that specify their keepalive as zero will be rejected. This is an issue for any clients that default to a keepalive of zero, such as the one I was using (mqtt_cpp). Out of the box, these clients won't connect to a default instance of mosquitto 2.0.13 (and probably newer).

There are two possible ways around this - either set the client's keepalive to non-zero, or set max_keepalive 0 in mosquitto's config file. Unfortunately both of these options require the user to know that they have to do this, which may be a problem for newcomers.

I'm not sure about v3 vs v5. I'm using a v3.1.1 client.