Dennis V McEnaney

(At least for the IPv4 transport) Should the 'invoke_id' checks within the 'BacnetAsyncResult' event handler methods also check that the ('routed-source') address is correct - in addition to checking for the correct (/matching) Invoke-ID? E.g. For this: private void m_comm_OnComplexAck(BacnetClient sender, BacnetAddress adr, BacnetPduTypes type, BacnetConfirmedServices service, byte invoke_id, byte[] buffer, int offset, int length) { if (invoke_id == m_wait_invoke_id) Should the line be something...

(At least for the IPv4 transport) Should the 'invoke_id' checks within the 'BacnetAsyncResult' event handler methods also check that the ('routed-source') address is correct - in addition to checking for the correct (/matching) Invoke-ID? E.g. For this: private void m_comm_OnComplexAck(BacnetClient sender, BacnetAddress adr, BacnetPduTypes type, BacnetConfirmedServices service, byte invoke_id, byte[] buffer, int offset, int length) { if (invoke_id == m_wait_invoke_id) Should the line be something...

Should the 'invoke_id' checks within the 'BacnetAsyncResult' event handler methods also check that the ('routed-source') address is correct - in addition to checking for the correct (/matching) Invoke-ID? E.g. For this: private void m_comm_OnComplexAck(BacnetClient sender, BacnetAddress adr, BacnetPduTypes type, BacnetConfirmedServices service, byte invoke_id, byte[] buffer, int offset, int length) { if (invoke_id == m_wait_invoke_id) Should the line be something similar to this (pseudo-code): //...

For the benefit of others; BitDefender Total Security seems to exhibit a similar problem, it deletes the debug build of 'ProperTable.exe', i.e. requires an BitDefender exception to be created.

F.Y.I. The 'DADR' value is generally a virtual MAC address, not a registered one (- with an OU assigned/included). But otherwise, proper MAC/physical/burned-in addresses should be unique; unless the unlikely case that Carrera Technology supposedly once had whereby the country (/Singapore?) that sold them bulk NICs had apparently copied the firmware verbatim - they all had the same MAC address assigned/burnt onto them; network-conflict city (!). ;P

Maybe to add to Monsieur Chaxel's answer; depending upon your location/situation, it might rely upon bog-standard network (/trunk) routing being fully configured if you are going across/into several VLANs/subnets (- as opposed to using a BBMD), and I don't believe you can target routed/gatewayed (/child) devices, i.e. ones that have a DNET/network segement # & currently DADR/virtual MAC address pairing assigned via YABE - but I could be wrong (?).

I wonder if you could (easily) use the room-simulator (with changes) as a test-bed.

@fchaxel ( I could be wrong but I believe C#/.NET is expecting the certificate chain to be present upon the O/S, so you'd probably have to open the relevant cert store 'location' & 'store' yourself in order to be able to traverse the full chain (/'Certification Path') of certificates; but I would imagine that in most cases what you're generally looking to do is just verify the chain - i.e. invoke the cert's 'Verify()' method during the remote-cert-validation. )