Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Basic configuration issue with multiple listeners

Peter Rockett <p.rockett@xxxxxxxxxxxxxxx> writes:

>> The key point is to see if this is bound to *.1883 or 127.0.0.1.1883.
>> The normal listen binds to INADDR_ANY, which is represented 0.0.0.0, and
>> matches all addresses.
> Great call! My only mosquitto listener was 0.0.0.0:1883. Don't know
> how I missed that! :-[
>
> This also clarifies for me how mosquitto handles the default
> listener. I was imagining some crazy process of seeking out all
> available interfaces and creating a listener for each... but I was
> overlooking the wildcard IP address.

A few programs like ntpd do this becuase they want to know which
interface a packet arrived on and send back (udp) from the same one.
MQTT over tcp is not so fussy and does not need this (much more
complicated) treatment.

> This appears to produce weird behaviour. When mosquitto has a default
> listener 'bound' to 0.0.0.0 and you attempt to bind the same IP
> address it seems to report an error and then trashes the listener you
> already had leaving with no listeners at all :-\

Sounds like a bug; if it is that upset it should exit.

> The problem was my adding a "socket_domain ipv4" directive in my local
> conf file. That starts the default listener (not obvious that it
> should, but it does). The ultimate error is, IMO, bizarre. It appears
> that having inadvertently started the default listener bound to
> 0.0.0.0 (i.e. everything), in attempting to bind a second listener to
> a specific address (such as localhost), mosquitto seems to determine
> that localhost is a subset of 0.0.0.0 and fails with an "address
> already in use" error. This is not a very helpful diagnostic, IMO! To
> make matters worse, the default listener gets trashed in the process
> and you end up with nothing!

So there are three bugs:

  default listener is instantiated by modifier commands

  modifiying commands not clearly bound to a listener

  odd behavior on bind failure
  
> The corollary: Is mosquitto's hidden invocation of the default
> listener by innocuous-looking directives really the best approach?

No, and this appears to be a widely-held view, but it's hard to change
because fixes will break existing configs.

> This looks to me like a side-effect waiting to bite you. Could
> starting the default listener be made explicit? Or indeed removed
> altogether? An explicit "listener 1883  0.0.0.0" directive would seem
> to do the same job but has the advantage of making it obvious what is
> happening?

That is a half-fix (doesn't fix the association of modifiers and
listeners), but the combination of:

  remove default listener from  code

  add "listener 1883 0.0.0.0" to example config, at end

  make modifier config lines be an error if there is no listener

would seem to have minimal pain for people with existing configs, and
avoid a lot of other confusion.


Back to the top