Foreign Device I-AM Response Question

[jasonmckenna00]

Hi Joel,

Thank you for clarifying my previous issue.

I am now faced with a foreign device implementation where after my device receives a forwardedNPDU from the BBMD, it responds directly to the source with a unicast message. Should I expect the response to be directed towards the BBMD to which it gets broadcast thereafter? Edit: The forwarded NPDU seems to get classified as a localStationAddr and not a localBroadcastAddr. This is causing the Unicast response and not the DistributeBroadcastToNetwork response I'm expecting. Not sure why is happening.

Here's what I'm seeing: BBMD: X.X.6.234 FD: X.X.7.13 Source: X.X.6.136

and Wireshark

Any guidance and areas to troubleshoot are much appreciated.

[JoelBender]

The BBMD is only used for broadcast distribution, not for unicast messages. The fact that it got to you forwarded means that the original source address sent it to the BBMD which then (1) broadcast it on the network and you picked it up or (2) you are also registered as a foreign device and the BBMD sent you a copy as unicast message.

The I-Am message (an unconfirmed "request" in the standard but usually sent as a "response" to a Who-Is) can be sent broadcast or a unicast. Back in the early days it was always broadcast, but then someone (and I can't remember who) sent it unicast to keep the volume of broadcast traffic to a minimum and still satisfy the Who-Is request. Now it is almost always unicast back to the original source, so the BBMD is not involved if there was one and these are Original Unicast NPDU messages.

There are times when the source/destination is not just a BBMD but also a router (has a network layer) and a device (has an application layer) so sometimes it is important to distinguish between the different BVLL messages, but those are unusual enough that it is simplified in BACpypes at the application layer, it's just an Address instance. If it was broadcast then the destination will be a LocalBroadcastAddress and if it was routed to get to you then the source will be a RemoteStationAddress, but in all cases the application can just respond by copying the source address into the destination (humorously referred to as "and the horse you rode in on" when it's routed going back).

[jasonmckenna00]

That unicast approach makes sense. If there was an implementation that required the I-AM to send through the BBMD and get broadcasted (like in the old days), what would the change be? I've been experimenting in the bvllservice.py to see this behavior.

I've also noticed Wireshark doesn't capture much of the traffic between a FD and a BBMD. Are there any tools you use to monitor the packets between the two? Maybe special filters?

[JoelBender]

If there was an implementation that broadcasted the I-AM, what would the change be?

Change this line to self.i_am(address=LocalBroadcast())

I've also noticed Wireshark doesn't capture much of the traffic between a FD and a BBMD.

Correct, broadcast messages are usually only used for "binding" like Who-Is/I-Am, Who-Has/I-Have, and for link layer messages Who-Is/I-Am-Router-To-Network. After that, almost everything is uncast. You will come across implementations that broadcast (unconfirmed) COV notifications rather than unicast to multiple recipients, the more vendors you work with the more variations in implementations you'll find, just about every place where there "is a local matter" in the standard.

If your application that's running as a foreign device is using ephemeral port numbers you might need to filter on those, but for me because the BBMD is using the standard socket $ tshark -f 'udp port 47808' works well enough, matching both source and destination port numbers.

[jasonmckenna00]

Change this line to self.i_am(address=LocalBroadcast())

Thanks for the guidance. That fix seems to be working.

I'll give that tshark command a try as well. I also found the tcpdump command let me sniff packets and their hex dumps.

I'll return with more feedback after I test it on more systems.