ES version bacnet module 3.6.0 issue compare ver. 3.5.2

[techalton]

@techalton said in ES version bacnet module 3.6.0 issue compare ver. 3.5.2:

@phildunlap Please check your email. thank you

Did u receive my email?

[phildunlap]

Yes, I did. They all show the same devices reporting IAms this time, but I do see that the 3.5 version is making solicitations in your captures for WhoIs specific device numbers, but there is no response in the captures where these devices are discovered so it's hard to say the significance of that. Perhaps different sets of points are enabled on the two Mango instances?

In all six submitted captures devices 10000, 1001, 1002, 1003 and 1004 responded to the initial discovery request and no other devices did.

And once again all the actual BACnet/IP protocol WhoIS discovery request bytes and the TCP/IP addressing is exactly the same in all six captures, leading once again to suggest it is not a Mango issue.

[phildunlap]

Also I notice we only see one bind address for any of these discoveries. While I wouldn't expect that to be the issue 1003 isn't in your images from 3.6 despite it being in the wireshark responding in exactly the same manner as it did in 3.5 . Can you confirm the local device configuration is the same in both versions? Can you try using a bind address of 0.0.0.0 ?

[techalton]

@phildunlap said in ES version BACnet module 3.6.0 issue compare ver. 3.5.2:

Also I notice we only see one bind address for any of these discoveries. While I wouldn't expect that to be the issue 1003 isn't in your images from 3.6 despite it being in the wireshark responding in exactly the same manner as it did in 3.5 . Can you confirm the local device configuration is the same in both versions? Can you try using a bind address of 0.0.0.0 ?

can we arrange a remote view session via Teamviewer to our pc...please let us know the time and date? when u are free. thank you

[phildunlap]

Were the wireshark captures provided from the same discovery attempts as the six images posted here?

Perhaps you can modify your Mango/classes/log4j2.xml file to log BACnet4J at trace level for the course of the test, and then send in the Mango/logs/ma.log file and wireshark from an attempted discovery in 3.6

Add near similar tags close to the bottom of log4j2.xml:
<AsyncLogger includeLocation="true" name="com.serotonin.bacnet4j" level="trace"/>

You can then either restart Mango or reload them on the /ui/administration/log4j-reset page, if the Log4J reset module is installed.

Until I have reason to suspect Mango as the cause of these discovery issues, we would assess an hourly support fee for any direct assistance.

[cwangv]

Hi,
I am having similar issue running Bacnet Module 3.6.1. I can only discover some of the bacnet/ip devices, however other bacnet/ip devices can see Mango points (via bacnet/ip).
Other bacnet/ip devices on the network can see each other with no issues.
Using the legacy UI yields the same problem.
Let me know If I need to check anything to help out.

thanks.

[cwangv]

Hi, Guys
I figured it out the issue (at least for me).
It is to do with the broadcast address. For me, I needed to change it from 255.255.255.255 to 192.168.69.255 (which is my subnet host ip range).
after doing that, all is well.

@techalton - give it try.

thanks.

[phildunlap]

Thanks for sharing what you saw on your network cwangv!

I would encourage @techalton to try the bind address is 0.0.0.0 . From the wiresharks emailed in, I believe they're broadcasting on 255.255.255.255 already, but we can see in one screenshot the local device's bind address is the IPv4 address.

[cwangv]

Phil
some bacnet/ip devices won't respond to broadcast of 255.255.255.255. They only respond to local subnet broadcast request. Hence the need to change the broadcast address to 192.168.69.255.
I hope the above would help @techalton

[techalton]

@phildunlap said in ES version bacnet module 3.6.0 issue compare ver. 3.5.2:

Also I notice we only see one bind address for any of these discoveries. While I wouldn't expect that to be the issue 1003 isn't in your images from 3.6 despite it being in the wireshark responding in exactly the same manner as it did in 3.5 . Can you confirm the local device configuration is the same in both versions? Can you try using a bind address of 0.0.0.0 ?

hello Phillip

