Expected Behavior
When multiple macOnline channels are configured with different MAC addresses, each channel should reflect only the result of GetSpecificHostEntry for its own MAC address.
If the FRITZ!Box returns SOAP fault 714 (NoSuchEntryInArray) for a MAC address, that MAC's macOnline channel must not subsequently become ON based on the response for another MAC address.
Current Behavior
With several macOnline channels configured for different devices, an offline/unknown MAC can incorrectly change to ON immediately after a successful GetSpecificHostEntry response for a different MAC.
This was observed with openHAB 5.1.0 and the TR-064 binding.
The problem is reproducible during a polling cycle. TRACE logging of org.openhab.binding.tr064.internal.soap.SOAPConnector shows the following sequence.
For MAC A (an absent device), the binding sends:
<u:GetSpecificHostEntry xmlns:u="urn:dslforum-org:service:Hosts:1">
AA:AA:AA:AA:AA:01
</u:GetSpecificHostEntry>
The FRITZ!Box responds:
<s:Fault>
s:Client
UPnPError
714
NoSuchEntryInArray
</s:Fault>
The corresponding IP address channel becomes UNDEF, as expected.
Shortly afterwards, another MAC (MAC B, an actually connected device) is queried:
<u:GetSpecificHostEntry xmlns:u="urn:dslforum-org:service:Hosts:1">
BB:BB:BB:BB:BB:02
</u:GetSpecificHostEntry>
The response for MAC B contains:
1
Immediately after this successful response, the macOnline item belonging to MAC A changes from OFF to ON, even though the FRITZ!Box had returned 714 NoSuchEntryInArray for MAC A.
The same behavior was observed for multiple absent MAC addresses in the same polling cycle.
The complete original TRACE log contains private MAC addresses, host names, internal IP addresses and item names, so I have not attached it. I can provide a further anonymized TRACE if required.
Possible Cause
While investigating the issue, I noticed that SOAPConnector appears to reuse/cache results for channels using the same getAction.
For GetSpecificHostEntry, however, the result also depends on the request parameter (NewMACAddress).
It therefore looks possible that a successful GetSpecificHostEntry response for one MAC address is reused when updating channels configured with a different MAC address.
This would also explain why several absent macOnline channels can become ON immediately after a connected host returns NewActive=1.
This is only a hypothesis based on the observed TRACE sequence; I have not yet tested a code change.
Steps to Reproduce
- Configure a TR-064 LAN subdevice with multiple macOnline channels for different MAC addresses.
- Have at least one configured device connected to the FRITZ!Box (NewActive=1).
- Have at least one other configured MAC absent or unknown to the FRITZ!Box (714 NoSuchEntryInArray).
- Enable TRACE logging for org.openhab.binding.tr064.internal.soap.SOAPConnector.
- Observe a polling cycle.
- The macOnline channel for an absent MAC may change to ON after the successful response for another MAC.
My Environment
openHAB: 5.1.0
Binding: TR-064
Thing type: TR-064 LAN subdevice (subdeviceLan)
Relevant channel types: macOnline and macOnlineIpAddress
TR-064 service: urn:dslforum-org:service:Hosts:1
Action: GetSpecificHostEntry
Installation: Docker
Expected Behavior
When multiple macOnline channels are configured with different MAC addresses, each channel should reflect only the result of GetSpecificHostEntry for its own MAC address.
If the FRITZ!Box returns SOAP fault 714 (NoSuchEntryInArray) for a MAC address, that MAC's macOnline channel must not subsequently become ON based on the response for another MAC address.
Current Behavior
With several macOnline channels configured for different devices, an offline/unknown MAC can incorrectly change to ON immediately after a successful GetSpecificHostEntry response for a different MAC.
This was observed with openHAB 5.1.0 and the TR-064 binding.
The problem is reproducible during a polling cycle. TRACE logging of org.openhab.binding.tr064.internal.soap.SOAPConnector shows the following sequence.
For MAC A (an absent device), the binding sends:
<u:GetSpecificHostEntry xmlns:u="urn:dslforum-org:service:Hosts:1">
AA:AA:AA:AA:AA:01
</u:GetSpecificHostEntry>
The FRITZ!Box responds:
<s:Fault>
s:Client
UPnPError
714
NoSuchEntryInArray
</s:Fault>
The corresponding IP address channel becomes UNDEF, as expected.
Shortly afterwards, another MAC (MAC B, an actually connected device) is queried:
<u:GetSpecificHostEntry xmlns:u="urn:dslforum-org:service:Hosts:1">
BB:BB:BB:BB:BB:02
</u:GetSpecificHostEntry>
The response for MAC B contains:
1
Immediately after this successful response, the macOnline item belonging to MAC A changes from OFF to ON, even though the FRITZ!Box had returned 714 NoSuchEntryInArray for MAC A.
The same behavior was observed for multiple absent MAC addresses in the same polling cycle.
The complete original TRACE log contains private MAC addresses, host names, internal IP addresses and item names, so I have not attached it. I can provide a further anonymized TRACE if required.
Possible Cause
While investigating the issue, I noticed that SOAPConnector appears to reuse/cache results for channels using the same getAction.
For GetSpecificHostEntry, however, the result also depends on the request parameter (NewMACAddress).
It therefore looks possible that a successful GetSpecificHostEntry response for one MAC address is reused when updating channels configured with a different MAC address.
This would also explain why several absent macOnline channels can become ON immediately after a connected host returns NewActive=1.
This is only a hypothesis based on the observed TRACE sequence; I have not yet tested a code change.
Steps to Reproduce
My Environment
openHAB: 5.1.0
Binding: TR-064
Thing type: TR-064 LAN subdevice (subdeviceLan)
Relevant channel types: macOnline and macOnlineIpAddress
TR-064 service: urn:dslforum-org:service:Hosts:1
Action: GetSpecificHostEntry
Installation: Docker