JoelBender / bacpypes

BACpypes provides a BACnet application layer and network layer written in Python for daemons, scripting, and graphical interfaces.
MIT License
296 stars 128 forks source link

BACnet device is not discoverable in Yabe #510

Open dipVyas92 opened 10 months ago

dipVyas92 commented 10 months ago

Hi Joel,

We have 2 HOST devices and all BACnet devices are added to these two host devices. Further, we use YABE to read/write operations on these BACnet devices.

Now, We are in a situation where, both the HOST devices have the same code and configurations set. but HOST-Device1 is discoverable on YABE and HOST-Device2 is not discoverable in the YABE.

We also looked at the Wireshark logs:

  1. HOST-Device1 - Discoverable device output is as follows:

    1018.342027777    192.168.9.198    192.168.9.255    BACnet-NPDU    60    I-Am-Router-To-Network
    1018.344317695    192.168.9.198    192.168.9.255    BACnet-APDU    71    Unconfirmed-REQ i-Am device,3601
  2. HOST-Device2 - Undiscoverable device output is as follows: 1018.342027777 192.168.9.197 192.168.9.255 BACnet-NPDU 60 I-Am-Router-To-Network

The undiscoverable devices enrolled with the HOST-Device2 are not sending the Unconfirmed-REQ i-Am device response. (BACnet port = UDP 47808)

So what does this say? What steps should we take to debug this further? Is this type of behaviour possible due to some network restrictions?

Any help would be appreciated!! Thanks!!

JoelBender commented 10 months ago

It would be strange to have network restrictions that block the same kind of traffic to different IPv4 addresses, but it's possible.

Run the "vanilla" module on HOST-Device-2 and turn on debugging like python3 -m bacpypes3 --debug bacpypes3.ipv4.IPv4DatagramServer. You should see messages like this in the log, this one happens to be a unicast I-Am message:

DEBUG:bacpypes3.ipv4.IPv4DatagramServer:confirmation <bacpypes3.pdu.PDU object at 0x7f978d29bca0>
    <bacpypes3.pdu.PDU object at 0x7f978d29bca0>
        pduSource = <IPv4Address 10.0.1.70>
        pduDestination = <IPv4Address 10.0.1.90>
        pduExpectingReply = False
        pduNetworkPriority = 0
        pduData = x'81.0a.00.15.01.00.10.00.c4.02.00.03.e7.22.04.00.91.00.22.03...'

If something is blocking the incoming Who-Is packets, it won't show up here. If this application responds (note that it uses device instance number 999 by default) then there's something else going on in your application.

JoelBender commented 10 months ago

In the "legacy" BACpypes turn on debugging with --debug bacpypes.udp.UDPActor.

dipVyas92 commented 9 months ago

Thanks for the response. I am attaching the logs of both working and non-working devices attached herewith.

We cannot find such differences, the only delta observed was in i-am requests. The working gateway shows I-am requests with multiple indications of a few different instance addresses but the non-discoverable device shows the i-am request only once in the beginning (single instance address). discoverable_bacnet.txt not_discoverable_bacnet.txt

dipVyas92 commented 9 months ago

@JoelBender

Please help me with this.

Thanks