sorry for the late reply I have tried bind address 0.0.0.0 and still I'm unable to scan device 1003

thanks.

[techalton]

@phildunlap said in ES version bacnet module 3.6.0 issue compare ver. 3.5.2:

Were the wireshark captures provided from the same discovery attempts as the six images posted here?

Perhaps you can modify your Mango/classes/log4j2.xml file to log BACnet4J at trace level for the course of the test, and then send in the Mango/logs/ma.log file and wireshark from an attempted discovery in 3.6

Add near similar tags close to the bottom of log4j2.xml:
<AsyncLogger includeLocation="true" name="com.serotonin.bacnet4j" level="trace"/>

You can then either restart Mango or reload them on the /ui/administration/log4j-reset page, if the Log4J reset module is installed.

Until I have reason to suspect Mango as the cause of these discovery issues, we would assess an hourly support fee for any direct assistance.

hello Phillip

On Wireshark and ma.log I'm able to see device 1003 but on the mango UI I'm unable to see the device.i have emailed the ma.log and Wireshark file to you

thanks.

[techalton]

@cwangv said in ES version BACnet module 3.6.0 issue compare ver. 3.5.2:

Phil
some BACnet/IP devices won't respond to broadcast of 255.255.255.255. They only respond to local subnet broadcast requests. Hence the need to change the broadcast address to 192.168.69.255.
I hope the above would help @techalton

Thanks for sharing @cwangv. when I change the broadcast address to 192.168.69.255.im unable to scan any device at all

[cwangv]

@techalton
You need to change the first three parts of the IP address to match you ip range.

I am having different BACnetIP issue. In your case, most likely it is down to mango since only thing that has been changed is the mango version of software. Your field controllers would have still be the same.

I have sent in my wireshark captures and am waiting for updates.

[phildunlap]

Thanks for being persistent, techalton, we are examining the files and information you submitted.

[techalton]

hello Phillip

@phildunlap said in ES version bacnet module 3.6.0 issue compare ver. 3.5.2:

Thanks for being persistent, techalton, we are examining the files and information you submitted.

any update?

[phildunlap]

Hi techalton,

Yes, we were able to replicate the issue and reached out to the developer who was working on the changes between BACnet4J 4 and 5, which is predominantly work toward getting a BACnet BTL Compliance certification.

The cause is that the device in question deviates from the BACnet specification with regards to the data type of its protocol version (section 12.11 specifies the protocol version to be an unsigned integer). The device in question provides a character string as its protocol version, The BTL specification stipulates how to respond to deviations from the specification, but I have not had access to the BTL compliance specification to ensure this is intended behavior, and the developer who did the work has not yet responded.

[techalton]

hello Phillip

@phildunlap said in ES version bacnet module 3.6.0 issue compare ver. 3.5.2:

Hi techalton,

Yes, we were able to replicate the issue and reached out to the developer who was working on the changes between BACnet4J 4 and 5, which is predominantly work toward getting a BACnet BTL Compliance certification.

The cause is that the device in question deviates from the BACnet specification with regards to the data type of its protocol version (section 12.11 specifies the protocol version to be an unsigned integer). The device in question provides a character string as its protocol version, The BTL specification stipulates how to respond to deviations from the specification, but I have not had access to the BTL compliance specification to ensure this is intended behavior, and the developer who did the work has not yet responded.

any update from your developer?

[phildunlap]

Hi techalton,

This is the git issue it is being tracked in: https://github.com/infiniteautomation/BACnet4J/issues/43

Michel has responded and it looks like Terry has coded a prospective solution to this specific issue, but that it needs review / assistance to generalize the relaxing of the type checking in reading properties from other devices.

[terrypacker]

@techalton I have a working solution but like @phildunlap said I am not planning to release it until it is fully vetted. However if you are interested in using a beta version I can build you a replacement jar for you to test with. This would involve replacing a jar file in the web/modules/BACnet/web/lib folder of your Mango installation and restarting Mango.

[terrypacker]

@techalton I've released a new module for 3.6.x that should fix your problem. Please report back if you have any issues. Thanks!