Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BACnet device is not discoverable in Yabe #510

Open
dipVyas92 opened this issue Nov 8, 2023 · 4 comments
Open

BACnet device is not discoverable in Yabe #510

dipVyas92 opened this issue Nov 8, 2023 · 4 comments

Comments

@dipVyas92
Copy link

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
  1. 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
Copy link
Owner

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
Copy link
Owner

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

@dipVyas92
Copy link
Author

dipVyas92 commented Nov 21, 2023

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
Copy link
Author

@JoelBender

Please help me with this.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants