In FreeBSD-8 there is a new feature for “jails” that is not enabled by default (for base information on standard FreeBSD jails, see the Jail Section of the FreeBSD Handbook).

The new optional feature is called “VNET” and it allows each jail to have a private networking stack. However useful and exciting this may sound, these VNET jails require you to “Bring Your Own Network Interface.”

The VNET feature allows you to move network interfaces in/out of the view of a jail. When a network interface is moved into the view of a jail, it is no longer visible to the host of said jail.

A VNET jail starts with an empty network stack.

For example, you can create an ad hoc persistent VNET jail using the following command (requires VIMAGE option enabled in kernel — more on that later):

jail -c vnet name=vj1 host.hostname=vj1 path=/ persist

NOTE: If your kernel is not compiled with the options VIMAGE line, then you’ll get an error of jail: unknown parameter: vnet).

This jail is now a special jail, called a VNET jail. In this jail, ifconfig shows a private network stack which is currently empty except for an unconfigured local-loopback interface (lo0).

You can now move network interfaces into that jail using the below ifconfig syntax from the host:

ifconfig <interface_name> vnet <jail_id>

Meanwhile, you can move the network interface back out-of that jail using the below syntax from the host:

ifconfig <interface_name> -vnet <jail_id>

Notice the -vnet to recover an interface versus vnet to relinquish an interface to a VNET jail.

Where <interface_name> is something like fxp0, em0, bge0, igb0, etc. and <jail_id> is the value shown in the “JID” column of the output produced by the jls utility (executed without arguments).

However, the usefulness of this is still very limiting. With the VNET feature alone, all one is afforded is the ability to move whole network interfaces into and out-of VNET jails. When one does this, the jail and host do not share the network interface but rather the host can no longer see (using ifconfig for example) nor use the network interface.

To alleviate this limitation, a bridging technology is required to allow the host and VNET jail to share a network interface.

Enter netgraph(4), another optional component in FreeBSD — graph based kernel networking subsystem — publicly available since FreeBSD-3.4. By adding a few NETGRAPH options to the kernel we can provide the VNET jails a solid bridging layer able to provide the jails fresh/functional network interfaces.

However, we’re still not to a point of usefulness because the following gaps still exist:

• How to automate the bootup, shutdown, and management of VNET jails?
• How to automate the creation, destruction, and bridging of netgraph devices?
• How to make sure bridged interfaces have unique MAC addresses?
• How to allow multiple VNET jails to have the same root directory? (considering each sets their own IP from rc.conf(5))

Enter vimage, software I’ve written to tie VNET jails together using netgraph.

NOTE: My “vimage” boot/management script (which lives in /etc/rc.d and oft-executed via “service”) should not be confused with the “vimage” utility from the VirtNet project (imunes.tel.fer.hr/virtnet/).

My vimage is a fork of the jail rc.d script — rewritten to work only with VNET jails and help you harness the most flexibility in network topology and jail structure.

