Skip to main content
Read last_error on that worker. It is the difference between the two cases the badge cannot distinguish:
  • A value — the socket opened and the bind was refused. Wrong credentials, wrong system type, an IP the carrier does not expect, or a bind limit already reached.
  • Empty — the socket never opened. Firewall, DNS, or a carrier that is down.
fireflo test-bind vendor1 dials once and tells you which, without waiting for the reconnect cycle.
Same distinction, same answer: last_error.On a listener, bound: 0 is usually neither — it means no customer is connected right now, which is quiet rather than broken. That is why a listener with nobody bound is not painted red the way a vendor with no session is.
Compare bound with bound_transmittable. A session carries traffic only if it is a transceiver, or a transmitter on a client session. A receiver-only vendor binds perfectly and sends nothing.If both are non-zero, check whether the vendor is held — accepting but not sending, with the queue growing — and whether tps_measured is zero while queue_depth is not. That pair is a stall, and it is invisible in any single number.
Because on a multi-listener deployment, one port conflict should not take down the ones that work.It logs and carries on. The cost is that a clean start is not proof every listener is up — check /ops/health rather than the absence of an error.
Every message through that vendor settles as EXPIRED at the deadline instead of DELIVERED or FAILED, because nothing ever reports an outcome.Your delivery rate for that vendor becomes meaningless rather than zero, which is worse — a zero looks like a problem, a meaningless number looks like data.
Four places, composing in this order: the customer’s submit_sm (only if the listener declares the tag), their credential’s defaultTlvs, the whitelist stamp, then the vendor’s default.tlvs.submit.Precedence is message > credential > vendor, and defaults only fill gaps. The exception is the whitelist stamp in replace mode, where the overwrite is the approval.Undeclared tags are discarded, not passed through.
Check the format. It is <name>_<tag>=<value>, comma-separated.PEID=1101234567890123456 has no tag on the name, so it parses to nothing and logs only a WARN. The setting looks applied and does nothing.Also check the tag base: vendor_1400 is decimal 1400, not 0x1400. If a carrier gave you a hex tag and you wrote it without the prefix, everything loads and the wrong tag goes on the wire.
Check the key is one the listener reads per-listener at all. A key that is not keeps its bare form, reads a global nobody sets, and therefore returns its coded default whatever you configure.whitelist.tlvs.replace shipped that way once and stamped nothing over SMPP for as long as it lasted — silently, because not stamping looks exactly like having nothing to stamp.
You cannot — it is refused, deliberately. A second bind on the same systemId can cost you the live session, and many carriers allow only one.Use it before traffic depends on the vendor, or after suspending it.
Yes, by default. conf.dlr.multipart is all, so there is one receipt per submit_sm they sent, each quoting the id they were given.first or last collapses that to one, carrying the real sub:/dlvrd: totals, for aggregators expecting one message in and one receipt out. Every receipt reports the same outcome whichever you pick, because the outbound segments are aggregated before any receipt is built.
Because the recipient did not receive a readable message. Resolution waits for the last segment and reports the worst, not the first.It is the honest answer, and it moves delivery-rate figures down relative to gateways that report the first segment. Worth knowing before comparing months.