BlogByNuX

Foundation, Foundation, Foundation

2026-10-01T00:00:00-07:00

Imagine spending the better part of an afternoon painting a fence.

Stroke.

Dip.

Stroke.

Dip.

A few hours go by and you're finally starting to see progress.

Then you look back and realize the neighbor kid has been throwing clods of dirt at the part you already finished.

That is sometimes what trying to introduce programmability and automation into networking feels like.

You can have the scripts.

You can have the APIs.

You can have the Python libraries, the templates, the source of truth, the automation servers, and the best intentions in the world.

But if the foundation is not there, one person can undo a surprising amount of work.

Sometimes intentionally.

Usually unintentionally.

Either way, the result is the same.

You spend your time repainting the fence.

Everyone Has to Row in the Same Direction

Sometimes the crew isn't just rowing in different directions. Sometimes one guy is chewing on the oar.

When programming concepts are applied to networking, a foundation has to exist first.

Standards.

Processes.

Trust.

Access.

Consistency.

People who understand what the automation is trying to accomplish.

And, perhaps most importantly, support from the people responsible for the environment.

I can already hear somebody saying:

One person can't disrupt an automation effort that badly.

Sure they can.

Imagine building an automation platform that depends on reaching a set of network devices from a known group of systems.

Then somebody modifies an access control list.

Maybe they do not know those systems are automation hosts.

Maybe they do know and have a different idea of how things should work.

Either way, your automation stops.

Nothing about Python changed.

Nothing about your code changed.

Nothing about the API changed.

The environment changed underneath you.

And suddenly the problem is no longer technical.

Technology Can't Solve Every Problem

That has probably been one of the more frustrating lessons of my career.

Technology can solve a lot of things.

It cannot make people cooperate.

It cannot make an organization agree on standards.

It cannot make a manager support a direction they do not believe in.

It cannot make a process consistent when everybody is allowed to invent their own version of it.

It cannot turn a dysfunctional environment into a functional one merely because somebody installed Ansible.

Sometimes the biggest obstacle to automation has absolutely nothing to do with automation.

When Networking and Programming Started Dating

There was a period when networking and programming were just beginning to seriously meet each other.

Today, Python in networking barely raises an eyebrow.

Back then, it was different.

Some of the libraries and tools I wanted to use ran cleanly on Linux and were, at best, unpredictable on Windows.

You could sometimes make them work.

Sometimes.

Other times you spent hours fighting dependencies, compilers, strange Python packaging behavior, or libraries that clearly assumed they were running on a Unix-like system.

Linux was simply the better tool for the job.

The problem was that sometimes management would say:

No Linux.

That could be frustrating.

You could lay out the possibilities.

You could explain how automation might reduce repetitive work.

You could show how consistency could improve.

You could talk about configuration generation, validation, reporting, auditing, backups, testing, and all of the other things that become possible once networking starts borrowing ideas from software development.

You could show the horizon.

But if the answer was no, the answer was no.

Technology does not override organizational authority.

One Person Can Only Push So Far

That is probably the heart of this post.

One person can build a lot.

One person can learn a lot.

One person can prototype.

One person can demonstrate what is possible.

One person can even build something from the ground up.

But one person cannot create organizational alignment by themselves.

That can be incredibly frustrating.

You may look at a decision and think it makes absolutely no sense.

You may see people doing things manually that could have been automated years ago.

You may see inconsistent configurations, undocumented changes, one-off exceptions, and processes that exist mostly because that is how somebody has always done them.

Eventually I learned that there is a difference between recognizing dysfunction and believing you are personally responsible for fixing all of it.

If an opportunity appears to improve something, take it.

If people want help fixing a broken process, help fix it.

But if the people, processes, or organization do not want to change, there is only so much force you can apply before you are just exhausting yourself.

Sometimes People Have Reasons You Cannot See

Years ago I worked for a manager who was actually a pretty sharp guy.

He understood technology.

He understood people.

He understood how to manage.

But when it came to applying programming techniques to networking, we rarely seemed to see things the same way.

At the time, I thought one of two things was happening.

Either he simply did not like me, or he really did not like the direction I was trying to take networking.

I eventually leaned toward the second explanation.

Later, I learned that earlier in his career he had worked for a company that was doing some very advanced work for the time around combining programming and networking.

From what I understood, that experience had not gone particularly well.

I can only speculate, but I have wondered whether that experience shaped how he viewed the same ideas later.

And honestly, that would make sense.

People do not walk into a meeting as blank slates.

Past failures matter.

Past outages matter.

Bad projects matter.

Being burned by a technology once can make somebody extremely cautious about touching it again.

At the time, though, I did not understand that.

All I could see was resistance.

Then Something Changed

Fast forward several years.

Maybe close to a decade.

People move on.

He did too.

He moved upward, eventually became a CIO, and later went on to bigger things.

Eventually he landed at a very large global organization.

And that organization was heavily invested in things that, years earlier, I had been trying to talk about:

Linux.

Automation.

Agile methods.

Programming applied to infrastructure.

Infrastructure being treated more like software.

After he had been there for a few years, our paths crossed again.

And something was different.

The resistance I remembered was gone.

The ideas that had once been difficult to even discuss were now completely normal.

Maybe it was exposure.

Maybe the technology matured.

Maybe the tools got better.

Maybe the surrounding culture changed.

Maybe his earlier concerns were absolutely valid for the environment we were in at the time.

Probably some combination of all of the above.

Whatever the reason, it reminded me of something important:

People change.

Technology changes.

Organizations change.

And sometimes an idea that looks ridiculous in one environment becomes obvious in another.

Don't Stop Learning

That experience is one of the reasons I believe so strongly in continuing to learn even when your current environment does not give you much opportunity to use what you are learning.

If you have to build a little lab at home, build the lab.

If that turns into a mini data center in the garage, well...

Welcome to the club.

Learn Linux.

Learn Python.

Learn APIs.

Learn automation.

Learn how the network actually behaves underneath all of those tools.

Learn because you are curious.

Learn because someday the environment around you may finally catch up.

You never know when the opportunity is going to appear.

Foundation, Foundation, Foundation

The tools matter.

The code matters.

The architecture matters.

But the foundation matters more.

It is very hard to get anywhere when you have a boat full of rowers all rowing in different directions.

I am pretty sure I have even seen one guy start chewing on his oar.

