XNB(4)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1, nixpkgs unstable

πŸ’– XNB(4) πŸ’–

Okay bestie, welcome to the Kernel Interfaces Manual entry for xnb, and let me tell you, this is giving "backend queen" energy fr fr πŸ’…

✨ NAME ✨

xnb β€” Xen Paravirtualized Backend Ethernet Driver πŸ¦‹

✨ SYNOPSIS ✨

So like, if you wanna compile this driver into the kernel (iykyk), you gotta put these lines in your kernel configuration file:

options XENHVM
device xenpci

Periodt. That's it. That's the whole vibe check. ✨

✨ DESCRIPTION ✨

The xnb driver provides the back half of a paravirtualized xen(4) network connection. The netback and netfront drivers appear to their respective operating systems as Ethernet devices linked by a crossover cable. πŸ”Œ

Typically, xnb will run on Domain 0 and the netfront driver will run on a guest domain. But lowkey, it's also possible to run xnb on a guest domain. It may be bridged or routed to provide the netfront domain access to other guest domains or to a physical network. Networking slay πŸ’…

In most respects, the xnb device appears to the OS as any other Ethernet device. It can be configured at runtime entirely with ifconfig(8). In particular, it supports:

  • MAC changing πŸŽ€
  • arbitrary MTU sizes πŸ“
  • checksum offload for IP, UDP, and TCP for both receive and transmit ✨
  • TSO πŸ”₯
But fr fr, see CAVEATS before enabling txcsum, rxcsum, or tso. Don't say I didn't warn you. πŸ’€

✨ SYSCTL VARIABLES ✨

The following read-only variables are available via sysctl(8):

  • dev.xnb.%d.dump_rings β€” Displays information about the ring buffers used to pass requests between the netfront and netback. Mostly useful for debugging, but can also be used to get traffic statistics. Lowkey a multitasker πŸ‘‘
  • dev.xnb.%d.unit_test_results β€” Runs a builtin suite of unit tests and displays the results. Does not affect the operation of the driver in any way. Note that the test suite simulates error conditions; this will result in error messages being printed to the system log. It's giving "chaos for science" energy πŸ§ͺ✨

✨ SEE ALSO ✨

arp(4), netintro(4), ng_ether(4), xen(4), ifconfig(8)

(Go read those too, bestie, they're iconic πŸ‘‘)

✨ HISTORY ✨

The xnb device driver first appeared in FreeBSD 10.0. A whole decade+ of slay πŸ’…βœ¨

✨ AUTHORS ✨

The xnb driver was written by:

  • Alan Somers <asomers@FreeBSD.org>
  • John Suykerbuyk

Absolute legends, no cap 🫢

✨ CAVEATS ✨

Okay so this is the important part, listen up bestie 🚨

Packets sent through Xennet pass over shared memory, so the protocol includes no form of link-layer checksum or CRC. That's right, none. Zero. Nada. πŸ’€

Furthermore, Xennet drivers always report to their hosts that they support receive and transmit checksum offloading. They "offload" the checksum calculation by simply skipping it. That works fine for packets that are exchanged between two domains on the same machine. But when a Xennet interface is bridged to a physical interface, a correct checksum must be attached to any packets bound for that physical interface. πŸ“¦βž‘οΈπŸŒ

Currently, FreeBSD lacks any mechanism for an Ethernet device to inform the OS that newly received packets are valid even though their checksums are not. So if the netfront driver is configured to offload checksum calculations, it will pass non-checksumed packets to xnb, which must then calculate the checksum in software before passing the packet to the OS. It's giving "I guess I'll do it myself" energy 😀

For this reason, it is recommended that if xnb is bridged to a physical interface, then transmit checksum offloading should be disabled on the netfront. The Xennet protocol does not have any mechanism for the netback to request the netfront to do this; the operator must do it manually. So like, you gotta do it yourself, bestie. No autopilot for this one πŸ™ˆ

✨ BUGS ✨

The xnb driver does not properly checksum UDP datagrams that span more than one Ethernet frame. Nor does it correctly checksum IPv6 packets. 😭 To workaround that bug, disable transmit checksum offloading on the netfront driver. Not ideal, but it is what it is πŸ’…


And that's the whole page, bestie! This was Debian, dated June 6, 2014, and it's XNB(4) in the Kernel Interfaces Manual. Stay slay, stay checksummed (or don't, I guess, depending on your bridge situation) πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from