Andrei Kazialetski — AVKSoft

Spec-Driven AI Development: Building bgpd-simple with Spec Kit and Local AI Coding Agents

2026-10-15T00:00:00+00:00

AI coding becomes much more useful when the model is not asked to invent both the requirements and the implementation at the same time.

That was one of the main lessons from working on bgpd-simple, a compact routing daemon written in C with BGP, OSPF, and MPLS/LDP support. The project is small enough to understand, but protocol work is unforgiving: a change can look perfectly reasonable in C and still be wrong because it violates one sentence in an RFC, serializes one field incorrectly, or breaks a state transition that only appears during reconnect or withdrawal.

For this project I used Spec Kit as the workflow layer, OpenCode as the coding agent, and local models served by llama.cpp. I started with Qwen 3.5 and GLM-4.7, then experimented with newer models, including Qwen 3.6 27B. The important part was not the particular model. The important part was moving as much engineering truth as possible out of the prompt and into versioned artifacts: specifications, RFC references, plans, task lists, tests, compliance matrices, and verification reports.

Why a routing daemon is a good SDD test case

A routing daemon is almost the opposite of a “vibe coding” application.

The external behavior is already specified. BGP is defined by documents such as RFC 4271, multiprotocol BGP by RFC 4760, OSPFv2 by RFC 2328, OSPFv3 by RFC 5340, and LDP by RFC 5036. The implementation may be original, but the observable protocol behavior cannot be arbitrary.

That makes the project a useful environment for spec-driven development because there are several independent sources of truth:

protocol RFCs;
the project configuration and CLI vocabulary;
internal architecture and invariants;
regression tests;
interoperability behavior;
explicit release/compliance gates.

The repository reflects this. Documentation is split into protocol domains and lifecycle-oriented material: BGP, OSPF, MPLS/LDP, shared architecture, troubleshooting, compliance matrices, and project reports. The release documentation also requires compliance claims to point to executable evidence rather than to prose alone.

In other words, the specification is not one large Markdown file. It is a graph of constraints.

The stack: Spec Kit, OpenCode or Claude Code, llama.cpp or LM Studio

The roles were deliberately separated. The primary configuration below is OpenCode + llama.cpp; Claude Code is an alternative coding agent, while LM Studio is an alternative local inference server. These are interchangeable components, not a claim that every combination was used for every bgpd-simple commit.

Spec Kit provided the structured development workflow. It turns an idea into artifacts such as a specification, technical plan, task list, and implementation/convergence steps. OpenCode acted as the coding driver: reading the repository, editing files, running builds and tests, and iterating on failures. llama.cpp supplied an OpenAI-compatible local HTTP endpoint. Qwen 3.5 and GLM-4.7 were my starting points, followed by experiments with newer models, including Qwen 3.6 27B.

This distinction matters. Spec Kit is not the model and it is not the coding agent. It is the process layer. OpenCode or Claude Code drives repository edits and tests; llama.cpp or LM Studio serves a model locally. The model is replaceable as long as it can follow the process, reason over the repository, and use tools reliably.

Current Spec Kit releases list opencode as a supported integration and install OpenCode command files under .opencode/commands. Current documentation often shows skill names such as /speckit-specify, /speckit-plan, and /speckit-tasks. During this work I used the dotted command form commonly seen in earlier Spec Kit workflows — /speckit.specify, /speckit.plan, and /speckit.tasks. The exact slash-command spelling is version/integration dependent; the workflow boundary is the important part.

From Qwen 3.5 and GLM-4.7 to newer local models

I did not start this project with Qwen 3.6 27B. My early experiments used Qwen 3.5 and GLM-4.7. As newer model releases became available, I tried them with the same general setup: a local llama.cpp inference server exposed through OpenCode, with Spec Kit supplying the development workflow. Qwen 3.6 27B is one of the newer configurations discussed below, not the only model used over the lifetime of the project.

This model progression is useful context for the SDD approach. Rather than tie protocol requirements to a particular model or chat history, I could keep the RFC references, plans, test commands, and acceptance checks in the repository while changing the inference backend. I am not presenting controlled model benchmarks here: the important observation is the portability of the workflow, not an unmeasured claim that one model outperformed another.

The hardware behind the local experiments

My main setup was a server/workstation built around a Supermicro H11SSL-C motherboard, an AMD EPYC 7551 processor, and 256 GB RAM.

For an alternative setup, I used a Mougol X99 motherboard and later moved to a Machinist X99 D8 Max board, with two Intel Xeon E5-2680 processors and 64 GB RAM.

The GPUs available for the experiments were:

PNY GeForce RTX 5060 Ti OC — 16 GB VRAM;
Gainward GeForce RTX 5070 Ti Phoenix-S — 16 GB VRAM.

On the Machinist X99 D8 Max, PCIe/NUMA topology matters when distributing inference work across GPUs. PCIe slots may be attached to different CPU sockets, and communication between GPUs on opposite sockets can cross the CPU-to-CPU interconnect. In my setup, that became a bottleneck. For multi-GPU workloads with frequent cross-GPU transfers, I place both cards in PCIe slots attached to the same CPU whenever the board's slot wiring, physical clearance, and available PCIe lanes permit it. This avoids the extra inter-socket hop; it does not eliminate normal PCIe transfer costs. Check the actual mapping with lspci -tv and nvidia-smi topo -m rather than assuming that adjacent slots share a CPU. The best choice still depends on the model split and the transfer pattern.

The H11SSL-C's revision supports EPYC 7002 processors, so an EPYC 7502 upgrade would also be possible. That upgrade deserves a separate article; the experiments described here used the EPYC 7551. See Supermicro's official EPYC 7002 support FAQ for the revision requirement.

For models that do not fit entirely into a single 16 GB VRAM allocation, llama.cpp can use quantized GGUF weights and appropriate CPU/GPU offloading; the practical fit and speed depend on the quantization, available RAM, context length, and the actual GPU configuration. The hardware list above describes my test equipment, not a claim that both GPUs were always installed together or that every model ran fully in VRAM.

This is why a local OpenAI-compatible endpoint was so valuable: OpenCode's connection remained broadly the same even as I changed machines, models, and inference settings.

Adopting Spec Kit in an existing repository

bgpd-simple was not a greenfield “generate an app” exercise. For an existing repository, I prefer to initialize Spec Kit in place from a clean, reviewable Git state:

uv tool install specify-cli

cd bgpd-simple
git status

specify init --here --force --integration opencode

For a repository that already matters, --force should not mean “overwrite without looking.” It means the generated integration files are applied to an existing tree, so I want the pre-init state committed or stashed and I review the diff immediately afterward.

The resulting separation is useful:

.specify/              shared Spec Kit workflow data
.opencode/commands/    OpenCode integration commands
specs/                 feature specifications / plans / tasks
src/, include/         implementation
tests/                 executable behavior
docs/                  architecture, RFC compliance, reports

For protocol work I also keep project-level rules explicit. The repository's docs/meta/WO.md captures several of them: plan first for non-trivial work, minimize the impact of changes, do not accept temporary fixes when the root cause is knowable, and never mark a task done without verification. Those rules are exactly the kind of constraints I want an agent to inherit before it starts editing C.

A practical Spec Kit workflow

For a non-trivial protocol change, my workflow is roughly:

constitution / project rules
        ↓
specify the externally visible behavior
        ↓
clarify ambiguous protocol or compatibility points
        ↓
plan the implementation boundaries
        ↓
turn the plan into checkable tasks
        ↓
analyze the plan against the specification
        ↓
implement with OpenCode
        ↓
run targeted tests + full regression gate
        ↓
update compliance/evidence documents
        ↓
converge only when code, tests and docs agree

In command form, depending on the Spec Kit version:

/speckit.constitution   or /speckit-constitution
/speckit.specify        or /speckit-specify
/speckit.clarify        or /speckit-clarify
/speckit.plan           or /speckit-plan
/speckit.tasks          or /speckit-tasks
/speckit.analyze        or /speckit-analyze
/speckit.implement      or /speckit-implement
/speckit.converge       or /speckit-converge

I do not necessarily use every phase for a tiny bug. The value comes from making the amount of process proportional to the risk.

For example, changing a CLI string is not the same as changing BGP UPDATE encoding. For the second case I want the plan to mention the exact RFC section, affected parser/encoder path, malformed-input behavior, regression test, and release evidence update before the agent starts coding.

RFCs as executable requirements

The repository's compliance summary is more useful to an AI agent than a generic instruction such as “implement BGP correctly.” It maps protocol areas to RFCs, scope, gate status, and required evidence.

Some of the core references used by the project are:

Domain	RFC	Purpose in the project
BGP	RFC 4271	Core BGP-4 protocol
BGP	RFC 4760	Multiprotocol extensions
BGP	RFC 6793	Four-octet AS numbers
BGP	RFC 4456	Route reflection
BGP	RFC 5065	Confederations
BGP	RFC 8654	Extended messages
BGP	RFC 9774	AS_PATH segment handling updates
OSPF	RFC 2328	OSPFv2
OSPF	RFC 5340	OSPF for IPv6
OSPF	RFC 3623	Graceful restart
OSPF	RFC 5187	OSPFv3 graceful restart
OSPF	RFC 5709	HMAC-SHA authentication
OSPF	RFC 4552	OSPFv3 authentication/confidentiality
MPLS/LDP	RFC 5036	Label Distribution Protocol
MPLS	RFC 3032	MPLS label stack encoding
LDP	RFC 6720	LDP capability negotiation
LDP	RFC 5918	LDP IPv6 extensions
MPLS PW	RFC 4447	Pseudowire signaling
LDP/IGP	RFC 7552	LDP/IGP synchronization

The useful pattern is not “put RFC links in a README.” It is to turn them into acceptance criteria.

A specification for an encoder change might say:

Requirement:
- UPDATE encoding must follow RFC 4271 section 4.3.
- Empty-path behavior must be deterministic and interoperable.
- Malformed input must be rejected without corrupting peer/session state.
- Existing IPv4/IPv6 and AS4 tests must remain green.
- Add a focused regression reproducing the previously observed failure.
- Update the BGP compliance matrix if the supported behavior changes.