Automation works best when everybody agrees on some basic truths.

Where configuration should come from.

Who is allowed to change it.

How changes are documented.

What the source of truth is.

What standards are expected.

What systems automation depends on.

What happens when reality no longer matches the template.

Without that foundation, automation becomes fragile.

And that leads to another lesson.

Defensive Programming Is Not Paranoia

Over the years, I have become much more defensive in how I write network automation.

Not defensive in the violent sense.

Defensive in the programming sense.

Check everything.

Validate everything.

Sanitize input.

Normalize data.

Verify assumptions.

Expect drift.

Expect somebody to change something.

Expect the network you saw yesterday to be slightly different today.

If an ACL is supposed to be deployed everywhere, do not assume it is.

Check.

If an interface is supposed to have a particular description, do not assume it does.

Check.

If a configuration template says one thing and the device says another, treat that difference as information.

The network is not a static database.

It is a living environment touched by people, processes, maintenance windows, vendors, outages, troubleshooting sessions, emergency fixes, forgotten exceptions, and the occasional mystery command nobody remembers entering.

The safest assumption is that assumptions expire.

That does not mean automation is pointless.

It means good automation has to account for the fact that reality moves.

You Can't Script Culture

That may be the biggest lesson of all.

You can script configuration.

You can script validation.

You can script backups.

You can script audits.

You can script reports.

You can script remediation.

You cannot script culture.

You cannot automate people into agreeing with each other.

You cannot pip install leadership.

You cannot fix a broken process with a YAML file if nobody agrees that the process is broken.

The technology still matters.

Keep learning it.

Keep building.

Keep experimenting.

Keep showing what is possible.

Just remember that the most sophisticated automation platform in the world still needs something solid underneath it.

A foundation.

A shared direction.

And preferably a crew that has agreed not to eat the oars.

I Put an AI on My Phone Line. Then Another AI Called It.

2026-09-30T00:00:00-07:00

I Put an AI on My Phone Line. Then Another AI Called It.

This project started because I wanted to play with voice again.

I have not done much with voice systems in years, and I thought it would be fun to combine some old-school telephony with newer local AI tools. What started as a simple experiment turned into a complete AI-powered IVR that can answer a real telephone call, listen to the caller, transcribe what they say, decide how to respond, generate speech, and send that audio back through the phone system.

Then something happened that I absolutely did not plan for.

Another AI called it.

And, because apparently I cannot leave well enough alone, my AI happened to sound like Duke Nukem.

Yes. That Duke Nukem.

The bubble-gum-chewing, alien-kicking video game hero of the 1990s.

Before I get to that part, though, it probably helps to explain what I actually built.

The Call Flow

The actual path of a call looks like this:

Caller
  |
  v
Xfinity Cloud / PSTN
  |
  v
Cisco ISR4351 Router
  |
  | FXO
  v
SIP Trunk
  |
  v
Asterisk 20.6.0
  |
  v
IVR Orchestrator
  |
  v
Faster-Whisper
  |
  v
Qwen 3.5 9B via Ollama
  |
  v
Coqui XTTS-v2
  |
  v
IVR Orchestrator
  |
  v
Asterisk
  |
  v
Caller

There is something I really like about this architecture.

At one end, I have the public telephone network and an analog FXO interface. That is technology with roots going back decades.

At the other end, I have local speech recognition, a large language model, and neural text-to-speech.

A telephone call comes in through Xfinity, crosses the PSTN, hits a Cisco router over FXO, gets converted into SIP, lands in Asterisk, gets handed to an application, becomes text, gets processed by an LLM, becomes speech again, and then travels all the way back out to the caller.

That is a ridiculous amount of technology involved just to say, "Hello."

And I love it.

Not Everything in the System Is AI

One thing I wanted to keep very clear while building this is that the entire system is not "AI."

There are really three AI workloads in the call path:

Faster-Whisper handles speech-to-text.
Qwen 3.5 9B handles the conversational response.
Coqui XTTS-v2 turns the generated response back into speech.

Everything else is infrastructure or application logic.

Asterisk is not AI.

The Cisco router is not AI.

The PSTN is definitely not AI.

Ollama is not the language model itself. It is the runtime serving the model.

And the IVR orchestrator is intentionally not AI either.

That part matters.

The Orchestrator Is the Traffic Cop

The IVR orchestrator is the piece that ties the whole thing together.

It coordinates the live call between Asterisk, speech recognition, the language model, and text-to-speech.

Its job is to manage things such as:

receiving audio from Asterisk
deciding when the caller has finished speaking
sending audio to Faster-Whisper
receiving the transcription
maintaining conversation state
sending the appropriate context to Qwen
enforcing rules that should not be left to the language model
sending the response to XTTS
receiving generated speech
handing that audio back to Asterisk
managing errors and timeouts

That last part is important.

There are some things I do not want to depend on the language model remembering.

For example, the system is programmed to identify the caller and provide a recording disclosure.

Those are deterministic application rules.

The LLM can handle the conversation, but the application decides what absolutely has to happen.

That separation turned out to be one of the more important lessons from the project.

Why I Needed More Than One Computer

Running a model is one thing.

Running several models quickly enough to hold a telephone conversation is something else.

Real-time voice has a deadline.

If someone says something and your system takes fifteen seconds to answer, the technology may technically be working, but the conversation is not.

Humans notice delay very quickly.

The system currently spreads the workload across several machines.

| Host | Role | |---|---| | voicertr | Cisco ISR4351 handling the Xfinity/PSTN side | | astricks | Asterisk 20.6.0 | | ai | IVR orchestrator, Faster-Whisper, Ollama, and Qwen | | babyAI | Coqui XTTS-v2 speech generation using CUDA |

This was not an attempt to build a cluster because clusters are cool.

It happened because the workload demanded it.

Speech recognition, LLM inference, and speech generation all have different compute characteristics. Once they start competing for the same CPU, GPU, memory, and storage resources, latency gets ugly very quickly.

Splitting the workloads let me keep the conversation moving.

Speech-to-Text: Faster-Whisper

The first AI component sees the caller's audio.

Faster-Whisper transcribes that audio into text.

My current configuration uses the tiny.en model with CPU inference and INT8 compute.

That might sound like the least exciting part of the system, but speech recognition is where the whole thing can fall apart immediately.

Telephone audio is not clean studio audio.

There can be:

background noise
compression
clipping
accents
people talking too quickly
people mumbling
people interrupting
silence that may or may not actually mean the caller is done

If the transcription is wrong, everything after it is working with bad input.

Garbage in, extremely confident AI garbage out.

The Language Model: Qwen Through Ollama

Once the caller's speech becomes text, the orchestrator sends the appropriate context to Qwen 3.5 9B through Ollama.

The model generates the response text.

This is where the conversational behavior lives.

But I discovered pretty quickly that a telephone conversation is very different from a normal chatbot session.

A chatbot can generate three paragraphs and nobody cares.

A voice IVR that answers every question with three paragraphs becomes unbearable almost immediately.

The responses need to be short.

They need to sound conversational.

They need to avoid rambling.

And the system needs enough context to understand the conversation without feeding it an ever-growing wall of text on every turn.

That is still one of the areas I continue to tune.

Text-to-Speech: Coqui XTTS-v2

Once Qwen generates a response, the text goes to Coqui XTTS-v2.

XTTS turns the response into speech.

This is running on a separate machine, babyAI, using CUDA.

And this is where I made a completely unnecessary but highly entertaining decision.

I cloned a voice modeled after Duke Nukem.

If you were around PC gaming in the 1990s, you probably know exactly the voice I mean.

For anyone who does not: imagine every exaggerated action-movie hero rolled into one person, given a microphone, and then told subtlety was illegal.

That was now my IVR.

And Then Rocket Mortgage Started Calling

Here is where the project became much more entertaining than I expected.

I started getting repeated calls that appeared to be from Rocket Mortgage.

I had not contacted them in years.

My mortgage is not even through them.

But the calls kept coming.

Eventually one of those calls landed on the AI IVR.

And the caller appeared to be an automated voice agent as well.

So, without intending to, I had created:

AI versus AI over the public telephone network.

My IVR was programmed to make sure it obtained the caller's name and provided the recording disclosure.

That sounds simple.

It is the sort of thing a human caller would barely notice.

But the automated caller seemed to have its own expected conversational flow.

At one point, my IVR asked for the caller's name in the middle of that flow.

And that was apparently enough to confuse the other system.

The conversation started going sideways.

My AI wanted a name.

The other system wanted to continue whatever script it was following.

Neither side behaved exactly the way the other expected.

And suddenly I was listening to two automated systems trying to negotiate control of a telephone conversation.

One of them sounded like Duke Nukem.

It was glorious.

When Two State Machines Walk Into a Phone Call

The funny part is that underneath the AI, there is a legitimate engineering lesson here.

Conversational systems still have state.

One system may expect something like:

INTRODUCTION
    ->
SALES MESSAGE
    ->
QUESTION
    ->
EXPECTED RESPONSE
    ->
NEXT QUESTION

My system has its own state:

ANSWER CALL
    ->
PROVIDE DISCLOSURE
    ->
IDENTIFY CALLER
    ->
LISTEN
    ->
TRANSCRIBE
    ->
GENERATE RESPONSE
    ->
SPEAK

Now put those two systems on the same telephone call.

Each one has goals.

Each one has assumptions about turn-taking.

Each one may be waiting for a specific kind of response.

Each one may have timeout rules.

Each one may attempt to recover when the conversation does something unexpected.

A human can usually handle an interruption such as:

"Before we continue, what is your name?"

Another automated agent may not.

That is exactly what made the call so interesting.

It was not simply two language models having a conversation.

It was two complete conversational systems, each with its own logic and expectations, colliding over a normal telephone call.

The Hard Part Is Latency

One of the biggest lessons from the project has been that conversational AI is not just about model quality.

It is about time.

The complete path looks roughly like this:

Caller speaks
    |
    v
Detect end of speech
    |
    v
Transcribe audio
    |
    v
Generate LLM response
    |
    v
Generate speech
    |
    v
Send audio back through Asterisk
    |
    v
Caller hears response

Every stage adds latency.

Even if every individual component is "fast," the delays add together.

There is also a difference between:

The model can run on this computer.

and:

The model can run fast enough on this computer to participate in a telephone conversation.

Those are not the same requirement.

This is one of the main reasons I ended up distributing the workload.

Things That Do Not Work Perfectly

This project has also been a reminder that demos are easy and systems are hard.

There are plenty of edge cases.

A few examples:

the caller talks over the AI
speech detection decides the caller is finished when they are not
Whisper mishears a word
the LLM generates too much text
TTS takes too long
audio levels are wrong
background noise creates nonsense transcription
one model consumes resources another model needs
the caller says something completely outside the expected flow
the LLM gives a response that sounds fine in text but terrible when spoken aloud
silence lasts just long enough to make the system wonder whether the call is over

None of these problems are individually shocking.

The interesting part is that they all happen in the same pipeline.

The Old Stuff Still Matters

One of the things I enjoyed most about this project was getting back into voice.

It also reminded me that modern AI does not replace traditional infrastructure knowledge.

You still need to understand:

FXO
SIP
RTP
codecs
Asterisk
routing
Linux
application state
audio handling
networking
CPU and GPU resource constraints

The AI models are only one part of the system.

If the SIP trunk is broken, Qwen cannot save you.

If the FXO interface is not working, Whisper is irrelevant.

If Asterisk cannot move the audio correctly, your fancy cloned voice is just a very expensive WAV file sitting on disk.

That is probably what I like most about the project.

It crosses a lot of different areas.

Old-school telephony.

Networking.

Linux.

Python.

Local AI.

GPUs.

Speech recognition.

Voice cloning.

And just enough ridiculousness to make the entire thing worth building.

So What Did I Actually Build?

In the end, this is not just a chatbot connected to a telephone.

It is a complete real-time voice pipeline:

PSTN
  ->
FXO
  ->
SIP
  ->
Asterisk
  ->
Application Logic
  ->
Speech Recognition
  ->
Language Model
  ->
Speech Synthesis
  ->
Asterisk
  ->
PSTN

And every part of that chain has to work quickly enough that the person on the other end still believes they are participating in a conversation.

The fact that another AI eventually called it was just a bonus.

The fact that the other AI got confused by mine asking its name was even better.

And the fact that the whole conversation happened in a cloned Duke Nukem-style voice?

That was just good engineering judgment.

Probably.

