DEV Community: Govind raj

I turned a dead HP laptop into a home server—and a Broadcom Wi-Fi chip fought me for 3 hours

Govind raj — Sat, 12 Sep 2026 19:57:04 +0000

My phone storage was full. Instead of paying for more cloud, I decided to repurpose an old HP laptop that had been collecting dust into a home server — somewhere to offload photos and, eventually, run a self-hosted photo library with AI search.

The install went fine. Then the Wi-Fi chip decided to make me earn it — and just when I thought it was over, the machine started shutting itself off for a reason I never would have guessed. This is the honest writeup, both fights included, in case someone Googling "BCM43142 Ubuntu Server no wifi" — or "laptop server shuts off under load" — at midnight needs it.

The hardware

Old HP laptop, 1 TB spinning drive
Realtek Gigabit Ethernet—but no cable could reach the router from where the laptop lives.
Broadcom BCM43142 Wi-Fi—the villain of this story
Ubuntu Server 24.04 LTS

That "no ethernet + Broadcom Wi-Fi" combo is the whole plot. Hold onto it.

Part 1: Installing Ubuntu Server (one gotcha worth catching)

The install is mostly next-next-next. Two things I'd flag:

Tick "Install OpenSSH server" on the profile screen. This is a headless box — SSH is how you'll talk to it once it's shelved.

The disk gotcha. With guided LVM storage, the installer only allocates 100 GB to the root volume by default, even on a 1 TB disk. For a storage server that's a disaster — you'd waste ~900 GB. On the storage screen, edit the ubuntu-lv logical volume and bump its size to the full volume group (mine was ~928 GB) before continuing. After the edit, free space should read zero.

Install, reboot, log in. So far, so smooth.

Part 2: The chicken-and-egg problem

First command on any fresh server:

I saw lo and the ethernet interface. No wl* interface at all. Confirmed the chip with:

The hardware is there — it just has no driver. The BCM43142 needs the proprietary bcmwl-kernel-source (a.k.a. broadcom-sta) driver, which is not in the base install.

Here's the trap: to install the Wi-Fi driver, you need internet. To get internet, you need the Wi-Fi driver. And I had no ethernet cable that could reach the router.

The way out: borrow a phone's connection over USB once, just long enough to install the driver.

Part 3: Phone USB tethering (the painful part)

I'll be honest — this was two hours of whack-a-mole. Lessons, so you don't repeat them:

dhclient isn't on Ubuntu Server 24.04

The classic DHCP client is gone. Use busybox instead:

Android tethering renamed its interface constantly

Every reconnect, the USB interface came back with a new name (enx32481b…, then enxe6ec39…, then enx8e63…). Any variable I'd set pointed at a ghost. The defensive move — always grab the current name fresh:

The key insight: address FIRST, then route

This one cost me the most time. udhcpc would report a lease but not actually apply it, so adding the default route failed with Nexthop has invalid gateway. The fix is ordering — put the address on the interface before the route:

DNS kept silently breaking

ping 8.8.8.8 worked while ping google.com gave "Temporary failure in name resolution."That signature = DNS not set. The _resolv.conf line above fixes it; sometimes you have to re-apply it because something overwrites the file.

Android vs iPhone

The Samsung tether was miserable — flaky DHCP, dropped routes, an MTU quirk where pings passed but package downloads failed. Switching to an iPhone Personal Hotspot over USB-C was night and day: stable interface name, gateway always 172.20.10.1, clean /28 subnet. If you have the choice, start with the iPhone.

Once that held, the payoff:

⚠️ It's bcmwl — b-c-m-w-l. I fat-fingered it as bcwl more than once and got "Unable to locate package." Learn from my typos.

DKMS compiled the module against the running kernel:

Then:

After the reboot:

wlp4s0 exists. The chip that had no driver all night is now a real interface. It scanned and saw my network:

Part 4: netplan alone wasn't enough — the real fix was NetworkManager