This is far harder for an agent to “interpret creatively” than “fix AS_PATH handling.”

What the commit history shows

The repository's own implementation ledger preserves a useful sequence of phase checkpoints from the March 7, 2026 stabilization work.

The sequence is interesting because implementation, tests, and documentation are interleaved rather than treated as separate afterthoughts:

8c64c0c hardened OSPF authentication writer fallback behavior and added regression coverage.
3d6dc52 added an MPLS VPN data-plane regression for transport-label resolution upgrades.
f4ed696 fixed VPNv4 serialization so send-community extended survives without forcing AF activation.
6b33ecd added VRF forwarding route-ownership transition coverage.
ede88bc / 38f5bb1 aligned LDP discovery CLI behavior with runtime loopback suppression and added a regression.
894dccb fixed RD-safe VPN import cache deletion and reconnect-time update-source <ifname> resolution, while cleaning up AF-scoped parser behavior.
225ca52 refreshed the implementation and project status documentation.
f04ef1b, 399d04a, and 3a3fca4 added parser/CLI regressions around VPNv4 shorthand and mixed-order VRF AF mutation.
b15e645 and 5493e3d consolidated the checkpoint/evidence documentation and removed duplicated readiness text.

The phase handoff recorded a full regression result of 152/152 passing tests at that checkpoint. The current repository README reports a different current test inventory, so I treat the numbers in the reports as historical evidence tied to that phase, not as an eternal project metric.

This is exactly the behavior I want from AI-assisted engineering: a code change should leave behind enough evidence that a later session — human or AI — can reconstruct why it exists.

The runtime architecture the agent had to preserve

The project is organized into focused C modules for infrastructure, platform integration, encoding, RIB, policy, routing, protocol state machines, OSPF, MPLS, configuration, and CLI.

A simplified data path looks like this:

That architecture is another form of specification. If a task says “fix parsing under address-family vpnv4,” it should not casually mutate best-path or FIB code. If an LDP CLI discrepancy is really a presentation/runtime parity issue, the plan should say exactly where the source of truth lives.

A good agent plan therefore contains not only what to change, but also what must not move.

Running Qwen 3.6 27B locally with llama.cpp

For these experiments, model inference ran locally. That was useful for two reasons: repository context stayed under my control, and I could iterate without tying the workflow to a hosted model provider.

llama.cpp provides an OpenAI-compatible HTTP server, which makes it a convenient boundary between a coding agent and a local GGUF model.

A typical text-only coding setup looks like:

llama-server \
  -m /models/Qwen3.6-27B.gguf \
  --alias qwen3.6-27b \
  --host 127.0.0.1 \
  --port 8080 \
  --ctx-size 65536 \
  --n-gpu-layers 99

The exact GGUF quantization, context size, and GPU offload depend on the machine. I prefer to set an explicit --alias; otherwise the model ID exposed by /v1/models may be based on the model path, which is awkward to reference from OpenCode.

Before involving the coding agent, I verify the serving boundary directly:

curl http://127.0.0.1:8080/v1/models

and, if needed, a minimal chat request:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3.6-27b",
    "messages": [
      {"role": "user", "content": "Return only: ready"}
    ]
  }'

This isolates model-serving problems from agent problems.

Connecting OpenCode directly to llama.cpp

OpenCode supports OpenAI-compatible custom providers, and its current provider documentation includes llama.cpp explicitly.

A minimal project opencode.json can look like this:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "llama.cpp/qwen3.6-27b",
  "provider": {
    "llama.cpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "llama-server (local)",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1"
      },
      "models": {
        "qwen3.6-27b": {
          "name": "Qwen 3.6 27B (local)",
          "limit": {
            "context": 65536,
            "output": 16384
          }
        }
      }
    }
  }
}

Then I start OpenCode from the repository root:

opencode

The basic local connection is simple:

The coding agent sees an OpenAI-compatible model provider. It does not need to know how Qwen is loaded, quantized, or placed across GPUs.

Alternative: OpenCode with LM Studio

LM Studio can replace llama-server without changing the Spec Kit specification, task list, or acceptance criteria. Load a model in LM Studio and enable its local server (default 127.0.0.1:1234). You can start the server with:

lms server start --port 1234
curl http://127.0.0.1:1234/v1/models

The model ID must match the ID returned by your server. For example, add an LM Studio provider to opencode.json and select it instead of the llama.cpp provider:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "lmstudio/my-local-model",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": { "baseURL": "http://127.0.0.1:1234/v1" },
      "models": {
        "my-local-model": { "name": "Local model (replace ID)" }
      }
    }
  }
}

my-local-model is a placeholder; replace it in both locations with a real ID from /v1/models. This JSON illustrates an alternative configuration, not a second opencode.json to place alongside the original. LM Studio and llama.cpp expose similar OpenAI-style interfaces, but sampling, tool-call parsing, and context handling can differ by runtime and model.

Alternative coding agent: Claude Code

Spec Kit also supports Claude Code directly. In current Spec Kit versions, a fresh project can be initialized with --integration claude rather than --integration opencode:

specify init --here --force --integration claude
claude

For an existing Spec Kit project, avoid reinitializing unnecessarily. To install Claude alongside OpenCode (in Spec Kit versions supporting multiple integrations), use:

specify integration install claude

If your installed version reports an integration conflict, inspect specify integration list and the relevant switch/--force guidance before changing existing integration files. Claude Code's Spec Kit skills live under .claude/skills/, while OpenCode uses its own integration directory. The shared .specify/ artifacts remain the workflow's common source of truth.

Claude Code normally uses hosted Anthropic models. It can also act as a local-model client when the inference server supports the Anthropic Messages API. That does not turn Qwen into an Anthropic Claude model: Claude Code is the CLI agent, and the locally served model is still Qwen (or another loaded model).

Claude Code + LM Studio

LM Studio exposes POST /v1/messages as an Anthropic-compatible endpoint. With the model already loaded:

lms server start --port 1234
export ANTHROPIC_BASE_URL=http://127.0.0.1:1234
export ANTHROPIC_AUTH_TOKEN=lmstudio
claude --model YOUR_LM_STUDIO_MODEL_ID

Use the actual model identifier from LM Studio. The placeholder token is sufficient only when server authentication is disabled; if enabled, use a real LM Studio API token. Keep these environment variables scoped to the terminal/session using the local server so that subsequent Claude Code sessions are not accidentally redirected.

Claude Code + llama.cpp

Recent llama-server builds also expose Anthropic-compatible /v1/messages. Start a tool-capable model with a compatible chat template and enable --jinja for tool calls:

llama-server \
  -m /models/YOUR-MODEL.gguf \
  --alias local-coder \
  --host 127.0.0.1 --port 8080 \
  --ctx-size 65536 --jinja

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export ANTHROPIC_AUTH_TOKEN=local
claude --model local-coder

The ANTHROPIC_BASE_URL deliberately has no /v1 suffix in these Claude Code commands; the client appends the Messages API route. As with LM Studio, tool-use behavior and streaming compatibility depend on the server build, template, context size, and model. Verify a small edit plus tool execution before starting a large RFC-driven task.

The practical combinations are:

Coding agent	llama.cpp	LM Studio
OpenCode	OpenAI-compatible `:8080/v1`	OpenAI-compatible `:1234/v1`
Claude Code	Anthropic-compatible `:8080/v1/messages`	Anthropic-compatible `:1234/v1/messages`

In this architecture, the Spec Kit plan and the repository tests stay the same even if the agent CLI or serving engine changes. Switching the coding agent may still require its matching Spec Kit integration files; switching the inference server does not.

Other connection patterns

1. llama.cpp on another workstation

If the GPU machine is on a trusted private network, llama-server can listen on a non-loopback address:

llama-server \
  -m /models/Qwen3.6-27B.gguf \
  --alias qwen3.6-27b \
  --host 0.0.0.0 \
  --port 8080

and OpenCode can point to:

"baseURL": "http://gpu-workstation:8080/v1"

I would not expose this unauthenticated endpoint directly to the public Internet.

2. Remote GPU machine through an SSH tunnel

For a machine outside the local trusted network, an SSH tunnel keeps the OpenCode configuration unchanged:

ssh -L 8080:127.0.0.1:8080 user@gpu-host

llama-server still binds to 127.0.0.1 on the remote machine, while OpenCode still connects to http://127.0.0.1:8080/v1 locally.

This is my preferred remote pattern because the inference endpoint itself remains loopback-only.

3. llama.cpp in Docker

The same boundary also works when the model server is containerized:

docker run --rm \
  --gpus all \
  -p 127.0.0.1:8080:8080 \
  -v /models:/models \
  ghcr.io/ggml-org/llama.cpp:server-cuda \
  -m /models/Qwen3.6-27B.gguf \
  --alias qwen3.6-27b \
  --host 0.0.0.0 \
  --port 8080 \
  --n-gpu-layers 99

OpenCode does not change. That is another advantage of keeping an HTTP compatibility boundary between the agent and inference runtime.

How I use the agent during implementation

A local model is still an agentic coding model, not an oracle. I get better results when the work is segmented around evidence.

For a protocol change I normally ask OpenCode to work through a bounded task such as:

Implement task T04 only.

Read the feature spec and plan first.
Use RFC 4271 and the project's BGP compliance document as authority.
Do not change unrelated CLI syntax.
Add the focused regression before considering the task complete.
Run the focused test, then the full relevant BGP gate.
Summarize changed files and verification evidence.

The useful part is that most of those instructions should already exist in project artifacts. The prompt becomes a selector and an execution boundary, not the sole memory of the project.

If the model starts making broad changes, that is usually a signal that the plan is too vague. If it repeatedly fails the same test, the project's workflow rules say to stop and re-plan rather than continue patching symptoms. This prevents the “agent keeps editing until the test happens to pass” failure mode.

Verification is part of implementation

bgpd-simple has dedicated compliance and soak tooling in addition to normal unit/regression tests. The project reports reference commands such as:

ctest --test-dir build --output-on-failure

