Add net device feature #3163

nayuta-ai · 2025-05-06T09:40:17Z

Description

Add the function to move the network device to a network namespace and the corresponding test.

Type of Change

Bug fix (non-breaking change that fixes an issue)
New feature (non-breaking change that adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Documentation update
Refactoring (no functional changes)
Performance improvement
Test updates
CI/CD related changes
Other (please describe):

Testing

Added new unit tests
Added new integration tests
Ran existing test suite
Tested manually (please provide steps)
- Set up a new network namespace and device, as shown below.

$ sudo ip netns add dummy0
$ sudo ip link add dummy0 typ dummy
$ sudo ip addr add 192.168.1.1/24 dev dummy0

Set up the configuration using youki spec and fix the netns and netDevice configurations as below

...
"linux": {
    "netDevices": {
      "dummy0": {}
    },
    ...
    "namespaces": [
      ...
      {
        "type": "network",
        "path": "/var/run/netns/dummy0"
      ...

Run the container

$ sudo ./youki create -b tutorial tutorial_container

Check the expected results

$ sudo ip netns exec dummy0 ip link
...
60: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 1a:95:f0:e7:3d:d8 brd ff:ff:ff:ff:ff:ff

Related Issues

Fixes #3136

Additional Context

Please review the placement of the setup_network_device function, whether the asynchronous logic is implemented correctly, and whether the test case is sufficient.

nayuta-ai · 2025-05-07T13:36:48Z

I have a few questions:

In the runc tests, some tests fail since the net-devices feature is not yet implemented. Would it be acceptable to add logic on the CI side to skip these tests?
The newly added unit test includes a process that checks the euid, which causes it to fail when executed as a non-root user. Which approach would be preferable: removing the test for non-root users, skipping the test when not running as root, or modifying the test to avoid checking the euid?
Regarding the newly added contest, it creates and deletes network namespaces, but the tests seem to fail due to insufficient permissions. Would adding support in the CI environment to grant permission to manipulate network namespaces be acceptable?

Thank you for your attention to these points.

(WIP) In the containerd integration test, I haven’t identified the cause yet, so I’d like to continue investigating it.

nayuta-ai · 2025-05-12T15:07:57Z

@utam0k
I forgot to mention you. Please take a look when you have a moment!
#3163 (comment)

utam0k · 2025-05-19T11:56:20Z

In the runc tests, some tests fail since the net-devices feature is not yet implemented. Would it be acceptable to add logic on the CI side to skip these tests?

Yes, but please leave the comment.

utam0k · 2025-05-19T12:00:00Z

Regarding the newly added contest, it creates and deletes network namespaces, but the tests seem to fail due to insufficient permissions. Would adding support in the CI environment to grant permission to manipulate network namespaces be acceptable?

Yes, it is acceptable.

utam0k · 2025-05-19T12:00:29Z

The newly added unit test includes a process that checks the euid, which causes it to fail when executed as a non-root user. Which approach would be preferable: removing the test for non-root users, skipping the test when not running as root, or modifying the test to avoid checking the euid?

How about using a system call mock?

crates/libcontainer/Cargo.toml

nayuta-ai · 2025-05-19T17:15:57Z

How about using a system call mock?

I'll proceed with that approach!

BTW, is my understanding correct that this refers to using the mock in the libcontainer/src/syscall package?
I have a few concerns about using the syscall package. Before introducing getter functions like get_xxid, we need to implement the set_id function on the mock side. Additionally, the existing MockCalls implementation in TestHelperSyscall is not sufficient, and we will likely need an implementation that allocates the ID values in memory, such as:

pub struct TestHelperSyscall {
    id: RefCell<MockId>,
    mocks: MockCalls,
}

pub struct MockId {
    uid: Uid,
    gid: Gid,
    euid: Uid,
    egid: Gid,
}

Furthermore, if we go with this approach, we would need to refactor many parts of the codebase that currently use getxxid directly, and switch them to go through the syscall package. Although I plan to support only rootless_required in this PR for now, it looks like it would involve quite a large change overall.

I'm currently thinking that building a mock like the above would be the right direction. Does this approach sound reasonable to you?

ref: 6d2d9a0

utam0k · 2025-05-21T11:58:02Z

BTW, is my understanding correct that this refers to using the mock in the libcontainer/src/syscall package?

Yes.

Furthermore, if we go with this approach, we would need to refactor many parts of the codebase that currently use getxxid directly, and switch them to go through the syscall package. Although I plan to support only rootless_required in this PR for now, it looks like it would involve quite a large change overall.

How large is it? You may use a different PR.

nayuta-ai · 2025-05-22T07:21:40Z

How large is it? You may use a different PR.

I'll address this in a separate PR.

utam0k · 2025-05-23T11:05:58Z

I'll address this in a separate PR.

Make sense +1 Thanks.

nayuta-ai · 2025-05-25T12:50:25Z

I’ve created a separate PR: #3173 .

Signed-off-by: nayuta-ai <[email protected]>

nayuta-ai · 2025-06-12T14:08:11Z

I have confirmed that it works locally, and it also succeeded the last time, as shown in the link below. Can we rerun the workflow?
https://github.com/youki-dev/youki/actions/runs/15473318906

I'd appreciate it if you could review it once the job has passed.

utam0k

Once I've looked overall.

crates/libcontainer/src/network.rs

crates/libcontainer/src/container/builder_impl.rs

utam0k · 2025-06-21T05:03:14Z

crates/libcontainer/src/network.rs

+
+    link_client.set_ns_fd(index, &new_name, netns_file.as_raw_fd())?;
+
+    let thread_handle = std::thread::spawn({


Please let me know why we need to use threads in this process.

Addressed in 66f8b6e.

@nayuta-ai I can understand if you do this in the init process, but if you do it in main or intermediate, I don't see the problem. Does it need to be a thread? Can't it be a process?

Given our previous discussion, it seems safer to perform the setns operations from a separate process rather than a thread, as it doesn't strictly need to be in the main process. Furthermore, since these operations don't require the main process itself, it would be beneficial to port them to the init process. Thank you for the confirmation.

Therefore, my proposed approach, which I believe is a suitable solution to the earlier questions, is as follows:

sequenceDiagram participant Main Process participant Intermediate Process participant Init Process Intermediate Process->>Main Process: Send "ready for intermediate process" and init PID Init Process->>Main Process: Send seccomp notify FD Main Process->>Init Process: Send "seccomp notify done" Note over Main Process: Setup network device and move<br>interface to target netns Main Process->>Init Process: Send "ready to setup network device" Note over Init Process: Setup network device for init process Init Process->>Main Process: Send "ready"

Loading

Seccomp is not directly related to the current implementation; it was included to indicate that the network device setup takes place after seccomp.

If the above understanding is correct, I think it should be feasible, so I'd like to try making the changes.

@utam0k
Please confirm if the above policy is acceptable. If so, there's one difficult implementation point: how to pass Vec<AddressMessage> to the init process.

The challenge is that AddressMessage itself is used for Netlink responses and is not serializable, so it cannot be directly added to the Message Enum.

I've considered two workarounds:

Keep the data as bytes internally within the addr_client.get_by_index function, without parsing it into Vec<AddressMessage>.

Create a new struct, like SerializableAddress, and convert the data into a structure that can be described in the Message Enum.

The current undecided policy is described in this Draft PR. Please refer to it for our discussion. If it seems fine, I plan to move it to this PR.

The relevant commit for the discussion is 6a055ec.

Personally, I think creating SerializableAddress and performing type-safe operations for each process is the better approach, but I'd like your input on how to implement this.

I'm correcting my previous comment, as there was a misunderstanding.
The prerequisite for executing dev_change_net_namespace is the presence of the CAP_NET_ADMIN capability.

I didn't understand why creating a thread would grant privilege.

The current implementation runs the thread within the main process, which has root privileges. Since the thread only joins the network namespace internally, it inherits the main process's privileges, allowing it to perform operations with those elevated permissions.

@utam0k
To meet these requirements, we've identified three potential approaches:

Continue with the current thread-based implementation.

Move the thread's operations to an intermediate process (this is feasible because network namespaces are inherited by child processes).

Perform the operations currently handled by the thread within the init process, specifically before capabilities are set (somewhere in https://github.com/youki-dev/youki/blob/main/crates/libcontainer/src/process/init/process.rs#L71-L299).

Personally, I'm leaning towards implementing the operations within the init process. My reasoning is that threads can be unsafe, and this approach helps prevent over-centralizing logic in an intermediate process. What are your thoughts on this? If you agree, I'll proceed with implementing this strategy.

Why are the threads unsafe?

Do you prefer this option?

Perform the operations currently handled by the thread within the init process, specifically before capabilities are set (somewhere in https://github.com/youki-dev/youki/blob/main/crates/libcontainer/src/process/init/process.rs#L71-L299).

Why are the threads unsafe?

Factors like a file descriptor being closed prematurely can introduce thread safety issues, requiring careful handling (e.g., ensuring file descriptors are not invalidated during thread execution).

Do you prefer this option?

Yes, I prefer this one because of its safe handling.

FYI

Thread Approach - Pros: - Shared Memory for Data: Threads operate within the same memory space as the main process, allowing for easy sharing of variables (like address lists). - Simple Lifecycle Management: The processing is consolidated within the main process, leading to a simpler and more centralized lifecycle management. - Cons: - Overhead from Thread Creation: There's an overhead associated with creating and tearing down threads, which scales with the number of devices being processed. - File Descriptor Safety Concerns: Factors like a file descriptor being closed prematurely can introduce thread safety issues, requiring careful handling (e.g., ensuring file descriptors are not invalidated during thread execution). - Potential Deviation from `youki`'s Design: If `youki` primarily uses processes rather than threads for operations, this approach might not align with its established architectural patterns. Init Process Approach - Pros: - No Thread Creation Overhead: This method avoids the overhead of creating new threads for each operation. - Alignment with `youki`'s Design: If `youki`'s core design favors process-based operations, this approach would be more consistent with its architectural philosophy. - Cons: - Requires IPC for Data Sharing: Sharing data like address lists would necessitate implementing inter-process communication (IPC) mechanisms, such as socket communication. - Challenges with Large Data Sharing: Handling large address lists or other significant data sizes through IPC can become complex and less efficient.

My concerns about using threads are performance and the potential for new security vulnerabilities. I don't think there is any other option besides the init process. Let's give it a try. Thank you for participating in the discussion. I feel like we've moved in a better direction.

crates/libcontainer/src/container/builder_impl.rs

crates/libcontainer/src/network.rs

utam0k · 2025-06-21T05:12:29Z

crates/libcontainer/src/network.rs

+    let new_name = device
+        .name()
+        .as_ref()
+        .filter(|d| !d.is_empty())
+        .map_or(name.clone(), |d| d.to_string());


new_name has to be validated.

Apologies for the delayed response. I've already performed the validation here:

youki/crates/libcontainer/src/utils.rs

Lines 361 to 372 in 60768cd

if let Some(devices) = linux.net_devices() {

for (name, net_dev) in devices {

if !dev_valid_name(name) {

return Err(NetDevicesError::InvalidDeviceName(name.to_string()));

}

if let Some(dev_name) = net_dev.name() {

if !dev_valid_name(dev_name) {

return Err(NetDevicesError::InvalidDeviceName(dev_name.to_string()));

}

}

}

}

. Do I need to perform the validation again?

… added comments on thread usage for safe namespace operations Signed-off-by: nayuta-ai <[email protected]>

…nd update dev_change_net_namespace to use a reference for LinuxNetDevice. Signed-off-by: nayuta-ai <[email protected]>

Signed-off-by: nayuta-ai <[email protected]>

…ation and reliability. Signed-off-by: nayuta-ai <[email protected]>

crates/libcontainer/src/container/init_builder.rs

utam0k · 2025-06-29T12:15:21Z

crates/libcontainer/src/network.rs

+
+    link_client.set_ns_fd(index, &new_name, netns_file.as_raw_fd())?;
+
+    let thread_handle = std::thread::spawn({


@nayuta-ai I can understand if you do this in the init process, but if you do it in main or intermediate, I don't see the problem. Does it need to be a thread? Can't it be a process?

utam0k · 2025-06-29T12:18:22Z

crates/libcontainer/src/network.rs

+    // Set the interface link state to DOWN before modifying attributes like namespace or name.
+    // This prevents potential conflicts or disruptions on the host network during the transition,
+    // particularly if other host components depend on this specific interface or its properties.
+    link_client.set_down(index)?;


If it fails under this line, does it leave the interface down?

Yes, the interface remains in the down state. This behavior is based on an implementation aligned with how runc handles it.
ref: opencontainers/runc#4538

To avoid leaving the interface down in cases where the operations before moving the interface into the network namespace (specifically addr_client.get_by_index and set_ns_fd) fail, it seems reasonable to add logic that brings the interface back up when such failures occur.

@aojea 👋 Hi, we are implementing nevdev feature. I have a question about it. What if a failure occurs after the link goes down? Should we recover or ignore it?
Probably, we should define this behavior on OCI Runtime Spec.

that is a good question, the main problem with dealing with interfaces is that they impact the entire namespace,so bringing an interface up that has changed or modified any network parameters can be dangerous as it impacts the entire host networking in this case

My opinion in anything networking related is that failing close/safe is always the best option, so leaving it down you ensure that there is no risk associated with the operation despite it failed ... if something in the host was already depending on this interface being up it will have the same impact that the operation succeeded than not succeed but leaving it down

crates/libcontainer/src/network.rs

…inct files, update error handling in LibcontainerError, and adjust imports for dev_change_net_namespace. This enhances code organization and clarity in network operations. Signed-off-by: nayuta-ai <[email protected]>

…onality by removing the netlink module, introducing a new client structure, and enhancing the wrapper for better abstraction. This improves code organization and facilitates testing. Signed-off-by: nayuta-ai <[email protected]>

…date imports in builder_impl.rs, and enhance AddressMessageHandler with target index functionality. Signed-off-by: nayuta-ai <[email protected]>

…k client tests for improved reliability and isolation. Update FakeNetlinkClient to handle success and error responses more effectively, ensuring better test coverage and accuracy. Signed-off-by: nayuta-ai <[email protected]>

…handling in network namespaces. Refactor dev_change_net_namespace to utilize this new function, enhancing code clarity and testability. Add tests to verify address processing and filtering based on scope and permanence. Signed-off-by: nayuta-ai <[email protected]>

nayuta-ai · 2025-07-21T10:28:17Z

@utam0k
Please review this at your convenience. I'd particularly appreciate your confirmation on this point.

Signed-off-by: nayuta-ai <[email protected]>

utam0k

I think the overall design is good, but please give me a little more time to review the details.

utam0k · 2025-08-10T12:38:34Z

crates/libcontainer/src/network/network_device.rs

+    name: String,
+    netns_path: String,


&str is enough for these vars. Others are the same.

utam0k

I took a quick look at everything except the client.

utam0k · 2025-08-11T07:11:08Z

crates/libcontainer/src/utils.rs

+    if linux
+        .namespaces()
+        .as_ref()
+        .unwrap()


Is this always safety?

fix: bb31374

utam0k · 2025-08-11T07:15:54Z

crates/libcontainer/src/utils.rs

+            }
+            if let Some(dev_name) = net_dev.name() {
+                if !dev_valid_name(dev_name) {
+                    return Err(NetDevicesError::InvalidDeviceName(dev_name.to_string()));


Others too.

Suggested change

return Err(NetDevicesError::InvalidDeviceName(dev_name.to_string()));

return Err(NetDevicesError::InvalidDeviceName(dev_name.into()));

utam0k · 2025-08-11T07:25:29Z

crates/libcontainer/src/utils.rs

+    if let Some(devices) = linux.net_devices() {
+        for (name, net_dev) in devices {
+            if !dev_valid_name(name) {
+                return Err(NetDevicesError::InvalidDeviceName(name.to_string()));
+            }
+            if let Some(dev_name) = net_dev.name() {
+                if !dev_valid_name(dev_name) {
+                    return Err(NetDevicesError::InvalidDeviceName(dev_name.to_string()));
+                }
+            }
+        }
+    }


Suggested change

if let Some(devices) = linux.net_devices() {

for (name, net_dev) in devices {

if !dev_valid_name(name) {

return Err(NetDevicesError::InvalidDeviceName(name.to_string()));

}

if let Some(dev_name) = net_dev.name() {

if !dev_valid_name(dev_name) {

return Err(NetDevicesError::InvalidDeviceName(dev_name.to_string()));

}

}

}

}

if let Some(devices) = linux.net_devices() {

devices.iter().try_for_each(|(name, net_dev)| {

if !dev_valid_name(name) {

return Err(NetDevicesError::InvalidDeviceName(name.to_string()));

}

if let Some(dev_name) = net_dev.name() {

if !dev_valid_name(dev_name) {

return Err(NetDevicesError::InvalidDeviceName(dev_name.to_string()));

}

}

Ok(())

})?;

}

utam0k · 2025-08-11T07:27:31Z

crates/libcontainer/src/process/init/process.rs

@@ -276,6 +277,16 @@ pub fn container_init_process(
        InitProcessError::SyscallOther(err)
    })?;

+    // Setup some operations in the network namespace.


Please make it clearly. What is some operations?

utam0k · 2025-08-11T07:35:14Z

crates/libcontainer/src/process/container_main_process.rs

+    init_sender: &mut channel::InitSender,
+) -> Result<()> {
+    let mut addrs_map = HashMap::new();
+    // host network pods does not move network devices.


What does pods mean?

fix: 6de834c

utam0k · 2025-08-11T07:42:09Z

crates/libcontainer/src/process/container_main_process.rs

+
+        // get the namespace defined by the config and fall back
+        // to the one created by youki to run the container process.
+        let fallback_ns_path = PathBuf::from(format!("/proc/{}/ns/net", init_pid.as_raw()));


What is fallback? I guess it may be default...?

utam0k · 2025-08-11T07:43:18Z

crates/libcontainer/src/process/container_main_process.rs

+        let ns_path = namespaces
+            .iter()
+            .find_map(|ns| {
+                if ns.typ() == LinuxNamespaceType::Network {
+                    ns.path().as_deref()
+                } else {
+                    None
+                }
+            })
+            .unwrap_or_else(|| &fallback_ns_path);


You should find ns_path before L250, then return Ok if not found it.

fix: b9d6233

utam0k · 2025-08-11T07:48:07Z

crates/libcontainer/src/process/container_main_process.rs

@@ -229,6 +237,62 @@ fn setup_mapping(config: &UserNamespaceConfig, pid: Pid) -> Result<()> {
    Ok(())
 }

+/// setup_network_device sets up and initializes any defined network interface inside the container.
+fn setup_network_device(


Could you please be more specific? As far as I know, this function is responsible for moving network devices.

ref: #3163 (comment)

utam0k · 2025-08-11T07:52:06Z

crates/libcontainer/src/process/container_main_process.rs

+        if let Some(devices) = linux.net_devices() {
+            main_receiver.wait_for_network_setup_ready()?;
+            for (name, net_dev) in devices {
+                let addrs = dev_change_net_namespace(
+                    name.to_string(),
+                    ns_path.to_string_lossy().to_string(),
+                    net_dev,
+                )
+                .map_err(|err| {
+                    tracing::error!("failed to dev_change_net_namespace: {}", err);
+                    err
+                })?;
+                addrs_map.insert(name.clone(), addrs);
+            }
+            init_sender.move_network_device(addrs_map)?;
+        }
+    }


How about this?

Suggested change

if let Some(devices) = linux.net_devices() {

main_receiver.wait_for_network_setup_ready()?;

for (name, net_dev) in devices {

let addrs = dev_change_net_namespace(

name.to_string(),

ns_path.to_string_lossy().to_string(),

net_dev,

)

.map_err(|err| {

tracing::error!("failed to dev_change_net_namespace: {}", err);

err

})?;

addrs_map.insert(name.clone(), addrs);

}

init_sender.move_network_device(addrs_map)?;

}

}

let addrs_map = devices

.iter()

.map(|(name, net_dev)| {

let addrs = dev_change_net_namespace(

name.to_string(),

ns_path.to_string_lossy().to_string(),

net_dev,

)

.map_err(|err| {

tracing::error!("failed to dev_change_net_namespace: {}", err);

err

})?;

Ok((name.clone(), addrs))

})

.collect::<Result<HashMap<String, Vec<SerializableAddress>>>>()?;

init_sender.move_network_device(addrs_map)?;

utam0k · 2025-08-11T07:57:03Z

crates/libcontainer/src/network/network_device.rs

+/// setup_network_device sets up a network device in a new namespace.
+/// It moves the device to the new namespace and adds the IP addresses to the device.
+/// It also sets the device up.
+pub fn setup_network_device(


This function has two roles.

Assign an address.

Link up.

Can these parts be separated into two functions?

The implementation wasn't complex enough to warrant a separate function, so I called it from within configure_container_network_devices.
6de834c

…pose of setup_network_device and SerializableAddress structs, improving code readability and maintainability. Signed-off-by: nayuta-ai <[email protected]>

…ed strings, improving performance and memory efficiency. Update related calls in the main and init processes for consistency. Signed-off-by: nayuta-ai <[email protected]>

…ions. Signed-off-by: nayuta-ai <[email protected]>

…_device, and fix clippy lints Signed-off-by: nayuta-ai <[email protected]>

…ace retrieval and improve error handling in move_network_devices_to_container function. Signed-off-by: nayuta-ai <[email protected]>

YJDoc2 added the kind/feature label May 7, 2025

utam0k requested changes May 19, 2025

View reviewed changes

crates/libcontainer/Cargo.toml Outdated Show resolved Hide resolved

nayuta-ai force-pushed the add-net-device-feature branch from 080cd27 to 6d2d9a0 Compare May 19, 2025 17:39

nayuta-ai mentioned this pull request May 25, 2025

add a system call mock for uid/gid. #3173

Merged

13 tasks

nayuta-ai force-pushed the add-net-device-feature branch 3 times, most recently from ab967f0 to af229bf Compare June 5, 2025 17:51

nayuta-ai added 6 commits June 10, 2025 15:46

Add setup_network_device

fd747f5

Signed-off-by: nayuta-ai <[email protected]>

add contest for the net_devices.

2d31df6

Signed-off-by: nayuta-ai <[email protected]>

remove tokio package

bee1d68

Signed-off-by: nayuta-ai <[email protected]>

delete tokio from tests

56b9f61

Signed-off-by: nayuta-ai <[email protected]>

delete rtnetlink

7e9d1e9

Signed-off-by: nayuta-ai <[email protected]>

exclude net_devices test for other container runtimes

431bbda

Signed-off-by: nayuta-ai <[email protected]>

nayuta-ai force-pushed the add-net-device-feature branch from af229bf to 431bbda Compare June 10, 2025 15:53

nayuta-ai requested a review from utam0k June 20, 2025 13:48

utam0k reviewed Jun 22, 2025

View reviewed changes

nayuta-ai added 3 commits June 22, 2025 14:22

enhanced dev_change_net_namespace with clearer name-handling docs and…

66f8b6e

… added comments on thread usage for safe namespace operations Signed-off-by: nayuta-ai <[email protected]>

refactor setup_network_device to accept a reference to Linux struct a…

4a692a1

…nd update dev_change_net_namespace to use a reference for LinuxNetDevice. Signed-off-by: nayuta-ai <[email protected]>

use fallback path when network namespace type exists but path is none.

2424422

Signed-off-by: nayuta-ai <[email protected]>

refactor net_devices tests to use unique device names for better isol…

4b9c09b

…ation and reliability. Signed-off-by: nayuta-ai <[email protected]>

nayuta-ai force-pushed the add-net-device-feature branch from e02c503 to 4b9c09b Compare June 22, 2025 16:34

nayuta-ai requested a review from utam0k June 22, 2025 16:45

utam0k requested changes Jun 29, 2025

View reviewed changes

nayuta-ai added 5 commits July 14, 2025 01:32

Refactor network module: remove network_device module from lib.rs, up…

19da816

…date imports in builder_impl.rs, and enhance AddressMessageHandler with target index functionality. Signed-off-by: nayuta-ai <[email protected]>

nayuta-ai requested a review from utam0k July 14, 2025 12:55

nayuta-ai added 2 commits August 8, 2025 15:31

Add SerializableAddress for network serialization.

e34dac0

Signed-off-by: nayuta-ai <[email protected]>

Update dev_change_net_device funciton on main and init process.

9f32433

Signed-off-by: nayuta-ai <[email protected]>

utam0k reviewed Aug 10, 2025

View reviewed changes

utam0k reviewed Aug 11, 2025

View reviewed changes

nayuta-ai added 5 commits August 13, 2025 17:00

Enhance network module documentation: Add comments to clarify the pur…

ea86886

…pose of setup_network_device and SerializableAddress structs, improving code readability and maintainability. Signed-off-by: nayuta-ai <[email protected]>

Refactor network device functions to use string slices instead of own…

bb31374

…ed strings, improving performance and memory efficiency. Update related calls in the main and init processes for consistency. Signed-off-by: nayuta-ai <[email protected]>

Fix unsafe unwrap and improve error handling in network device operat…

08e9e98

…ions. Signed-off-by: nayuta-ai <[email protected]>

Refactor network device setup: rename functions, inline setup_network…

6de834c

…_device, and fix clippy lints Signed-off-by: nayuta-ai <[email protected]>

Refactor network device namespace handling: streamline network namesp…

b9d6233

…ace retrieval and improve error handling in move_network_devices_to_container function. Signed-off-by: nayuta-ai <[email protected]>

nayuta-ai force-pushed the add-net-device-feature branch from 5ef9c7a to b9d6233 Compare August 13, 2025 17:01

Merge branch 'main' into add-net-device-feature

eed018f

nayuta-ai requested a review from utam0k August 15, 2025 01:00


		link_client.set_ns_fd(index, &new_name, netns_file.as_raw_fd())?;

		let thread_handle = std::thread::spawn({

	if let Some(devices) = linux.net_devices() {
	for (name, net_dev) in devices {
	if !dev_valid_name(name) {
	return Err(NetDevicesError::InvalidDeviceName(name.to_string()));
	}
	if let Some(dev_name) = net_dev.name() {
	if !dev_valid_name(dev_name) {
	return Err(NetDevicesError::InvalidDeviceName(dev_name.to_string()));
	}
	}
	}
	}

Add net device feature #3163

Are you sure you want to change the base?

Add net device feature #3163

Conversation

nayuta-ai commented May 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Type of Change

Testing

Related Issues

Additional Context

Uh oh!

nayuta-ai commented May 7, 2025

Uh oh!

nayuta-ai commented May 12, 2025

Uh oh!

utam0k commented May 19, 2025

Uh oh!

utam0k commented May 19, 2025

Uh oh!

utam0k commented May 19, 2025

Uh oh!

Uh oh!

nayuta-ai commented May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

utam0k commented May 21, 2025

Uh oh!

nayuta-ai commented May 22, 2025

Uh oh!

utam0k commented May 23, 2025

Uh oh!

nayuta-ai commented May 25, 2025

Uh oh!

nayuta-ai commented Jun 12, 2025

Uh oh!

utam0k left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nayuta-ai Jun 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nayuta-ai Jun 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nayuta-ai Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nayuta-ai Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nayuta-ai commented May 6, 2025 •

edited

Loading

nayuta-ai commented May 19, 2025 •

edited

Loading

nayuta-ai Jun 22, 2025 •

edited

Loading

nayuta-ai Jun 29, 2025 •

edited

Loading

nayuta-ai Jul 10, 2025 •

edited

Loading

nayuta-ai Aug 4, 2025 •

edited

Loading

nayuta-ai Aug 13, 2025 •

edited

Loading

nayuta-ai Aug 13, 2025 •

edited

Loading

nayuta-ai Aug 13, 2025 •

edited

Loading