I did the "correct" Ubuntu Server thing and wrote a netplan Wi-Fi config:

It came up UP but never got an address. netplan status showed the damning line:

_"(null)" _= associated with nothing. I checked the supplicant logs:

That was the real clue. No entries means the handshake was never even attempted — the networkd backend wasn't starting wpa_supplicant for this driver at all. It wasn't a wrong-password problem; the join never happened.

The fix: hand Wi-Fi to NetworkManager, which manages the supplicant itself.

And:

Address assigned. ping google.com — 0% loss. iPhone unplugged. Still online. Survives reboots and auto-reconnects. Done.

Part 5: making it behave like a server

So it keeps running with the lid shut:

Charger stays plugged in permanently, lid closed, tucked somewhere with airflow. From here on it's all SSH from my main machine:

Part 6: the sequel — it booted, then kept dying

I thought I was done. Lid closed, shelved, walked away. The next day it started shutting itself off.

The pattern was maddening: it booted cleanly, showed the login: prompt, let me log in — then the instant I ran an actual command, the whole thing cut to black. No kernel panic, no error, no shutdown message. Just gone. Every time, right when the CPU had to do something.

My first assumption was the worst one: dead motherboard. It wasn't.

Here's the context that solved it. This laptop's battery no longer holds a charge, so I'd taken it out and was running on the charger alone — seemed reasonable for a machine that lives plugged into the wall. That was the mistake.

A laptop battery isn't just an energy store. Even at 0% it acts as a buffer/shock-absorber on the power rail. When the CPU suddenly ramps (spinning up services at login, running a command), it briefly draws more than the charger can deliver on its own. With a battery in the circuit, the battery covers that spike. With no battery, the rail sags below spec and the board browns out and instantly powers off — which looks exactly like a fatal hardware death but isn't.

The fix was almost stupidly simple:

Put the dead battery back in. Even though it holds no charge, it smooths the power spikes. Then leave the charger plugged in permanently.

To confirm it rather than guess, I hammered the CPU on purpose:

Before (battery out): dead within seconds of any load. After (dead battery back in): rock solid through a full-core stress loop. Confirmed — it was never the motherboard, it was a power-buffering problem.

If your always-plugged-in laptop server randomly powers off under load — especially if you removed a "useless" dead battery — put the battery back in before you suspect anything else. One caveat: if the battery is swollen or puffy, don't reinsert it (fire risk) — recycle it and use a cheap replacement as the buffer instead.

What I'd tell my past self

BCM43142 needs bcmwl-kernel-source, and that needs one internet connection to install. Everything else is downstream of solving that once.
Prefer an iPhone hotspot over Android for the temporary tether — far more stable interface and DHCP.
Address before route. The _invalid gateway error_ is almost always ordering.
On this driver, netplan's networkd backend didn't start wpa_supplicant — NetworkManager did. If journalctl -u wpa_supplicant says "No entries," stop debugging the password and switch renderers.
The disk default is 100 GB. Expand the LV during install or lose most of your drive.
Don't run a laptop server with the battery removed. Even a dead battery buffers power spikes. Charger-only means the board browns out and powers off under load — and it looks exactly like a dead motherboard.

What's next

The whole point was storage, so next up is a Samba share for phone photo offload, then a self-hosted photo library with on-device AI search. But the server itself — full disk, SSH, auto-connecting Wi-Fi on a chip that ships with no Linux driver — is alive and standing on its own.

A "dead" laptop, a $0 budget, and one genuinely stubborn Wi-Fi chip. Worth it.

If this saved you an evening, drop a note — and if your BCM43142 did something new and cursed, I want to hear it.

AI Agent #2: Requirements-to-Test Mapper — Here's What I Learned

Govind raj — Sat, 08 Aug 2026 02:45:56 +0000

The Problem

You're drowning in requirements.