and targeted protocol slices, plus scripts such as:

tools/run_bgp_mpls_compliance_gate.sh
tools/protocol_soak_evidence.sh
tools/mpls_ldp_soak_gate.sh

This is where spec-driven AI development becomes materially different from “AI generated the patch.”

The implementation is not done when the agent says it is done. It is done when:

the requested behavior is present;
the focused regression passes;
the relevant protocol gate passes;
unrelated regressions do not appear;
compliance documentation still matches reality;
the commit explains the behavioral boundary.

The repository's release rules capture the same idea: no in-scope FAIL items, explicit constraints for partial support, and compliance claims backed by both implementation references and executable evidence.

Where local models work well — and where they do not

In my use, Qwen 3.6 27B was useful for repository-level work, especially when the task had a narrow spec and strong tests. But a local model benefits even more than a frontier hosted model from reducing ambiguity.

The highest-value uses were:

tracing behavior across parser, protocol, RIB, CLI, and tests;
generating focused regression tests from a concrete failure;
implementing bounded changes after the plan was accepted;
keeping documentation and test evidence synchronized;
checking repetitive RFC-related conditions across multiple code paths.

The weaker pattern is giving the model a broad request such as “make OSPF fully compliant” and hoping it will discover scope, architecture, protocol semantics, test strategy, and release criteria by itself.

That is not a model-size problem. It is a requirements problem.

What Spec-Driven Development changed for me

The biggest change was not code generation speed. It was context durability.

A chat session is temporary. A specification, compliance matrix, regression test, and commit are durable. When the next task begins, OpenCode and the local model can re-read the same artifacts that a human maintainer would use.

The workflow also makes model replacement much less disruptive. I can use Qwen locally today, another local model tomorrow, or a hosted model for a difficult task. The process does not disappear with the model because the important state lives in the repository.

For protocol software, that is the direction I want AI development to move:

requirements as versioned artifacts, implementation as a constrained transformation, and verification as executable evidence.

The model is a powerful participant in that loop, but it is not the loop itself.

References

Project:

Tooling:

Libella — Privacy Policy

2026-10-14T00:00:00+00:00

Effective date: 14 October 2026

This policy explains how Libella handles information. Libella is provided by ANDREI KAZIALETSKI, trading as AVKSoft. Privacy questions can be sent to libella@iamavk.info. No postal address is required to contact us.

Documents and local data

Libella is designed as an offline PDF/DjVu reader. Imported documents are copied into app-managed local storage and processed locally. Documents, library metadata, bookmarks and reading positions are not uploaded to AVKSoft servers or AVKSoft cloud services. Libella has no AVKSoft account system and no proprietary cloud synchronization or backend.

Apple or Google operating-system or cloud backups may include application data according to the user's platform and account settings. Those backups are outside AVKSoft's direct control.

Analytics, advertising and tracking

For Libella specifically, there are no ads and no AVKSoft analytics or tracking used to profile reading behavior. Document and reading activity is not used for advertising. AVKSoft does not sell personal data.

Store purchases

Libella may communicate with the Apple App Store or Google Play for product information, localized pricing, purchase initiation, purchase restoration or recovery, and determining whether a Pro entitlement is active. Apple and Google process payments under their own terms and privacy policies. AVKSoft does not receive or store payment card details. Apple App Store and Google Play purchases are separate, and Libella has no account or backend that transfers purchases between stores. Store availability and recovery behavior should be confirmed with the relevant store setup.

Support communications

The app does not require personal contact details. If you voluntarily email support, AVKSoft may receive your email address, message contents, device/OS/app-version information, screenshots, and files or documents you attach. This information is used to respond to support requests and diagnose reported problems, not for advertising. Please avoid sending confidential or sensitive documents unless necessary. Support correspondence is kept for as long as reasonably necessary to handle the request, maintain relevant support records, or comply with legal obligations. You may request deletion at libella@iamavk.info.

AVKSoft does not sell personal data or share documents or reading activity with advertisers or data brokers. Apple and Google may process information in connection with their store, operating-system, payment and backup services. Email infrastructure providers necessarily process support correspondence. Information may also be disclosed when required by law.

Retention and deletion

Local app-managed data remains on the device or in app storage. Deleting a document removes the app-managed copy according to the app's behavior. Uninstalling normally removes Libella's local app data, but original files may remain at their source location and operating-system or cloud backups may have their own retention.

Privacy rights

Depending on applicable law, you may request access, correction, deletion, or restriction or objection where applicable, and may complain to a supervisory authority. In Poland, this includes the Prezes Urzędu Ochrony Danych Osobowych (UODO). Contact libella@iamavk.info.

Children's privacy

Libella has no account, advertising, or behavioral analytics/profile system. This policy makes no unsupported age-certification claim.

Security

AVKSoft uses reasonable measures appropriate to the information handled, but no method of storage or transmission can be guaranteed completely secure.

Changes to this policy

If this policy changes, the new version will be published on this page with a new effective date. For questions, contact libella@iamavk.info or see the Libella Support page.

Chasing a PCIe Ghost on Raspberry Pi 5

2026-10-14T00:00:00+00:00

How a simple expansion experiment turned into a deep dive through link training, oscilloscopes, kernel patches, and a plan to build my own PCB.

The setup

I wanted to connect standard PCIe cards to a Raspberry Pi 5. I used the 52Pi P02 (EP-0219) adapter: a full-size PCIe slot connected to the Pi's external PCIe FFC connector. The Pi exposes one lane, so even physically wider cards operate at x1.

My test hardware included an AXAGON PCEE-G25 RTL8125B 2.5GbE NIC, a 10Gtek four-port RTL8125 NIC behind an ASMedia ASM1806 switch, a standalone ASM1184E switch card, and a Broadcom/LSI SAS9300-8i (SAS3008) HBA.

The results were not what I expected.

A puzzling compatibility matrix

Device	Raspberry Pi 5 + P02 result
AXAGON RTL8125B	No link; ends in `Polling.Compliance`
ASM1184E	No usable link; sometimes reaches `Polling.Configuration`
10Gtek ASM1806	Upstream link works; switch and downstream bridges enumerate
10Gtek 4× RTL8125	No NIC endpoints enumerate
SAS3008	Works, including Gen3 8.0 GT/s x1, with no reported AER errors

The SAS3008 was a particularly useful control. It demonstrated that the same Pi, FFC cable, and P02 could carry a working Gen3 link. But that did not prove every electrical and timing characteristic of the adapter was correct for every endpoint.

Watching PCIe link training

I enabled the Raspberry Pi Broadcom driver's LTSSM tracing:

pcie-brcmstb.trace_ltssm=1

For the AXAGON, the result was repeatable across Gen1, Gen2, and Gen3 settings:

Detect.Active
Polling.Active
~24 ms later: Polling.Compliance
link down

The ASM1184E behaved differently. At Gen2/Gen3 it could reach Polling.Configuration, but still never established a usable link. Working cards advanced through Configuration.Link, the other configuration substates, and ultimately L0.

These are different failure stages, not one universal symptom.

Ruling out the obvious

I tested Raspberry Pi kernel 6.12 and 6.18; the behavior persisted. I forced Gen1/Gen2/Gen3, tried a 500 ms delay before PERST# release, changed the P02's power arrangement, and tested with CLKREQ held low. I checked the 5 V supply and PCIe slot's 3.3 V rails. None of these changes fixed the failing cards.

With a FNIRSI DPOX180H oscilloscope, I verified that PERST# was released during the link-training window and reasserted after failure. I also observed an approximately 100 MHz REFCLK during training on the AXAGON and ASM1184E. So the reset and clock signals were not simply absent.

The scope cannot resolve a PCIe 2.5 GT/s eye diagram, but it can reveal coarse activity. The AXAGON showed activity from the card toward the Pi; comparable Pi-to-card training activity was not clearly visible. The ASM1184E showed Pi-to-card activity and progressed farther in the LTSSM.

An approximately 208 mV receiver-detect-looking event was visible with an empty slot, and a similar event appeared with the working 10Gtek. I did not see an equally clear event with the AXAGON. This was an interesting comparison, not a compliance-grade measurement or proof of a particular receiver-detection failure.

Eventually, probing the tiny FFC connector with ordinary multimeter probes became more risky than useful. Adjacent contacts were too easy to bridge, and continuity readings could be misleading.

A kernel patch: retry without PERST#

One hypothesis was that the RTL8125 needed more time after startup. I patched the Raspberry Pi 6.18 pcie-brcmstb driver to toggle the root port's Link Disable bit after the initial failure, restarting link training without reasserting PERST#.

The first attempt produced:

Detect.Active → Polling.Active → Polling.Compliance

The retry produced the same sequence. The second capture reported zero timestamps because tracing began after the restart, so those timestamps were not useful for timing analysis. The meaningful result was that the warm LTSSM retry did not recover the AXAGON.

This weakened the simple “endpoint was not ready yet” explanation, although it did not reveal the underlying cause.

The x86 cross-check changed everything

Later I tested the cards in an x86-64 PC. Every card worked. The ASM1184E exposed its four ports; the 10Gtek enumerated its ASM1806 switch and all four RTL8125 NICs; and the AXAGON worked. A separate PCIe x1-to-x16 riser/extender also successfully detected an RTL8127.

This ruled out treating the endpoint cards as generally defective.

It also exposed a problem with the early “RTL8125 versus BCM2712” theory: on the 10Gtek, the four RTL8125 controllers are behind the ASM1806 switch, not directly connected to the Raspberry Pi PHY. A direct BCM2712-to-RTL8125 electrical mismatch alone cannot explain every observation.

The common failure environment is the Pi 5 + FFC cable + 52Pi P02 combination. Plausible causes still include P02 signal integrity or power/reset implementation, BCM2712 external PCIe interoperability, or an interaction between them. Successful HATs such as Hailo setups show that the Pi's external PCIe can work, but they do not isolate the P02 because they replace the adapter path entirely.

The adapter became the unknown

I consulted the 52Pi EP-0219 wiki and the official Raspberry Pi 5 PCIe connector specification. The official J20 signal assignment includes:

