I’m trying to connect to equipment via BACnet/IP. The controller communicates BACnet/IP, and the equipment is connected to the controller via BACnet MS/TP.
I can successfully connect to the controller, but when I try to connect to a device through the controller, I get the following error:
java.lang.IllegalArgumentException: Not an I/P mac
I also see variations of the error below, but for other device IDs:
Here’s the local device config:
BACnet/IP controller (initializes successfully):
VAV (fails to initialize):
It seems likely that the controller isn't configured properly.
Error during send: OutgoingConfirmed [...] address=Address[networkNumber=1100, macAddress=[1f]], linkService=null]
Not an I/P mac
In BACnet IP, the "macAddress" is a hexadecimal representation of the IP & port for a device. This error is telling us that the mac address 1f is not an IP address. Which is true. That being said, I'm not entirely convinced that this error is related to your device not initializing. The device numbers in your logs do not match the device number in your config. It's possible that there is an error just like this for the device you have configured, but I want to be careful not to assume that.
So, if 1f is not an IP address, why in the world are we trying to send BACnet IP messages to it? My guess is that this is part of the driver's discovery process. The driver sends out a blanket whoIs message, and the controller has happily forwarded the iAm requests from all of the MS/TP devices back to the driver. Since those devices are communicating MS/TP, their macAddress is the device's address on the serial network.
I would assume that the controller should be a bit smarter about how it forwards the iAm requests by directing the driver to communicate with the MS/TP device via the controller's own IP.
This is why I say it's likely that the controller is not properly configured. Have you properly configured the controller as a BBMD? If not, I suggest trying that. If you think you have it properly configured as a BBMD, you can also try configuring Ignition to "register as a foreign device" and provide the BBMD address in the local device config. My understanding is that is not necessary if the BBMD has a properly configured BDT, but I am not expert in BACnet deployments.
Another thing to consider is that the Ignition BACnet driver and the library it uses for protocol communication have both recently received several bug fixes for issues that prevent devices from initializing. A majority of these fixes were included in 8.3.3. One issue that was not fixed until 8.3.4 is that the device could hang when shutting down. This includes when the device is restarting due to configuration changes made to the local or remote device configurations. To avoid getting hit with this bug while trying to troubleshoot this issue, consider updating to 8.3.4 RC2 or restarting the gateway after making changes to the device config, especially if it appears as if your config changes did not take effect how you expected.
Without a packet capture and details about which controller you're using and how it is configured, I'm just just making educated guesses.
3 Likes
Hi Cody,
Thanks for the details. I tried configuring the controller as a BBMD with and without the “register as a foreign device” option and the VAV-15-04 MS/TP device did not initialize. I also restarted the gateway but it did not work.
We’re running Ignition 8.3.3, and trying to connect to a Schneider Electric AS-P controller. If there’s any details from the controller setup that you need specifically, let me know. We have been able to get the MS/TP devices talking with Kepware, but we’d like to use the built in Ignition driver if possible. Working on getting a .pcap for you as well.
Thanks,
Cade
I'm not familiar with that particular controller, but I'll see if there's anything else I can dig up.
In the meantime, feel free to upload any PCAPs, logs, or other info that you'd rather not share publicly on the forum here:
Edit: I can't seem to find any documentation about how to configure the AS-P as a BBMD. It looks capable, but I have no idea what the configuration looks like. Screenshots might help. Support may be able to help more with a screen sharing session 
2 Likes
Hi Cody,
I’ve uploaded a PCAP of the BACnet traffic during connection. I tried to configure the connection as a BBMD in Ignition. In the capture, we enable the connection to the AS-P first and it initializes successfully, then we enable the connection to the VAV and it fails to initialize. Let me know if you need any details.
Thanks,
Cade
Hey Cade,
Could you try setting the local device's network number to something different? If that doesn't work, could you try setting all of the BACnet loggers to trace and uploading them to the dropbox?
There's some logic in the BACnet library we use to determine if a router is being used. The BACnet router sits between two BACnet networks, so there should be a different network number on either side.
BBMD config on the Ignition side probably isn't necessary. I'm not sure if any config changes will need to happen on the AS-P to assign distinct network numbers for the BACnet/IP and MS/TP networks
1 Like
Hey Cody,
I tried using setting the local device’s network number to something different, and unfortunately that didn’t work. One note is that this setup does work using Kepware, although we want to use Ignition for simplicity’s sake. Here’s a couple screenshots of the settings - the AS-P controller/router is accessible on network 1, and the MS/TP devices are on network number 1100.
Local device:
AS-P controller:
RTU-1 (MS/TP network via AS-P controller):
Thanks,
Cade
Looks like Kepware is using 1 for the local device network number. Did you try that in Ignition?
I'm afraid I'd need the debug logs and maybe another PCAP with that change made to be able to help more. Support can help with getting the logs.
1 Like
Hi Cody,
I tried 1 for the local device number and unfortunately the connection to the RTU still did not initialize. I’ve uploaded logs and a pcap of this to the Dropbox.
I did notice that we are getting a buffer overflow from the AS-P controller after the BACnet driver requests the object list for 1110101, which is the RTU. This seems similar to what was happening in 8.1. I believe Kepware falls back and reads individual properties, but I could be wrong about that.
Thanks,
Cade
1 Like
Cool, now we're getting somewhere. The logs no longer show the Not an I/P mac error, and the PCAP shows the driver is now attempting to read properties. So, network number set to 1 in the local device config is correct.
The PCAP also shows the buffer overflow you mentioned. Coincidentally, one of the recent changes made to the driver is that it should fallback and read individual properties when it receives a Reject response indicating bufferOverflow. We don't see that happening in the Wireshark. It looks like that change was limited in scope to when we read multiple properties at a time. With this request, we're reading a single (large) property, and it doesn't get split the same.
If you have a PCAP from a working Kepware install, that might help clarify the differences, but don't go out of your way to grab one it if it's a pain. I think we can probably deduce enough without it.
Something else that is a bit strange in your PCAP are the errors we receive when we attempt to read the max-segments-accepted property. I would have assumed that property is required, but maybe not. I'll take a look at that also.
2 Likes
Hi Cody,
Thanks for looking into this! I don’t have a PCAP of Kepware connecting, but I do have one of YABE successfully grabbing the objects from the same controller and MS/TP devices. I’ve uploaded that to the Dropbox folder as well.
Cade
1 Like
I've created ticket IGN-15622 to track this work. We plan to fix it, but it won't make 8.3.4 or 8.3.5.
Would you be willing to test a nightly build with the fix?
1 Like
Hi Cody,
Sounds good to me. Unfortunately I can’t test a nightly build at this time, but I’ll test once the fix is implemented in the next version.
Thanks,
Cade
1 Like
No worries, I appreciate the help you've already given us so far. While I think I know what is needed to fix this, we don't have a system that behaves this way. My understanding is the BACnet device should use Abort instead of Reject in this situation, it's part of the reason why this isn't handled already on our side.
I'm trying to find a test system to verify, so that we have a bit more confidence in the fix.
2 Likes