Your product manager hands you a 20-page requirements document. Each requirement has 3-5 acceptance criteria. You need to create test cases for ALL of them.

That's 3-4 hours of manual work. Per project.

And here's the painful part: You create the test cases. You document them. You maintain them. Then someone updates a requirement and you have to manually re-trace everything.

Sound familiar?

For QA teams handling multiple projects, this becomes a bottleneck. Especially if you need traceability (ISO 9001, FDA, CSA compliance requires it).

The Real Cost

Manual test case creation = more than just time wasted.

It means:

❌ Inconsistent test case quality (depends on who writes them)
❌ Coverage gaps (easy to miss edge cases when writing manually)
❌ Traceability breaks (requirements and tests fall out of sync)
❌ Compliance risk (auditors ask: "Can you prove all requirements are tested?")
❌ Team bottleneck (only senior QA can write good test cases)

I wanted to eliminate this. So I built an AI agent that does it in seconds.

The Solution: Requirements Mapper AI Agent

Instead of manually reading requirements and writing test cases, what if Claude API did it?

The agent:

Parses your requirements document
Sends each requirement to Claude API
Generates 3-4 detailed test cases per requirement
Creates a traceability matrix (REQ ↔ TC mapping)
Identifies coverage gaps
Exports a professional Excel report

Result: Same work in 35 seconds.

Not 3-4 hours. 35 seconds.

Here's How It Works
Step 1: Requirements Parser

Upload a requirements document with this format:

REQ-001: User Authentication
Description: The system shall authenticate users.
Details:

Support email/password login
Failed attempts logged
Account lock after 5 failures

REQ-002: Email Verification
Description: System shall verify user emails.
Details:

Send verification email within 2 seconds
Link expires after 24 hours
Resend limit: 3 per hour

The parser extracts:

Requirement ID
Title
Description
Detailed criteria
Step 2: Claude API Test Case Generator

For each requirement, the agent asks Claude:

"REQ-001: User Authentication
Description: The system shall authenticate users.

Generate 3-4 detailed test cases.
Include test ID, title, steps, and expected result."

Claude returns:

TC-001-001: Valid Credentials Login
Steps:

Navigate to login page
Enter valid email
Enter valid password
Click Login Expected: Dashboard displays successfully

TC-001-002: Invalid Password Rejection
Steps:

Navigate to login page
Enter valid email
Enter wrong password
Click Login Expected: "Invalid password" error message

TC-001-003: Account Lock After 5 Failures
Steps:

Attempt login 5 times with wrong password
Attempt 6th login with correct password Expected: "Account locked" message (not "invalid credentials")

Why Claude? Because it understands intent, not just keywords.

"User shall authenticate" and "System authenticates users" mean the same thing. A regex-based tool would miss this. Claude gets it.

Step 3: Traceability Matrix

Automatically maps requirements to test cases:

REQ-001: User Authentication
├─ TC-001-001: Valid credentials ✅
├─ TC-001-002: Invalid password ✅
├─ TC-001-003: Account lockout ✅
└─ TC-001-004: Password reset ✅
Coverage: 100%

REQ-002: Email Verification
├─ TC-002-001: Email sent within 2s ✅
├─ TC-002-002: Link expires after 24h ✅
├─ TC-002-003: Resend limit enforced ✅
└─ TC-002-004: Unverified account deletion ✅
Coverage: 100%
Step 4: Gap Analysis

Identifies requirements with insufficient test coverage:

Coverage Report:
✅ Total Coverage: 95%
⚠️ Coverage Gaps: 2 requirements

Gap #1: REQ-005 (Dark Mode)
Issue: Only 2 test cases
Recommendation: Add tests for theme persistence,
toggle behavior, accessibility

Gap #2: REQ-008 (Data Export)
Issue: Missing edge case tests
Recommendation: Add tests for large datasets,
character encoding, file corruption
Step 5: Excel Report Generation

Generates a professional, audit-ready Excel file:

Sheet 1: Summary

Total requirements: 10
Coverage %: 95%
Gaps identified: 2
Total test cases: 38

Sheet 2: Traceability Matrix

Req ID Requirement Test Count Test IDs Coverage
REQ-001 Authentication 4 TC-001-001, TC-001-002, TC-001-003, TC-001-004 100%
REQ-002 Email Verification 4 TC-002-001, TC-002-002, TC-002-003, TC-002-004 100%

Sheet 3: Coverage Gaps

Lists what's not tested
Suggests additional test cases
Prioritizes by risk

Sheet 4: Test Cases

Full test specifications
All steps and expected results
Ready for QA to execute
Real Example: Medical Device Requirements

To demo this, I used 10 realistic medical device requirements:

REQ-001: User Authentication
REQ-002: Password Security

REQ-003: Email Verification
REQ-004: Device Connection
REQ-005: Data Collection
REQ-006: Real-time Alerts
REQ-007: Dashboard Display
REQ-008: Data Export
REQ-009: HIPAA Compliance
REQ-010: Role-Based Access

Result:

✅ 40 test cases generated
✅ 100% coverage
✅ Excel report ready for audit
✅ Time elapsed: 35 seconds

Without automation: 3-4 hours of manual work.

With this agent: 35 seconds.

Why This Matters
For QA Teams
✅ Eliminate manual test case writing
✅ Ensure consistent quality
✅ Maintain complete traceability
✅ Save 3-4 hours per project
For Compliance
✅ ISO 9001: Complete traceability matrix
✅ FDA: All requirements documented and tested
✅ CSA: Coverage gaps identified and addressed
✅ Audit-ready reports in minutes
For Business
✅ Faster time-to-test
✅ Better quality assurance
✅ Reduced rework
✅ Scalable QA process
The Architecture

The tool is built with Python + Claude API:

python
class RequirementsParser:
# Reads requirements, extracts structured data

class TestCaseGenerator:
# Sends to Claude API, generates test cases
# Includes robust JSON extraction with 4 fallback strategies

class TraceabilityMapper:
# Maps REQ ↔ TC, calculates coverage %

class GapAnalyzer:
# Finds untested requirements
# Suggests missing test scenarios

class ExcelGenerator:
# Creates professional 4-sheet report
# Includes formatting, colors, styling

Performance:

Parse 10 requirements: < 1 sec
Generate 40 test cases: ~30 sec (Claude API latency)
Create matrix + gaps: < 1 sec
Generate Excel: ~2 sec
Total: ~35 seconds
Why Claude API, Not ML Models?

I considered TensorFlow, PyTorch, custom ML models.

But here's why Claude API is better:

ML models (❌ not ideal):

Require training data
Need fine-tuning for accuracy
Hard to reason about edge cases
Black box results

Claude API (✅ perfect fit):

Understands requirement semantics
Generates complete test cases with reasoning
Consistent quality
Transparent reasoning

Example:

Requirement: "System shall validate email format"

ML model might generate:

"Test: enter email"
"Test: enter invalid email"

Claude generates:

"Test: RFC 5322 compliant email"
"Test: Missing @"
"Test: Multiple @ symbols"
"Test: Invalid domain"
"Test: Internationalized domain names"

Claude thinks semantically. ML models pattern-match.

For QA, semantic understanding wins.

Three Lessons Learned
Lesson 1: JSON Extraction is Harder Than You Think

When Claude returns test cases as JSON, it's not always perfect.

Sometimes it wraps JSON in text. Sometimes the formatting is inconsistent.

My first attempt had a simple regex: re.search(r'{.*}', text)

That failed 80% of the time.

I built 4 fallback strategies:

Find JSON object with nested braces
Find JSON array of objects
Look for triple-backtick code blocks
Clean markdown and extract

Now: 95%+ success rate.

Lesson: When integrating with LLMs, assume the response will be messy. Plan for it.