J20 pin	Signal
4 / 5	PCIe reference clock P / N
7 / 8	PCIe RX P / N
10 / 11	PCIe TX P / N
13	PCIe power enable
14	PCIe detect / wake
15	PCIe CLKREQ#
16	PCIe reset

Without a full, verified P02 schematic and layout—or another equivalent PCIe slot adapter for A/B testing—I could not confidently separate the board's behavior from the Pi's own PCIe behavior. Basic continuity measurements were not going to tell me enough about AC coupling, controlled impedance, clock routing, and reset or power sequencing.

Next: designing my own PCIe PCB

I'm going to design and build a custom PCB with all required onboard power converters and a full-size PCIe connector, replacing the 52Pi P02 adapter in my test setup.

The design will include a Pi 5-compatible FFC interface, regulated 12 V and 3.3 V slot supplies sized for the intended cards, controlled-impedance PCIe TX/RX and REFCLK routing, correct reset and sideband handling, and accessible test points for power and low-speed signals. The slot will accept wider physical cards, while the Pi connection remains one PCIe lane. I'll also make the schematic, component choices, and power sequencing fully inspectable.

I have not proven that the P02 is defective. The purpose of the custom PCB is to remove an opaque adapter from the experiment and make the entire signal and power path understandable and measurable.

If the same cards fail on the new PCB, the evidence will shift toward Pi 5 / BCM2712 behavior or a shared design assumption. If they work, the P02 implementation or its connection will become the much stronger suspect.

Either outcome is progress. The next chapter will be about designing, assembling, and testing the replacement board.

References

Welcome to the AVKSoft blog

2026-10-14T00:00:00+00:00

AVKSoft is an independent software developer. We build mobile applications for the Apple App Store and Google Play.

Our first applications are still in development. When they are ready, we will publish their store links on this site and announce them here.

From BlueSCSI Ultra to DaynaPORT: Connecting Legacy SCSI Devices to Linux and Windows

2026-08-16T00:00:00+00:00

The project did not start with networking. It started with a much more practical problem: I wanted to use my old SCSI devices again.

I had devices such as a Sony SMO-F551 magneto-optical drive and Iomega Jaz 1 GB / 2 GB drives. The drives were still useful to me, but connecting them to a modern computer was the difficult part. At the time, I could not find a suitable old SCSI controller.

Instead, I used a BlueSCSI Ultra and began exploring how far its bridge capabilities could be taken. My original goal was straightforward: give a modern Linux or Windows host access to physical legacy SCSI peripherals, without first having to source a period-correct SCSI host adapter.

That distinction matters. BlueSCSI is widely known for emulating SCSI peripherals, such as hard disks backed by SD-card images. My problem was the other way around: I already had real SCSI devices and wanted to communicate with them.

How networking entered the picture

The original goal: access real legacy SCSI hardware without a vintage host adapter.

Working on the SCSI bridge exposed another possibility. BlueSCSI also has DaynaPORT-related functionality, based on the DaynaPORT SCSI/Link network adapter protocol from the 1990s. It was worth exploring whether the bridge and a host-side driver could expose that interface to Linux and Windows as an ordinary network adapter.

That led to the work described here: BlueSCSI bridge changes, a Linux DaynaPORT driver, and a Windows DaynaPORT driver family. The network interface was an extension of the original SCSI-access project, not the reason I bought or started using BlueSCSI Ultra.

The work now spans three repositories:

BlueSCSI-v2, with my experimental avkghost/birdge-with-daynaport branch
daynaport-scsilink-linux-driver
daynaport-scsilink-windows-driver

The interesting part is not only that the driver works like a network card. It is that the same basic DaynaPORT protocol has to survive several very different environments:

native SCSI,
BlueSCSI's USB bridge,
Linux kernels from 2.0 to 7.x,
Windows 9x,
Windows NT 4.0,
Windows 2000/XP,
and Windows 10/11.

The result is a useful example of what happens when a packet protocol from the early 1990s meets several decades of operating-system driver architecture.

DaynaPORT is not a disk

A DaynaPORT SCSI/Link appears on the SCSI bus as a Processor device (type 0x03), not as a Direct Access device.

The host discovers it with a normal SCSI INQUIRY, looking for something equivalent to:

Vendor:  Dayna
Product: SCSI/Link
Type:    Processor (0x03)

From there, Ethernet frames are moved with ordinary-looking six-byte SCSI commands that have Dayna-specific semantics.

The core operations are surprisingly small:

INQUIRY          0x12   identify the device
READ(6)          0x08   receive Ethernet frames
WRITE(6)         0x0A   transmit Ethernet frames
RETRIEVE STATS   0x09   retrieve MAC address and counters
ENABLE/DISABLE   0x0E   bring the interface up or down

A Linux or Windows driver therefore sits between two completely different subsystems:

BlueSCSI itself does not run DHCP for the host and does not own the host's IP configuration. In this mode it behaves much more like an Ethernet bridge: the operating system still owns the network stack.

The first important limitation: there is no RX interrupt

The operating system handles networking; the DaynaPORT driver converts Ethernet traffic to SCSI commands.

A normal Ethernet controller raises an interrupt when a packet arrives.

DaynaPORT does not.

The only way to discover incoming traffic is to issue READ(6) repeatedly.

That creates one of the central design problems in the entire driver.

Poll too slowly and latency becomes terrible or the device's RX queue fills.

Poll too aggressively and the driver wastes CPU time and occupies the SCSI bus.

There is another constraint: effectively there is one command path. RX polling and TX must be arbitrated. If receive traffic monopolizes the SCSI transport, transmit suffers. If transmit is allowed to dominate, the receive queue may overflow.

This becomes much more important once BlueSCSI is placed behind another bridge.

Native SCSI was the easy case

With a real SCSI HBA, one Ethernet frame can be transferred in one SCSI operation.

A typical receive record looks like this:

BlueSCSI can also return several records in one READ(6) when the host uses the multi-packet form.

The driver therefore cannot assume that one SCSI read equals one Ethernet frame. It has to walk the returned buffer record by record.

For transmit, the simplest path is even cleaner: one raw Ethernet frame becomes one WRITE(6).

This is close to how the original hardware was intended to be used.

Then came the USB bridge.

The 512-byte problem

My BlueSCSI bridge work introduced a very different transport constraint.

The early USB Mass Storage bridge path moved SCSI data through a 512-byte buffer.

That is perfectly natural for block storage.

It is not natural for Ethernet.

A normal Ethernet frame can be roughly 1.5 KB, so a packet that was previously transferred in one SCSI operation suddenly no longer fits.

The transport now looks more like this:

This is where the driver stopped being only a DaynaPORT driver and started becoming a DaynaPORT-over-bridge driver.

Adding chunking without breaking DaynaPORT

Bridge-specific fragmentation preserves the Ethernet frame despite a smaller transport limit.

The bridge protocol uses a continuation flag (0x20) so that one Ethernet frame can be spread across multiple SCSI transactions.

On receive, the driver collects chunks until it sees the final record and then reconstructs the Ethernet frame.

On transmit, a large frame is split into several WRITE(6) commands and reassembled on the BlueSCSI side.

For the USB bridge path, TX chunks are limited to 506 bytes because some bytes are consumed by protocol framing.

Conceptually:

A zero-length write can be used to abort an incomplete transmit chain.

The important architectural decision was to keep this extension outside the normal DaynaPORT semantics as much as possible. Native SCSI should continue to behave like native SCSI. Chunking is transport-specific.

That distinction appears throughout the Linux and Windows implementations.

The Linux driver became three drivers

The original Linux driver work comes from Jeff Flitton. My fork adds the bridge/chunking support, diagnostics, shared protocol work, and subsequent improvements.

One source file cannot realistically cover the Linux kernel API from 2.0 through 7.x, so the repository now contains three separate driver implementations:

linux-2.0/
linux-2.4/
linux-7.0/

What can be shared lives in:

lib/daynaport.h

That file deliberately contains protocol logic rather than Linux kernel API calls.

It is C89-clean so that the same protocol core can be used by very old compilers and modern toolchains.

This turned out to be one of the most valuable design choices in the project, because the same core could later be reused by the Windows ports.

Discovery instead of hard-coded SCSI IDs

Another small but important rule is that the driver must not assume a fixed SCSI target.

BlueSCSI lets the user choose the SCSI ID of the emulated DaynaPORT.

The driver therefore follows normal SCSI discovery and binds to a device matching the Dayna identity:

Peripheral type: 0x03
Vendor:          Dayna
Product:         SCSI/Link

This sounds obvious, but it keeps the driver compatible with:

real DaynaPORT hardware,
BlueSCSI,
ZuluSCSI,
PiSCSI,
and potentially more than one adapter on a bus.

Another historical detail: wait after ENABLE

One of the less obvious pieces of the protocol is the delay after enabling the interface.

After:

0E 00 00 00 00 80

the host should wait about 500 ms before issuing further commands.

That behavior is visible in other DaynaPORT driver implementations as well.

It is exactly the sort of detail that disappears if you only implement the obvious packet path and do not compare multiple implementations and the original command documentation.

The protocol-reference work in the Linux repository became almost as important as the driver itself.

Polling was the real performance problem

At first it was tempting to assume that the 512-byte bridge buffer would be the main bottleneck.

The benchmarks showed something more interesting.

The Linux test notes record roughly:

During active receive traffic, the driver reached roughly 70–85 SCSI reads per second.

That was close to the device round-trip limit in the tested configuration.

The polling logic was changed so that after a productive read the driver could continue polling aggressively for a short fast window rather than immediately sleeping for the normal poll interval.

When the link becomes idle, it falls back to the slower polling cadence.

This is important because a fixed polling interval creates a nasty feedback loop:

With back-to-back packets, every artificial sleep directly reduces throughput.

The optimized path instead behaves approximately like:

packet arrives
      |
productive READ
      |
immediate READ
      |
productive READ
      |
immediate READ
      |
...
      |
empty READs
      |
return to idle cadence

The cost is temporarily higher CPU usage, so the driver exposes parameters such as poll_ms, poll0_ms, fast_hold, and tx_burst.

