ES version bacnet module 3.6.0 issue compare ver. 3.5.2

[frankalton]

As for testing, we have ES and also a PC installed with MANGO (non-commercial version).

With bacnet module version 3.5.2 on MANGO PC (Windows 10), we manage to scan ALL the controllers on old interface screen on bacnet/IP discovery.

Upon we upgrade the bacnet module version 3.6.0 on MANGO PC, even the old interface or new interface we faced similiar issue that we did not manage to get all the DDC controller online in the list on bacnet/IP.

Initially, we won't perform above test scan until we noticed MANGO ES bacnet discovery had very less of controllers it manage to scan on bacnet/IP on version 3.6.0.

Same issue we encounter too on bacnet/mstp on MANGO ES - manage to discover Alerton and Honeywell Spyder but not others brand of bacnet mstp ddc on same rs-485 comm. Is there any restriction on brands bacnet ms/tp ddc that MANGO ES allow to discover on bacnet ms/tp ?

Any firewall or settings we need to look into ?

regards,
Frank

[phildunlap]

Hi Frank,

Hmm, hard to say offhand what might be happening. Did you run this test multiple times?

The most in-depth path of investigation is to take two wireshark captures, one starting with the discovery process from 3.5 and one from 3.6 and see the network traffic.

In the images of discovered devices, I find it interesting how an IP device, 192.168.0.20 has only appeared in the second discovery. I also find it interesting that some of the devices on network number #8000 have been discovered, while others have not. I would expect that means a device on the IP network is the router to network 8000, so it received and responded to the discovery broadcast but not all of its devices responded.

Is there any restriction on brands bacnet ms/tp ddc that MANGO ES allow to discover on bacnet ms/tp ?

No.

Any firewall or settings we need to look into ?

Not in Mango. No settings in Mango should have changed in the course of upgrading. BACnet4J 5 was bundled instead of 4, so there were changes to the underlying library but that doesn't seem to me to be why the devices on the 8000 network are not being discovered, and would be most fruitfully investigated if that does appear the culprit with the wireshark captures mentioned above.

[frankalton]

Dear Philips,

We will re-test again with wireshark and post the result here.

regards,
Frank

[frankalton]

Dear Philips,

Apologize for late reply.
I cannot send the wire shark file capture in this forum, I will drop an email to you with same subject as above for the file capture that test scan on bacnet version 3.5.2 and 3.6.0 on MANGO installed on PC.
Hope this can ease you to troubleshoot, same issue happen in MANGO ES on scanning bacnet mstp and ip.

Regards,
Frank

[phildunlap]

Thanks. What I see in the capture is that Mango is sending out the exact same broadcast in both captures. It appears the device at 192.168.0.80 is the gateway to the majority of missing devices. Why its behavior is different, I could not say - Mango is broadcasting the same discovery packet in both cases.

Further it would appear device 400 at IP .40 and 200 at IP .20 appeared in this run of the discovery on 3.5.2, but is not present in your initial screenshot of devices, while device 89256 does not appear to respond in the 3.5.2 capture.

Devices 2050, 9001 and 9002 don't have responses in the 3.6.0 capture. These appear to be linked through 192.168.0.80 .

These captures are not indicative of a difference in Mango's behavior between the two versions, but rather that the network in question doesn't consistently respond to discovery broadcasts generally. This capture only indicates to us the traffic that made it to 192.168.0.7, but it is possible there is one or more devices inefficiently using the network and degrading its overall health, or that 192.168.0.80 is overwhelmed and not properly forwarding messages on its segment.

I would expect you do not get the same results running the discovery over and over again on the same version. The fact that IP hosts are appearing differently indicates it may be the whole network though, and not just the device at 192.168.0.80

[frankalton]

Dear Philips,
Thank you, since there are confuse matter on verifying the issue we face. Can we downgrade the bacnet module version to 3.5.2 for further checking on MANGO ES ? Please advise .

We will redo check on both version, and come out with the schematic diagram for better understanding for both of us.

As I told you earlier - we noticed some controller unable to discover on bacnet version 3.6.0

Thank you
regards,
Frank

[phildunlap]

You would have to use Mango 3.5.x to use a 3.5.x version of BACnet. Database downgrades aren't supported, so you'll either need to restore a database backup from 3.5 to 3.5, or you can export the JSON from the 3.6 instance and import it into 3.5 . But, you must already have 3.5 to have given me those captures, yes?

As I told you earlier - we noticed some controller unable to discover on bacnet version 3.6.0

Your capture doesn't indicate that using 3.6 is the cause from my understanding presented in the last post.

[frankalton]

Hi Philips,
The MANGO ES upgraded every time there is upgrade available , I didn't take action to backup any older version unless the ES has a auto backup "If yes - do tell me how to restore"
The scan result on earlier post was performed on MANGO PC (free version) - that we have 3.5 and 3.6.
Can you elaborate in details steps how shall we rescue MANGO ES now
My main concern is MANGO ES.

regards,
Frank

[phildunlap]

If you had it configured to make backups, you would perhaps still have a backup like core-database-H2-date.zip in the /opt/mango/backup directory. If you have one from before the upgrade (which is checked by default, but if you backup task doesn't backup the database that wouldn't happen), you could restore that into 3.5

[techalton]

Dear Philips,
Hi, I'm Eswaran, we now we are having two issues that we unable to solve

• First issue we unable to scan some brand controller in BACnet version 3.6.0 on pc version (windows 7)

  • First attempt with BACnet version 3.6.0 on pc version (windows 7)
    

  • Second attempt with BACnet version 3.6.0 on pc version (windows 7)
    

  • Third attempt with BACnet version 3.6.0 on pc version (windows 7)
    

    

  • First attempt with BACnet version 3.5.2 on pc version (windows 7)

    

  • Second attempt with BACnet version 3.5.2 on pc version (windows 7)

    

  • Third attempt with BACnet version 3.5.2 on pc version (windows 7)
    

  As you can see ..... why Dev 1003 unable to scan in Bacnet version 3.6.0 (the latest version)

The Second issue was we unable to scan the DDC properly BACnet IP on mango ES

• 

Pls refer to the link below for Wireshark file together with the mango host file :
https://files.mycloud.com/home.php?brand=webfiles&seuuid=ec51add0c5fe1adc5cc3e5a6d5627780&name=Mango_forum_Post_230819

[phildunlap]

Please email the wireshark logs to support@infiniteautomation.com

[techalton]

@phildunlap Please check your email. thank you

[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.