As per the WebRTC Remote IP Addresses description:
IP Addresses of the Vehicle allowed to be used for the WebRTC ICE Routing. Usually, the IP of the tether/cabled interface. Blank means any route. E.g: 192.168.2.2
I take this to understand that the field can be left blank. You can do that, and it works. However, when you reload the page, and whether the value is in BlueOS bag of holding, or in your browsers local storage, upon re-load of the cockpit page, this is interpreted as a signal to replace the blank value, with the robots value (for instance 192.168.2.2).
I would say this is unexpected behavior, as leaving it blank is valid (it works), and the possibility is even touched upon in the description, but does not survive a reload.
This is useful for us, as we access robots via different kinds of VPN solutions, and the IP adresse of the robot is not static. This causes loss of video, when the Allowed WebRTC adresse no longer matches (robot has change, IP endpoint is the same. Or VPN solution has re-organized the IP addresses).
As a temporary fix, I worked out that I can modify the contents of "bag of holding", and quite litterally leave the entry for cockpit-allowed-stream-ips blank:
"cockpit-allowed-stream-ips": [
""
],
This will work, however, it looks a bit strange (see below):
All the while, after a few seconds, you get met with this message, despite the fact that this is the only way I could work out to leave it "blank":
I would propose that the handling of empty entry (null?) is respected in Cockpit, and not taken as a signal to do some kind of default behavior.
If that is not possible, then I would ask that you allow for setting some other kind of way, like: *, 0.0.0.0/0, any, or permit-all
You're totally right. We didn't think about this case where the user wouldn't want that field to be auto-populated.
We will work on something for the next release already.
As per the WebRTC Remote IP Addresses description:
I take this to understand that the field can be left blank. You can do that, and it works. However, when you reload the page, and whether the value is in BlueOS bag of holding, or in your browsers local storage, upon re-load of the cockpit page, this is interpreted as a signal to replace the blank value, with the robots value (for instance 192.168.2.2).
I would say this is unexpected behavior, as leaving it blank is valid (it works), and the possibility is even touched upon in the description, but does not survive a reload.
Video of the problem in action:
https://github.com/user-attachments/assets/393fdb41-84ec-4753-b961-80b100ff04b8
This is useful for us, as we access robots via different kinds of VPN solutions, and the IP adresse of the robot is not static. This causes loss of video, when the Allowed WebRTC adresse no longer matches (robot has change, IP endpoint is the same. Or VPN solution has re-organized the IP addresses).
As a temporary fix, I worked out that I can modify the contents of "bag of holding", and quite litterally leave the entry for
cockpit-allowed-stream-ips
blank:This will work, however, it looks a bit strange (see below):![image](https://github.com/user-attachments/assets/e4c8a03e-16ef-49df-a979-a6e2c9bb1462)
All the while, after a few seconds, you get met with this message, despite the fact that this is the only way I could work out to leave it "blank":![image](https://github.com/user-attachments/assets/c03680f0-86c2-48cf-a1a0-fc91a8000bf0)
I would propose that the handling of empty entry (null?) is respected in Cockpit, and not taken as a signal to do some kind of default behavior.
If that is not possible, then I would ask that you allow for setting some other kind of way, like:
*
,0.0.0.0/0
,any
, orpermit-all