Return to Answer

A TAP interface provides a virtual link with two sides:

• the interface side seen by the network layer on the host, which for OP's use case is often in tap mode (layer 2 Ethernet) and set as a bridge port.
• an invisible side: a process having opened a file descriptor to a special device (/dev/net/tun), which allows this process to read and write IP packets (tun mode) or Ethernet frames (tap mode). Those packets either come from or go to the interface side of the host.

Creating the interface isn't the most important part. The most important part is having a process attached to the invisible side of this interface to read and write packets. As long as there's no such process, the communication over this link doesn't exist. This is naturally translated as "NO-CARRIER" because it makes sense. This is a normal and expected behaviour.

Three examples of such processes that come to me are QEMU (which provides the device emulation to KVM, including network interfaces), OpenVPN and openssh's Tunnel option.

Normally you would let qemu or an helper to qemu, or libvirtd create itself the interface (and while at it attach it to the bridge) and handle qemu what's needed to have the corresponding file descriptor in use. The interface would then have this invisible other side handling it correctly: qemu, and it would report a carrier is detected. It might be possible to hand the manually created interface to qemu (or libvirtd etc.) yourself, but as it's not the usual method, you'll have extra work to do.

A TAP interface provides a virtual link with two sides:

• the interface side seen by the network layer on the host, which for OP's use case is often in tap mode (layer 2 Ethernet) and set as a bridge port.
• an invisible side: a process having opened a file descriptor to a special device (/dev/net/tun), which allows this process to read and write IP packets (tun mode) or Ethernet frames (tap mode). Those packets either come from or go to the interface side of the host.

Creating the interface isn't the most important part. The most important part is having a process attached to the invisible side of this interface to read and write packets. As long as there's no such process, the communication over this link doesn't exist. This is naturally translated as "NO-CARRIER" because it makes sense. This is a normal and expected behaviour.

Three examples of such processes that come to me are QEMU (which provides the device emulation to KVM, including network interfaces), OpenVPN and openssh's Tunnel option.

Normally you would let qemu or an helper to qemu, or libvirtd create itself the interface (and while at it attach it to the bridge) and hand qemu what's needed to have the corresponding file descriptor in use. The interface would then have this invisible other side handling it correctly: qemu, and it would report a carrier is detected. It might be possible to hand the manually created interface to qemu (or libvirtd etc.) yourself, but as it's not the usual method, you'll have extra work to do.

A TAP interface provides a virtual link with two sides:

• the interface side seen by the network layer on the host, which for OP's use case is often in tap mode (layer 2 Ethernet) and set as a bridge port.
• an invisible side: a process having opened a file descriptor to a special device (/dev/net/tun), which allows this process to read and write IP packets (tun mode) or Ethernet frames (tap mode). Those packets either come from or go to the interface side of the host.

Creating the interface isn't the most important part. The most important part is having a process attached to the invisible side of this interface to read and write packets. As long as there's no such process, the communication over this link doesn't exist. This is naturally translated as "NO-CARRIER" because it makes sense. This a normal and expected behaviour.

Normally you would let qemu or an helper to qemu, or libvirtd create itself the interface (and while at it attach it to the bridge) and handle qemu what's needed to have the corresponding file descriptor in use. The interface would then have this invisible other side handling it correctly: qemu, and it would report a carrier is detected. It might be possible to handle the manually created interface to qemu (or libvirtd etc.) yourself, but as it's not the usual method, you'll have extra work to do.

The three most known examples of such processes are QEMU (which provides the device emulation to KVM, including network interfaces), OpenVPN and openssh's Tunnel option.

A TAP interface provides a virtual link with two sides:

• the interface side seen by the network layer on the host, which for OP's use case is often in tap mode (layer 2 Ethernet) and set as a bridge port.
• an invisible side: a process having opened a file descriptor to a special device (/dev/net/tun), which allows this process to read and write IP packets (tun mode) or Ethernet frames (tap mode). Those packets either come from or go to the interface side of the host.

Creating the interface isn't the most important part. The most important part is having a process attached to the invisible side of this interface to read and write packets. As long as there's no such process, the communication over this link doesn't exist. This is naturally translated as "NO-CARRIER" because it makes sense. This is a normal and expected behaviour.

Three examples of such processes that come to me are QEMU (which provides the device emulation to KVM, including network interfaces), OpenVPN and openssh's Tunnel option.

Normally you would let qemu or an helper to qemu, or libvirtd create itself the interface (and while at it attach it to the bridge) and handle qemu what's needed to have the corresponding file descriptor in use. The interface would then have this invisible other side handling it correctly: qemu, and it would report a carrier is detected. It might be possible to hand the manually created interface to qemu (or libvirtd etc.) yourself, but as it's not the usual method, you'll have extra work to do.

A TAP interface provides a virtual link with two sides:

• the interface side seen by the network layer on the host, which for OP's use case is often in tap mode (layer 2 Ethernet) and set as a bridge port.
• an invisible side: a file descriptor opened by a process, which allows this process to read and write IP packets (tun mode) or Ethernet frames (tap mode). Those packets either comefrom or go to the interface side of the host.

Creating the interface isn't the most important part. The most important part is having a process attaching to this interface to read and inject packets. As long as there's no such process, the communication over this link doesn't exist. This is naturally translated as "NO-CARRIER". This a normal and expected behaviour.

Normally you would let qemu or an helper to qemu, or libvirtd create itself the interface (and while at it attach it to the bridge). The interface would then have this invisible other side handling it correctly: qemu, and it would report a carrier is detected.

The three most known examples of such processes are QEMU (which provides the device emulation to KVM, including network interfaces), OpenVPN and... openssh.

So if you want to have a carrier on this link you could do (as root to avoid additional settings on the interface and on openssh to enable it, so ssh must be able to connect to root)

A TAP interface provides a virtual link with two sides:

• the interface side seen by the network layer on the host, which for OP's use case is often in tap mode (layer 2 Ethernet) and set as a bridge port.
• an invisible side: a process having opened a file descriptor to a special device (/dev/net/tun), which allows this process to read and write IP packets (tun mode) or Ethernet frames (tap mode). Those packets either come from or go to the interface side of the host.

Creating the interface isn't the most important part. The most important part is having a process attached to the invisible side of this interface to read and write packets. As long as there's no such process, the communication over this link doesn't exist. This is naturally translated as "NO-CARRIER" because it makes sense. This a normal and expected behaviour.

Normally you would let qemu or an helper to qemu, or libvirtd create itself the interface (and while at it attach it to the bridge) and handle qemu what's needed to have the corresponding file descriptor in use. The interface would then have this invisible other side handling it correctly: qemu, and it would report a carrier is detected. It might be possible to handle the manually created interface to qemu (or libvirtd etc.) yourself, but as it's not the usual method, you'll have extra work to do.

The three most known examples of such processes are QEMU (which provides the device emulation to KVM, including network interfaces), OpenVPN and openssh's Tunnel option.