BacNet DataSource Device Scan not listening for broadcasts
I am attempting to pull points into a new mango install from a large existing campus. The equipment is mostly Alerton hardware. I have, to date, been unable to get it to pick up any of the alerton hardware (non-alerton hardware comes in fine), and after some deep wireshark time, I have found the issue. The Who-is is sent out properly, on the designated interface (192.168.92.247), to the proper broadcast address (192.168.92.255). All the hardware responds with I-AM messages, but the Alerton hardware is broadcasting the I-AM to 192.168.92.255, and not sending it directly to the mango server (192.168.92.247). These broadcast messages are being ignored by Mango, and as a result, I cannot add those devices to the datasource.
Is there a way to get Mango to acknowledge i-am messages on broadcast? I am not sure if the standard requires I-AM's to be only directed, or if they could be broadcast, but I see no technical reason why mango shouldn't listen for directed AND broadcast responses.
JoelHaggar last edited by
I'm going to look into this and get back to you as soon as possible.
See http://developerweb.net/viewtopic.php?id=5722. The Alerton hardware is behaving properly. In unix, you cannot have BACnet4J bind to a specific address because it then ignores broadcasts. Ironically, Windows handles this better.
Okay, so that helps in one regard. By changing the datasource's bind to address to 0.0.0.0, it is now recognising the I-Am's resulting from the global Who-Is, and populating the (VERY LARGE) table of device results. Which comes to the next issue. The list is ordered in the order the results come in, and there is no way to sort the list. Finding an item on a site with >1200 devices would be quite a chore (luckily, find works).
I did find another issue which I'll put into a new post, as ti is unrelated to the actual network issues.
Upon further playing, it seems that setting the bind to address to 0.0.0.0 screws up actual data point access - so that's a non-fixer. I did see this thread, that seems to indicate a possible fix for the quirky behavior in regards to linux/java/local IP bniding/broadcast reception.
I actually had already disabled IPv6 on ubuntu, but didn't do so in java itself.
I added the preferIPv6Addresses=false and preferIPv4Stack=true to the ma-start.sh script, and it allowed binding to the broadcast address, but then it wouldn't receive directed packets. It really looks like the only way to get around this 'limitation' in linux+java is to bind to both the broadcast address, AND to the interface address with separate bindings, and route packets from either to the parser.
Did you ever look further into this issue?