This post describes my own lab setup and my observations of calls received by the system. References to third-party companies or automated callers describe what I observed during those calls and are not claims about the internal design of those companies' systems.

Falling Asleep to Flying Toasters

2025-12-20T00:00:00-08:00

Falling Asleep to Flying Toasters

You know, screen savers used to actually matter.

I don’t mean “this looks cool while I’m away from my desk.” I mean they had a job. CRTs would burn images into the phosphor if you left something up too long. So you needed motion. Constant motion.

And somewhere along the way, someone decided that if things had to move anyway, they might as well be weird.

That’s how we ended up with screen savers that weren’t just background noise, but little moments. Stuff you noticed. Stuff you remembered.

The After Dark Era

If you had a PC in the 90s, there’s a decent chance After Dark was installed on it. Even if you don’t remember the name, you remember the visuals.

Flying Toasters are the obvious one. They’re practically shorthand for “old computer.” Chrome toasters with wings just casually floating by like that was a totally normal thing to see on an office machine.

But honestly, those were just the friendly ones.

Totally Twisted Was Something Else

The ones that stuck with me came from Totally Twisted After Dark.

I saw it running on a friend’s PC and immediately realized this wasn’t passive entertainment. Some of these screen savers wanted you involved. Others just wanted to see how uncomfortable they could make you while still technically being allowed.

There was one where people bungee-jumped from the top of the screen. Most of the time it was fine. And then sometimes… it wasn’t. Cord snaps. Splat. End of story.

Another one turned the screen into a shooting gallery. Crosshairs, ammo, mimes everywhere. It was a screen saver that dared you to touch the mouse.

And then there was the old man.

If you know, you know.

He walks across the screen in a trench coat, muttering at you. Laughing to himself. Saying things that feel like they shouldn’t be directed at a computer user. Then he stops, turns toward you, and asks if you want to know what time it is.

You do.

He opens the coat. He’s naked. Except he isn’t, because there’s a big clock covering exactly what it needs to cover. He sways back and forth and the clock moves with him, perfectly timed.

It’s dumb. It’s juvenile. It’s absolutely ridiculous.

And it made me laugh way harder than it should have.

Still does, honestly.

Fast Forward a Few Decades

Like most things, that era got boxed up by life.

Work happened. Kids happened. Time disappeared. At some point I bought the original CD, mostly out of nostalgia, knowing full well it probably wouldn’t run anymore.

It didn’t.

And for a long time, that was fine. It sat on a shelf like a little time capsule I didn’t have time to open.

Then the house got quieter. Kids moved out. Time showed up again.

And that old thought came back: I kind of want to see how this thing actually works.

Step One: Make It Run

My first instinct was to spin up Windows 95 in a VM. Easy enough, right?

I got the startup sound, which immediately sent me back to fixing PCs for a school district. That part was great.

The rest… not so much.

Crashes. Missing DLLs. Blue screens. Rebuild after rebuild, same weird behavior. I tried different ISOs, different configs, and kept getting the same results.

Eventually it clicked that nothing was corrupted. The machine was just too fast.

Modern CPUs don’t just outperform old ones — they break assumptions. Timing loops, delays, things that were never meant to run at gigahertz speeds just fall apart.

Slowing Time Down

That’s where 86Box came in.

I set it up with what felt right without really thinking about it too hard. Pentium II. A couple hundred megahertz. Enough memory to be generous, but not ridiculous.

And suddenly Windows 95 behaved like it remembered who it was.

Totally Twisted installed cleanly. The screen savers ran. Everything worked.

Which is where curiosity officially took over.

Poking at the Files

After Dark’s setup is pretty clever. There’s an engine, and then there are these .AD files that hold each individual screen saver.

Naturally, I assumed those files were packed with sprites and sounds in some extractable format.

So I did what anyone would do first — I tried the obvious tools. Resource editors. Resource Hacker. The usual stuff that cracks open a DLL and spills out bitmaps and WAVs like candy.

Nothing.

No images. No audio. No friendly resource tables. Not even junk that looked like it wanted to be something.

At that point I backed up and asked a simpler question: what are these files, really?

Using file on Linux made things clearer. These weren’t modern PE DLLs at all — they identified as NE executables, old 16-bit Windows–era files. Windows 3.x territory. That explained why modern tools were shrugging.

What surprised me was that even tools from that era didn’t help. NE-aware resource viewers still came up empty. No bitmaps. No WAV resources. No candy spilled out at all.

That’s when it really set in: these .AD files weren’t storing assets the traditional Windows way — not then, and not now.

So I stopped treating them like executables and started treating them like raw data.

When in Doubt, Use Strings

I ran strings across the files just to see what was in there.

And buried in the noise were familiar markers. RIFF. WAVE.

That was enough.

Once I had offsets, dd did the rest. No loaders. No emulation. Just raw bytes pulled straight out of the file.

And sure enough, clean WAV audio dropped out the other side.

That alone told me these files weren’t using anything like standard Windows resource storage. Whatever Berkeley Systems did here, it was custom.

Sprites Were Another Story

The visuals didn’t give themselves up so easily.

I couldn’t find anything obvious to carve out, which suggests the drawing was happening programmatically, or at least in a format that never expected to be seen outside the engine.

So instead of extracting them, I watched them.

I ended up writing a small custom application whose only job was to take pictures. No fancy automation, no deep hooks — just a way to capture frames coming off a running system reliably.

Frame by frame. Slow. Manual in the very literal sense — stitching individual sprite cells back together by hand after capture, making sure timing and alignment still felt right.

But it worked.

Closing the Loop

Once I had audio and visuals, it felt wrong to just leave them sitting in a folder.

So I wrote a very basic screen saver in VB.NET. Nothing ambitious. Just enough to display what I’d recovered and hear those sounds again without needing the original engine.

Seeing it all move again — disconnected from where it started, but still recognizable — felt like finishing something I’d left hanging years ago.

Why I Even Bothered

This wasn’t about cracking software or proving anything.

It was curiosity. And nostalgia. And wanting to understand how people snuck humor into places where no one was really supposed to be watching.

Screen savers were never meant to be serious.

And maybe that’s why they stuck with me.

A Bad Workman Blames His Tools

2025-11-03T00:00:00-08:00

For a while now, this old proverb has been stuck in my head:

“A bad workman blames his tools.”

It’s one of those lines that sounds like something your grandfather might say, but the older you get, the truer it becomes.

The Meeting That Sparked It

It happened during a logistics meeting. I was there for technical reasons — we’re preparing for what I’ve been calling a heart transplant, replacing our core systems. The talk was all about the new gear, timelines, migration paths — everything shiny and forward-looking.

Then I asked a simple question:

“Have we thought about transporting the old equipment from the rented data centers back to one of our facilities?”

The room went quiet for a moment. Then the manager — can’t really say “leader” — replied:

“Why didn’t you say that earlier?”

And there it was — that familiar feeling of the spotlight turning your way, as if responsibility suddenly shifted to you for something everyone else missed.

I don’t mind owning mistakes when they’re mine, but this one wasn’t. The budgets were locked. The plans approved. Yet somehow, I was the convenient target.

That’s when the proverb came back to me — sharp and clear.

What the Proverb Really Means

The line dates back centuries. Originally, it referred to craftsmen who blamed their hammers or chisels when their work went wrong — instead of admitting they hadn’t mastered their craft.

In tech or leadership, the tools just look different: servers, scripts, dashboards, or people. But the habit is the same — to push the fault somewhere else.

A technician might blame the software or hardware.
A manager might blame their team.
A leader might blame the system or “circumstances.”

But in every case, it’s a way of avoiding reflection.

Good workmen — and good leaders — look inward first. They ask, What could I have done differently? They sharpen the tools, train the people, or fix the process. They don’t hide behind excuses.

Reflection Over Deflection

Leadership isn’t about having all the answers; it’s about taking responsibility for finding them.

When something goes sideways, it’s easy to look for a place to land the blame. But integrity means owning your slice of it — even when it’s uncomfortable.

So whether you’re leading a team or tightening bolts on the floor, remember the old line. It’s lasted this long because it’s true:

“A bad workman blames his tools.”

And maybe, for our modern world:

“A good leader sharpens them.”

— NuX | BlogByNuX

Dave — A Masterclass in Leadership

2025-08-11T00:00:00-07:00

When I first crossed paths with Dave, we were both new hires — him stepping in as the supervisor, me coming on as the Network Engineer. It didn’t take long before I started noticing how he handled things. I’d catch myself watching, almost without meaning to, like leaning toward a porch light on a summer night without thinking about it.

I never asked where he picked it up, and maybe it didn’t matter. Whatever the case, Dave made leadership feel natural — like it was just part of who he was. He knew the big ideas, like Maslow’s Hierarchy of Needs, but it never felt like a lecture. He’d just work it into the moment, and you’d find yourself thinking, “Huh… that actually makes sense.”

Same thing with the Myers-Briggs personality types. He never pulled out a form or made us take a quiz. It was more like he kept a mental notebook, using it quietly to figure out how people ticked and what might help them get unstuck.

Even when he moved higher up the ladder, he didn’t vanish behind a wall of meetings. If you sent him a message, he got back to you. If you were drifting, he’d toss you a quick word or two to get you back on track.

Looking back now, I realize a lot of what I know about motivating people came from him — not in big “training moments,” but in little things I picked up along the way. He showed me that meeting people where they are isn’t just about patience. It’s about respect, and it’s where real progress starts.

Ode to Dave: Here’s to the leader who taught by example, inspired through action, and left a lasting mark on those fortunate enough to work alongside him.

Why SSH Works from Windows but Not Ubuntu in Proxmox + GNS3

2025-08-05T00:00:00-07:00

The Symptom

I ran into a strange issue while labbing in Proxmox with GNS3:

Windows (bare metal) could SSH to my GNS3 router without a problem.
Ubuntu (running as a VM in Proxmox) could ping the router but SSH timed out.
Both were on the same subnet and connected to the same Proxmox bridge (vmbr0).

At first glance, this made no sense. Ping worked, so Layer 3 was fine — why not TCP/22?

First Clues

Inside the Ubuntu VM:

ip neigh show

showed correct ARP resolution for the router’s MAC.

A Wireshark capture on the GNS3 side revealed:

Ubuntu’s TCP SYN packets arrived at the router.
No SYN/ACK reply was sent back.
Instead, debug ip tcp transactions on the Cisco router showed:

TCP: checksum failure <192.168.2.233,XXXXX> <192.168.2.136,22>

That was the smoking gun.

The Cause: TX Checksum Offload

The problem turned out to be TCP checksum offloading.

Modern NIC drivers (including Proxmox’s virtio) sometimes leave the TCP checksum unset, expecting the physical NIC to fill it in before sending.
In GNS3, the virtual router sees the raw packet before a real NIC ever touches it, so the checksum is wrong.
Windows’ NIC/driver stack handled this differently, so it never showed the problem.

Ubuntu’s NIC (ens18) was sending packets with invalid checksums to the router, so IOS dropped them instantly.

The Fix (Quick)

Disable TX checksum offload in Ubuntu:

sudo ethtool -K ens18 tx off

Test SSH again:

ssh admin@192.168.2.136

It should now connect without issue.

The Fix (Persistent)

Since Ubuntu now uses Netplan instead of /etc/network/interfaces, you can’t just add post-up lines.
The easiest persistent fix is a systemd service:

# /etc/systemd/system/disable-tx-offload.service
[Unit]
Description=Disable TX Checksum Offload on ens18
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K ens18 tx off

[Install]
WantedBy=multi-user.target

Enable it:

sudo systemctl daemon-reload
sudo systemctl enable disable-tx-offload.service
sudo systemctl start disable-tx-offload.service

Verify:

ethtool -k ens18 | grep tx-checksumming

It should read off.

Takeaways

If you can ping but not SSH from a Proxmox VM to a GNS3 router, check for TCP checksum failures in IOS debug.
In GNS3 environments, checksum offload can break traffic to virtual devices.
Disabling TX checksum offload on the VM NIC is a safe workaround in lab setups.

Have you run into similar odd networking issues between Proxmox and GNS3?
Drop a comment — this one took a while to nail down.

Occam’s Razor in the Real World: A Monday Morning Mystery

2025-04-09T00:00:00-07:00

It was a bright, beautiful Monday morning. All was quiet in the land… too quiet.

Since I take Fridays off, Monday mornings are my time to reacquaint myself with the monitoring tools—make sure everything’s still humming along. But this Monday, the silence was broken by a rising tide of tickets flowing into the “network” queue:

“Google Search isn’t working.”

That’s never a good start to the week.

The First Signs

As I began investigating, the volume of tickets kept increasing. A few minutes later, I got a call from the Manager who shared something interesting: this all might have started on Friday. He added me to a chat thread where the Friday coverage team had been discussing some strange behavior.

Reading through the conversation, I saw a lot of theories flying around—some complex, some wild. But one thing jumped out at me:

Occam’s Razor

The simplest explanation is often the correct one.

Clue in the Firewall Logs

I tried reproducing the issue—and succeeded. Google Search was unresponsive. DNS resolution? Fine. Internet access? Working. But something felt off.

I checked the firewall, and that’s where the mystery unraveled: traffic to Google was being denied.

Digging deeper, I found the culprit.

When "Google" Becomes a Game

The firewall's definition update service had pushed a change that reclassified the application "google". Specifically, it tagged doodles.google more restrictive category—one typically associated with games or high-risk entertainment content.

That meant, thanks to automated policy enforcement, outbound access to Google’s search services was now blocked by default under our existing rule set.

No one had manually touched the firewall rules. It was just a subtle classification change that quietly broke a critical service.

A Razor Sharp Reminder

So no, it wasn’t DNS. It wasn’t our upstream provider. It wasn’t some exotic zero-day.

It was a simple classification update and a security policy doing exactly what it was configured to do—with unintended consequences.

Occam’s Razor wins again.

Start simple. Don’t assume conspiracy when configuration is enough.

🔍 Takeaway:
When troubleshooting, especially on a Monday, don’t ignore the basics. Automated tools are powerful, but not infallible. Sometimes, the simplest answer is just hiding behind a quiet update.

Automating the Download of Old Time Radio Shows with XOJO

2025-01-05T00:00:00-08:00

Automating the Download of Old Time Radio Shows with XOJO

Growing Up Out of Era

When I was young, I remember when Old Time Radio (OTR) was on the local radio station every weekend. Listening to the best like "The George Burns and Gracie Allen Show," "Yours Truly Johnny Dollar," and "The Shadow," to name a few. These programs captured the imagination of listeners across generations.

Well, I stumbled across a website a while back that had backed up some OTR shows in MP3 format. I thought to grab a couple, but with style. That’s when I decided to create a basic downloader for these using a language called XOJO.

The Idea

The idea was simple: 1. Parse the website's HTML to extract all MP3 links. 2. Decode the filenames from their URL-encoded form (like %20 into spaces). 3. Save the MP3 files into a neatly organized folder. 4. Add error handling and a clean user interface for selecting a folder and initiating the download.

Building the `DownloadManager` Class in XOJO

To streamline downloading files in our application, we created a versatile DownloadManager class in XOJO. This class handles file downloads using XOJO's URLConnection and ensures files are saved seamlessly to the destination folder specified during initialization.

The class includes: 1. A Constructor to initialize the destination folder:



   Public Sub Constructor(destinationFile As FolderItem)
       Self.DestinationFile = destinationFile
   End Sub
Public Sub StartDownload(fileURL As String)
    Try
        ' Set request headers (optional)
        Me.RequestHeader("Accept") = "*/*"

        ' Send the request and save the file to the destination folder
        Me.Send("GET", fileURL, DestinationFile)
    Catch e As IOException
        MessageBox("Failed to download: " + fileURL)
    End Try
End Sub

Why Use `DownloadManager`?

This approach encapsulates download functionality in a reusable class, making it easier to:

Handle downloads in a structured and error-resilient manner.
Extend the functionality (e.g., logging, retries, or progress tracking).
Integrate seamlessly into larger projects.

Why XOJO?

XOJO is a fantastic tool for developing cross-platform applications quickly. Its straightforward syntax and powerful built-in libraries made it easy to handle tasks like HTTP requests and file management.

Learn More

The full source code and documentation for the downloader are available on GitHub. Feel free to explore and contribute!

Final Thoughts

This project combined nostalgia with modern technology, allowing me to preserve and enjoy these classic shows in a unique way. Whether you're an OTR enthusiast or just exploring XOJO, I hope this inspires you to create something of your own.

Happy Coding!

Mastering the Network: Seeing the Full Picture in Troubleshooting

2024-12-17T00:00:00-08:00

Introduction

In the world of network troubleshooting, perspectives can greatly influence outcomes—much like the well-known parable of the three blind men and the elephant. This story tells of three blind men who encounter an elephant for the first time, each touching a different part of the animal. One feels the trunk and declares the elephant is like a snake; another touches a leg and says it's like a tree; the third feels the side and insists it's like a wall. Each man, limited by his direct experience, believes he understands the whole elephant. Yet, none of them has the complete picture.

The Role of Bias in Network Troubleshooting

In troubleshooting, just as in the parable, personal experience and inherent biases can cloud our judgment. Confirmation bias leads us to favor solutions that align with our past experiences, potentially overlooking novel fixes or underestimating emerging issues. Limited perspective —our personal 'touch' of the elephant—can prevent us from seeing the full scope of a network problem, especially in complex environments. Emotional investment in our networks and our solutions can make it difficult to accept that a cherished methodology might be outdated or ineffective. Lastly, cognitive dissonance arises when new information conflicts with our established beliefs, causing discomfort and, sometimes, denial.

Recognizing these biases is the first step towards overcoming them. Like the blind men with the elephant, we must acknowledge that our perspective is just one part of a larger whole. We need to collaborate, share knowledge, and be open to the idea that our initial assessment may need adjustment.

Systematic Troubleshooting Steps

To ensure a comprehensive approach to network troubleshooting, following a structured methodology can help minimize the impact of personal bias:

Identify the Problem: Clearly define the issue based on user reports and your own observations.
Establish a Theory of Probable Cause: Consider all potential causes based on the symptoms, not just those you have encountered before.
Test the Theory: This step verifies your hypothesis and ensures that the theory aligns with the reality of the problem.
Plan and Implement a Solution: Develop a solution strategy that is both efficient and minimally disruptive.
Verify System Functionality: After applying the fix, confirm that the system operates as expected without introducing new issues.
Document: Keep detailed records of the problem and solution for future reference and learning.
Feedback: Communicate with all stakeholders to confirm the resolution and gather feedback for future improvements.

Divide and Conquer Technique