Lesson 2: Fallback Test Cases Are Actually Good

When Claude's JSON fails, my code creates 3 automatic test cases:

TC-001: Basic functionality
TC-002: Error handling
TC-003: Edge cases

These fallback test cases are actually good. They cover the important scenarios.

So "failures" become wins. Full coverage maintained even when JSON parsing fails.

Lesson: Smart fallbacks can be as valuable as the primary path.

Lesson 3: Traceability Drives Quality

Once you make coverage visible (REQ ↔ TC matrix), teams prioritize filling gaps.

Before: "We have test cases" (nobody knows coverage) After: "We have 95% coverage, here are the 2 gaps" (teams fix gaps immediately)

Visibility drives action.

Lesson: For QA automation, measurement and visibility matter as much as automation itself.

Use Cases
✅ Medical device software (FDA traceability required)
✅ Enterprise applications (ISO 9001, CSA compliance)
✅ Financial software (regulatory requirements)
✅ Any project requiring documented test coverage

Next Steps

The code is open source:

👉 GitHub: github.com/gov466/requirements-mapper

Features:

Parse requirements from text files
Generate test cases with Claude API
Create professional Excel reports
Identify coverage gaps
Ready for production use

Installation:

bash
pip install -r requirements.txt
python requirements_mapper.py

Output: Professional Excel file with complete traceability.

Cost

Claude API for 10 requirements:

Input tokens: ~10,000
Output tokens: ~5,000
Cost: ~$0.01

Per 100 requirements: ~$0.10

Essentially free compared to 3-4 hours of manual work.

Takeaway

Test case generation is one of QA's biggest bottlenecks.

Manual work = inconsistent, slow, error-prone.

AI + Claude API = fast, consistent, comprehensive.

The future of QA isn't just automation. It's intelligent automation.

Semantic understanding + traceability + compliance = modern QA tools.

That's what I'm building.

Have you built anything with Claude API? I'd love to hear about it in the comments.

Want the code? GitHub link above. It's production-ready.

Want to learn more? Read the full technical write-up on GitHub.

Thanks for reading! 🚀

QA #AI #Automation #Claude #Python #Testing #ComplianceFirst

I Built an AI Bot to Find Duplicate Defects in Jira — Here's What I Learned

Govind raj — Sat, 01 Aug 2026 03:07:57 +0000

I built a Jira bot powered by Claude API that comments on new tickets with likely duplicates. It reasons about root cause instead of keyword matching. Here's the architecture and what surprised me.

The Problem Every QA Team Faces

You're triaging defects. A new bug comes in: "Device disconnects after 2 minutes."

You've got 50 open issues. One of them is probably the same root cause, but it's buried in your backlog with a different symptom: "Connection loss during thermal stress."

How do you know they're the same issue without reading every single ticket?

Traditional duplicate detection fails:

Keyword matching misses issues with different symptoms but identical root causes
Manual review takes 30 minutes per ticket
You inevitably miss connections
The Solution: A Bot That Reasons About Root Cause

I decided to build a bot that does what I wish I could do instantly: read a new defect, compare it to all open issues, and identify likely duplicates by reasoning about the actual root cause.

Here's how it works:

New defect submitted to Jira → Webhook fires
Bot fetches the new ticket + all open issues
Send to Claude API with a prompt like:
"Here's a new defect: [full description]

Here are 50 open issues: [list with details]

Which issues likely share the same root cause?
Explain your reasoning. Confidence score for each."

Claude analyzes and returns ranked matches
Bot comments on the ticket with suggestions
Engineer reviews — human makes the final call

The key: Claude understands causation, not just word overlap.

The Bot in Action

Here's what it looks like when it works in real time:

Real Example: Two Bugs, Same Root Cause

I tested this with two actual defects:

Bug #1: Display backlight flickers when device runs on battery

