Help - wsdd knocking my SV3C IP camera off the network

[potchin]

I just upgraded from Fedora 39 to Fedora 40 ( which included Gnome46 and wsdd 0.7.1-2.fc40) and have noticed a strange issue. Whenever my desktop is turned on my IP camera (SV3C c18) goes into a reboot loop. Digging through wireshark I discovered that wsdd is sending a HTTP POST request to my camera (presumably its discovered the ONVIF advertisement) and promptly crashing the camera. The HTTP request is this..

POST / HTTP/1.1
Accept-Encoding: identity
Content-Length: 943
Host: 192.168.0.196:8000
Content-Type: application/soap+xml
User-Agent: wsdd
Connection: close

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsdp="http://schemas.xmlsoap.org/ws/2006/02/devprof" xmlns:pnpx="http://schemas.microsoft.com/windows/pnpx/2005/10" xmlns:pub="http://schemas.microsoft.com/windows/pub/2005/07"><soap:Header><wsa:To>urn:uuid:8b1b90ed-d3f4-11b1-a000-44291e4245a5</wsa:To><wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action><wsa:MessageID>urn:uuid:1cbe1dcc-0338-11ef-ba87-04d9f560cc60</wsa:MessageID><wsa:ReplyTo><wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address></wsa:ReplyTo><wsa:From><wsa:Address>urn:uuid:142958b8-d8fd-58f8-b950-e283c5c9bd2b</wsa:Address></wsa:From></soap:Header><soap:Body /></soap:Envelope>

it never receives a response and the camera falls off the network a few seconds later. I have confirmed that killing off wsdd stops the camera from rebooting.

Whilst I dont doubt that this is a bug in my camera's firmware the likelihood of it being fixed is pretty slim. Is there a way to prevent wsdd from querying that device? Or any other suggestions? The wsdd package is listed as a dependency of gnome-shell so removing it long term isnt an option. I'm looking to see if I can block it via a firewall rule without breaking anything else.

Happy to provide more info if needed

[christgau]

Interesting observation. Do you have a Windows machine in your network? If so, does it cause the same issue?

Whilst I dont doubt that this is a bug in my camera's firmware...

Why not? (😉)

I'm looking to see if I can block it via a firewall rule without breaking anything else.

From my point of view just block outgoing traffic from your machine to port 8000 and the IP address of your cam. Alternatively you can also block incoming UPD traffic from the camera's IP to your machine's UDP port 3702

[potchin]

I dig out a windows laptop later and see if that causes the same issue.

In the meantime, for anyone else who has a similar problem, the below correctly blocks the port. Thankfully its not the main rtsp port so you can still access the video stream.

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -p tcp -m tcp -d 192.168.0.196 --dport=8000 -j REJECT

[darrylb123]

My ASECAM with Vatilon chipset and firmware has the same behaviour. In fact, I have 2 cameras and they both crash together.
Disabling wsdd in gnome was my fix, but obviously, this is not a long term fix.

[christgau]

Maybe the same software stack is used by the devices, but anyways... same question as above:

Do you have a Windows machine in your network? If so, does it cause the same issue?

[darrylb123]

Yes, no issues when using Windows. Only started using Fedora 40.
Ubuntu doesn't cause problems either, I assume it doesn't use wsdd.

[christgau]

It's a little hard to test/reproduce/analyze without those devices at hand. Therefore, I'd like to share the steps that I would do:

1. Although windows does not cause an issue, it would be interesting to know if and how the WSD message flow looks like, i.e. a PCAP trace of the WSD traffic between cam and Windows host would be interesting. Btw: Is the cam somehow detected by Windows using WSD?
2. To figure out the reason for the crashing hardware, it would be interesting if it's the UDP communication or (like stated in the OP) or HTTP metadata exchange
3. If the latter is the case, i.e. HTTP is causing the trouble, confirming the crash with curl and the HTTP workload would be interesting.
4. Finally, comparing the HTTP messages (body and header) of Windows with the WSD ones may reveal some differences which cause the devices to crash.

Ubuntu doesn't cause problems either, I assume it doesn't use wsdd.

Maybe not yet...

[darrylb123]

