You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am posting this as a PSA/FYI as I spent a few hours banging my head against this problem.
This is not an issue with the code in this repo; I am posting in the hopes that the next guy doesn't waste time on the stuff I already solved :D.
I hit this issue with the DR970X_PLUS camera but I'd assume that it applies to other models in the same generation and possibly older generations with recent firmware.
Issue
All requests - from a different subnet - are silently dropped before reaching the web server on the camera.
For the sake of simplicity/demonstration, I'll use the 192.168.10/24 and 192.168.90/24 as the two subnets; the camera lives on .90 and the sync tool on .10.
# From a host in 192.168.10 space running the sync tool# Note that the dashcam lives on the .90 network, not the .10
❯ curl -vvv http://dashcam.my-lan.internal/
* Host dashcam.my-lan.internal:80 was resolved.
* IPv6: (none)
* IPv4: 192.168.90.24
* Trying 192.168.90.24:80…
* connect to 192.168.90.24 port 80 from 192.168.10.15 port 39390 failed: Connection
timed out
* Failed to connect to dashcam.my-lan.internal port 80 after 134465 ms: Co
uldn't connect to server * Closing connection curl: (28) Failed to connect to dashcam.my-lan.internal port 80 after 1344 65 ms: Couldn't connect to server
But when I do the same request from another host on the .90 network, it works fine.
# From a host in the 192.168.90 space; same subnet as the dashcam
❯ curl -vvv http://dashcam.my-lan.internal/
* Host dashcam.my-lan.internal:80 was resolved.
* IPv6: (none)
* IPv4: 192.168.90.24
* Trying 192.168.90.24:80...
* Connected to dashcam.my-lan.internal (192.168.90.24) port 80
> GET / HTTP/1.1
> Host: dashcam.my-lan.internal
> User-Agent: curl/8.8.0
> Accept: */*>* Request completely sent off
< HTTP/1.1 200 OK
< Date: Wed, 31 Jul 2024 02:03:57 GMT
< Server: DR970X_PLUS
< Accept-Ranges: bytes
< Connection: Keep-Alive
< Keep-Alive: timeout=10, max=1000
< Content-Length: 59
< Last-Modified: Tue, 09 Jul 2024 06:40:53 GMT
< Content-Type: text/html
<<html><body><H1>BlackVue</H1><br></body></html>* Connection #0 to host dashcam.my-lan.internal left intact
Cause
So there's a basic filter on the camera that looks at the IP address of the incoming request and silently drops it if it's not from the same network segment as the camera (.90 network in this example).
Solution
The solution is to do source NAT/SNAT on whatever host(s) are responsible for routing between the subnets.
Effectively, you need a rule that says:
if the destination is $dashcam and the $sourceIP is not in the .90 network, rewrite the $sourceIP to one that lives on the .90 network
This way, the camera will always see requests as coming from another device on the same network and will happily respond to them. The device that did the SNAT will then re-write the packet and send it down to the originating requester on the other subnet.
Doing so is an exercise left to the reader as it depends on the routing setup in your network...etc.
The text was updated successfully, but these errors were encountered:
I am posting this as a PSA/FYI as I spent a few hours banging my head against this problem.
This is not an issue with the code in this repo; I am posting in the hopes that the next guy doesn't waste time on the stuff I already solved :D.
I hit this issue with the
DR970X_PLUScamera but I'd assume that it applies to other models in the same generation and possibly older generations with recent firmware.Issue
All requests - from a different subnet - are silently dropped before reaching the web server on the camera.
For the sake of simplicity/demonstration, I'll use the
192.168.10/24and192.168.90/24as the two subnets; the camera lives on.90and the sync tool on.10.But when I do the same request from another host on the
.90network, it works fine.Cause
So there's a basic filter on the camera that looks at the IP address of the incoming request and silently drops it if it's not from the same network segment as the camera (
.90network in this example).Solution
The solution is to do source NAT/SNAT on whatever host(s) are responsible for routing between the subnets.
Effectively, you need a rule that says:
This way, the camera will always see requests as coming from another device on the same network and will happily respond to them. The device that did the SNAT will then re-write the packet and send it down to the originating requester on the other subnet.
Doing so is an exercise left to the reader as it depends on the routing setup in your network...etc.
The text was updated successfully, but these errors were encountered: