How heavily were you filtering that packet capture? There should have at least been a broadcast who-Is message in addition to the unicast messages.
Can your python scripts send and receive who-Is and I-Am messages with these devices?
It’s possible that they are broadcasting the I-Am response rather than sending it unicast, in which case you would need to use a bind address of 0.0.0.0 in order to receive them.
If these devices simply do not respond to who-Is messages then it won’t be possible to establish communication with them right now.
edit: I think the broadcast address may also need to be 10.A.255.255 based on what you described, but the driver may need a tweak to allow that: a network prefix length setting to go along with the broadcast address. right now the library gets configured with fixed network prefix length of 24 to go with whatever broadcast address.
Same issue with a bind address of 0.0.0.0. Firewall (ufw) disabled. No packet response with ignition. I’m going to try to install ignition on a VM on the same subnet and see if I get a response.
I’ll research the who-is / I-Am support for the python BAC0 package and see.
The target device is an Emerson sitelink card, which are very popular in the industry. It’ll be good to figure out what is going on. I’ll give you updates as they arrive.
I’m getting responses from the remote device when the VM is on the same local subnet. It’s still not initializing, so I’ll do some more trouble shooting on the instance number in the packet sniffing.
Even so, there needs to be a way for your driver to query devices on a different subnet. A simple test script, or error logging would help users. Where should I look for connectivity logging? The log directory just seems to have web logging only. That additional feature in the logs would be very useful for cases like this.
I used 0.0.0.0 for the broadcast to get the responses.
Thanks, forwarding broadcast messages isn’t activated by default on most networks to prevent a single misconfigured or malicious device creating packet overloads on other segments. You should document this requirement. Similarly, I’d suggest that you create an alternative test that doesn’t solely rely on broadcasts for connectivity testing. I’d be more than happy to work with you on testing this. We see a great opportunity with ignition and would like to see success on your part. Thanks for the logging link. Updates soon.
I think we can eventually get to a point where discovery isn’t required, though your devices should also just support unicast like the other ones we test. Broadcast isn’t strictly required right now.
From what I understand having spent some time in the BACnet spec, if you can’t forward broadcasts between subnets and you can’t locate Ignition on the same network as your devices, the proper approach is to use a gateway that acts as as BBMD and configure Ignition to register as a foreign device.
fwiw, I would expect the broadcast address to be the x.y.z.255 address in the device’s subnet, not the subnet of the Ignition gateway. But note @noc’s point that commercial/industrial grade routers will not forward directed broadcasts by default.
We took this into DMs and got him sorted. He had the wrong bind address and broadcast address settings. Once he moved his test VM onto the same network and corrected those (including using x.y.z.255 as the broadcast address) it started working.
I said this above, but to anybody else who makes is this far, Bind Address must be 0.0.0.0 for Ignition to receive broadcast packets. They will not be received if you use the bind address of the local network adapter.
Unlikely for the initial release, but we’ll eventually figure out an alternate way to do all the configuration ahead of time instead of relying on the Who-Is / I-Am to get some of necessary information from the device, since as we’ve seen some devices will only broadcast these responses and that can be an issue if you aren’t on the same subnet.
Just tested against a Schneider EcoStruxure SmartX AS-B-24 controller and all good, our test setup is just local Ethernet connected device, but once configured as suggested we could browse all the BACnet objects and create tags from them, we also created a BACnet Point UDT based on the supplied flags UDT and added the presentValue, look forward to using this in a customer project soon.
Kevin,
The “Status” tag for each BACnet device only tells me if it is Initialized or not…but doesn’t tell me if the actual device is connected or not like other drivers. This means I can’t provide any indicators or alarms on when the device goes offline. In the picture below, Device Viconics301 was previously Initialized, but someone physically disconnected that ethernet cable. Tags show as Bad quality, but I can’t differentiate between those that are online vs. offline. Any suggestions?
“Connected” is not a concept that maps well to UDP-based protocols. “Initialized” is the best you can do (i.e. we made contact and got all the initial info we need to start communications). If you need more info consider watching the quality of a tag you poll or subscribe to on the device.
edit: oops, you already mentioned that. But it’s still the best option. Even at the driver level I couldn’t possibly tell you that someone physically disconnected the ethernet - at best I just know that a response isn’t received to a request.
After digging around in the BACnet documentation, I realized that I needed a BBMD within the subnet of my devices, since it is not possible to broadcast UDP between subnets.
I made one of me devices a BBMD and configured the ignition BBMD also – after this the connection was successful.
How to configure local device and devices to access an MSTP device with a IP/MSTP gateway?
We dig around with various configuration for ip/broadcast address without any success. Direct access to data in the LIP gateway is working but not devices on the MSTP part.
Thanks,
Try binding the Local Device in Ignition to 0.0.0.0. Set the broadcast to 192.168.50.255.
Configure a Remote Device and then see if you can get a Wireshark capture. You should see Ignition sending a unicast and broadcast who-Is and then the MSTP gateway should be sending you back a bunch of broadcast I-Am messages.
Hi,
We did try this without any success. As the project was quick and urgent, we fall back to an opc ua server and voila. We’ll test the same architecture later. I’ll keep you informed.
Thanks.
Could you help me with this issue I have a notifier bacnet card with the IP 10.30.43.1
Ignition is on 10.100.30.43 could you help me with the configuration
