Improving the Modem Request Process - Looking for Feedback

[kwschulz]

I run this project solo (with Claude as my development partner), and over the past 10 weeks it's grown from 1 modem to 18 (12 verified, 5 awaiting testing, 1 in progress). That's thanks to:

• 22 contributors who submitted captures, tested parsers, and provided feedback
• @sfennell, @dimkalinux, and @BowlesCR who contributed code
• @ChBi89 for ongoing testing and beta feedback

Thank you. This project wouldn't exist without you.

The challenge I'm facing

As modem requests increase, I've noticed a pattern: most requests require 3-5 rounds of back-and-forth before I have complete data to build a parser. Each round means delays for you and context-switching for me.

Here's a pattern I've seen across several requests:

Round	What happened
1	Capture submitted
2	Wrong capture type for this modem's protocol
3	Recapture has gaps from browser caching
4	Fresh capture, parser built and shipped
5	User confirms it works
6	Edge case discovered - needed data was never in the capture

Capture methods

Most modems use HTML - the built-in Capture HTML button works great for these. Of the 18 modems in the library, 14 are HTML-based.

HNAP/API modems need HAR capture - these modems (like MB8611, S33) load data via JavaScript API calls. The HTML page is just a shell. For these, the key is visiting every page during HAR recording:

1. Start HAR recording with cache disabled
2. Log in to your modem
3. Visit all status pages - downstream, upstream, system info, logs
4. Wait 3-5 seconds per page for async data to load
5. Stop recording

Each page visit triggers API calls that become part of your modem's test fixture - a frozen snapshot I use to:

1. Build the parser - Understand your modem's data format
2. Write tests - Verify the parser extracts data correctly
3. Prevent regressions - Ensure future changes don't break your modem

Missing pages or cached responses mean incomplete fixtures, which means edge cases slip through.

What I need to see in submissions

1. Authentication flow - How login works (form, HTTP basic, HNAP)
2. All channel types - The actual modulation strings (QAM256, OFDM PLC, ATDMA, etc.)
3. Real API responses - For HNAP modems only

For reference, here's what a complete fixture looks like - note the hnap_full_status.json containing actual channel data with modulation strings.

Documentation

• Modem Request Guide - How to capture and submit your modem's data
• Troubleshooting - Common issues and solutions
• Fixture Library - All supported modems with examples
• Parser Development Guide - Step-by-step guide for adding parsers
• Modem Request Triage Skill - Claude skill to analyze captures before submission

Ideas I'm considering

• Capture validation script that checks completeness
• Better diagnostics for faster troubleshooting

Your input

If you've submitted a modem request:

• What was confusing about the process?
• What would have helped you submit complete data the first time?

If you're technical:

• Ideas for tooling that could validate captures?
• Want to help with documentation or parser development?

The vision

Near-term: Streamline the process - complete captures on the first try, less back-and-forth.

Longer-term: Fully self-serve modem submissions - where you can validate your own capture and know it's complete before opening an issue.

Your feedback helps get us there. If your modem isn't supported yet, let's add it.