This topic describes the "why" and "how" of making the Windows ?OpenAFS client use the Microsoft Loopback Adapter.

Why use the Loopback adapter?

The AFS Client (both IBM and ?OpenAFS) relies on a network protocol called Server Message Block (SMB) to mount AFS drives. This protocol runs on ?NetBIOS and is a part of the so-called Common Internet File System (CIFS). Normally, it is used to access Windows shares on remote machines. It is part of what Microsoft calls "File and Print Sharing".

The AFS Client subverts this protocol for its own uses. Since Windows already knows how to access files on a remote ?NetBIOS share, the AFS Client simply pretends it is such a share. Therefore, one might view the Windows AFS Client as a gateway between the AFS world and the ?NetBIOS (or "CIFS" or "SMB") world.

To reiterate, when you access files or use AFS commands (klog, fs, pts, etc) using the Windows AFS Client, you are effectively making your machine talk to itself using the SMB/NetBIOS protocol.

Since this protocol stack is also used to talk to other computers, it is possible for the AFS Client to receive stray network traffic. Sometimes, this network traffic can interfere with the operation of the AFS Client, causing it to stop working properly or simply crash.

More importantly for mobile users, the AFS Client Service requires a valid network adapter with an IP address to bind the SMB service to. If there is no valid IP address available, the AFS Client Service will fail to start. If there is a change to the available IP addresses after the AFS Client Service has started, it will crash.

Fortunately, it is possible to isolate the AFS Client's virtual SMB server from the outside world and provide a long term stable IP address for the service to use. This can be done using the "Microsoft Loopback Adapter," as described below.

How do I use the Loopback adapter?

It happens by default.