Broker Configuration

What runs on port 8883, what it enforces, and the limits to design around.

The 8883 listener

OhioIoT runs Eclipse Mosquitto 2 as its MQTT broker. Every device and every external client reaches the platform through a single TLS listener on port 8883 — there is no plaintext entry point exposed to the internet.

The listener is configured with its own scoped settings (Mosquitto's per_listener_settings mode), so the authentication and authorization rules that follow apply specifically to traffic coming in on 8883.

listener 8883
allow_anonymous false
max_connections 1000
max_inflight_messages 20
max_queued_messages 100

TLS termination

The broker terminates TLS using a managed certificate pair (fullchain.pem and privkey.pem). Renewals happen on the broker side — there is nothing for you to rotate or restart on the device.

On your side you only need the CA certificate so your client can verify the broker's identity. That's covered in TLS & Security.

Authentication

allow_anonymous false — every connection on 8883 must present a valid MQTT username and password. Anonymous connections are rejected at the protocol layer before any topic activity is possible.

Credentials are stored server-side in a password file. You manage yours from the Settings page of the dashboard; all of your devices share a single MQTT username and password tied to your account. The MQTT credential is intentionally separate from your OhioIoT login — a leaked device password compromises your tenant data, but not your account itself.

Failed authentication attempts are logged on the broker. Repeated failures from a device usually mean stale credentials baked into firmware after a password reset.

Authorization (ACL)

Tenant isolation is enforced by the broker, not by convention. Every authenticated connection is checked against an ACL file before any publish or subscribe is allowed through. The full ACL is two lines:

topic read broadcast/beacon
pattern readwrite %u/#

pattern readwrite %u/# — %u is substituted with the connecting client's username. If you authenticate as larry, you have full read/write access to anything under larry/# and nothing else. This is the entire mechanism behind tenant isolation: there is no way to accidentally or deliberately reach another tenant's namespace.

topic read broadcast/beacon — every authenticated client is granted read-only access to the single topic broadcast/beacon. The platform uses this for global announcements that all clients should see. It's a single topic, not a wildcard — neighboring topics like broadcast/anything-else are not readable.

When the ACL denies a publish or subscribe, the broker drops the operation silently — your client won't see an error. If a published message never arrives at its subscriber, the first thing to check is whether the topic actually starts with your MQTT username.

Limits

These are the broker-side limits in effect on 8883. Knowing them up front saves debugging time later.

Setting	Value	What it means
max_packet_size	102400	Largest single MQTT packet the broker will accept — about 100 KB. Includes topic, payload, and protocol overhead. Packets above this are refused and the connection is dropped.
max_inflight_messages	20	Maximum outgoing QoS 1 / QoS 2 messages waiting for acknowledgement at any one time per client. Beyond this, the broker pauses sending to that client until acks come in.
max_inflight_bytes	2048	Byte-size companion to the count limit above. Whichever cap is reached first applies.
max_queued_messages	100	QoS 1+ messages buffered for a disconnected client with a persistent session. Beyond this, the oldest queued messages are discarded.
max_connections	1000	Concurrent connections accepted on the 8883 listener. Reach out if your fleet is approaching this number — it's a soft limit we can raise.
autosave_interval	1800	Seconds between broker-state snapshots. Internal — listed here so the value isn't a mystery if you see it in support conversations.

Practical implications. The 100 KB packet ceiling is the one most customers run into first — usually with a verbose JSON payload from a gateway batching many sensors at once. If you're approaching it, split the batch across several smaller publishes or move the bulk data to the gateway publishing path.

The in-flight and queued numbers matter for QoS 1+ workflows. A device coming back online after a long outage will only receive the most recent ~100 buffered messages from each subscription — older ones are gone. For long-horizon catch-up, pull from the Data API instead of leaning on queued delivery.

Quick reference

Listener port	8883 (TLS only)
Authentication	Username + password, required (no anonymous)
Authorization	ACL — read/write on `<your-username>/#`, read on `broadcast/beacon`
Max payload	100 KB per packet
Concurrent connections	1,000 (soft cap)
QoS buffering	20 in-flight, 100 queued for offline persistent clients