Yabe on Linux unable to locate bacnet device

Question

I have a Win11 laptop and I installed Yabe and was easily able to explore bacnet objects on my home thermostat. I'm trying to duplicate this on a Linux Laptop. My issue is that Yabe is not finding my thermostat on the Linux machine.

I'm running Linux Mint 21 Cinnamon 5.4.12. I installed Mono and downloaded Yabe. I am running with command "mono ./Yabe.exe". The Win11 laptop rules out thermostat setup/network issues. In the Yabe log window I get a message that says "error loading plugins". I did't try to install any plugins so I don't know where this is coming from and I'm not sure if it's even the root cause. Initially I just left the Yabe folder in my downloads folder. I also moved it to /usr/bin but that didn't solve anything. Any suggestions would be appreciated. I would really like not to have to use Win11 as it is a memory hog.

A similar question was raised on sourceforge but the answers have not helped me. https://sourceforge.net/p/yetanotherbacnetexplorer/discussion/general/thread/1e78874922/?limit=25

Thank you for the suggestions. I ran Wireshark capture with filter "udp and port 47808" and received i-Am 100001 from the thermostat at 192.168.0.150 which is the static address I assigned. Like I said, since I literally have a Win-11 laptop sitting beside this one with Yabe installed and it sees the thermostat just fine, that rules out most network router issues. Also, I currently have the Linux firewall turned off. I believe it must be some bug with the Yabe installation on this version of Linux. I keep wanting to get away from Windows and rely solely on Linux and then I run into issues like this that make me realize why it's not universally adapted in industry.

Answer 1

At least for Windows, I believe that the plug-in DLLs are not strictly necessary/important; and you could drop the relevant plug-in DLLs alongside the 'YABE.exe' binary (- within the same folder); I've included a picture of plug-in DLLs' filenames.

Is both the (BACnet) client machine and server/thermostat machine using a public IP address, or at least a private IP address within the same subnet/network address range?

Have you got a Linux (and/or Windows) firewall blocking communication?

Can you see the 47808 port # open using the 'NMap' tool?

Also - for generic reference, an answer of mine for a half-similar question (- some points are could also be relevant here):

Things worth considering :-

Tools such as YABE, VTS and Wireshark - to learn from the success cases/successful instances of communication.

The network card (NIC) that your tools and/or libraries are using/selecting to send the ('service' request) messages - e.g. definitely don't mix routable addresses with non-routable 'private' addresses (between the BACnet 'client' IP & the 'server' IP).

(UDPv4-only) 'Broadcasts' will only work upon the local network (- if a BBMD is not present & correctly set-up to relay the broadcast on to another part/hop of the "internetwork"/connected networks).

If you're unlucky - with a particular device, your client port just might have to be 47808/0xBAC0; and just possibly for the broadcasts too.

Also try directed/'unicast' traffic/'service' requests too - e.g. attempting to read the device object instance # (DOIN) of a target device; check you've got/are specifying the correct DOIN when targeting/firing a request at a device.

Does the target device have a BACnet router or BACnet gateway in front of it (- therefore would also need the inclusion of a DNET & DADR paired values as part of addressing it)?

If so, are you talking the same variant of BACnet, e.g. IP - as in BACnet/IP between both the (BACnet) 'client' & 'server'/serving device?

If it's a commercial/enterprise device, does it have a IP whitelist - to allow for the processing of incoming requests?