APDU timeouts

SteveN

Hi,

I've pulled down the latest bacnet4/j and am attempting to use it for the first time. I had no problems discovering devices, objects and properties with a BACnet simulator, but in my first attempt at querying actual BACnet devices, I've run into a few significant discovery problems. I'm new to the spec, so I'm not completely sure if the devices are not completely compliant or if bacnet4j is not handling it properly.

The biggest problems are timeouts, which occur in 2 scenarios:

All 100+ devices respond with I-AM from 10.1.1.5, but when I query for protocol-services-supported (to 10.1.1.5), many of the devices respond from 10.20.1.5. The response packet looks good, but BACnet4j ignores it because the key doesn't match, which leads to a timeout.
Many of the devices respond successfully to the protocol-services-supported request but do not send any response packets at all to the subsequent read multiple properties request. I am suspicious in this case if this may be related to a MAX APDU size problem, since it seems that these situations occur when the device does not support segmentation. I stopped requesting Properties.all in these cases, but I haven't cleared the issue yet.

There are also a few devices that immediately return an ErrorAPDU unknown object response to the initial protocol-services-supported request.

Any suggestions or insight would be appreciated.

Thanks!
Steve

mlohbihler

Hi Steve,

I can't imagine why a device would respond to one request with some IP and another request with a different IP, unless there were something like a load balancer mediating. Further, are all 100+ devices on the same host? Why do they all have the same IP address? Am i missing something?

Re your second problem, devices should always respond somehow to a request. If it were the non-segmented-all-properties issue, the device should still respond with an abort error.

SteveN

Matthew,

Thanks for the info. Unfortunately, I don't know much about the system that I am testing at this point. One of the devices responds with a Vendor_Name of Alerton Technologies, Inc. and a Model_Name of BTI Controller. I can verify that the source IP on all 100+ I-AM packets is 10.1.1.5 and I've added enough logging to the BACnet4j code to see that the waitingroom is waiting for 10.1.1.5, but the notifyMember receives 10.20.1.5. I also see these IP's in the tcpdump. Do you think this behavior is contrary to the spec? Perhaps the 10.1.1.5 host is acting as a BACnet router to devices on a different network? I actually do see in the I-AM packet a BACnet Virtual Link Control header that contains:

Function : Forwarded-NPDU
IP : 10.20.1.5
Port: 47808

Bottom line is that if I want to support these devices, it looks like I would need to change the waiting room key mechanism to use the IP from this virtual link header instead of the source IP of the I-AM packet. Any cautions or recommendations on that?

On the second problem, I have obtained a little more information. In the cases where this timeout occurred, the device reported "no segmentation" but reported ReadMultipleProperties TRUE. But I found that if I altered the LocalDevice code to avoid ReadMultipleProperties if segmentation is not supported as shown below, then this second timeout problem goes away.


        boolean multipleSupported = d.getServicesSupported() != null
                && d.getServicesSupported().isReadPropertyMultiple()
                // temporary test
                && d.getSegmentationSupported().hasTransmitSegmentation();

Not only do these devices stop timing out, but a few of the other devices that were giving me an Abort error started working also. I'm not sure if this is really the "right" fix, but I had the maxReadMultipleReferencesNonsegmented value tweaked down to 6 and they still wouldn't respond to the multiple read.

Another note is that most of these I-AM packets report Maximum APDU Length Accepted of 128.

Thanks,
Steve

mlohbihler

Looks like you're making your way through the second problem.

Re the first, i thought later that a BBMD or router might be mediating. There might be a problem in the stack for this since no such equipment was available for testing during development. Can you send me the byte stream of one or more of the IAm responses?

SteveN

Here's a couple of the I-AM responses...

Note the 0a 01 01 05 is the source address of the packet (10.1.15) and the 0a 14 01 05 (10.20.1.5) is where the acks come from later on.


0000  ff ff ff ff ff ff 00 60  2d 00 5b 35 08 00 45 00   .......` -.[5..E.
0010  00 3d f0 b9 00 00 40 11  74 f0 0a 01 01 05 0a 01   .=....@. t.......
0020  ff ff ba c0 ba c0 00 29  bc ec 81 04 00 21 0a 14   .......) .....!..
0030  01 05 ba c0 01 28 ff ff  00 00 0b 01 01 fe 10 00   .....(.. ........
0040  c4 02 00 2a f9 21 80 91  03 21 12                  ...*.!.. .!.     


0000  ff ff ff ff ff ff 00 60  2d 00 5b 35 08 00 45 00   .......` -.[5..E.
0010  00 3d f0 c0 00 00 40 11  74 e9 0a 01 01 05 0a 01   .=....@. t.......
0020  ff ff ba c0 ba c0 00 29  ba e4 81 04 00 21 0a 14   .......) .....!..
0030  01 05 ba c0 01 28 ff ff  00 00 0d 01 19 fe 10 00   .....(.. ........
0040  c4 02 00 32 e1 21 80 91  03 21 12                  ...2.!.. .!.

Attachment: download link

mlohbihler

Hi Steve,

Please try this... At line 492 in IpMessageControl replace the code:


            if (function == 0x4) {
                // A forward. Ignore the next 6 bytes.
                queue.pop(6);
            }

... with this:


            if (function == 0x4) {
                // A forward. Use the addr/port as the from address.
                byte[] addr = new byte[4];
                queue.pop(addr);
                fromAddr = InetAddress.getByAddress(addr);
                fromPort = queue.popU2B();

                // // A forward. Ignore the next 6 bytes.
                // queue.pop(6);
            }

This might not end the story, but i believe it may at least be an improvement.

SteveN

It seems to be working with that change. I'm definitely receiving the responses now. I'll let you know if I see any further related problems.

Thanks!

Steve

mlohbihler

Sweet. Thanks for reporting the problem Steve.