When the unit is unplugged and running on battery, the screen backlight
flickers noticeably. Doesn't happen while it's plugged into mains power —
only on battery.

Bug #2: Screen brightness unstable during unplugged operation

Running the device without external power, the display keeps fluctuating
in brightness. As soon as it's back on wall power the screen is steady
again. Seems tied to running off the internal cell.

The Challenge: These bugs describe the exact same problem with completely different wording. Bug #1 mentions "backlight flickers on battery." Bug #2 says "brightness unstable when unplugged." Same root cause (battery power delivery), different symptom descriptions.

Keyword matching would miss this. The words don't overlap much. But the root cause is identical: power delivery instability on battery.

The Bot's Response:

When I submitted Bug #2, the bot immediately flagged Bug #1 as a likely duplicate. It explained:

"Both defects describe the same root cause (battery power delivery instability) affecting the same subsystem (display backlight) with identical behavior pattern (flickering/fluctuating brightness on battery, stable on mains power)."

Confidence: High (duplicate)

That's not pattern matching. That's reasoning about causation.

Why Claude API, Not Machine Learning?

You might think: "Shouldn't you build an ML model for this?"

Short answer: No. Here's why:

ML approach would require:

Training data (100+ labeled duplicate pairs)
Weeks of experimentation
GPU compute
Ongoing model refinement
Retraining when patterns change

Claude API approach:

Works immediately
$0.50/month
Handles novel patterns (Claude generalizes)
No training data needed
Reasoning is transparent (you see why it flagged something)

For a QA team's duplicate detection problem, semantic reasoning beats statistical learning.

Architecture: Simple and Elegant
Jira Webhook (new defect)
↓
Google Apps Script
├─ Fetch new ticket details
├─ Query Jira for open issues
├─ Build prompt with context
└─ Call Claude API

Claude API
├─ Analyze for root-cause similarity
├─ Return ranked matches + confidence
└─ Return reasoning

Bot Action
├─ Post comment to ticket
├─ Link likely duplicates
└─ Flag for human review

Total: ~200 lines of code. Zero infrastructure.

Three Things That Surprised Me

Claude understood domain context without training

I didn't need to teach it what "battery power delivery" means or what makes two display issues related. It understood from context that both bugs point to a power-related instability affecting the backlight circuit.

Confidence scores were surprisingly accurate

When the bot ranked matches with confidence percentages, those rankings matched my intuition perfectly. Higher confidence = stronger root-cause connection.

The "human-in-the-loop" note matters

I added: "Suggestions only — please confirm before linking or closing."

That line is critical. It tells engineers: This is assistance, not automation. That actually builds trust faster than auto-closing tickets would.

Lessons for Building QA Automation

If you're thinking about adding AI to your QA workflow:

Root-cause reasoning > pattern matching For debugging, duplicate detection, or root cause analysis, semantic understanding beats keyword overlap every time. Use Claude for reasoning tasks.
Human-in-the-loop is a feature Don't try to fully automate. Surface candidates, let humans decide. That friction is actually what makes the tool trustworthy.
Start with APIs, not models You don't need to train ML models. Claude API costs $1-3/month and solves most QA reasoning problems. Save complex ML for truly custom use cases.
Transparency helps adoption Show your reasoning. "Why did you flag this?" is more important than "I flagged this." Engineers trust tools that explain themselves.
Test before deploying Obvious, but: validate that your duplicates are actually duplicates before letting the bot loose. One bad match kills engineer trust.

The Takeaway

Building this bot taught me that the best automation tools aren't the ones that eliminate human judgment — they're the ones that amplify it.

A bot that comments "Here are 3 issues that might be related, here's why" is infinitely more useful than one that auto-closes tickets.

If you're automating QA workflows, think about where reasoning matters more than matching. That's where Claude API shines.

Built with Claude API + Google Apps Script + Jira Webhooks

Have you built bots for your team? What problem did it solve? Drop a comment.