Measuring the bridge separately changed the diagnosis

The most useful benchmark was not an Ethernet benchmark.

It was block I/O through the same bridge.

Using the raw bridge with a SCSI Jaz drive produced approximately:

block read:   ~2.7 Mbit/s
block write:  ~2.6 Mbit/s

That was several times faster than the DaynaPORT network download result.

This immediately showed that the USB bridge itself had significant headroom.

The network RX path was being limited somewhere else.

That is exactly why end-to-end benchmarking alone can be misleading. If I had only measured iperf3, it would have been easy to blame USB chunking for everything.

Increasing the USB buffer to 4096 bytes

A later experiment increased the TinyUSB MSC buffer from 512 bytes to 4096 bytes.

That changed block-read performance significantly.

The benchmark notes show approximately:

512-byte era:
    block read  ~2.7 Mbit/s

4096-byte buffer:
    block read  ~5.35 Mbit/s

A full Ethernet frame could now fit into one bridge read instead of being split across up to three 512-byte transactions.

But something else was revealing:

The Jaz drive itself was now the write-side limit.

And the expected DaynaPORT network improvement was small, because the Wi-Fi inbound path was already the tighter bottleneck.

That is the kind of result I like in low-level projects: changing a parameter makes one subsystem dramatically faster while proving that another subsystem was never limited by that parameter in the first place.

From Linux to Windows

Once the DaynaPORT protocol logic had been separated from the Linux kernel glue, porting the concept to Windows became much more realistic.

But "Windows driver" does not mean one architecture.

The repository currently targets four eras.

Windows 10 / 11

Modern Windows uses a two-driver split:

daynaportfn.sys
    KMDF companion driver
    owns the SCSI-side communication

daynaportnd.sys
    NDIS 6 miniport
    exposes the network adapter

This keeps SCSI access and NDIS networking separated.

Windows 2000 / XP

The 2000/XP version uses a single NDIS 5.1 miniport.

It talks to the SCSI device through:

Windows NT 4.0

NT 4 follows the same broad idea but targets NDIS 4.0 and the NT-era driver environment.

Windows 95 / 98 / ME

Windows 9x is different again.

The design uses:

The amusing part is that the network protocol itself did not fundamentally change.

The operating-system plumbing changed completely.

One protocol core, decades of driver APIs

Platform-specific driver plumbing stays separate from the protocol core.

The Windows repository vendors the shared DaynaPORT protocol header derived from the Linux project.

That means the project can be viewed as two layers:

+-------------------------------------------+
| OS-specific driver                       |
|                                           |
| Linux 2.0 / 2.4 / 7.x                    |
| Win9x / NT4 / 2K-XP / Win10-11           |
+--------------------+----------------------+
                     |
                     v
+-------------------------------------------+
| shared DaynaPORT protocol core            |
| framing, opcodes, RX parsing, chunking    |
+--------------------+----------------------+
                     |
                     v
+-------------------------------------------+
| SCSI transport / BlueSCSI                 |
+-------------------------------------------+

This is probably the most reusable part of the whole exercise.

The protocol is old.

The driver APIs are not.

Keeping those two facts separate makes the code much easier to reason about.

Bridge options on Windows

The Windows side follows the same split between normal DaynaPORT traffic and bridge-specific transport.

The legacy configuration includes tunables for:

UsbBridge selects the USB MSC chunked path.

RawBridge selects the BlueSCSI raw DaynaPORT bridge path, where both directions must respect the bridge transfer limit.

The important point is that the network stack should not care.

It still sends and receives Ethernet frames.

Only the SCSI transport layer knows whether a frame was moved in one command or reconstructed from several.

What the repository history shows

Looking across the repositories, the project did not evolve as one giant "write a driver" commit.

It evolved in layers:

1. Understand the DaynaPORT command set
2. Build a Linux driver around normal SCSI
3. Separate reusable protocol logic
4. Add multi-kernel Linux implementations
5. Add USB-bridge chunking
6. Add diagnostics and benchmark tooling
7. Tune the polling loop
8. Benchmark storage and network paths independently
9. Increase the MSC buffer and measure again
10. Reuse the protocol core for Windows
11. Split Windows support by driver era

This progression matters because several design decisions only became obvious after measurement.

For example, the 512-byte bridge limitation looked like the obvious performance problem.

It was a real limitation — but not the dominant limitation for Wi-Fi receive.

Likewise, making the poll loop faster improved behavior, but only until the device round-trip became the next ceiling.

Current status

The Linux repository is the most mature part of the project.

It contains:

Linux 2.0.x support
Linux 2.4.x support
Linux 7.x support
shared DaynaPORT protocol code
USB bridge chunking
diagnostics
a benchmark runbook
protocol documentation

The Windows repository currently contains implementations for:

Windows 10/11
Windows 2000/XP
Windows NT 4.0
Windows 9x

The Windows 10/11 and 2000/XP code paths are structurally complete in the repository, while the NT4 and 9x trees are currently best treated as completed scaffolding.

Most importantly, the Windows repository still needs real validation with the corresponding Microsoft toolchains and hardware/emulator combinations.

I consider that distinction important: source code that looks complete is not the same thing as a validated driver.

What I learned

A few lessons from this project are useful beyond BlueSCSI.

Storage bridges and packet protocols have different assumptions

A 512-byte transfer buffer is perfectly reasonable for a storage bridge.

It becomes a protocol-design problem when the payload is a 1500-byte Ethernet frame.

Polling behavior can dominate throughput

When there is no receive interrupt, a few milliseconds of unnecessary sleep can matter more than the raw bus bandwidth.

Measure layers independently

iperf3 told me the network was slow.

Block I/O through the same bridge showed that USB itself was much faster.

That changed where I looked for the bottleneck.

Keep protocol code separate from OS APIs

The shared C89 DaynaPORT core made it possible to support Linux kernels separated by decades and then reuse the same logic in Windows drivers with completely different architectures.

Old protocols are often better documented in code than in manuals

The useful details came from several places:

the original Dayna command reference,
BlueSCSI/ZuluSCSI firmware,
PiSCSI,
existing BSD driver behavior,
and real benchmark results.

No single source tells the whole story.

Final result

My original motivation was to connect physical SCSI hardware — including the Sony SMO-F551 and Iomega Jaz 1 GB / 2 GB drives — when a suitable vintage SCSI controller was not available. BlueSCSI Ultra provided the starting point for that experiment.

The original DaynaPORT was a SCSI-to-Ethernet adapter designed for computers of the early 1990s.

BlueSCSI already proved that this protocol can be emulated.

The next step was to turn that emulation around and make Linux and Windows machines treat it as a network interface — including when the SCSI traffic itself has to cross another 512-byte USB bridge.

That required more than wrapping READ(6) and WRITE(6) in a network driver.

It required:

protocol reconstruction,
SCSI discovery,
polling and arbitration,
packet chunking and reassembly,
cross-kernel Linux work,
several generations of Windows driver architecture,
and a lot of benchmarking to determine which bottleneck was actually real.

That is what made the project interesting.

The network protocol is more than thirty years old.

The engineering problems are not.

Repositories

BlueSCSI v2 experimental branch: https://github.com/avkghost/BlueSCSI-v2/tree/avkghost/birdge-with-daynaport
Linux DaynaPORT driver: https://github.com/avkghost/daynaport-scsilink-linux-driver
Linux bridge branch: https://github.com/avkghost/daynaport-scsilink-linux-driver/tree/avkghost/birdge-with-daynaport
Windows DaynaPORT drivers: https://github.com/avkghost/daynaport-scsilink-windows-driver
Linux DaynaPORT protocol notes: https://github.com/avkghost/daynaport-scsilink-linux-driver/blob/main/reference/daynaport.md
Linux bridge benchmark notes: https://github.com/avkghost/daynaport-scsilink-linux-driver/blob/main/reference/benchmark.md

Recovering Iomega Media in 2026: Building iomega_tools for Jaz, Zip, and QIC-122

2026-08-09T00:00:00+00:00

Update: This post was created on August 9, 2026 and later expanded as the tooling and hardware tests evolved during August.

The story started with a simple problem: I still had useful SCSI hardware, but no convenient way to connect it to a modern machine.

That problem eventually led me to experiment with a BlueSCSI Ultra as a bridge to physical SCSI devices. I described that part of the project in From BlueSCSI Ultra to DaynaPORT: Connecting Legacy SCSI Devices to Linux and Windows.

Among the devices I was testing were Iomega Jaz drives.

Once the transport problem was mostly solved, another question appeared:

What can I actually do with old Iomega media once Linux can see the drive?

Mounting a filesystem is only part of the answer.

Old removable storage has its own failure modes, protection states, formatting behavior, vendor commands, damaged sectors, strange bridge interactions, and—in the case of old Iomega backup software—archive formats that modern systems do not understand.

That became the reason for iomega_tools.

Why Iomega media is still interesting

Zip and Jaz are good examples of a period when removable storage was not just a generic USB block device.

At the host level, the drives may look familiar:

But there is more going on below the filesystem.

A drive can have:

media protection modes,
password-based locking,
vendor-specific status pages,
mechanical eject and load behavior,
FORMAT UNIT behavior,
firmware-specific command restrictions,
bad sectors that stall a bridge instead of returning a clean SCSI error,
and media layouts created by old Iomega software.

A modern Linux kernel can handle the ordinary block-device part.

For recovery work, however, I wanted to see and control the layer underneath it.

The project

The repository currently builds three independent tools:

There was also an SG_IO tracing path during the reverse-engineering work.

The code is intentionally implemented as normal Linux userspace tooling. There is no custom kernel driver for Jaz or Zip. Commands are sent through the Linux SCSI generic interface using SG_IO.

That makes the project useful with more than one transport:

This was important for my setup because BlueSCSI Ultra was already being used as a path from a modern host to physical legacy SCSI hardware.

Starting with SCSI passthrough

The first layer is deliberately boring: identify the device, send commands, decode sense data, and avoid hiding failures.

For example:

sudo ./scsi_probe identify /dev/sdX
sudo ./scsi_probe explore /dev/sdX