I'm not aware that the cameras understand wsd at all. I had never heard of wsd until I found that wsdd generated errors in the journal as the camera crashed. Sep 30 08:37:39 myhost gvfsd[8558]: 2024-09-30 08:37:39,640:wsdd WARNING(pid 8558): no interface given, using all interfaces Sep 30 08:37:43 myhost gvfsd[8558]: File "/usr/bin/wsdd", line 330, in read_socket Sep 30 08:37:43 myhost gvfsd[8558]: File "/usr/bin/wsdd", line 742, in handle_packet Sep 30 08:37:43 myhost gvfsd[8558]: File "/usr/bin/wsdd", line 534, in handle_message Sep 30 08:37:43 myhost gvfsd[8558]: File "/usr/bin/wsdd", line 802, in handle_probe_match Sep 30 08:37:43 myhost gvfsd[8558]: File "/usr/bin/wsdd", line 856, in perform_metadata_exchange ... Going by your earlier reply the initial message is on port 8000 with the response as UDP? TCP port 8000 is not open on the cameras. They do send a bit of multicast traffic on startup. I have a Windows VM and can run wireshark on it. I have no idea how to look for wsd traffic. I also have no clue what to send with curl and where (which port on the target) I'm happy to assist with getting to the bottom of it.

…

On Thu, 3 Oct 2024 at 07:52, Steffen Christgau ***@***.***> wrote: It's a little hard to test/reproduce/analyze without those devices at hand. Therefore, I'd like to share the steps that I would do: 1. Although windows does not cause an issue, it would be interesting to know if and how the WSD message flow looks like, i.e. a PCAP trace of the WSD traffic between cam and Windows host would be interesting. Btw: Is the cam somehow detected by Windows using WSD? 2. To figure out the reason for the crashing hardware, it would be interesting if it's the UDP communication or (like stated in the OP) or HTTP metadata exchange 3. If the latter is the case, i.e. HTTP is causing the trouble, confirming the crash with curl and the HTTP workload would be interesting. 4. Finally, comparing the HTTP messages (body and header) of Windows with the WSD ones may reveal some differences which cause the devices to crash. Ubuntu doesn't cause problems either, I assume it doesn't use wsdd. Maybe not yet... — Reply to this email directly, view it on GitHub <#203 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSUVPPDXGNBZT5KVIZTYLZZRTIZAVCNFSM6AAAAABGZQDS5CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOBSGU3DKMY> . You are receiving this because you commented.Message ID: ***@***.***>

[darrylb123]

I found the following command will crash the cameras.
$ wsdd --no-host --discovery --listen $XDG_RUNTIME_DIR/gvfsd/wsdd
2024-10-05 15:25:34,086:wsdd WARNING(pid 16855): no interface given, using all interfaces
2024-10-05 15:25:39,104:asyncio ERROR(pid 16855): Exception in callback MulticastHandler.read_socket(<socket.socke....0.0', 42836)>)
handle: <Handle MulticastHandler.read_socket(<socket.socke....0.0', 42836)>)>
Traceback (most recent call last):
File "/usr/lib64/python3.12/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/bin/wsdd", line 330, in read_socket
handler.handle_packet(msg.decode('utf-8'), address)
File "/usr/bin/wsdd", line 742, in handle_packet
self.handle_message(msg, src)
File "/usr/bin/wsdd", line 534, in handle_message
retval = handler(header, body)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/bin/wsdd", line 802, in handle_probe_match
self.perform_metadata_exchange(endpoint, xaddr)
File "/usr/bin/wsdd", line 856, in perform_metadata_exchange
with urllib.request.urlopen(request, None, args.metadata_timeout) as stream:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/urllib/request.py", line 215, in urlopen
return opener.open(url, data, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/urllib/request.py", line 515, in open
response = self._open(req, data)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/urllib/request.py", line 532, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/urllib/request.py", line 492, in _call_chain
result = func(*args)
^^^^^^^^^^^
File "/usr/lib64/python3.12/urllib/request.py", line 1373, in http_open
return self.do_open(http.client.HTTPConnection, req)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/urllib/request.py", line 1348, in do_open
r = h.getresponse()
^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/http/client.py", line 1428, in getresponse
response.begin()
File "/usr/lib64/python3.12/http/client.py", line 331, in begin
version, status, reason = self._read_status()
^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/http/client.py", line 292, in _read_status
line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/socket.py", line 720, in readinto
return self._sock.recv_into(b)
^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError: timed out

Attached is the pcap file during the period.
crashed-camera.pcapng.gz