There comes a time in every OT technician’s life (probably more often than they’d like) when they just can’t figure out what the heck is going on. After all, BACnet issues have a habit of masking their root cause behind common symptoms: Duplicate devices can throw up strange errors that look like physical connection issues, and excessive read rates will generate enough traffic to make everything look like an overloaded device.
This is where you need to be able to get back to basics – that’s where packet analysis comes in. But network packet packets can be unruly, containing lots of traffic that doesn’t help solve your BACnet issues.
We’ve put together this article to help you get what you need from a BACnet PCAP file, filtering out what you don’t, and giving you a quick reference to understanding the parts of a BACnet packet that matter most. To that end, we’ll spend some extra time focusing on the unique information elements in the highest two layers of the OSI model.
A Quick Primer on Packet Capture Files
What is a Packet Capture?
In the most basic sense, a packet capture file is all the intercepted network traffic recorded during a certain period. There can be many different methods to capture packets, but for our purposes, BACnet packet capture from Ethernet, BACnet/IP, or MS/TP networks can usually be captured from one central machine, like your Building Management System. The captured bits of network traffic are displayed as individual packets.
What’s in a BACnet Packet?
Since we’re specifically focusing on BACnet issues, we’ll typically see the data packets in the PCAP file referred to as ‘frames’. These frames capture all the information needed to find, establish connections, and communicate with networked devices, broken out by OSI layers.
As you can see, the traditional OSI model breaks down communication into seven layers to act as a visual map to understand what’s going on in a networking system. There are several great explainers on what each layer is responsible for, but for BACnet, we only need to be concerned with four:
- The Physical Layer: your physical (wired or wireless) connections between devices. For BACnet, this is usually twisted pair wires (RS-485) or Ethernet cable.
- The Data Link Layer: where bits are packaged into frames and the protocol (such as MS/TP) for communication is established.
- The Network Layer: where routing for packets is defined and transferred between different networks. BACnet Virtual Link Control (BVLC) and Network Protocol Data Unit (NPDU) frames define the routing details of the packet from source to destination.
- The Application Layer: Provides the network services for applications to interact with each other. For BACnet devices, this is where the processing of requests, responses, and notifications takes place. In a frame, it is labeled as APDU or Application Protocol Data Unit.
Important! When inspecting a BACnet packet capture frame, the layers will be displayed in reverse order. Technically, things are built “up”, but it’s easier to read top-down.
Pro Tip: Create the Best Possible BACnet Packet Capture
To help get the best packet captures into OptigoVN, we recommend using Optigo Networks Hardware Capture Tool for all BACnet MS/TP packet capture activities, and our free Optigo Networks Software Capture Tool (available as a Windows or Linux application) for BACnet IP or BACnet Ethernet captures.
We’ve also created an expert how-to guide for creating the best packet capture files for your BACnet system. It’s a deep dive into the best way to set up, deploy, and filter your network traffic so you get only what you need to diagnose your BACnet system.
Here are some key points:
- A MINIMUM one-hour (to 24 hours) capture time is recommended for a general network health check and identifying issues, and further captures of 5-20 minutes for troubleshooting and validating.
- Trigger a global discovery from your BMS during capture to get all devices
- Perform packet captures on each MS/TP network individually
- If using Wireshark, filter your packet captures for BACnet traffic only
- It’s important to capture from a device that communicates with BACnet devices. Capturing from a “passive” device on the same network will only reveal broadcast packets. To evaluate the performance of a network, we need unicast packets. Capture from a device (e.g. BMS server, point server) that actively communicates with BACnet devices (e.g. reading points).
How to Read a BACnet PCAP Frame
BACnet frames (packets), in this case, a BACnet/IP frame, look like this when displayed with a packet analysis tool (or within OptigoVN):
Keep in mind:
- These frames display the layers in reverse order. While the first line is your header – which frame number this is, file size, and so on – the second line is our bottom (physical) layer.
- This packet has been expanded to only display the BACnet-related data. Each key section has a toggle to expand it. The frame in this example has been expanded to the sections specific to BACnet – BVLC, NPDU, and APDU.
Let’s go section by section and visually explain what we’re looking at.
Header and Common OSI Model Information
- Line 1: This is the header. The header contains the basic information about the frame itself.
- Line 2: This is the Network Layer. In this example, you can see the source (Src) address and the destination (Dst) address.
- Line 3: This is the IP layer. Here you can see the IP addresses for the source and destination devices.
- Line 4: This is the Transport Layer. In a BACnet/IP frame, this displays the UDP ports being used by source and destination devices.
Capturing from a strictly MS/TP network? Your packet will look a little different, as any references to TCP/IP information won’t be present. As you can see below, that means no IP Layer (line 3 above), and no Transport/UDP Layer (Line 4).
BVLC Information
This is a network layer specific to BACnet/IP, BACnet/IPv6, and BACnet Secure Connect (BACnet/SC). The BACnet Virtual Link Layer executes a series of functions necessary for BACnet/IP to manage broadcast messages from other subnets. The function itself is carried out by a BACnet Broadcast Management Device (BBMD), and if that sounds like a lot of B-words, it is!
Just know when you see this section, it more than likely indicates that a BBMD is forwarding a BACnet broadcast message from another network onto the one you are performing the capture on.
Want to know more details on BBMDs? We’ve got a whole explainer article on them here.
NPDU Information
APDU is a unit of information that is added every time a message is moved up a layer in the OSI model. So at the Network Layer, the Network Protocol Data Unit is introduced, layering on additional information to the packet for routing data across the network. The key information to look for is:
- Destination network (DNET): The BACnet network number where the destination device is located
- Destination MAC address (DADR): The MAC address of the destination device on its network
- Source network (SNET): The BACnet network number of the source device
- Source MAC address (SADR): The MAC address of the source device on its network
Hop Count: The number of times a message has passed through a BACnet router. Counts down from 255. Helpful to check for indications of a circular network!
APDU Information
At the top level is the Application layer. And just like the Network layer, it adds its own information set to the message packet.
APDU Type
For BACnet specifically, there are eight different types of APDU messages.
BACnet PDU Type | What it Looks Like | What is It? |
confirmed-request-pdu | [0] BACnet-Confirmed-Request-PDU | A message you expect a response to, such as a Read Property request. |
unconfirmed-request-pdu | [1] BACnet-Unconfirmed-Request-PDU | A message (commonly a broadcast) that doesn’t require a response, such as an event notification or WHO-IS/I-AM. |
simple-ack-pdu | [2] BACnet-SimpleACK-PDU | Basic acknowledgment for a confirm request. “OK”. |
complex-ack-pdu | [3] BACnet-ComplexACK-PDU | Acknowledgment for a confirm request with content in it. |
segment-ack-pdu | [4] BACnet-SegmentACK-PDU | Acknowledgment for a confirm request with a response that needs to be split into multiple messages due to length. |
error-pdu | [5] BACnet-Error-PDU | E.g. trying to read an object that does not exist. |
reject-pdu | [6] BACnet-Reject-PDU | E.g. Device is to busy to respond. |
abort-pdu | [7] BACnet-Abort-PDU | E.g. A process was aborted due to communication issues. |
APDU Service Choice
The details of the message itself. There are currently over 100 different service choice message types broken out into separate types of services:
- ReadProperty (12)
- WriteProperty (15)
- ReadProperty Multiple (14)
- WriteProperty Multiple (16)
- Subscribe COV (5)
- Confirmed COV notification (1)
- Confirmed Private Transfer (18)
In the example above, you can see that the service choice is readPropertyMultiple. You can find the full list of Service Choices in sect. 21.2 of the ASHRAE Standards and Guidelines
Invoke ID
Like any parcel delivery, an Invoke ID is essentially the BACnet version of a tracking number for the packet. This allows the system to send out a stream of requests without having to wait for each one to come back in order. Any confirmed request PDU type will have an Invoke ID, so the reply can be traced back to the request.
Object Identifiers
The object identifier contains three key pieces of information
- The object type: what “type” of data does this device record? Here’s a full list of the object types
- The object instance number.
- Property ID: the request’s parameters (pressure, temperature, etc.)
Putting this APDU together we can start to decipher the message:
- The Invoke ID for this message is 247
- It’s a request for multiple properties
- It’s requesting the analog input value from the device with Device ID 105
- It’s requesting the binary input value from the device with Device ID 10
- It’s requesting the binary output value from the device with Device ID 5
- Specifically, what the present value of those data points are (assumed from the request expanded on device ID 5).
One message, asking for three points, from three different devices.
This is Just The Beginning
Creating a good BACnet Packet Capture is just the first step in understanding what’s happening in your network. Being able to make basic sense of the information in a BACnet frame is an extremely valuable skill. While there’s a lot more information you will learn to derive from studying the way information is displayed, seeing the basic flow of a packet from its source to its destination, and what’s inside that message are the fundamentals you need to start troubleshooting.
When it comes to diagnosing and resolving BACnet and OT network issues, we are admittedly a bit partial to Optigo Visual Networks. It’s our latest-generation BACnet monitoring software, with more than 25 diagnostic tests designed to help pinpoint your issues down to the device. And with the addition of a Site Scope to your network, you’ll gain deep deep visibility into all BACnet packet traffic of unlimited length and size.
Ready to see what OptigoVN can do for your network monitoring and maintenance? Sign up for a guided demo, or try a solo experience free of charge today at www.optigo.net/optigovn