scsi_probe is read-only. I use it when I want to understand what a device accepts before adding behavior to the main tool.

This became useful beyond Iomega itself. The probe code eventually grew better MMC decoding and DVD structure reporting as I kept using it against other SCSI-class devices.

But the original purpose was much simpler: find out what the Iomega hardware actually does.

Reading files without trusting the host mount path

For FAT-family media, iomega_tools can access the filesystem directly through FatFs.

That allows operations such as:

sudo ./iomega_tools list /dev/sdX -r
sudo ./iomega_tools get /dev/sdX README.TXT
sudo ./iomega_tools get /dev/sdX --all -o recovered

The get path supports FAT12, FAT16, FAT32 and exFAT directly.

Long filenames and subdirectories are supported, and filesystem detection does not assume that the filesystem starts at one hard-coded sector.

This matters because Iomega media can contain an MBR layout rather than a filesystem beginning at LBA 0.

The code recognizes both:

The traditional Iomega layout prefers partition table slot 4, but the tools do not require it.

Recover first, repair later

One of the main design rules is that inspection should be read-only unless I explicitly ask the program to modify the cartridge.

For example:

sudo ./iomega_tools verify /dev/sdX

verify combines several checks:

drive and protection-state probing,
filesystem consistency checking where a safe read-only checker exists,
and a full read-only surface scan unless it is disabled.

Likewise:

sudo ./iomega_tools surface /dev/sdX

is read-only by default.

This is the behavior I want from a recovery tool. Before changing anything on old media, I want to know what can still be read.

When a bad sector is not just a bad sector

Old hardware behind a modern bridge produces failure modes that are easy to miss if software assumes a normal SATA or USB disk.

A large read may fail even though most of the requested sectors are fine.

The surface scanner therefore works in stages:

After a chunk failure, the scanner can fall back to single-sector reads for the remaining media.

This turned out to matter with USB-to-SCSI/IDE paths. One observed bridge configuration rejected large READ(10) transfers at roughly 240 sectors.

The tooling therefore cannot simply assume that a failed transfer means every sector inside that transfer is bad.

Recovering from a stalled bridge

There is an even less pleasant case: a failing data phase can leave the transport itself in a bad state.

Instead of receiving a nice SCSI CHECK CONDITION, the host may get an ioctl-level transport error.

The recovery path became:

For USB storage, the reset can become a USB device reset so the bridge toggles the underlying drive reset line.

If the device node actually disappears with ENODEV, the scanner can force a USB re-enumeration and resume.

That sounds excessive for ordinary storage.

For recovering aging removable media through an adapter stack, it is extremely useful.

Capacity without READ CAPACITY

Another interesting hardware detail appeared while working with Zip.

Normally, a disk utility would ask a SCSI disk for its size using READ CAPACITY.

That assumption does not always work here.

The Zip drive I tested can reject READ CAPACITY with an illegal-request sense response.

So when the user does not specify the scan length, surface can determine the readable limit by probing the address space instead of depending entirely on the normal capacity command.

It is a small feature, but it captures an important theme of the project:

old hardware often works correctly according to its own assumptions, not ours.

Bad-sector registries instead of a private database

Finding damaged sectors is useful.

Preventing a filesystem from reusing them can be even more useful.

With an explicit:

sudo ./iomega_tools surface /dev/sdX --mark-bad

the tool can write bad locations into the filesystem's own bad-block mechanism.

The implementation is filesystem-specific:

Metadata areas and already allocated data are protected from this operation.

Formats without an appropriate bad-block registry are refused.

This is intentionally not the default. --mark-bad modifies the media and requires write access.

Iomega protection modes

Another part of the project came from reverse-engineering IomegaWare behavior.

The drives support more than a simple writable/read-only switch.

The tool implements protection operations including:

normal read/write,
write protection,
password-protected write access,
password-based read/write lock,
temporary unprotect,
password removal.

For example:

sudo ./iomega_tools password /dev/sdX -w
sudo ./iomega_tools password /dev/sdX -rw -pw secret
sudo ./iomega_tools password /dev/sdX -u -pw secret

The password is carried in the vendor command parameter list, matching the behavior reconstructed from Iomega's old Linux tooling.

The same research also informed mount, umount, eject, status, and info.

Formatting was more complicated than expected

At first glance, formatting a Jaz or Zip cartridge sounds like:

That is only the logical side.

The tool can create an Iomega-style MBR layout and invoke the appropriate Linux mkfs implementation:

sudo ./iomega_tools format /dev/sdX --fs fat16

Supported filesystem paths include FAT variants, exFAT, NTFS and ext filesystems.

But IomegaWare also has a drive-level long-format path.

That path sends a SCSI FORMAT UNIT command and then monitors the drive while the physical format is in progress.

Reverse-engineering the old Linux IomegaWare binaries exposed the command form and the progress calculation used by the original software.

Conceptually:

The distinction between logical formatting and a real drive-level format turned out to be important.

A BlueSCSI-specific surprise: sense data can disappear

This was one of the more interesting interactions between the Iomega project and my BlueSCSI work.

During a long format, the drive reports:

The format progress value lives in bytes 16-17 of fixed-format sense data.

The confusing observation was that BlueSCSI debug output could show the expected 04/04 sense data, while a later host-side REQUEST SENSE returned 00/00/00.

The repository notes explain why this is plausible.

In initiator mode, BlueSCSI can issue REQUEST SENSE internally after a command returns CHECK CONDITION. The bridge consumes and acts on that sense data, but it does not necessarily preserve it for a later REQUEST SENSE from the Linux host.

So the path can look like this:

That changed the implementation.

TEST UNIT READY became the reliable completion condition, while REQUEST SENSE is used for progress information when it is available.

This is exactly the kind of issue that appears only when several old and new protocol layers are stacked together.

What IomegaWare was still useful for

I did not want to copy the original tooling.

I wanted to recover protocol facts.

The old IomegaWare for Linux binaries were therefore used as reverse-engineering reference material.

The work exposed details such as:

the drive-level FORMAT UNIT command,
the 4-byte format parameter list,
progress calculation from REQUEST SENSE,
which drive classes are allowed to perform a long format,
protection state encoding,
the vendor protection command,
mount/unmount/eject sequencing.

The implementation in this repository is original C/C++ code built from those observed protocol behaviors.

This distinction matters both technically and legally: old proprietary binaries are reference material, not project dependencies.

`qic_extract`: recovering old Iomega backup archives

The third program in the repository solves a different problem.

Even if the disk itself is readable, old backup software may have stored the useful data inside a QIC-122 archive.

qic_extract operates on an image or archive file rather than directly on the SCSI device:

./qic_extract analyze backup.qic
./qic_extract list backup.qic
./qic_extract extract backup.qic -o recovered

The reverse-engineered format contains structures such as:

The compressed path includes a custom bitstream decoder, segment-chain handling, and UTF-16 filename recovery.

I find this part of the project particularly interesting because it shows that recovering an old cartridge can involve several independent layers:

Being able to read the disk is not the same as being able to recover the files that a user originally stored.

The commit history tells the real story

The repository was created on August 9, 2026 with the three main tools already separated:

The first commit also included the SCSI passthrough layer, filesystem work, QIC extraction, tests, and the SG_IO tracing infrastructure.

Later the same day the project gained more practical recovery features: image/benchmark streaming, wildcard file recovery, additional filesystem formatting support, and ATA SMART probing through SAT.

The next rounds of work came directly from hardware behavior:

This is one reason I like keeping experimental work in git.

The interesting history is not just "feature A was added."

It shows which assumptions failed when the code met real hardware.

The relationship with the BlueSCSI project

The BlueSCSI work and iomega_tools solve different halves of the same problem.

BlueSCSI Ultra gave me a practical way to connect physical legacy SCSI hardware when I did not have a suitable vintage host adapter.

iomega_tools deals with what happens after that connection exists.

The DaynaPORT project pushed the bridge in another direction: transporting Ethernet frames over SCSI.

The Iomega project pushes it toward storage recovery and hardware diagnostics.

Together they turned BlueSCSI Ultra from something I originally associated with SCSI emulation into a much more interesting laboratory for real legacy hardware.

Current workflow

For an unknown old cartridge, my preferred workflow is conservative.

First identify the drive:

sudo ./scsi_probe identify /dev/sdX

Then inspect the media:

sudo ./iomega_tools info /dev/sdX
sudo ./iomega_tools list /dev/sdX -r

If the filesystem is readable, recover the files:

sudo ./iomega_tools get /dev/sdX --all -o recovered

Then perform a read-only check:

sudo ./iomega_tools verify /dev/sdX

For questionable media, perform an explicit surface scan or image it before attempting repair.

Only after recovery would I consider write operations such as formatting or marking bad blocks.

That ordering is intentional:

Old removable media is not the place for optimistic automation.

What I learned

A few conclusions from the project are broader than Iomega.

First, SCSI passthrough is still extremely useful. A modern kernel provides the infrastructure needed to investigate devices that were designed decades ago.

Second, a bridge is part of the protocol path. It can impose transfer limits, transform errors, consume sense data, reset hardware, or disappear during a failed command.

Third, filesystem recovery and device recovery are different problems. A perfectly valid FAT parser cannot help if the transport stalls on one physical sector.

Fourth, old vendor tools are valuable documentation when the real protocol documentation is incomplete or difficult to find.

And finally, the safest recovery feature is usually the one that does not write anything.

That is why iomega_tools started as a collection of low-level experiments and gradually became a recovery toolkit.

The code is available in the iomega_tools repository.

Building Cisco-Like Loopback Interfaces on Linux

2026-01-12T00:00:00+00:00

Cisco routers use loopback interfaces as stable Layer 3 identities. They are independent of physical ports, making them useful for router IDs, routing-protocol endpoints, management addresses, and service IPs. Linux can provide nearly the same functionality without a custom kernel module: use a dummy network interface.

This article explains how dummy interfaces behave, how to route to them, how to use them with policy routing and FRRouting, and how to create one from C using Netlink. It also covers anycast, VRRP, and the cases where a custom kernel driver or a TUN device is actually necessary.

