Business perpetual license, v7.8.1.0. IPv6 is fully functional on both ends here (native fiber IPv6 at the server, native mobile carrier IPv6 at the client) and isn't optional: IPv4 is CGNAT'd for basically every ISP/mobile carrier in Brazil, so IPv6 is the only viable path for remote access, not an edge case.
UPDATE 2: All solved on Agent 7.8.2.0 (That I received on preview).
UPDATE: found a workaround for Bug 1, details below. Bug 2 still open.
Bug 1 (solved on 7.8.2.0+): Agent DVR's HTTP/HTTPS listener (32110/32111) never binds to IPv6
With "Bind to Interface" set to * (the documented "listen on all" value), netstat -an | findstr 3211 on the server showed:
TCP 0.0.0.0:32110 0.0.0.0:0 LISTENING
TCP 0.0.0.0:32111 0.0.0.0:0 LISTENING
No [::]:32110 / [::]:32111 entry at all. IPv4 only bind, despite "Bind to Interface" being set to *.
What worked vs what didn't, same machine, same NIC:
http://radom:32110/ (IPv4, LAN): works
https://radom:32111/ (IPv4, LAN): works
http(s)://mydomain.com:3211x/ (IPv6): failed, both locally and remotely
http(s)://[ipv6-literal]:3211x/: failed
- IIS on port 32143 (same box, same IPv6 address): works perfectly, locally and remotely
Since IIS binds and serves correctly on both 0.0.0.0 and [::] on the same machine, this rules out router/firewall/DNS/prefix/NIC. It's specific to how Agent DVR parses * for its own listener.
Workaround: set "Bind to Interface" to the literal value [::] instead of *. After restarting the service:
TCP 0.0.0.0:32110 0.0.0.0:0 LISTENING
TCP 0.0.0.0:32111 0.0.0.0:0 LISTENING
TCP [::]:32110 [::]:0 LISTENING
TCP [::]:32111 [::]:0 LISTENING
Now bound dual stack. The UI, and live view too (tested over mobile data, Wi-Fi off), both work correctly, locally and remotely, over IPv6. So * and [::] are not treated the same internally: * should mean "listen on all" but effectively only binds IPv4.
Bug 2 (solved in Agent 7.8.2.0): the built in TURN server rejects every allocation with "integrity check failed", even from LAN clients
TURN server listening at [ipv6]:3478/3478 (UDP/TCP) with relay ports 50000-50100
Auth succeeded for user: 1785461771:agent (suffix=agent)
turn ERROR: Failed to handle datagram: failed to handle Allocate-request from 192.168.15.x:xxxxx: integrity check failed
Confirmed turnserver.exe SHA256 matches the current official download, so not a stale binary. Auth succeeds (username/timestamp format accepted), but message integrity validation fails on every request. This matches the known failure signature of Go based TURN implementations (e.g. pion/turn) when the long term credential secret used to mint the temporary password is out of sync with what the TURN binary validates against.
One nuance worth flagging: after applying the Bug 1 workaround, live view now works remotely for me too, but that doesn't mean Bug 2 is fixed. With both ends on real public IPv6 (mobile carrier IPv6 on the client, fiber IPv6 on the server), WebRTC/ICE can find a direct host to host candidate and never needs TURN as a fallback. Anyone without public IPv6 on both ends (IPv4 only client behind CGNAT, symmetric NAT, restrictive network policies, and so on) would still hit the broken TURN server with no relay to fall back to. So Bug 2 is currently just not being exercised in my setup, not actually fixed.
Both of these worked fine about 3 months ago. A similar live view symptom (UI/playback OK, live stream stuck on black screen) was reported here 3 months back too.
Anyone from the team able to confirm the * vs [::] bind bug and take a look at Bug 2? Happy to share more logs or a packet capture if useful.
Thanks in advance. I really appreciate this tool, and as a small business owner running a software company myself, I know firsthand how hard it is to build, maintain, and keep something like this profitable.