One effective strategy in troubleshooting is the "divide and conquer" technique. This approach involves breaking down a large problem into smaller, more manageable parts to isolate the source of the issue. By methodically eliminating segments of the network that are functioning properly, you can focus your efforts on the areas that are likely causing trouble. This technique not only simplifies complex problems but also helps in pinpointing exact issues, facilitating a quicker resolution.

To further enhance the divide and conquer approach, the OSI Model or DoD Model can be invaluable tools. These models provide a layered framework that can help systematically isolate the problem area. You can leverage these models to methodically check each layer:

Physical Layer: Verify all physical connections like cables and ports.
Data Link Layer: Check MAC address filtering, Ethernet switches, and VLAN configurations.
Network Layer: Ensure routing is intact and inspect IP configurations and subnet masks.
Transport Layer: Look at TCP connections and port numbers.
Application Layer: Check application-specific services that might impact connectivity.

For instance, if in an optimal environment you were able to ping a device but now cannot, start at the network layer and work down.

Conclusion

Mastering network troubleshooting requires more than technical skills—it demands an open mind and an awareness of our own biases. Like the blind men and the elephant, we must remember that our perspective is limited and collaboration is key. By employing structured troubleshooting methods and techniques like divide and conquer, and utilizing models like OSI or DoD for layered analysis, we can overcome biases to maintain and restore our networks more effectively.

Objectifying Cisco Network Devices in Python with Netmiko

2024-12-09T00:00:00-08:00

Managing network devices programmatically has become a crucial skill for network engineers. By objectifying network devices and their components, you can simplify operations, make your code modular, and automate tedious tasks. In this blog post, we’ll explore how to objectify a Cisco network device using Python and Netmiko, focusing on representing device storage with clear and reusable properties.

Why Objectify a Network Device?

Objectifying a network device means modeling it as a Python class that encapsulates all its properties and operations. This approach offers several benefits:

Modularity: Keep code organized and reusable.
Scalability: Easily manage multiple devices.
Maintainability: Isolate and fix issues in one place.
Extensibility: Add features without breaking existing functionality.

The Plan

We’ll create two classes:

CiscoDevice: Represents a Cisco network device and its operations.
Storage: Encapsulates storage-related properties, such as bytes_free and bytes_total.

Using Netmiko, the CiscoDevice class will connect to a Cisco device and fetch its storage information by parsing the output of the dir bootflash: command.

Implementation

Step 1: Define the `Storage` Class

The Storage class represents storage information on a network device, making it reusable and self-contained.

class Storage:
    def __init__(self, bytes_free=0, bytes_total=0):
        self.bytes_free = bytes_free
        self.bytes_total = bytes_total

    def __repr__(self):
        return f"<Storage(bytes_free={self.bytes_free}, bytes_total={self.bytes_total})>"

Step 2: Define the `CiscoDevice` Class

The CiscoDevice class handles device connection and operations, including fetching storage details.

from netmiko import ConnectHandler

class CiscoDevice:
    def __init__(self, name, ip, username, password):
        self.name = name
        self.ip = ip
        self.username = username
        self.password = password
        self.connection = None
        self.storage = None  # Will hold an instance of Storage

    def connect(self):
        """Establish a Netmiko connection."""
        try:
            self.connection = ConnectHandler(
                device_type="cisco_ios",
                host=self.ip,
                username=self.username,
                password=self.password,
            )
            print(f"Connected to {self.name} ({self.ip})")
        except Exception as e:
            raise Exception(f"Failed to connect to {self.name} ({self.ip}): {e}")

    def disconnect(self):
        """Close the Netmiko connection."""
        if self.connection:
            self.connection.disconnect()
            self.connection = None
            print(f"Disconnected from {self.name} ({self.ip})")

    def fetch_storage(self):
        """Fetch storage details from the device."""
        if not self.connection:
            raise Exception("Not connected to device")
        try:
            output = self.connection.send_command("dir bootflash:")
            if "bytes free" in output:
                # Parse the last line for storage details
                parts = output.splitlines()[-1].split()
                bytes_free = int(parts[3].strip("("))  # Extract free space
                bytes_total = int(parts[0])            # Extract total space
                self.storage = Storage(bytes_free=bytes_free, bytes_total=bytes_total)
                print(f"Storage fetched for {self.name}: {self.storage}")
            else:
                raise Exception("Failed to parse storage information")
        except Exception as e:
            raise Exception(f"Error fetching storage for {self.name}: {e}")

    def __repr__(self):
        return f"<CiscoDevice(name={self.name}, ip={self.ip}, storage={self.storage})>"

Step 3: Putting It All Together

Here’s an example script that demonstrates connecting to a device and fetching its storage details.

if __name__ == "__main__":
    # Instantiate a CiscoDevice object
    device = CiscoDevice(
        name="Router1",
        ip="192.168.1.1",
        username="admin",
        password="password",
    )

    # Connect to the device and fetch storage details
    try:
        device.connect()
        device.fetch_storage()
    finally:
        # Disconnect from the device
        device.disconnect()

    # Print the device details
    print(device)

Expected Output

Here’s what you might see when running the script:

Connected to Router1 (192.168.1.1)
Storage fetched for Router1: <Storage(bytes_free=23456789, bytes_total=50000000)>
Disconnected from Router1 (192.168.1.1)
<CiscoDevice(name=Router1, ip=192.168.1.1, storage=<Storage(bytes_free=23456789, bytes_total=50000000)>)>

Key Benefits of This Approach

Encapsulation:
- The Storage class cleanly separates storage details from the main CiscoDevice logic.
Scalability:
- Easily extend the CiscoDevice class to support additional features like fetching model, OS version, or other device-specific attributes.
Error Handling:
- Handle connection and command execution errors gracefully, ensuring the script doesn't crash.
Reusability:
- The Storage class can be reused in other contexts requiring storage information.

Final Thoughts

By objectifying a Cisco network device and its storage, we’ve created a modular and reusable framework that simplifies device management. This approach not only saves time but also reduces errors and makes your code easier to maintain.

Since we’ve now objectified the storage, we can easily run logic against it for advanced operations. For example, you could test if a new IOS file will fit on the device before attempting to upload it. This might look something like:

if device.storage.bytes_free > new_ios_file_size:
    print("Sufficient storage space available. Proceeding with upload...")
