It's one of the most common conversations in this trade. The controllers are offline at the head end. IT says, “We tested it. We can ping every one of them.” And they're right — you can. BACnet still doesn't work.
Nobody is lying. Ping and BACnet are simply different traffic. Ping proves that the IP layer works between two addresses. It says nothing about whether BACnet messages can get through, whether the device is listening where you're talking, or whether your laptop is even listening for the answer. This checklist walks up from ping to a working BACnet conversation, one thing at a time.
What ping actually proves
Ping uses ICMP — a separate protocol from the one BACnet uses. A reply tells you:
- The target IP address exists and something at that address answered.
- There's a working route there and back, including any gateway in between.
- Nothing along the way is blocking ICMP.
BACnet/IP runs over UDP port 47808 (0xBAC0 in hex). Firewalls, access lists and host security treat UDP 47808 as a completely separate rule from ICMP. A path can pass one and block the other, and very often does. Ping narrows the problem down — it rules out the cable, the IP address and basic routing — which is useful. It just doesn't finish the job.
arp -a with the one on the controller's label.The checklist
Work down it in order. Each step is cheap, and each rules out a layer before you move to the next.
Is a firewall passing ICMP but blocking UDP 47808?
This is the big one, especially after IT changes anything: a new firewall between buildings, a new VLAN, a security review. The rule that got written allowed ping for testing and nobody thought to add the BACnet port. Everything pings. Nothing talks.
Look for: a recent network change. Ask IT specifically whether UDP 47808 is allowed in both directions between the head end and the controllers. Give them the exact port from the port reference — “open BACnet” is not a firewall rule.
Is the device on the port you think?
47808 is the default, not a law. Some sites run a second BACnet/IP network on 47809 (0xBAC1) or another port to keep systems apart, and some devices get set to a non-standard port and forgotten. Your tool sends to 47808; the device is listening on 47809; nothing happens. In Wireshark, traffic on a non-standard port won't even decode as BACnet until you use “Decode As” to tell it what it's looking at.
Look for: the device's configured UDP port on its own display or configuration page, and any traffic in a capture from the device's IP on a port other than 47808.
Is discovery trying to cross a router?
If your laptop and the device are on different subnets, a routed ping works fine, but a Who-Is is a broadcast — and broadcasts stop at the router. Unicast reads to a device you've added by IP may still work; discovery won't. You need a BBMD on each subnet or foreign device registration from your tool. That's its own article: BBMDs and foreign devices.
Look for: the device's subnet versus yours. The subnet checker will tell you in a second whether two addresses and masks are on the same network. A wrong mask on either end makes this worse, because broadcasts go to the wrong broadcast address.
Is the thing you pinged a router, with the devices behind it on another BACnet network?
Pinging a BACnet router proves the router is alive. The MS/TP controllers behind it aren't on IP at all — they're on a separate BACnet network with its own network number. Reaching them depends on the router being configured with the right network numbers and your tool discovering across networks (a global Who-Is rather than a local-only one). If two routers claim the same network number, devices behind both will flicker. The three addresses article covers how routers use network numbers.
Look for: I-Am-Router-To-Network messages in a capture, and whether the network number the router advertises is unique on the site.
Is your laptop's own firewall eating the replies?
The device may be answering perfectly. The I-Am comes back to your laptop on UDP 47808, and the laptop's host firewall drops it because nothing ever told it to allow inbound UDP on that port for your tool. This is extremely common on a new or freshly reimaged laptop, and on Windows when the network gets classified as “Public.”
Look for: I-Am replies visible in Wireshark on your laptop but nothing in your BACnet tool. Wireshark captures before the host firewall does its filtering, so it sees packets your application never receives. That mismatch is the proof.
Is something else on your laptop already holding 47808?
Only one program can own a UDP port on an address at a time. If your front-end software, a background service, or another BACnet tool is already bound to 47808, the second tool either refuses to start its BACnet interface (“failed to bind”), or starts on a different port and never hears the replies sent to 47808.
Look for: a bind error in the tool, or check what's listening with netstat -ano on Windows (or ss -ulpn on Linux) and look for :47808. Close the other program and try again.
Is your tool bound to the right network adapter?
Your laptop has Ethernet to the BAS switch and Wi-Fi to the office network. Ping works because Windows routes it out the right adapter. But your BACnet tool picked the Wi-Fi adapter when it started — so its Who-Is broadcast goes out onto the office Wi-Fi, where there are no controllers. Discovery comes back empty, and ping is fine.
Look for: the adapter or local IP address your tool is bound to. Pick the Ethernet address explicitly, or turn Wi-Fi off while you work. A VPN adapter can cause the same problem.
Is there NAT in the path?
BACnet/IP and network address translation don't mix well. Some BACnet messages — especially broadcasts forwarded by BBMDs — carry the original sender's IP address inside the BACnet message itself, not just in the IP header. NAT rewrites the header and leaves the inside alone, so the far end ends up replying to a private address it can't reach. Ping crosses NAT without a problem, because ICMP doesn't care.
Look for: a remote site, a cellular router, or a cloud connection in the path. If NAT is unavoidable, it needs a BACnet-aware design, not just a port forward.
Reading the answer in a capture
The fastest way through this list is Wireshark on your own laptop, filtered to bvlc || bacnet || bacapp, while you run a Who-Is.
| What you see | Where to look |
|---|---|
| Your Who-Is goes out; no I-Am comes back | Firewall in the path (1), wrong port (2), a router in the way (3), or the device's own configuration. |
| No Who-Is from you at all on the adapter you're watching | Tool bound to another adapter (7), or not running its BACnet interface (6). |
| I-Am arrives in Wireshark; tool shows nothing | Your laptop's host firewall (5), or another program holding the port (6). |
| Traffic from the device on an unexpected UDP port | Non-standard port (2). “Decode As” BVLC to read it. |
| ICMP “port unreachable” back from the device | Nothing listening on that UDP port at that IP — wrong port, or the wrong device on that address. |
| Reject or Abort replies, rather than silence | The network is fine; now it's a BACnet question. The BACnet error codes page decodes them. |
Silence and an error are very different results. Silence means something between you and the device is losing the message. An error reply means BACnet got there, and the device is telling you what it didn't like.
A worked example
Monday morning, a building's controllers are all offline at the head end. IT moved that building behind a new firewall over the weekend and says they tested it — everything pings. From the head end, I run Wireshark and a Who-Is. The Who-Is leaves. Nothing comes back. I ask IT to look at the firewall log for UDP 47808 from the head end's address, and there it is: denied, hundreds of times since Saturday. They'd written a rule for ICMP so they could test, and the BACnet rule never made it in. One rule added, both directions, and every controller came back.
That took ten minutes because the question was specific. “Can you open BACnet?” gets you a shrug. “Your firewall log shows UDP 47808 from 10.20.1.10 being denied — can you allow it both ways between these two subnets?” gets you a fix.
The short version
- Ping proves IP, not BACnet. It's a good first check and a poor last one.
- Firewall and port first, especially after any network change.
- Subnet next: discovery doesn't cross a router without a BBMD or foreign device registration.
- Then your own laptop: host firewall, adapter binding, and whatever else is sitting on 47808.
- Capture on your laptop. Wireshark shows what reached the wire and what your tool actually received, and the difference is usually the answer.
Go deeper
From the IP layer up to BACnet, with the capture to prove each step
IP addressing, firewalls and the request to hand IT, BACnet/IP ports, BBMDs, and reading a Wireshark capture without drowning in it. BAS Communication is the protocol layer underneath this article, written for the tech holding the laptop.
Get BAS Communication — A Field ReferenceFound a wrong number or a broken link? Tell me and I’ll fix it.