Presuming they're using standard terminology here, it's the other way around: privileged mode causes the container runner to not revoke user permissions and kernel capabilities relative to those the Linux kernel granted the runner itself. I think it is also safe to presume — despite lack of a FOSS implementation to inspect — that a privileged container won't have a separate userns, pidns, netns…
This will surely not be a "sudo" type feature, granting additional capabilities above what the OCI runner has.
It's important to separate the concepts of LLM agent and LLM runner. The agent is a specialized type of HTTP client that knows how to talk to things like the OpenAI API, interpret the replies, and then go ’round again until some goal is fulfilled. This feature does not mean they're trying to run LLM models on-device. It gives you a local browser-facing front-end to other LLM instances.
Nous Research has their own LLMs, but their agent is trying to go up against OpenClaw and such.
Yeah, but if you had to guess freely, what do you think is the actual purpose of this whole thing? I honestly have no clue this time..
Btw, in LLM terminology I would normally call the component running or interfacing with the model a runtime harness. An agent client may include an MCP client, though it can also use native direct integrations with the surrounding tooling, like Claude CLI. An agent-facing tool server is often more like an MCP server, IMO.
Blurring terminology aside, I imagine the intent is to let people set up an agent on their router, pointed at each of the APIs the user subscribes to, with their keys, once. Now that user has access to all their models from all hosts on that LAN, or via VPNs, from anywhere in the world.
Setting up multiple machines with the same API keys again and again is a pain.
Not that it's a huge help, since as you point out, we are being given a lot of choices of harnesses and agents and such, forcing re-setup for that reason separately from the multitude of models and runners. To solve this, they could add LiteLLM Proxy Server.
It is for this basic class of reason that Open WebUI is in 7.23.
Probably something similar to docker run --privileged ?
On docker/linux this grants containers R/W access to host /sys pseudo file system, cgroups, device files and processes.
ROS implementation will most likely be less permissive. Will be interesting to see what additional container privileges come with it.
I don't really know if this issue is new or was present before because it does not happen very often:
I have configured a wifi network with multiple ssids (new /interface/wifi). the virtual wifi interfaces are dynamically added to the bridge via the datapath configuration.
Wireless clients are put to specific vlans using radius, so the access point does not know to what vlan it has to join. This usually works ok, but sometimes when a "new" vlan gets added according to the cli it should be all ok, but in practice /tool/sniffer sees the inbound traffic on the correct vlan, but outbound traffic of that vlan to wifi does not work. To fix that (temporarly) I have to reprovision the access point (or enable/disable the wifi interface).
I also noticed that disabling/enabling the whole bridge seems to have the same, or at least similar breaking effect on the wifi interfaces: according to cli everything is joined dynamically as it should, but traffic does not really flow in both directions
The bridge itself has set both ingress-filtering=yes and vlan-filtering=yes, so it could also be that the bridge itself misbehaves with dynamic interfaces and the bug/issue is in that subsystem and wifi is fine
Probably it's more about (improper) configuration of WiFi. To have "dynamic" VLANs working, wifi interface has to be added to bridge without PVID set and with either frame-types=admit-only-vlan-tagged (my recommendation) or frame-types=admit-all. At the same time, WiFi interface has to have vlan-id set to VID in datapath settings for "default" stations/clients (which might not get VID assigned by radius or ACL rules). And that has to be done (separately) for all wifi interfaces (both master and slave) regardless if they are configured locally or provisioned by capsman..
By default, containers are not able to make changes to the system that runs the container (privileged=no), but if you enable privileged mode (privileged=yes), your container can directly make changes to your system.
This feature should NOT be used unless you understand the risks involved and you absolutely need it. For example, a vulnerable container with privileged=yescan make adjustments to your Firewall or format disks. This includes devices under /dev (with exceptions) and /sys.
Containers that were running on older versions on RouterOS will have the same privileges after upgrading, the default value (privileged=no) does not remove nor add any new permissions. If you manually enable it (privileged=yes), then you are removing most restrictions that your container had before.
I don't beleave its a configuration error.
Again, it works, just sometimes a vlan gets stuck. don't know if you really tested that, but as said the vlan does not come from data-path but from radius. It's impossible to set the vlan id prior to the person connecting. as for the vlan-id, yes thes provision the "default", and yes, I see that being done "dynamically" as soon as the interface is there. It's funny tough that this is the pvid of the port, but the port is added as tagged in bridge/vlan. Works without an issue tough). The issue I am talking is on the vlan's that get added completely dynamically from radius (and according to bridge/vlan this vlans are added/removed just as needed). Also I see inbound traffic with the correct "dynamic" vlan assigned. It's just that outbound from bridge to the specific wifi interface gets not sent, just as if the vlan itelf is not really a member of the bridge.
Doing a provision to trigger a "restart" of the wifi interfaces fixes the issue, so imho it's impossible that this is a configuration error. Also the thing that I see traffic points to the direction that something with dynamic handling is broken. I totally see the reason for such bugs, handling dynamic vlan members on dynamic wifi interfaces is probably quite tricky.
Until now the issue occured on a dynamically created wifi interface that is dynamically added to the bridge and dynamically added/removed specific vlan id's. Again, not very frequently
We'll rename the feature on next update to "dying gasp"
For LLDP, it's implemented exactly as stated in 802.1AB-2005 10.2.1.2. Shutdown LLDPDU construction: most TLV's are not sent on "dying gasp" ND packet
For MNDP new field TTL was added and similar to LLDP most other fields are not sent
For CDP only TTL is adjusted
TLDR: TTL=0 is set on all ND packets and sent out before reboot/shutdown/upgrade and NOT in case of panic/crash/power-loss etc. Meaning, by checking logs, a "graceful" "loss of device" can be detected via ND
Sflow on 7.24
(Posted again, after deleted.)
(New excellent forum tool, same nature.)
And with that kind of behavior, they label the need for version-controlled product documentation as "nitpicking"...
Sflow is supported on all Marvell Prestera used by MikroTik in CCRs and CRS.
It reports flows of packets forwarded in hardware-offload.
It takes samples from data-plane, and all the control-plane needs to do is encapsulate and send to target.
No enrichment, no extra counters, no extra memory usage, no extra lookups in routing table, no extra cpu usage.
Today IPFIX do not report correctly any traffic that goes through Hardware-Offload.
How are the plans of using what is already done in SwitchChip and deliver it via control-plane?
It is completely understandable that in those cases, control-plane is not able generate outgoing packages to send on interfaces.
But in case of power-loss, would be desirable that the devices could generate and sending dying-gasp packages.
I know this involves many variables...
The first is the need for the operating system to be aware of conditions (voltage levels, etc.) at the power inputs.
Certainly, a large portion of the hardware produced by MikroTik does not support providing this level of information.
However, there are indeed some product series that feature this capability.
And generating a "Dying Gasp" signal in these cases would be a highly compelling feature.
Yes, and without warning or explanation, because I expect you to obey the instruction in the top message: Please keep this forum topic strictly related to this particular RouterOS release.
Be warned. Repeatedly bringing up old topics unrelated to the release merely to ride the wave of attention will not be tolerated.
Start a new topic if you want to go on banging the drum.
The topic is the 7.24 beta release series, which includes no Sflow features in the list at the top. Therefore, it is off-topic in this thread. The list of new features and changes limits the scope of this topic.
And you've been warned before. Stop arguing. You're wrong.