else:
    print("Insufficient storage space. Cleanup required before upload.")

This capability allows for more intelligent automation, helping you handle edge cases and reduce manual interventions.

What tasks would you like to automate next? Let us know in the comments or reach out on BlogByNuX! If you’re interested in extending this script to fetch other device details, manage configurations, or implement dynamic decision-making, stay tuned for upcoming posts.

Happy automating! 🚀

Welcome to BlogByNuX

2024-12-07T00:00:00-08:00

Welcome to BlogByNuX

Hello, and welcome to BlogByNuX!

I’m a seasoned network engineer with over 20 years of experience in designing, securing, and optimizing complex systems. My passions for technology, cybersecurity, and sharing knowledge have led me to create this blog as a platform for learning, growth, and connection.

Over the years, I’ve discovered a deep love for breaking down complex concepts into accessible insights. Whether guiding someone through troubleshooting a network issue or introducing new tools, I find joy in empowering others to tackle challenges with confidence. Teaching and mentoring have become integral to my journey, and BlogByNuX is a reflection of that passion.

What BlogByNuX is About

This blog is a space where technology, security, and life intersect. My goal is for every reader to leave with practical skills, a deeper understanding, and the confidence to tackle challenges—not just in technology and cybersecurity, but also in life.

Here’s what you can expect from BlogByNuX:

Tech Tutorials: Step-by-step guides to demystify technology.
Security Best Practices: Insights and strategies to protect yourself and your systems.
Lessons from Experience: Stories and tips from my professional journey.
Life Insights: Personal reflections on navigating life and mastering skills.

And because life is about balance, I’ll also share practical tips beyond the tech world, drawing on experiences like my journey as a certified NRA pistol instructor to offer advice on shooting techniques and firearm safety.

Who Is This Blog For?

BlogByNuX is for anyone eager to learn, including:

Tech Enthusiasts: People curious about the inner workings of technology.
Cybersecurity Beginners: Individuals taking their first steps in this exciting field.
Seasoned Professionals: Experts seeking fresh perspectives or exploring new tools.
Lifelong Learners: Readers looking for insights on topics ranging from mastering technology to improving life skills.

Why Pelican?

When choosing a platform for this blog, I went with Pelican, a lightweight and flexible static site generator built with Python. Python is a language I’m passionate about, and Pelican provides full control over my blog’s design and functionality without relying on complex backend systems.

The process of setting up Pelican was both challenging and rewarding. Configuring it with Nginx in a reverse proxy environment tested my skills, but it also deepened my understanding of web server configurations. Customizing the themes to match my vision felt like crafting BlogByNuX from the ground up, and it was an experience I thoroughly enjoyed.

What’s Next?

In the coming posts, I’ll cover topics that reflect the essence of BlogByNuX, such as:

Practical Tech Tutorials: Learn how to solve real-world problems step by step.
Cybersecurity Insights: Discover best practices and tips to stay secure in today’s digital world.
Life Skills: Gain new perspectives, whether it’s mastering technology or honing skills like firearm safety.

I don’t have a rigid posting schedule just yet, but my goal is to share meaningful, well-researched content whenever inspiration strikes. Every post will be crafted with the aim of adding value, whether you’re a beginner, an expert, or just curious to learn something new.

Thank you for stopping by, and I hope you’ll join me on this journey. If you have questions, feedback, or topics you’d like me to explore, don’t hesitate to reach out. Let’s learn, grow, and tackle challenges together—one post at a time.

Welcome to BlogByNuX!

BlogByNuX

Foundation, Foundation, Foundation

Everyone Has to Row in the Same Direction

Technology Can't Solve Every Problem

When Networking and Programming Started Dating

One Person Can Only Push So Far

Sometimes People Have Reasons You Cannot See

Then Something Changed

Don't Stop Learning

Foundation, Foundation, Foundation

Defensive Programming Is Not Paranoia

You Can't Script Culture

I Put an AI on My Phone Line. Then Another AI Called It.

I Put an AI on My Phone Line. Then Another AI Called It.

The Call Flow

Not Everything in the System Is AI

The Orchestrator Is the Traffic Cop

Why I Needed More Than One Computer

Speech-to-Text: Faster-Whisper

The Language Model: Qwen Through Ollama

Text-to-Speech: Coqui XTTS-v2

And Then Rocket Mortgage Started Calling

When Two State Machines Walk Into a Phone Call

The Hard Part Is Latency

Things That Do Not Work Perfectly

The Old Stuff Still Matters

So What Did I Actually Build?

Falling Asleep to Flying Toasters

Falling Asleep to Flying Toasters

The After Dark Era

Totally Twisted Was Something Else

Fast Forward a Few Decades

Step One: Make It Run

Slowing Time Down

Poking at the Files

When in Doubt, Use Strings

Sprites Were Another Story

Closing the Loop

Why I Even Bothered

A Bad Workman Blames His Tools

The Meeting That Sparked It

What the Proverb Really Means

Reflection Over Deflection

Dave — A Masterclass in Leadership

Why SSH Works from Windows but Not Ubuntu in Proxmox + GNS3

The Symptom

First Clues

The Cause: TX Checksum Offload

The Fix (Quick)

The Fix (Persistent)

Takeaways

Occam’s Razor in the Real World: A Monday Morning Mystery

The First Signs

Occam’s Razor

Clue in the Firewall Logs

When "Google" Becomes a Game

A Razor Sharp Reminder

Occam’s Razor wins again.

Automating the Download of Old Time Radio Shows with XOJO

Automating the Download of Old Time Radio Shows with XOJO

Growing Up Out of Era

The Idea

Building the DownloadManager Class in XOJO

Why Use DownloadManager?

Why XOJO?

Learn More

Final Thoughts

Mastering the Network: Seeing the Full Picture in Troubleshooting

Introduction

The Role of Bias in Network Troubleshooting

Systematic Troubleshooting Steps

Divide and Conquer Technique

Conclusion

Objectifying Cisco Network Devices in Python with Netmiko

Why Objectify a Network Device?

The Plan

Implementation

Step 1: Define the Storage Class

Step 2: Define the CiscoDevice Class

Step 3: Putting It All Together

Building the `DownloadManager` Class in XOJO

Why Use `DownloadManager`?

Step 1: Define the `Storage` Class

Step 2: Define the `CiscoDevice` Class