We’re running a Jetson Orin NX with JetPack 6.2 / L4T 36.4.3, and we’re seeing a strange network behavior that seems related to the jetson-vst.service.
The system is connected to three identical IP cameras (Gigabit Ethernet, PoE).
Under normal conditions, all three cameras remain stable for days with no packet loss or latency issues.
However, after several hours of uptime with jetson-vst.service running, one of the interfaces suddenly stops responding —
no ping replies, no RX/TX activity, though the link LED remains ON.
Key points:
The issue occurs even if DeepStream (ai_nvr) is not running — only the VST service needs to be active.
Disabling jetson-vst.service makes the problem disappear entirely; the system stays stable indefinitely.
When the failure occurs, another interface sometimes shows very high latency (ping increases from ~5 ms to >1000 ms).
Restarting toggling PoE power via GPIO (gpioset gpiochip2 set=0 / 1) does not recover the link.
The only way to restore connectivity is a full system reboot.
Impact
We manage these Jetson devices remotely, so losing network access means the unit goes completely offline until it is physically rebooted — which is obviously critical for remote deployments.
Question
Has anyone else experienced similar link stalls or NIC lock-ups when running jetson-vst.service (or other long-running RTSP/video streaming services) on JetPack 6.2 / L4T 36.4.3?
Any known driver, kernel, or networking fixes that might help prevent this behavior without requiring a reboot?
Any feedback or experiences would be greatly appreciated.
— Juan C. Gassó
Hi Keson, thanks for your replay. Yes, I always keep an eye on the disk space. We are using two SSD drive NVR quality of 500GB, mounted with jetonson-storage service. We set the vst-storage to 900GB and set the percentage of storage to 90%. It never went over 90GB. The last time we have problem we deactivate the vst storage options and since that the cameras state up without problems. However, we need to enable it, it’s a requirement. We were working with another j4011 Jetson oring NX 8GB RAM for quite a time, using 2 cameras, and we do not have this problem, using 2 standard HDD of 1TB and 500GB nicely. This problem appears with at least with 3 cameras.
Something I just remember is that we’ve experimented some problems with docker compose. Every time I do a ‘docker compose up’ it pulls the image as we are building. It seems as it couldn’t save the image permanently. Another time, we have seen that the VST start failing because the VST-volumen was mounted as RO.
We had discovered that if we disable the VST video recorder for every sensor, the system remains stable. With this configuration, the VST keeps every camera working fine and stable, in fact our deployment running the full ai_nvr service is working without interruption for the last two weeks, and even the deepstream services runs uninterrupted.
So we suspect that the video recording service of the VST is the problem. As we couldn’t fine any solution changing the VST configuration, we are trying to develop a custom recorder service using media-mtx solution to at least replace the video recording service because we need this feature for our products.