ONVIF discovery not working on vlan after network reconfiguration

billie

I have just finished reprogramming various switches (all NetGear equipment) to isolate camera traffic from my normal intranet traffic. Although the cameras remain untagged, once they hit the switch, they get put on an internal vlan across several 10G connections, and ultimately reach my Mac mini on this vlan. This keeps my lower performance broadband routers from ever seeing this traffic, as those ports are isolated to a different vlan by the switch, and the respective ports are vlan specific. Only the 10G link will see both camera traffic and intranet traffic, and it will be isolated by vlan there.

After partially implementing this configuration change, I notice that the ONVIF discovery no longer works on the camera vlan. With 9 cameras moved, and after restarting SecuritySpy, the ONVIF section for Auto-Discovered Devices no longer shows the moved cameras, and I end up having to enter their (new) IP addresses instead to access them (which then works fine).

Any idea why this might be the case? Previously, all my cameras were discoverable via ONVIF.

The intranet traffic now comes in on vlan 7 across switches and to my Mac mini (although it is untagged traffic at all other devices). The new camera vlan is vlan 101 across switches and to my Mac mini (again, it is untagged traffic at the cameras themselves). The untagged ethernet interface for the same physical port on my Mac mini is disabled.

Ben

ONVIF device discovery uses UDP, as opposed to the actual RTSP connection to the camera to obtain the video stream, which uses TCP (almost always). So this could explain the difference. Is there some option you have to enable to allow the VLAN to pass UDP packets?

billie

The NetGear configuration is simply port based, not protocol based. It is tagging all traffic from a given port with a designated vlan tag, and then stripping that tag when sending data to devices on the port. Only my Mac is configured to keep the vlan tags.

Let me do some more research. Perhaps there is some kernel config to replicate a broadcast and/or multicast packet sent by an application to all interfaces?? Or perhaps there is something on the Netgear switch filtering such packets. Certainly the broadcast domains are distinct between the two vlans, so it would the Mac's responsibility to replicate the packet to both VLANs.

billie

Running tcpdump on each of the interfaces shows the discovery request going out on each vlan, and responses are received for all the cameras. However, SS drop-down box only shows those from a single vlan, and not from both vlans. The difference in the returned data seems to be:

camera vlan has standalone="yes" , and the tags are thus not encoded with the expected tags. For example, <s:Envelope rather than <SOAP-ENV:Envelope. My guess is that DNS entries are wrong for the new vlan, so I'll pursue that angle.

A good response properly processed by SS:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope&quot; xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding&quot; xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery&quot; xmlns:dn="http://www.onvif.org/ver10/network/wsdl&quot; xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"&gt;
<SOAP-ENV:Header>
<wsa:MessageID>uuid:d336818e-000e-11ea-b621-b0c5540f037a
</wsa:MessageID>
<wsa:RelatesTo>uuid:990aff51-019f-4da0-abcd-5119faa14661
</wsa:RelatesTo>
<wsa:To SOAP-ENV:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/addressing/role/anonymous
</wsa:To>
<wsa:Action SOAP-ENV:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches
</wsa:Action>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<d:ProbeMatches>
<d:ProbeMatch>
<wsa:EndpointReference>
<wsa:Address>urn:uuid:77bae9cb-79c0-71bc-e3c1-b0c5540f037a
</wsa:Address>
</wsa:EndpointReference>
<d:Types>dn:NetworkVideoTransmitter
</d:Types>
<d:Scopes>onvif://www.onvif.org/type/video_encoder onvif://www.onvif.org/type/audio_encoder onvif://www.onvif.org/location/taiwan onvif://www.onvif.org/hardware/DCS-5029L onvif://www.onvif.org/name/DCS-5029L onvif://www.onvif.org/vendor/D-Link%20Corporation onvif://www.onvif.org/Profile/Streaming
</d:Scopes>
<d:XAddrs>http://192.168.7.135/onvif/device_service
</d:XAddrs>
<d:MetadataVersion>1000
</d:MetadataVersion>
</d:ProbeMatch>
</d:ProbeMatches>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

and a bad response from the new vlan:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<s:Envelope xmlns:sc="http://www.w3.org/2003/05/soap-encoding&quot; xmlns:s="http://www.w3.org/2003/05/soap-envelope&quot; xmlns:dn="http://www.onvif.org/ver10/network/wsdl&quot; xmlns:tds="http://www.onvif.org/ver10/device/wsdl&quot; xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery&quot; xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"&gt;
<s:Header>
<a:MessageID>uuid:55ead128-a569-4ae5-9b47-2e7416e5ef5a
</a:MessageID>
<a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery
</a:To>
<a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches
</a:Action>
<a:RelatesTo>uuid:88aadf52-504a-4da0-abcd-076f0977466c
</a:RelatesTo>
</s:Header>
<s:Body>
<d:ProbeMatches>
<d:ProbeMatch>
<a:EndpointReference>
<a:Address>uuid:ed397a0b-b8a9-3929-506e-cf584e85b8a9
</a:Address>
</a:EndpointReference>
<d:Types>dn:NetworkVideoTransmitter tds:Device
</d:Types>
<d:Scopes>onvif://www.onvif.org/location/country/America onvif://www.onvif.org/name/LOREX onvif://www.onvif.org/hardware/LNB8105X onvif://www.onvif.org/Profile/Streaming onvif://www.onvif.org/type/Network_Video_Transmitter onvif://www.onvif.org/extension/unique_identifier
</d:Scopes>
<d:XAddrs>http://192.168.101.5/onvif/device_service
</d:XAddrs>
<d:MetadataVersion>1
</d:MetadataVersion>
</d:ProbeMatch>
</d:ProbeMatches>
</s:Body>
</s:Envelope>

billie

Ok, I think I see the issue. My EERO-mesh system is too simplistic to handle internally routed traffic. So requests go out to the internet, but the EERO doesn't know how to route the responses back. There are no static route configuration options available. So the cameras cannot communicate with the outside world, and that is what seems to be the issue with ONVIF discovery. However, there is a lot more communication with the outside world than I would have expected, so perhaps this is a good problem to have (after all, I don't require ONVIF discovery).. I see a lot of DNS queries for devaccess.easy4ipcloud.com, and subsequent accesses to *.us-west-2.compute.amazonaws.com.ndmp servers (both of which I hadn't expected).

Howdy, Stranger!

Categories