Re: [BACpypes-developers] Devices ignoring Destination Specifier

[Monson, K. E <Kyl...@pn...>]

Thanks Joel. This makes clear the needed enhancements to my configuration grabber and BACnet driver.

It doesn't help that everywhere I've tried using a WhoIs with a destination specifier (remote address or not) it has worked as I expected and I only get back an IAm from the device I care about. Bad luck I guess.

It doesn't help that the help rep from another vendor looked at our pcap file and claimed that the "problem" device should not be responding to the WhoIs because of the destination specifier in the request. Apparently he was confusing it with the device instance range or something. 

Thanks again,
Kyle

-----Original Message-----
From: Joel Bender [mailto:jo...@ca...] 
Sent: Wednesday, February 17, 2016 19:33
To: Discussion about developing BACpypes
Cc: Gerard Cassie (gc...@in...)
Subject: Re: [BACpypes-developers] Devices ignoring Destination Specifier

Kyle,


> When a WhoIs with a destination specifier is broadcast out to a subnet (192.168.1.255 for example) are other devices on that subnet required to respect the destination specifier and not respond with an IAm?

If the WhoIs contains a device instance range, and the device identifier of the recipient falls in that range, they are obligated to reply.  This is independent of how the WhoIs request was delivered to them.  Like other distributed directory services, the device initiating the WhoIs request typically has no idea where the destination can be found, so the request is broadcast.

All devices on the subnet will receive the request, so rather than "respecting the destination" they assume that since they got it, they should respond.  An "unconstrained WhoIs", where the device instance range is not specified, will generate a response from every device on the subnet.  For large networks (and especially where the destination was a "global broadcast") this can result in a bone crushing number of responses.

> Likewise is the device required to respect the destination specifier 
> of a read property request even if the request was broadcast to an 
> entire subnet? (We are getting a rouge IAm response before the real 
> one which triggers a read property request in my script before we've 
> established the route to the device.)

WhoIs requests are unconfirmed services, while read property requests are confirmed.  Unconfirmed services may be broadcast or unicast, but confirmed services may only be unicast.  If you need to "bind" with the device, which is a BACnet concept of translating a device identifier into an address, you should be doing that first.

Note that you may already have some knowledge someplace (like in a topology database) of that device-address-binding so you can simply use what you've already learned.  When you get back an error, like the object doesn't exist, then the device has been reconfigured or maybe the topology has changed and your device-address-binding is obsolete, which means going back through the WhoIs-IAm sequence.

> I ask because we are dealing with such a device. Are they terrible and 
> should be ashamed or is this something we have to learn to deal with? 
> If it goes against the bacnet spec where in the spec does it say so? 
> (My googling was fruitless)

If they are rejecting your ReadPropertyRequest because it was sent to them via a broadcast address, they are being more strict with their interpretation of the standard.  They are likely rejecting all broadcast confirmed services early in their stack before even getting to the point of knowing what confirmed service is being requested.

A vast majority of the devices that I'm aware of do not pay attention to how they go the packet, even if that information is available to them courtesy of their IP stack.  BACpypes opens up two sockets, one for unicast and one for broadcast traffic, so that kind of distinction can be made.  If you dig into the lowest part of the application layer in BACpypes you will see that it does NOT check, and this is done to accommodate stacks that bind to ('', 47808) and have no way of knowing how a packet arrived.

> I think I can work around it by specifying a device id range limited to our intended target and then ignore IAm responses that don't match the id. Does that sound like a reasonable solution?

That is absolutely the correct thing to do, and everyone that was at the very first plugfest in NIST (this one was in 1993-1994 while the protocol was being adopted, before "coming out party" in Atlanta) latched on to that technique as a way to bind to a specific device and keep the volume of broadcast traffic to a minimum.

> I've CCed the unfortunate owner of said device.

The fault, dear Brutus, is not in their stack but in ourselves, and there may be sample code of mine that has led you astray.

It is shameful to admit, but there is some code that I have written that sends a ReadPropertyRequest as a local broadcast with the DNET/DLEN/DADR of the destination device, because at the time I knew the BACnet address of the destination but I didn't want to be bothered going through the WhoIsRouterToNetwork and IAmRouterToNetwork dance.  Of course the appropriate router would forward the message for me, and I would learn which one that was by looking at the source address of the response (and the SNET/SLEN/SADR would be appropriate).  Once I had the path "loaded", I didn't need to do that until the application restarted, which was every couple weeks, and at night when nobody was looking :-).

This (not in a nice use of the term) hack solution doesn't work if the source and destination are on the same network because (a) I could get multiple responses from the devices that are not paying close attention or (b) not getting a response from a device that is paying attention.

<sidebar>

There is one other dragon lurking in the shadows.  For COV notifications, some devices will turn notifications from confirmed to unconfirmed and broadcast them, even if you requested them to be confirmed and therefore unicast.  For example, if devices A and B both subscribe to the outside air temperature sensor on device C and they both request confirmed notifications, the device C will send out one unconfirmed broadcast notification and expect that both A and B will be happy when they get it.  It is highly presumptuous for device C to do that, but as it turns out A, B, and C are all from the same vendor so they all participate in this travesty.

That's not the worst part.  If A, B, and/or C happen to be on different BACnet networks, C will send the message as a global broadcast, which means that you have to take extraordinary measures to keep these from flooding your networks (with things like split horizons and network visibility rules in your routers).

</sidebar>

As the last comment, I'll leave you with the Robustness Principle [1], being generous with what you receive and strict in what you generate.  As a systems integrator, I also interpret that to mean it is my job to accept the foibles of others, yet strive to not contribute to the madness.  If there's something I can do to help, let me know.


Joel
[1] https://en.wikipedia.org/wiki/Robustness_principle
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
BACpypes-developers mailing list
BAC...@li...
https://lists.sourceforge.net/lists/listinfo/bacpypes-developers