HINT: If you are familiar with the IMUNES project (http://www.imunes.tel.fer.hr), both their work and my own performance-test results were factored into the ultimate choice to settle on netgraph for our bridging needs.

My vimage boot/mgmt script is available here:
http://druidbsd.sourceforge.net/download.shtml#vimage

Let’s get started…

First, you’ll need a custom kernel for your FreeBSD host before you can run any VNET jails, let alone vimage jails (VNET jails with netgraph).

Add the following to a GENERIC FreeBSD kernel config as a minimum:

makeoptions NO_MODULES=yes
options VIMAGE
options NETGRAPH
options NETGRAPH_ETHER
options NETGRAPH_BRIDGE
options NETGRAPH_EIFACE
options NETGRAPH_SOCKET
nooptions SCTP

NOTE: In the future, when VIMAGE is compatible with SCTP, you will not need the nooptions SCTP line.

UPDATE: A known issue is that the non-default options IPFILTER conflicts with VIMAGE in stable/9 (and possibly HEAD too) in that a kernel panic occurs during boot. A backtrace shows the trap originating from fr_resolvenic() in sys/contrib/ipfilter/netinet/fil.c. My current recommendation for running a kernel with both Firewall abilities and VIMAGE is to use the IPFIREWALL family of options and ipfw(8).

Compile your kernel and boot it. Next, grab the FreeBSD package for vimage-1.4 and use the following command to install 2 files (/etc/rc.d/vimage and /etc/rc.conf.d/vimage):

pkg_add vimage-1.4.tbz

Now we’re ready to build a jail. Personally, I use my own “jail_build” script to build jails from binary releases. You can get jail_build from my SourceForge page:

http://druidbsd.sourceforge.net/download.shtml#jail_build

NOTE: If you are planning on running i386 jails under an amd64 kernel, be advised that you may need a patch to your amd64 kernel to solve a problem with applying a default gateway using the 32-bit route command (as discussed here).

Currently jail_build works with any release, 8.x and older (sorry, no 9.x support yet).

How you use jail_build in a nut-shell:

fetch http://druidbsd.sourceforge.net/download/jail_build.txt
mv jail_build.txt jail_build
chmod +x jail_build
mkdir -p /usr/repos
cd /usr/repos
# For example
mkdir 8.3-RELEASE
cd 8.3-RELEASE

# Now pick a single base-URL from below:
# ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/8.3-RELEASE/
# ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/8.3-RELEASE/
# ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/8.3-RELEASE/
# ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/amd64/8.3-RELEASE/

# Download "base" directory from FTP to local "."
# Download "doc" directory from FTP to local "."
# Download "dict" directory from FTP to local "."
# Download "games" directory from FTP to local "."
# Download "info" directory from FTP to local "."
# Download "manpages" directory from FTP to local "."
# Download "proflibs" directory from FTP to local "."
# Download "kernels" directory from FTP to local "."


You should now have:

/usr/repos/8.3-RELEASE/{base,doc,dict,games,info,manpages,proflibs,kernels}/

TIP: jail_build will automatically probe for /usr/repos/*-{RELEASE,STABLE,CURRENT}

NOTE: You can certainly run older releases as a jail, but generally speaking you should not run newer releases than what your host is running. So if you build an 8.3-RELEASE jail, you should have at least an 8.3 kernel or higher.

Executing jail_build brings up a menu of repositories to select from (living in /usr/repos) and allows you to select one before prompting you to enter the directory you wish to unpack the contents to (creating a new jail root directory). The default directory is /usr/jail/<jail_hostname> (change <jail_hostname> to the fully qualified hostname of the jail — this is suggested for easy tracking but feel free to make this whatever you like).

NOTE: You don’t have to use my jail_build technique to build jails, in fact there is a long-standing tradition of populating jails from source-code. For details on how to build a jail from source, see the Creating and Controlling Jails section of the FreeBSD Handbook.

After you’ve created a jail, it’s time to configure it as a vimage.

In the host’s /etc/rc.conf file, add the following:

vimage_enable="YES" # Set to NO to disable starting of any vimages
vimage_list="vj1" # Space separated list of names of vimages

vimage_vj1_rootdir="/usr/jail/vj1" # vimage's root directory
vimage_vj1_hostname="vj1" # vimage's hostname
vimage_vj1_devfs_enable="YES" # mount devfs in the vimage


This configures your basic vimage (we’ll cover how to give it a network interface in a moment). You can compare this directly to the procedures documented in the Creating and Controlling Jails section of the FreeBSD Handbook.

The same rules that apply to jail_list in the Handbook apply to vimage_list. The methodology is the same because again, /etc/rc.d/vimage is a fork of the documented /etc/rc.d/jail script.

Next, if you only want to move whole network interfaces into the vimage when it is started (and implied, automatically move the interface back out when the vimage is stopped), add the following to the same rc.conf file as above:

vimage_vj1_vnets="igb0" # list of interfaces to give to the vimage

However, the real flexibility comes from using the bridging option based on netgraph. To create a bridged interface for the vimage — leaving the original interface on the host unaffected — add the following instead of the above:

vimage_vj1_bridges="igb0 igb0" # list of interfaces to bridge

In the above example, a single port physical Intel Gigabit network adapter is listed twice — this will create two unique bridged interfaces from the same physical interface. This is not an error and is perfectly valid (imagine simulating a router that runs on two subnets but over the same physical wire).

If you start the vimage at this point (using service vimage start) you can get a list of the bridged interfaces from the jail’s point of view by executing:

jexec vj1 ifconfig

You’ll see (in the bridging example) two network interfaces, one named ng0_vj1 and the other ng1_vj1. The naming convention for bridged interfaces is ng#_NAME where # is a counter that starts at zero and increases by one for each bridge (regardless of the device being bridged) and NAME is the vimage name as seen in vimage_list.

NOTE: Due to an internal limitation, the name of any network interface in FreeBSD cannot exceed 15 characters. For long vimage names, be aware that ng#_NAME will be truncated to be less than 16 characters if necessary.

PRO-TIP: By placing the vimage name within the name of the bridged network interface, it makes it simple to configure multiple vimages to use the same root directory.

The network configuration for the above vimage is configured within the vimage’s own /etc/rc.conf file, example below:

ifconfig_ng0_vj1="inet 192.168.1.100 netmask 255.255.255.0"
ifconfig_ng1_vj1="inet 10.0.0.1 netmask 255.255.255.0"
defaultrouter="192.168.1.1"

Let’s say you had a second vimage named “vj2″ pointed at the same root directory (and therefore the same /etc/rc.conf file). You would then add the following, for example:

ifconfig_ng0_vj2="inet 10.0.0.2 netmask 255.255.255.0"

The vj1 vimage jail would ignore the vj2 entries and vice-versa.

At this point, let’s recap — you should have done the following:

1. Compiled, installed, and executed a custom kernel that enables the VNET and netgraph(4) requirements.
2. Installed my vimage package from druidbsd.sf.net.
3. Created a jail using either the source-method mentioned in the FreeBSD Handbook or using jail_build and a binary release.
   PRO-TIP: You can actually get by in testing without building a discrete jail but instead use “/” as the jail root path. This is perfectly valid and acceptable.
4. Configured the vj1 test vimage in /etc/rc.conf
5. Configured vj1 to bridge at least one physical interface using vimage_vj1_bridges (in the example above, we use igb0 — twice)
6. Configured ifconfig_ng0_vj1 and [optionally] defaultrouter in the /etc/rc.conf file within the vj1 root directory.

At this point, the vimage will boot with the rest of the machine and can be controlled after boot with the following syntaxes:

# Stop, start, or restart all vimages
service vimage stop
service vimage start
service vimage restart

# ... versus: Stop, start, or restart just the vj1 vimage
service vimage stop vj1
service vimage start vj1
service vimage restart vj1


When the vj1 vimage starts, the ng*_vj1 network interfaces will automatically be created with unique MAC addresses and moved into the VNET jail before kickstarting the FreeBSD boot process within the jail. As the jail boots, it will automatically configure the network interfaces through rc.conf(5). You can use jls(8) to see the running vimages and you can use jexec(8) to execute processes inside them (like tcsh(1), ps(1), and ifconfig(8)).

PRO-TIP: ps(1) can produce the JID of all running processes with the syntax:
ps axopid,jid,command

However, what if you want to SSH into the vimage jail? SSH is not automatically started inside the vimage (and in-fact, only the network services required to get the vimage talking to the net are started). The answer is to add a new configuration line to the host machine’s /etc/rc.conf to configure sshd to be started in each/every jail:

vimage_afterstart_services="sshd" # set new default for all vimages

The default for vimage_after_services is NULL but can be set to a space separated list of services (names of scripts living in /etc/rc.d like sshd). If you wanted to leave this the default and only have the vj1 vimage start sshd, you can instead opt for the following line:

vimage_vj1_afterstart_services="sshd"

So now we have a usable framework for creating multiple vimages that can be SSH’d into as (let’s say) development environments. When you scale this out, netgraph starts to shine. Afterall, netgraph is based on graphs.

Without any additional work, simply by using vimage to produce VNET jails with netgraph bridged interfaces, we can produce graphs of the vimage network topology with the following syntax:

ngctl dot | dot -Tsvg -o vgraph.svg

PRO-TIP: The dot(1) utility can produce more than SVG (like PNG, JPEG, and GIF), but I find SVG to be the most scalable and informative (modern SVG viewers such as latent browsers display much information as tool-tips which I find helpful).

Here are some graphs of different topologies we’ve used over the years:

warden0.jbsd netgraph of bridges for vimage jails

folsom netgraph of bridges for vimage jails

It’s worth noting that if an interface is not bridged, it is shown in the “disconnected” cluster. This does not imply that the network interface is unused within FreeBSD — just that it has not been connected to any nodes within the netgraph layer.

That’s it for now, thank you for reading. Comments welcome. Depending on comments, I may do another installment showing the more exotic things you can do with this configuration.
–
Cheers,
Devin

This entry is for those persons already well versed in this well-edified system.

I would like to announce a completely new — written from scratch — boot menu for the FreeBSD operating system. It is today that I release the code that I’ve been developing for nearly 5 years. Code to enhance the level of options provided to the user at each and every boot of this venerable OS.

Historically, the original menu offered by FreeBSD featured our beloved helper-daemon mascot, named “Beastie.” But soon after, this menu was revamped to [a] lay-rest our triton-carrying/sneaker-wearing assistant in favor of the less-controversial textual “FreeBSD” banner and [b] imbue the menu with new options.

Currently, the default boot menu offers booting normally as well as options for the following:

• Booting with ACPI support disabled (if you’re running an i386 compatible system)
• Booting into “Safe Mode” (implies disabling ACPI)
• Booting verbose
• Booting into single-user mode

However, one of the things that is not currently possible is the ability to boot into any combination of the aforementioned options. That is to explain, you cannot boot into single-user mode with ACPI disabled but verbosity enabled. The reason for this is obvious as once a menu option has been selected, the system proceeds to boot with those options rather than allowing additional selections to be made. See below.

The Standard FreeBSD Boot Menu

Enter my new menu (pictured below in the following paragraphs), first created in 2006 internally for a proprietary custom installer, now generalized for the rest of the world and being released for all to enjoy. This new loader does not proceed to boot the system after selecting a menu option but rather updates the menu to display the option status, allowing the user to toggle any number of multiple options before pressing ENTER to finally boot with the displayed options.

And for those like myself that balked when Beastie exited stage-left, I have a nice surprise. Some time back, the FreeBSD community held a contest for artists to create a new logo for the FreeBSD project. The results of which can be viewed here: http://www.freebsd.org/logo.html

When the contest ended, I had my fun in running the graphics through some Image-to-ASCII conversion programs without much luck. Months later, I doubled-down my efforts still to no avail, attempting to create an ASCII-art version of the new orb to display at boot time. Six months later, I succeeded in producing a bi-color ASCII-art representation of the “horny orb” logo easily recognizable as the FreeBSD logo. This gem (as well as a B&W copy) have been added to the latest “beastie.4th” module for your viewing pleasure and is enabled by default upon installation.

Here you can lay your eyes on the final edition of the first-offering being made to the public today:

New FreeBSD Boot Loader Menu

Installing the new boot loader menu couldn’t be easier. After downloading the FreeBSD package from http://druidbsd.sf.net/, use the pkg_add(1) command to install the package, and finally reboot.

Other additions that you will notice are that the replacement menu does not load right away. Another enhancement is that there is a 2 second delay before launching the menu where the user can press Ctrl-C to escape the menu, allowing immediate booting or escape to the loader prompt. Something that the current menu does not allow for. See below.

Loading the New Menu

The new menu is a system of ANS/FICL Forth (a reverse-polish stack-based language) modules that extend (but do not replace) the standard FreeBSD boot loader (/boot/loader). An interesting note about this package is that it will backup any files that will be replaced during installation to the file /var/backups/loader_menu.backup.tgz. Should you decide that you do not like the new and improved boot loader, you can uninstall it, returning your system back to the original boot loader by using the pkg_delete(1) utility (the backup will automatically be restored upon pkg_delete(1)).

With this initial offering, there are only two short-comings which should certainly be livable for most if not all:

1. The menu that we are replacing only conditionally displays the option to disable ACPI support (based on whether you are running an i386 compatible system), whereas the new loader always presents this option. This should be of no concern unless you’re running a non-i386/amd64 system (such as sparc, pc98, ppc, etc.).

2. The ability to boot into single-user mode by pressing “s” and boot verbose by pressing “v”, etc. is not enabed. The proponents for these options on the FreeBSD-Questions mailing list were clear in that they liked these options because they allowed “one-key” booting into a special mode. However — with the new menu — even if I enabled the use of those keys as shortcuts for toggling these options in the new stateful menu, the user would still have to press an additional key to boot (’1′ or ENTER). So the primary principle use — one-key booting into a special mode — is no longer capable, unless I add these keys not as togglers for the visible menu items but invisible hot-keys for immediately booting into single/verbose mode. I’ll have to sleep on that (maybe as a concession for power-users as invisible options are obviously less than intuitive).

However, don’t let those misgivings dissuade you. All but the most ardent and stringent of surveyors will find those to be shortcomings and overall I predict your experience will be a rather pleasing one.

Some other nice additions are that if/when you select the option to escape to the loader prompt, you are given a way to get back to the menu (simply type “menu” and press ENTER), allowing you to perform work under the hood and then return to the menu as desired (without losing track of the status of the menu options even). As shown below:

Escaping to the Loader Prompt

Overall, the new stateful nature of this menu over the old makes it far less likely that a user will need to reboot if they hit the wrong key. The only mistake that could result in wasted cycles would be if they prematurely hit #1 to boot or hit #7 to reboot. All other options would simply toggle a menu item (except for #6 to escape to the loader prompt, to which they can immediately return to the menu if desired).

Last, but certainly not least, I’m including a completely rewritten password-checking module to replace the existing one (I couldn’t get the standard one to work). See below.

New Password Checking Module

I hope that you like what I’ve developed, and your feedback is certainly welcome. I’ll be cross-posting this to the FreeBSD mailing lists, announcing in RSS feeds, and updating http://druidbsd.sourceforge.net/ all simultaneously to coincide with this blog-post.
–
Cheers,
Devin

I found the solution to all this, and you’ll be surprised at how much work Apple makes us do in order to maintain backward compatibility. This problem had me on the ropes for 2 weeks while I tried to figure out how to — with *either* the new XCode 4 or the still-offered legacy XCode 3.2.6 (both released last month) — compile ANY code for my iPhone 3G which — due to Apple’s decisioning — cannot update to the latest iOS. Without the below solution, I would not be able to compile code for the iPhone 3G without downgrading XCode. However, with the below solution, I can use the latest and greatest XCode with the older SDKs to compile code for the older devices.

Step 1: Stay up to date, but make backups!

Whenever Apple issues a new XCode installer, that installer only comes with the SDKs that they want to provide you. Currently, that’s only iOS 4.3 (note: the Device SDK is different than the Simulator SDK). Running said installer will wipe-out any existing old SDKs, leaving you only with what they have provided you in the latest installer. This is certainly cause for alarm, because if your device doesn’t use one of the provided SDKs, you cannot publish for that device. However, there are no rules for the AppStore that says you must baseline your app to a specific SDK, so whatever baseline you want to choose is fine with Apple — as long as it runs smoothly on the Device SDKs that Apple will test your App against.

Naturally, you’ll want to prevent the loss of any existing older SDKs before you install. Go to the Finder (by clicking the “Finder” icon in the Dock, or clicking the desktop background image, for example), and then select from the menubar Go->Go To Folder… (or simply press Apple+Shift+G). This will bring up a dialog prompt allowing you to go to a directory based on UNIX pathname. Enter the text “/Developer/Platforms/iPhoneOS.platform/Developer/SDKs” (without quotes) and press ENTER (aka return). This will open the directory where the SDKs are installed. Before installing the latest XCode Developer Tools from Apple, backup everything in this directory.

Step 2: If you want to install additional SDKs (one’s that you don’t have).

Visit this webpage to find links to the old Developer Tools.

NOTE: We’re not going to be installing these developer tools, but rather we’ll rip-open the images and pluck out only the SDK information (not XCode and associated developer tools such as gcc and friends).

http://iphonesdkdev.blogspot.com/2010/04/old-versions-of-iphone-sdk.html

Once you’ve downloaded the SDK, it should automatically mount on your desktop (if you’re using Safari anyway) as a disk image named “Xcode and iPhone SDK”. Within this disk image is a hidden directory named “Packages”. Since it is hidden, the simplest way to access this directory is to once-again use the Go->Go To Folder… menubar item (or press Apple+Shift+G), entering “/Volumes/Xcode and iPhone SDK/Packages” (without quotes) and pressing ENTER. This will allow you to browse the hidden “Packages” directory on the read-only disk image containing the Developer Tools. Within this directory are files named similar to:

iPhoneSDK3_0.pkg
iPhoneSDK3_1_2.pkg
iPhoneSDK3_1_3.pkg
iPhoneSDK3_1.pkg
iPhoneSDK3_2.pkg
iPhoneSDK4_0.pkg

…ad nauseum. Go ahead and double-click any of these “*.pkg” files to launch the SDK installer (which will install ONLY to the directory “/Developer/Platforms/iPhoneOS.platform/Developer/SDKs”.

As you launch the Installer, be aware that we’ll have to make some adjustments to allow the installation to occur. When prompted to select the target installation disk (immediately after clicking “Continue” on the initial dialog) click the hard disk that you want to install to (even if it’s already highlighted) to cause a “Choose Folder…” button to appear. Click the “Choose Folder…” button and pick somewhere that is writable as you (if you attempt to install to the default location, the installation will fail — because the installer did not pre-authenticate with root privileges as is done in the main-installer opposed to these sub-installers). I chose to make a new directory on my Desktop. After the installation is complete, you should have a “Developer/Platforms/iPhoneOS.platform/Developer/SDKs/{version}” directory in the target installation directory that you chose. This “{version}” directory will need to be plucked from where you installed it and dropped into the “/Developer/Platforms/iPhoneOS.platform/SDKs/” directory.

Once you’ve installed a new SDK, you’ll need to restart XCode.

Immediately after installing the device SDK required by any Apple Sample code and restarting XCode, you’ll then be able to simply select “Device” from the arch menu (at the top-left of the project window), and press Apple+R to run the app on your connected device. No more need to go into the project settings to change the default SDK (sometimes needs to be done for each sub-target) to one that exists.
–
Happy coding,
Devin Teske

So here we are. XCode (Apple’s interactive development system for building applications) version 4 has been released to the general public. I am wonderfully pleased with the simplification/unification efforts but XCode4 has me scratching my head why Apple would remove CVS support.

I look around me and all I see is CVS — sourceforge.net still firmly embraces CVS. Is this a sign that Apple doesn’t like open-source ventures such as sourceforge.net? Was maintaining CVS support too difficult? Were there some capabilities that were lacking in CVS?

As a person well entrenched in the ways of CVS, I find it ineffable that I might have to migrate sizable iOS projects to some other SCM system such as Subversion (SVN) or Git just to maintain GUI integration within XCode. Mind you, I have no qualms with doing all SCM from the command-line and leaving XCode as a debugger/profiler/analyzer/compiler/editor/builder (though I have to admit, having CVS SCM built-in to XCode 3 was oh-so nice — in-fact I use to pitch it to co-workers as a “does everything” editor that could even be used for unix projects too, optionally replacing a system of Makefiles).

I can only hope and pray that in the coming weeks/months, there is an overwhelming public outcry over the removal of CVS from XCode 4 and that Apple — hopefully being the kind-hearted and in-touch kind of people I could only imagine them to be — might resurrect this industry-standard (truly a fallen comrade). Until then, back to the command-line.
–
admin -ko,
Devin

P.S. If Apple decides to subsequently remove the command-line utility from the Developer Tools installation, I’ll be turning to MacPorts, Fink, or compile it from source (yeah, I’m that determined to use CVS).

P.P.S. With tools like gource [ http://code.google.com/p/gource/ ], nobody in their right mind would switch from their current SCM to any other unless their 15+ year commit history was guaranteed to be preserved in the conversion process.

NOTE: These are my own internal notes. They will be translated into a full technical explanation in another blog posting. However… the fact is that I’ve sat on this technology for 10 years and want to finally make it public. This is the first step in doing so. Last, this will serve as a backup should my iPhone crash (currently the only machine in the world with a documented example of the methodology). This is not meant to be digested by mere mortals (but if you can, all the more power to you — you’ll have a leg-up on the rest of those waiting on the technical discussion).

shxd.rfc04 — dStr data object

Len
0×00 => 0×00
0×01 => 0×01 0×00 0×00 DATA
0xFF => 0xFF 0×00 0×00 DATA
0×0100 => 0×0101 0×00 0×01 DATA
0×0101 => 0×0101 0×00 0×00 DATA
0xFFFF => 0xFFFF 0×00 0×00 DATA
0×010000 => 0×010101 0×00 0×03 DATA
0×010100 => 0×010101 0×00 0×02 DATA
0×010100 => 0×010101 0×00 0×01 DATA
0xFFFFFF => 0xFFFFFF 0×00 0×00 DATA
0×01000000 => 0×01010101 0×00 0×07 DATA
0×01000001 => 0×01010101 0×00 0×06 DATA
0×01000100 => 0×01010101 0×00 0×05 DATA
0×01000101 => 0×01010101 0×00 0×04 DATA
0×01010000 => 0×01010101 0×00 0×03 DATA
0×01010001 => 0×01010101 0×00 0×02 DATA
0×01010100 => 0×01010101 0×00 0×01 DATA
0xFFFFFFFF => 0xFFFFFFFF 0×00 0×00 DATA
0×0100000000 => 0×0101010101 0×00 0x0F DATA
0×0100000001 => 0×0101010101 0×00 0x0E DATA
0×0100000100 => 0×0101010101 0×00 0x0D DATA
0×0100000101 => 0×0101010101 0×00 0x0C DATA
0×0100010000 => 0×0101010101 0×00 0x0B DATA
0×0100010001 => 0×0101010101 0×00 0x0A DATA
0×0100010100 => 0×0101010101 0×00 0×09 DATA
0×0100010101 => 0×0101010101 0×00 0×08 DATA
0×0101000000 => 0×0101010101 0×00 0×07 DATA
0×0101000001 => 0×0101010101 0×00 0×06 DATA
0×0101000100 => 0×0101010101 0×00 0×05 DATA
0×0101000101 => 0×0101010101 0×00 0×04 DATA
0×0101010000 => 0×0101010101 0×00 0×03 DATA
0×0101010001 => 0×0101010101 0×00 0×02 DATA
0×0101010100 => 0×0101010101 0×00 0×01 DATA
0xFFFFFFFFFF => 0xFFFFFFFFFF 0×00 0×00 DATA
0×010000000000 => 0×010101010101 0×00 0x1F DATA
0×010000000001 => 0×010101010101 0×00 0x1E DATA
0×010000000100 => 0×010101010101 0×00 0x1D DATA
0×010000000101 => 0×010101010101 0×00 0x1C DATA
0×010000010000 => 0×010101010101 0×00 0x1B DATA
0×010000010001 => 0×010101010101 0×00 0x1A DATA
0×010000010100 => 0×010101010101 0×00 0×19 DATA
0×010000010101 => 0×010101010101 0×00 0×18 DATA
0×010001000000 => 0×010101010101 0×00 0×17 DATA
0×010001000001 => 0×010101010101 0×00 0×16 DATA
0×010001000100 => 0×010101010101 0×00 0×15 DATA
0×010001000101 => 0×010101010101 0×00 0×14 DATA
0×010001010000 => 0×010101010101 0×00 0×13 DATA
0×010001010001 => 0×010101010101 0×00 0×12 DATA
0×010001010100 => 0×010101010101 0×00 0×11 DATA
0×010001010101 => 0×010101010101 0×00 0×10 DATA
0×010100000000 => 0×010101010101 0×00 0x0F DATA
0×010100000001 => 0×010101010101 0×00 0x0E DATA
0×010100000100 => 0×010101010101 0×00 0x0D DATA
0×010100000101 => 0×010101010101 0×00 0x0C DATA
0×010100010000 => 0×010101010101 0×00 0x0B DATA
0×010100010001 => 0×010101010101 0×00 0x0A DATA
0×010100010100 => 0×010101010101 0×00 0×09 DATA
0×010100010101 => 0×010101010101 0×00 0×08 DATA
0×010101000000 => 0×010101010101 0×00 0×07 DATA
0×010101000001 => 0×010101010101 0×00 0×06 DATA
0×010101000100 => 0×010101010101 0×00 0×05 DATA
0×010101000101 => 0×010101010101 0×00 0×04 DATA
0×010101010000 => 0×010101010101 0×00 0×03 DATA
0×010101010001 => 0×010101010101 0×00 0×02 DATA
0×010101010100 => 0×010101010101 0×00 0×01 DATA
0xFFFFFFFFFFFF => 0xFFFFFFFFFFFF 0×00 0×00 DATA
.
.
.
0×0100000000000000 => 0×0101010101010101 0×00 0x7F DATA
0xFFFFFFFFFFFFFFFF => 0xFFFFFFFFFFFFFFFF 0×00 0×00 DATA
.
.
.
0×01000000000000000000000000000000 => 0×01010101010101010101010101010101 0×00 0x7FFFF DATA
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF => 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 0×00 0×0000 DATA

That’s a length identifier of 2^(8*16) or 2^128 or 3.4028236692094e+38 or 340,282 thousand Decillion bytes long. The length identifier is valid with only 3 bytes of overhead preceding the actual DATA (compared to 16 bytes for the length identifier).

Scaling this higher (to 512 bit integers — 64-bytes wide), the overhead would be 9 bytes.

The overhead is always the length of the length-identifier (in bytes) divided by 8 plus one (with the minimum overhead being two bytes at the low end).

If a dStr contains 0 bytes of data, the dStr will be 0×00.

If a dStr contains 1-15 bytes of data, the dStr will be 0xLL 0×00 0xNN DATA (header is 3 bytes). LL is the length of DATA. NN is the encode register.

If a dStr contains 65536-16777215 bytes of data, the dStr will be 0xLLLLLL 0×00 0xNN DATA (header is 5 bytes).

If a dStr contains 16777216-4294967295 bytes of data, the dStr will be 0xLLLLLLLL 0×00 0xNN DATA (header of 6 bytes).

If a dStr contains 4294967296-1099511627775 bytes of data, the dStr will be 0xLLLLLLLLLL 0×00 0xNN DATA (header of 7 bytes).

If a dStr contains 1099511627776-281474976710655 bytes of data, the dStr will be 0xLLLLLLLLLLLL 0×00 0xNN DATA (header of 8 bytes).

If a dStr contains 281474976710655-7.2057594037928e+16 bytes of data, the dStr will be 0xLLLLLLLLLLLLLL 0×00 0xNN DATA (header of 9 bytes).

If a dStr contains 7.2057594037928e+16-1.844674407371e+19 bytes of data, the dStr will be 0xLLLLLLLLLLLLLLLL 0×00 0xNN DATA (header of 10 bytes).

If a dStr contains 1.844674407371e+19-4.7223664828696e+21 bytes of data, the dStr will be 0xLLLLLLLLLLLLLLLLLL 0×00 0xNNNN DATA (header of 12 bytes).

If the dStr contains 4.7223664828696e+21-1.2089258196146e+24 bytes of data, the dStr will be 0xLLLLLLLLLLLLLLLLLLLL 0×00 0xNNNN DATA (header of 13 bytes).

Ad nausea to infinitum.

This is my first post =)