1. Dummy versus loopback: what is actually routable?

Create a dummy device and assign a host address:

sudo ip link add dummy0 type dummy
sudo ip addr add 10.255.0.1/32 dev dummy0
sudo ip link set dummy0 up
ip addr show dummy0

Linux installs a local route for the address, normally visible in table local:

ip route show table local
# local 10.255.0.1 dev dummy0 proto kernel scope host src 10.255.0.1

ping 10.255.0.1 succeeds on the host. This does not mean that packets are physically transmitted through dummy0: packets destined to a local address are delivered by the IP stack. The dummy driver's transmit path discards packets sent out through it.

To reach the address from another machine, that machine or its upstream routers must know a path to the Linux host. For example, if the Linux host has eth0=192.168.1.1:

# On a second machine on 192.168.1.0/24:
sudo ip route add 10.255.0.1/32 via 192.168.1.1
ping 10.255.0.1

The packet arrives on eth0 and is delivered locally because 10.255.0.1 belongs to the host. IPv4 forwarding is not required for this traffic. Forwarding is required only for packets whose destinations are not local and which must traverse the router.

A dummy interface provides a routable local identity, not a virtual wire. Adding ip route add 10.200.0.0/24 dev dummy0 does not make 10.200.0.0/24 reachable: packets routed out of the dummy device are dropped.

2. Source-based policy routing

Suppose a router has these addresses:

Device	Address	Role
`dummy0`	`10.255.0.1/32`	Stable identity
`eth0`	`192.168.1.1/24`	LAN
`eth1`	`172.16.0.2/24`	ISP 1
`eth2`	`172.17.0.2/24`	ISP 2

To route traffic sourced from the dummy address through ISP 2:

sudo ip route add default via 172.17.0.1 dev eth2 table 200
sudo ip rule add from 10.255.0.1/32 lookup 200 priority 1000
ip rule show
ip route get 8.8.8.8 from 10.255.0.1

The expected lookup selects eth2, with source 10.255.0.1. This only works end-to-end if the upstream network accepts the source address and a return route exists. On multihomed hosts, reverse-path filtering (rp_filter) can also interfere with asymmetric paths.

Linux checks the local-routing rule before ordinary user policy rules, so traffic destined to a locally owned dummy address is ordinarily delivered locally.

3. Stable BGP endpoints with FRRouting

Loopback addresses make good BGP peering endpoints because the session can survive a change in physical path provided another routed path remains available.

Example topology:

	Router A	Router B
Physical IP	`192.168.10.1`	`192.168.10.2`
Dummy IP	`10.255.0.1/32`	`10.255.0.2/32`
ASN	`65001`	`65002`

On each router, create the appropriate dummy interface. Before starting the BGP session, provide underlay reachability:

# Router A
sudo ip route add 10.255.0.2/32 via 192.168.10.2

# Router B
sudo ip route add 10.255.0.1/32 via 192.168.10.1

Install FRRouting (sudo apt install frr on Debian/Ubuntu), enable bgpd in /etc/frr/daemons, and configure it with vtysh.

Router A:

configure terminal
router bgp 65001
 bgp router-id 10.255.0.1
 neighbor 10.255.0.2 remote-as 65002
 neighbor 10.255.0.2 update-source 10.255.0.1
 neighbor 10.255.0.2 ebgp-multihop 2
 address-family ipv4 unicast
  neighbor 10.255.0.2 activate
 exit-address-family

Router B:

configure terminal
router bgp 65002
 bgp router-id 10.255.0.2
 neighbor 10.255.0.1 remote-as 65001
 neighbor 10.255.0.1 update-source 10.255.0.2
 neighbor 10.255.0.1 ebgp-multihop 2
 address-family ipv4 unicast
  neighbor 10.255.0.1 activate
 exit-address-family

Check the session with:

sudo vtysh -c 'show bgp summary'

A BGP router ID is only a 32-bit identifier: it need not be assigned to an interface or reachable. Using the loopback address as the router ID is a convention, not a requirement.

4. Anycast service addresses

Anycast uses the same service IP on multiple hosts, with the routing system selecting which host receives traffic. For example, three DNS servers might all own 10.100.0.53/32 on dummy0:

sudo ip link add dummy0 type dummy
sudo ip addr add 10.100.0.53/32 dev dummy0
sudo ip link set dummy0 up

Each server advertises the prefix via its routing daemon. In FRRouting, the advertisement can include:

router bgp 65001
 address-family ipv4 unicast
  network 10.100.0.53/32
 exit-address-family

This assumes BGP neighbors are configured and the prefix exists in the relevant routing table. Routing preference is determined by routing policies and metrics; it is not necessarily geographic proximity.

A key failure mode is that the dummy interface stays up even when the DNS application fails. A production deployment must link route advertisement or withdrawal to service health. Anycast is particularly useful for stateless services such as DNS; stateful TCP sessions can break if routing shifts an active flow to another node.

5. VRRP and high availability

For a virtual IP on the same Ethernet subnet as clients, Keepalived/VRRP is often a better fit than an always-present dummy address. Consider:

Server A: 192.168.1.10
Server B: 192.168.1.11
Floating VIP: 192.168.1.100

Example Keepalived configuration for Server A:

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1

    virtual_ipaddress {
        192.168.1.100/24 dev eth0
    }
}

Server B uses compatible settings with a lower priority, for example 100. For a VIP on a directly attached subnet, assigning it to eth0 supports normal neighbor discovery. For routed service IPs, a dummy interface plus dynamic routing may be preferable. Keepalived configurations also need appropriate peer communication, health checks, and security controls for production use.

6. Create a dummy interface from C with libnl

The preferred implementation is a userspace management program using rtnetlink, not a new kernel network driver. Netlink messages include:

Task	Message	Key attributes
Create interface	`RTM_NEWLINK`	`IFLA_IFNAME`, `IFLA_LINKINFO`, `IFLA_INFO_KIND=dummy`
Bring up	`RTM_NEWLINK`	`IFF_UP`
Add IP address	`RTM_NEWADDR`	`IFA_LOCAL`, `IFA_ADDRESS`
Add route	`RTM_NEWROUTE`	`RTA_DST`, `RTA_GATEWAY`, `RTA_OIF`
Add policy rule	`RTM_NEWRULE`	`FRA_SRC`, `FRA_TABLE`, `FRA_PRIORITY`
Delete interface	`RTM_DELLINK`	Interface identifier

Install development packages:

sudo apt install libnl-3-dev libnl-route-3-dev pkg-config

Minimal implementation (cloop.c):

#include <stdio.h>
#include <net/if.h>
#include <sys/socket.h>
#include <netlink/netlink.h>
#include <netlink/socket.h>
#include <netlink/route/link.h>
#include <netlink/route/link/dummy.h>
#include <netlink/route/addr.h>
#include <netlink/addr.h>

int main(void)
{
    struct nl_sock *sock = nl_socket_alloc();
    struct rtnl_link *link = NULL, *change = NULL;
    struct rtnl_addr *addr = NULL;
    struct nl_addr *ip = NULL;
    int err = -1, index;

    if (!sock) return 1;
    err = nl_connect(sock, NETLINK_ROUTE);
    if (err < 0) goto out;

    link = rtnl_link_dummy_alloc();
    if (!link) { err = -NLE_NOMEM; goto out; }
    rtnl_link_set_name(link, "cloop0");
    err = rtnl_link_add(sock, link, NLM_F_CREATE | NLM_F_EXCL);
    if (err < 0) goto out;

    index = rtnl_link_name2i(sock, "cloop0");
    if (index <= 0) { err = -NLE_OBJ_NOTFOUND; goto out; }

    addr = rtnl_addr_alloc();
    if (!addr) { err = -NLE_NOMEM; goto out; }
    err = nl_addr_parse("10.255.0.1/32", AF_INET, &ip);
    if (err < 0) goto out;
    rtnl_addr_set_ifindex(addr, index);
    err = rtnl_addr_set_local(addr, ip);
    if (err < 0) goto out;
    err = rtnl_addr_add(sock, addr, 0);
    if (err < 0) goto out;

    change = rtnl_link_alloc();
    if (!change) { err = -NLE_NOMEM; goto out; }
    rtnl_link_set_flags(change, IFF_UP);
    err = rtnl_link_change(sock, link, change, 0);
    if (err < 0) goto out;

    puts("Created cloop0: 10.255.0.1/32");
out:
    if (err < 0) fprintf(stderr, "Netlink error: %s\n", nl_geterror(err));
    if (change) rtnl_link_put(change);
    if (ip) nl_addr_put(ip);
    if (addr) rtnl_addr_put(addr);
    if (link) rtnl_link_put(link);
    nl_socket_free(sock);
    return err < 0 ? 1 : 0;
}

Compile and run:

gcc cloop.c -o cloop $(pkg-config --cflags --libs libnl-3.0 libnl-route-3.0)
sudo ./cloop
ip -d link show cloop0
ip addr show cloop0
ping 10.255.0.1

The program requires CAP_NET_ADMIN in its network namespace. It intentionally uses NLM_F_EXCL, so rerunning it while cloop0 exists returns an error. This is a minimal demonstration: a production daemon should reconcile desired state, handle Netlink notifications, validate inputs, and roll back partially applied changes.

7. Do you need a kernel module?

Usually not. A kernel module using alloc_netdev() and register_netdev() can expose a new device, but it introduces kernel API compatibility and lifecycle concerns. A device built with ether_setup() is Ethernet-like, not an exact clone of Linux lo (ARPHRD_LOOPBACK with loopback-specific semantics).

Use existing device types unless you truly need new transmit/receive behavior:

Requirement	Recommended mechanism
Stable router IP / Cisco-style Loopback	`dummy`
Custom source-based routing	`ip rule` / rtnetlink
BGP/OSPF control plane	FRRouting
Service anycast	`dummy` + BGP + health checks
Active/passive floating LAN VIP	Keepalived / VRRP
Userspace processing of IP packets	TUN
Virtual Ethernet frames in userspace	TAP
Routed path between hosts	GRE, IPIP, WireGuard, etc.
Novel device-specific kernel TX/RX semantics	Custom `net_device` driver

