Capturing traffic on a BACnet network has never been the hard part. Wireshark and tools like it have done it reliably, and for free, for more than twenty years, in every industry that runs on a packet network. The hard part is reading the result. A busy campus produces captures that run to millions of packets, and turning such a capture into findings takes time and expertise that most teams do not have to spare.
A newer category of platform exists to do that reading. Upload a capture, and the platform returns an analysis: a health score, a ranked list of problems, a picture of who is talking to whom. That is genuinely useful, and nothing in this article argues otherwise. But two limits come with it, and they deserve to be stated plainly. The reading is only as good as the capture it was given. A reading, however good, changes nothing on the wire.
What These Platforms Do, and What They Are Handed
These platforms analyze captures. They do not take them. The capture arrives from whoever ran it: an integrator on a service visit, the in-house technician, the controls contractor. The platform then processes that file by a proprietary method and returns a proprietary score.
This division of labour matters more than it first appears. Where the capture was taken, when, and for how long were all decided before the platform ever saw the file. The score inherits all three decisions and can verify none of them. The analysis may be excellent. The question is what it was given to analyze.
Only as Good as the Capture
Three things decide what a capture contains: where it was taken, when, and for how long.
Where matters most. The usual practice is to capture at the front end, and for broadcast traffic that practice is fair. In a network where every subnet is tied into a BBMD mesh, broadcasts are forwarded to every other subnet, so a capture at the front end really does contain the broadcast traffic of the whole system. That much arrives on its own.
What never arrives is everything else. The unicast conversation between controllers, the reads, the writes, the change-of-value notifications, the routine polling between peers, travels device to device and does not cross the capture point. Any segment that is not tied into the mesh is absent as well. The file is a faithful record of the traffic that reached one place, and silent about the traffic that did not.
And that is the simple case: one front end, one mesh. A large campus is rarely so tidy. Systems are replaced in stages, so many sites run two front ends at once, the legacy system and its successor, each with its own BBMD arrangement. Some devices still report to the old front end, others to the new, and the two populations often sit on subnets that are deliberately isolated from each other. Now there is no single place where the traffic aggregates. A capture at the old front end shows the old system’s share, a capture at the new one shows the rest, and neither shows the whole. Even stitching the two files together misses whatever neither mesh carries.
Supervisory controllers and point servers deepen the same problem. Where a supervisory controller fronts a field trunk, the devices behind it do not appear on the IP network as themselves. The supervisor polls its field bus privately and re-presents the results as its own points. A front-end capture records one moderately busy device where there are actually fifty controllers and a trunk behind it, and the health of everything on that trunk, the polling, the retries, the errors, is not in the file no matter where on the IP side the capture was taken.
Then there are sites that run BACnet on more than one UDP port. It is common enough: a second system put on a different port to keep it apart from the first, or a vendor default nobody revisited. A capture filter written for the standard port, or an analysis that assumes it, drops that entire system without a trace. Whether a different UDP port actually separates anything is its own question, and one for a future article.
None of this is anyone’s failure. It is what large sites look like after twenty years of phased upgrades. But every one of these layouts makes "where do we capture" harder to answer correctly, and every wrong answer produces a clean-looking file and a confident score for a network the capture did not fully see.
When and for how long set the window. Ten quiet minutes on a Sunday and an hour mid-commissioning are two different networks. A capture only holds what happened while it was running.
Two practices have grown up to compensate. One is to treat the front-end capture as the whole story, on the reasoning that the important traffic aggregates there. Mostly it does, but not always. The other is to automate the capture, taking one on a schedule and uploading it without a person involved, so the window problem shrinks. Neither practice is wrong. But both exist to patch the same weakness, and the patching is itself the evidence that the weakness is real.
The result is simple to state. A score built from a capture can be accurate, or it can be blind to the thing that matters, and it looks exactly the same either way. Nothing in the score tells you which one you are holding.
Two Kinds of Health
There is a second limit, separate from capture quality. Even a perfect capture measures the BACnet conversation. It says almost nothing about the network the devices run on.
Replace aging switches with enterprise-grade hardware, fix a duplex mismatch, resolve an uplink that was quietly dropping frames, and a BACnet health score will barely move, because none of that is visible in the application-layer traffic it reads. Yet the score is routinely presented as the health of the network. Those are two different measurements sharing one name. Judging the whole network from the BACnet packets is like taking the temperature of a long steel rod at a single point while part of it lies in the sun and part in the shade, and reporting the result as the temperature of the rod. The reading is real. The conclusion drawn from it is bigger than the evidence.
A Reading Changes Nothing
Grant the best case: a well-taken capture, honestly analyzed. The next morning, the network is exactly as loud as it was. Every broadcast the report counted is still being sent. A report describes traffic; it does not carry the means to reduce it. A score can even improve while the network stays untouched, when what changed was the measurement rather than the traffic. That is worth noticing, because it is the difference between watching a number and fixing a building.
Suppose you go further and act on the report. A team can spend real labour on the fixable findings: track down the unreachable devices, renumber the duplicate instances, quiet the worst of the polling offenders. That work is worth doing, and a good report earns its keep by pointing to it. But underneath those findings sits a class of problems that no series of site visits can reach, because they are not defects in any one device. They are the broadcast architecture itself. Fixing that layer means a full investigation of the BACnet internetwork: answering, subnet by subnet, the hard question of what actually needs to talk to what, and then building the broadcast distribution tables by hand to match the answer. Few sites ever complete that exercise, and fewer still keep it current through the next renovation.
Suppose one did. The result would still be fragile, because nothing enforces it. The repaired network is a state, not a property of the system. One operator clicking discovery over and over at the front end, one edit to a distribution table, one BBMD added during a retrofit, and the storm is back, network-wide, with nothing to say so except the next capture someone happens to take. Every hard-won correction depends on no one ever making an ordinary mistake again.
Analyze Your Own Capture, Free of Charge
Reading a capture well is still worth doing, so we built our own analyzer, the BSA-1000, and put a free version online. At scan.bacsync.com you can upload a BACnet capture and get a straightforward reading of what it contains: how much is broadcast, how much of that is discovery, and where the noise comes from. It costs nothing. It asks for a work email address, and the capture itself is deleted as soon as the report is built. If your policies do not allow a capture to leave the building, the same engine is available as a small desktop tool that captures and analyzes entirely on your own machine, and the raw packets never leave it.
Every limit in this article applies to our analyzer too, and it says so itself: alongside the findings, the report includes a capture-confidence band stating what this particular capture could and could not see. It will show you a storm. It will not still one. If your traffic turns out to be quiet, you have learned something useful at no cost. If it is not, you now know what has to change, and you have the yardstick for judging any remedy, including ours.
An Architecture That Stands Where the Problem Is
Reducing the traffic is not a better analysis. It is a different kind of product, built on a different architecture, and the architecture is the point.
The BSP-1000 (BACsync is the product line; the BSP-1000 is the platform, and the BSA-1000 above is its analyzer) has two parts. A lightweight agent is installed on each Layer 2 broadcast domain, one per subnet, connected like any other device on that segment. A central server aggregates every agent into one live, network-wide device directory and dashboard. The agents are read-only toward your controllers: they take part in discovery, and they never originate a write or a command of their own.
Each agent answers discovery on its own segment, so once the BBMDs are retired, there is no forwarding layer left to carry a broadcast storm across the site. Lookups that used to be answered by flooding every subnet are answered instead from the directory the agents hold in common. During a migration, the agents run alongside the existing BBMDs until you choose to retire them.
Now set that architecture against the three capture questions from earlier, because it answers each one structurally rather than by effort.
Where: there is no single vantage point. An agent stands on every segment, so every segment’s broadcast activity is observed first-hand, where it happens. Nothing has to be inferred about a subnet from a file taken somewhere else, and no segment is outside the picture, because every segment has its own agent.
When: there is no window. The agents are permanent residents of the network, not ten-minute visitors. The directory and the dashboard reflect the network as it is now, on the quiet Sunday and during the commissioning push alike.
What it changes: everything the reading could not. The agents do not merely count the broadcast load; they remove it, and they count what they remove. Each agent reports the discovery traffic it answered locally instead of letting it flood, so the reduction is a measured figure on the dashboard, per agent and per segment, not an estimate.
The fragility goes with it. The ordinary mistakes that would undo a hand-repaired network land differently here. A discovery clicked over and over at the front end is answered on that segment, is rate limited, and goes no further. There are no distribution tables to maintain, so there are none to mis-edit, and no hard questions of what needs to talk to what to answer by hand, because the directory already holds the answer. A BBMD that appears where none should be is flagged by the agent on that segment, and its broadcasts are absorbed rather than relayed onward. This is what solving the problem at the source means: not that no one will ever make a mistake, but that a mistake stays local instead of travelling the whole network.
None of this trades away the insight a reading provides. The opposite is true: the same presence that removes the storm keeps the diagnosis running, continuously and from every segment at once. The platform holds a live inventory of every device, its identity, address, and model, and tracks each device’s status as it changes: online, stale, offline, or flapping. Duplicate instance numbers are caught as devices appear, not months later in a capture. A new device on any segment is quarantined until an operator approves it. A device broadcasting far more than it should is identified at its source. The dashboard presents all of it on a live topology of sites, buildings, and segments, with the health of each agent’s connection shown alongside, and the platform does not wait to be asked: when something needs a person, an alert goes out by email or text message, with escalation and acknowledgment.
Diagnosis is not the remedy, but the remedy carries the diagnosis with it. And the proof is available with any capture tool you already trust: point an analyzer at a network the BSP-1000 is managing, and the report comes back quiet, because the traffic it looks for is no longer being sent.
The Instrument and the Treatment
A measurement and a remedy each have a place, and neither substitutes for the other. A capture-based score is a narrow instrument: one point, one window, one layer. Used with its limits understood, it is a good instrument, and you can apply it to your own network today at scan.bacsync.com. But when the picture shows a storm, the useful question is not who can describe the storm most precisely. It is what makes the storm stop. That is an architectural question, and it is the one the BSP-1000 was built to answer.
Frequently Asked Questions
How do I analyze a BACnet packet capture?
Capturing is the easy half: Wireshark and tools like it have done it reliably for decades. The hard part is digesting millions of packets into findings. The BSA-1000 does that digestion: upload a capture at scan.bacsync.com free of charge (it asks for a work email address, and the capture is deleted as soon as the report is built), or use the desktop version, which captures and analyzes entirely on your own machine.
How accurate is a BACnet health score?
A score is a statement about a capture, not about a network, so it is only as good as the file it was given. Where the capture was taken, when, and for how long decide what it contains: a front-end capture in a fully meshed system does carry the broadcast traffic, but not the unicast conversation between controllers, segments outside the mesh, or anything outside the capture window. A score built from a blind capture looks exactly like an accurate one, which is why the BSA-1000 reports a capture-confidence band alongside its results.
Can analytics fix a BACnet broadcast storm?
No. A report describes traffic; it does not carry the means to reduce it, and the morning after the report the network is exactly as loud. Quieting the storm requires something that lives in the network rather than beside it. The BSP-1000 places a read-only agent on each subnet to answer discovery locally, removes the need for BBMDs, and counts the broadcasts it eliminates, so the reduction is measured rather than estimated.
If this resonates with what you are seeing on your network, we would welcome the opportunity to discuss it further. More information about BACsync and the BSP-1000 is available at bacsync.com.
About the Author. Mark Van Weert is the founder and director of Humber Horizons Limited, a building automation and cybersecurity consulting firm based in Ontario, Canada. A certified engineering technologist (C.E.T.) with thirteen years of experience in BACnet systems integration, a CCNP ENCOR certification, and a background in large campus deployments, Mark specializes in IT/OT convergence and network infrastructure for universities, hospitals, and commercial facilities.
More in this series
- Beyond Broadcast: BACnet Discovery Doesn’t Scale (February 2026)
- Managing Mixed BACnet/IP and BACnet/SC Networks (April 2026)
- Default Posture: BACnet Governance Without IT Dependency (May 2026)
- Device Address Proxying and BBMD Caching (June 2026)
- The Other Half of Discovery: Who-Has and Object Discovery (July 2026)
- Diagnose a BACnet Broadcast Storm in 30 Minutes (August 2026)