8. Suggested architecture for a router-like product

A clean Cisco-like management architecture has three layers:

C management daemon: parses commands such as interface Loopback0, stores desired configuration, creates dummy interfaces, assigns addresses, and watches rtnetlink notifications.
Linux kernel: owns the interfaces, local and forwarding routing tables, policy rules, and packet forwarding.
FRRouting: implements BGP/OSPF, route advertisements, and convergence.

For example, a CLI command interface Loopback0 could map to dummy device lo0 or Loopback0; ip address 10.255.0.1/32 maps to RTM_NEWADDR; and routing protocol configuration is delegated to FRRouting.

This approach preserves the operational advantages of Cisco loopbacks without maintaining a custom kernel driver. The central rule is simple: dummy interfaces anchor addresses; physical interfaces and tunnels carry transit traffic.

References

Restoring a Roland MT-120: Building an Arduino Floppy Drive Tester

2025-08-25T00:00:00+00:00

An old Roland MT-120 was the starting point for an unexpectedly interesting embedded project. I wanted to restore the instrument, but its floppy drive was not working correctly. Before replacing parts or making mechanical adjustments, I needed a way to control the drive independently and see what its signals were doing.

That led to FDTester: an open-source Arduino-based tester for standard PC-style 3.5-inch floppy drives. Rather than attempting to read files, it exercises the drive's mechanical and electrical interface directly.

Scope: FDTester is a mechanical and electrical diagnostic tool, not a complete floppy disk controller. It does not decode MFM sectors, read filesystem data, or prove that the magnetic read channel works.

The problem: a drive that could not read other disks

The Roland MT-120 restoration raised a practical question: was the failure caused by the drive mechanics, its interface signals, the spindle speed, or head positioning? In particular, Track 0 alignment was a challenge: the drive did not reliably read disks written by other devices.

A drive can respond to motor and seek commands while still being unable to read a disk correctly. A Track 0 sensor confirms that the mechanism reached its reference position; it does not, by itself, prove correct radial head alignment or interchangeability with another drive. That distinction shaped the test strategy.

Architecture: separating control from the host

FDTester uses an Arduino as a small, dedicated interface controller. A serial terminal sends commands; the Arduino drives the floppy interface and reports status and measurements. The repository documents an Arduino Uno / ATmega328P reference setup, while its project description also mentions Mega compatibility.

The repository's validated target is an Epson SMD-300, configured for DS0. This is the documented test configuration; compatibility with other drives depends on their pinout, jumpers, and electrical characteristics.

The floppy drive has its own external 5 V supply (the README specifies approximately 1 A capability), with a common ground shared with the Arduino. Do not power the motor from the Arduino USB port. A ULN2803 or appropriate transistor buffering is recommended for the active-low interface lines; check your exact drive's electrical requirements before connecting it.

The signals that matter

A classic 34-pin floppy interface gives direct access to the most useful diagnostic controls and feedback signals:

Floppy pin	Signal	Arduino Uno pin	Diagnostic purpose
10	Drive Select 0	D7	Select the target drive
16	Motor Enable	D6	Start and stop spindle
18	Direction	D5	Set seek direction
20	Step	D4	Advance the head by one track
32	Side Select	D8	Select head 0 or 1
8	Index	D2 / INT0	Count revolutions
26	Track 0	D11	Detect home position
28	Write Protect	D12	Inspect disk protection status
34	Disk Change	D10	Detect media change (default configuration)
24	Write Gate	D9	Dangerous write control; locked by default

Important: The table reflects the repository's Epson SMD-300 / DS0 wiring. Odd-numbered connector pins are grounds. Pin 34 may have a different function on other drives or jumper settings. Pin 2 (Density Select) is left unconnected in the documented setup.

Diagnostic workflow

I wanted a repeatable way to distinguish an interface problem from a mechanical problem before attempting fine adjustment.

The basic sequence is straightforward:

Check wiring and drive selection. Confirm common ground, the external supply, and the DS0 jumper configuration.
Spin the motor. Confirm that the mechanism starts reliably.
Measure rotational speed. Count Index pulses over a known interval.
Home the head. Move toward Track 0 and inspect the Track 0 signal.
Exercise stepping. Seek to known tracks and sweep across a range to reveal mechanical issues.
Inspect status lines. Check Write Protect and Disk Change while inserting or removing media.
Evaluate disk interchangeability separately. If disks from other devices still cannot be read, investigate mechanical alignment and the read path using appropriate reference media and equipment.

RPM measurement using the Index pulse

The Index signal provides one pulse per revolution on a typical drive. If N pulses arrive during a measurement window of T seconds, rotational speed is approximately:

RPM = 60 × N / T

For example, 15 pulses over three seconds corresponds to about 300 RPM. That is a calculation example, not a recorded measurement from the Roland restoration.

Track 0: homing is not alignment

The most interesting part of this repair was Track 0. Homing tells the firmware where the mechanism's reference sensor is triggered. However, an incorrectly positioned head assembly can still produce a plausible Track 0 signal and fail to read disks recorded by another machine.

This is why I treated Track 0 detection and head alignment as different problems. FDTester can help with the former and with repeatable movement tests; it cannot directly measure magnetic head alignment or validate sector decoding. Alignment should be checked against appropriate reference media or specialist equipment rather than inferred solely from the Track 0 switch.

Using FDTester

The firmware exposes a simple 115200-baud serial console. Once the drive is wired and powered correctly, these are useful commands from the published README:

P                  # Report status
M                  # Toggle motor
R 3                # Measure RPM for 3 seconds
H                  # Home to Track 0
G 40               # Seek to absolute track 40
S 1                # Select side 1
T 0 79 100         # Sweep tracks 0–79, 100 ms dwell
RATE 6             # Set stepping interval to 6 ms
?                  # Show help

The firmware also includes Write Gate controls protected by an explicit UNLOCK command. Do not unlock or assert Write Gate on a disk containing valuable data. None of the diagnostic steps above requires writing to the disk.

See the source sketch and README for the implementation and full command reference.

What the tester can—and cannot—tell you

FDTester is useful for isolating failures in spindle control, stepping, drive selection, home sensing, status wiring, and basic timing. It also gives you a repeatable way to move the mechanism while inspecting its behavior.

It does not establish that the read head, analog read channel, MFM decoding, or media are good. If the drive responds correctly to all commands but cannot read disks from other devices, the next step is targeted read-path and alignment diagnosis, not an assumption that the controller has fixed the problem.

Lessons learned

The most valuable outcome was not a new storage controller; it was observability. Breaking the drive into independent signals and commands turned a vague "doesn't read disks" failure into a sequence of testable questions.

For me, the Roland MT-120 restoration was also a reminder of why embedded engineering is rewarding: software, timing, electrical interfaces, and mechanics all meet at the same debugging bench.

From BlueSCSI Ultra to DaynaPORT: the same kind of hands-on work on legacy SCSI devices, from the controller side.
Recovering Iomega Media in 2026: the floppy-era hardware story continues with Jaz and Zip drives and QIC-122 tape.

Project: FDTester on GitHub · Arduino sketch · GPL-3.0 license

Diagrams in this article are conceptual illustrations, not oscilloscope captures or a certified wiring schematic. Confirm connections against the repository and your drive's technical manual.

Andrei Kazialetski — AVKSoft

Spec-Driven AI Development: Building bgpd-simple with Spec Kit and Local AI Coding Agents

Why a routing daemon is a good SDD test case

The stack: Spec Kit, OpenCode or Claude Code, llama.cpp or LM Studio

From Qwen 3.5 and GLM-4.7 to newer local models

The hardware behind the local experiments

Adopting Spec Kit in an existing repository

A practical Spec Kit workflow

RFCs as executable requirements

What the commit history shows

The runtime architecture the agent had to preserve

Running Qwen 3.6 27B locally with llama.cpp

Connecting OpenCode directly to llama.cpp

Alternative: OpenCode with LM Studio

Alternative coding agent: Claude Code

Claude Code + LM Studio

Claude Code + llama.cpp

Other connection patterns

1. llama.cpp on another workstation

2. Remote GPU machine through an SSH tunnel

3. llama.cpp in Docker

How I use the agent during implementation

Verification is part of implementation

Where local models work well — and where they do not

What Spec-Driven Development changed for me

References

Libella — Privacy Policy

Documents and local data

Analytics, advertising and tracking

Store purchases

Support communications

Sharing

Retention and deletion

Privacy rights

Children's privacy

Security

Changes to this policy

Chasing a PCIe Ghost on Raspberry Pi 5

The setup

A puzzling compatibility matrix

Watching PCIe link training

Ruling out the obvious

A kernel patch: retry without PERST#

The x86 cross-check changed everything

The adapter became the unknown

Next: designing my own PCIe PCB

References

Welcome to the AVKSoft blog

From BlueSCSI Ultra to DaynaPORT: Connecting Legacy SCSI Devices to Linux and Windows

How networking entered the picture

DaynaPORT is not a disk

The first important limitation: there is no RX interrupt

Native SCSI was the easy case

The 512-byte problem

Adding chunking without breaking DaynaPORT

The Linux driver became three drivers

Discovery instead of hard-coded SCSI IDs

Another historical detail: wait after ENABLE

Polling was the real performance problem

Measuring the bridge separately changed the diagnosis

Increasing the USB buffer to 4096 bytes

From Linux to Windows

Windows 10 / 11

Windows 2000 / XP

Windows NT 4.0

Windows 95 / 98 / ME

One protocol core, decades of driver APIs

Bridge options on Windows

What the repository history shows

Current status

What I learned

Storage bridges and packet protocols have different assumptions

Polling behavior can dominate throughput

Measure layers independently

Keep protocol code separate from OS APIs

Old protocols are often better documented in code than in manuals

Final result

Repositories

Recovering Iomega Media in 2026: Building iomega_tools for Jaz, Zip, and QIC-122

Why Iomega media is still interesting

`qic_extract`: recovering old Iomega backup archives