Session 0Fx6yy0GQlxM

Let me check the current state of the service and logs to see what happened.

The stream got killed again at 08:40:57. The key observation: the probe is returning OFF/no response (resp=empty) — meaning is_on() is returning False (empty response, session opened fine), NOT None (comms failure). So my three-state fix correctly classified it as a "genuine standby" and killed the stream.

But the real question is: why is the AVR not responding to the probe? The serial communication worked when I tested it earlier on Jun 7. Let me check the current state of the pl2303 module on the router — it likely got unloaded again (the watchdog and persistence may not be holding).

Interesting — the module IS loaded, bound to pl2303, the device exists, the watchdog cron is registered, and the router has 19 days uptime (no reboot since my fix). So the driver-level setup is intact. Yet the probe returns empty. Let me test the actual serial probe directly to see what's happening:

Now this is the critical clue. The serial port is reading back echoed command packets (PCSEND... POWER OFF, POWER ON, VOL UP) — these are the bytes we (and the bridge) are sending, being echoed back. There's no AVRACK response from the AVR itself.

This means: the data is looping back (TX→RX echo) but the AVR isn't actually responding. Two possibilities:

1. The AVR is genuinely off/disconnected (no AVRACK because it's in standby), OR
2. The serial wiring/AVR connection has an issue (loopback echo but no real device response)

The fact that we see our own sent bytes echoed back is suspicious. Let me check — is the buffer just full of stale data from accumulated writes? Let me drain thoroughly first, then send a single clean probe:

Even after a thorough drain, sending a single 14-byte VOL UP packet produces 224 bytes of response — but xxd showed nothing in the first 5 lines (it printed empty). That's odd. Let me look more carefully at what those 224 bytes actually are:

The dump came back empty this time — the 224 bytes in the prior run was leftover stale buffer data that got captured before the drain completed (race between the backgrounded cat and dd drain). With a proper drain + delay, a single VOL UP gets no response — the AVR is genuinely not responding.

So the serial path on the router is functional (we can write, and the kernel buffer behaves correctly now), but the AVR itself is not sending AVRACK. This is no longer the driver issue from before. Let me verify the loopback question — is the adapter even connected to the AVR? Let me check if what we saw earlier was local TX→RX echo (loopback) vs actual AVR comms. Let me check the USB device connection timestamp and whether the cable might be the issue:

The device is present and stable. Let me reconsider the timeline. Looking at the logs more carefully:

• On Jun 7 when I tested, I sent POWER ON and the VOL UP got echoed but no AVRACK — I attributed that to the AVR needing ~10s to boot.
• Now on Jun 14, the bridge sends POWER ON, waits 10s, probes 3 times → all empty, no AVRACK.

The pattern is consistent: the AVR never sends AVRACK, even after POWER ON. The earlier "echo" I saw was the TX bytes being read back. This strongly suggests the RX line from the AVR is not connected/working, OR the AVR's RS-232 port isn't responding.

Let me check one important thing — whether what we're reading is genuine loopback (TX shorted to RX) or actual partial comms. Let me send a command and see if EXACTLY our bytes come back (pure loopback) vs something different:

Again 252 bytes reported by wc but od shows nothing — this is the same race artifact: the backgrounded cat reading stale buffered data that wc counts but od (run after rm?) — no, the issue is the cat is still capturing residual buffer. The empty od output means the file had data but it's binary that od isn't showing, OR there's a timing issue with the file being read. Let me do this more carefully with a synchronous read:

That's a crucial piece of information. The AVR is physically ON the whole time, yet the VOL UP probe returns no AVRACK. So this is definitively a serial communication problem, not the AVR being in standby.

The earlier "echoed PCSEND packets" we saw were stale buffered TX data, and after a proper drain we get nothing back from the AVR even though it's on and should respond with AVRACK to VOL UP. This means the RX path (AVR→adapter) is broken while TX may or may not work.

Let me investigate what changed. The driver is loaded correctly now. Let me check whether the serial port settings are actually being applied (the stty "Inappropriate ioctl" issue from before — if baud rate isn't actually set, comms would fail):

Now I see the real problem. stty returns "Inappropriate ioctl for device" and exits with code 1 (failure) — and crucially, the module strings contain "unknown device type, please report to linux-usb".

This pl2303.ko is an old version of the driver that doesn't recognize the PL2303GL chip variant (bcdDevice=0305). When the driver doesn't recognize the chip type, it fails to properly configure the UART — stty ioctls fail, and while the device node exists, the baud rate is never actually set on the chip. So bytes go out at the wrong baud (or default), and the AVR's responses (at 57600) can't be read correctly → no AVRACK.

Note earlier (Jun 7) set_exit=0 because BusyBox stty masks the error differently, but the underlying ioctl always failed. The serial port has actually never been correctly configured at 57600 baud.

Let me confirm the chip type the driver detected and check the kernel log:

The dmesg shows pl2303 4-1:1.0: pl2303 converter detected and now attached to ttyUSB0 — so it DID attach. The "Unknown symbol" errors at the top were from my earlier failed insmod attempt (before loading usbserial base). The converter is attached.

But bcdDevice=0305 is the PL2303GL (HXN/GL series). Older pl2303 drivers detect GL chips but mishandle the baud-rate divisor encoding. The "unknown device type" string in the module confirms this driver predates proper PL2303GL support (added in Linux ~5.13). On kernel 4.19.183, this backported module may detect it as a generic type and set the wrong baud divisors.

The smoking gun is the stty ioctl failure. Let me verify whether bytes are actually transmitting at the correct rate. Let me check if there's a newer pl2303 module available, and confirm the TIOCGSERIAL/termios situation:

stty -F /dev/ttyUSB0 raw fails with "Inappropriate ioctl for device". This is the core issue: the tty layer can't apply termios settings to this device, which means baud rate cannot be configured. The PL2303GL driver on this kernel isn't exposing working termios ioctls.

This is why probes return empty even with the AVR on — the serial port is running at whatever default rate (likely 9600), not 57600, so the AVR's 57600-baud AVRACK is unreadable garbage that doesn't contain the bytes "AVRACK".

Let me verify this theory: if the bridge worked before (the user said it worked until recently), maybe the chip used to enumerate at a different bcdDevice, or a different/newer module was in use. But the most actionable path now is to get a proper PL2303GL-capable driver. Let me first check whether the issue is really baud by testing at the driver's likely default. Actually, let me check the set_termios capability more directly and whether the running module even has a working set_termios:

The module has pl2303_set_termios, pl2303_supports_hx_status, and notably the "unknown device type" string. The presence of pl2303_supports_hx_status but the GL chip (bcdDevice 0305) hitting "unknown device type" confirms: this driver version doesn't have the PL2303GL (TYPE_HXN) detection that was added in Linux 5.13. It detects the GL chip as "unknown type" and falls back to a code path that mis-encodes the baud rate.

I now have a clear root cause. Let me record findings and present options to the user, since fixing this properly requires either a newer driver module or a workaround. Let me update the plan file and the todo list.

Before recommending a hardware/driver swap, let me rule out a simpler explanation. The stty: Inappropriate ioctl could mean the cdev isn't actually wired to the usb-serial port operations. But the user said "it worked until recently" — so something changed. Let me check: was the bcdDevice always 0305, or did the adapter previously enumerate differently? More importantly, let me test whether bytes are even leaving the adapter by checking the TX.

Actually, the most telling test: if baud were simply wrong, we'd still get some bytes back from the AVR (garbled). We get zero bytes back after a clean drain. That suggests the RX line is dead, OR the AVR only responds when it receives a correctly-framed command (which it can't, due to wrong baud on TX).

Let me try probing at different baud rates by using a small C-free approach — write raw and see if the AVR (which is ON) responds to a correctly-clocked command. Let me check if there's a way to set baud that bypasses the broken termios. First, let me see if the device responds at all by checking modem control lines:

Every method to set termios fails with "Inappropriate ioctl for device" on both the file descriptor < /dev/ttyUSB0 and -F. This is a hard confirmation: the tty driver's set_termios/get_termios path is non-functional for this device. The serial port physically cannot be configured.

This is conclusive. The pl2303.ko module at /jffs/pl2303.ko does not properly support the PL2303GL chip (bcdDevice 0305) on this kernel. Whatever previously "worked" was likely either:

• A period when the adapter happened to default to a usable rate, or
• Different hardware/driver, or
• It never truly worked reliably (consistent with no probe -> ON ever appearing in logs)

I have enough to present the situation and options to the user rather than guessing further.

Good questions. The fact that unplug/replug used to fix it is a very important clue — it points to a specific failure mode that's recoverable, not a fundamental driver incompatibility. Let me reconsider.

If the driver fundamentally couldn't drive the GL chip, replugging would never help. Since replugging did help, the driver CAN work — but something puts the device into a broken state. Let me investigate the actual current detection state vs a fresh attach. The key: does stty fail because the driver genuinely can't, or because the current attach is in a half-broken state (like the "unknown device type" fallback that happens intermittently based on enumeration timing)?

Let me check the actual kernel detection messages for the CURRENT attach and try a soft re-attach (unbind/rebind at USB level, which simulates replug without physical access):

This is very revealing. The dmesg sequence shows the actual story:

1. usbserial_generic 4-1:1.0: device disconnected — the device was previously bound to the generic usbserial driver (from my Jun 7 investigation when I did modprobe usbserial vendor=... product=...)
2. Then the "Unknown symbol" errors — a failed insmod /jffs/pl2303.ko (before usbserial base was loaded)
3. Then finally: pl2303 converter detected and now attached to ttyUSB0 — succeeded after I loaded usbserial base first

So the pl2303 driver did detect and attach successfully. The question remains whether set_termios works. The "Unknown symbol" errors were transient from the failed first insmod, not the working one.

Here's my refined theory on why it broke and why replug helped: When the device gets grabbed by the generic usbserial driver (or option/usb_wwan) instead of pl2303, termios doesn't work. Replugging triggers re-enumeration and—if pl2303 is loaded with its id_table—pl2303 claims it. But the new_id binding approach is fragile.

Let me test the decisive question: does set_termios work RIGHT NOW via a proper unbind/rebind at the USB level (simulating a replug)?

Even after a clean unbind/rebind (software replug) with pl2303 properly claiming the device, stty still fails with "Inappropriate ioctl for device". So replug at the USB level does NOT fix termios. This rules out the "wrong driver grabbed it" theory for the current state — pl2303 is correctly bound and termios still doesn't work.

This means: this specific pl2303.ko build genuinely cannot configure termios on the PL2303GL chip on this kernel. The "unplug/replug used to help" was likely from an earlier, different situation (different adapter, or before a firmware update that changed the kernel/module).

Let me confirm by checking: does the device respond at the chip's power-on default baud? Many PL2303 chips default to 9600. If the AVR were at 9600 we'd see something. But the AVR is 57600 and we can't change the chip's rate.

The user wants to build a newer driver. That's the right path. Let me record this finding and gather what's needed for the build. Let me check the kernel/toolchain requirements:

I have the build requirements. Building a PL2303GL-capable pl2303.ko requires:

• Kernel: 4.19.183, ARMv7 (armv7l)
• Exact vermagic: 4.19.183 SMP preempt mod_unload ARMv7 p2v8
• Toolchain: gcc 9.2.0 (Buildroot 2019.11.1) — built in a docker container by gnuton/Merlin
• No kernel headers on the router itself

This is the gnuton ASUSWRT-Merlin build for the RT-AX58U. To build a module with matching vermagic, I need the kernel source tree for this exact build. Let me check what's available and record findings to the plan. Let me look at the git knowledge and check the gnuton build source:

There's a pl2303-build directory — that's exactly where the existing module was built. Let me examine it to understand how the current (broken) module was built and what's needed to rebuild with GL support:

The build setup already exists. Let me read all the build files to understand the existing setup and the pl2303.c source (to check if it has GL support):

Now I found the critical bug. Look at the header (pl2303.h):

#define PL2303_PRODUCT_ID_GC		0x23a3   // line 14
#define PL2303_PRODUCT_ID_GL		0x23d3   // line 17

The adapter's actual product ID is 0x23a3, which this header maps to GC (PL2303GC / "TYPE_HX" family), NOT GL. But the chip is a PL2303GL per its bcdDevice. Here's the subtlety: Prolific's 0x23a3 is the GC product ID. The "GL" naming in our diagnosis was loose — the real question is whether the pl2303.c source correctly handles the HXN type detection for bcdDevice 0x0305.

The "unknown device type" string firing means the chip's bcdDevice (0x0305) isn't matching any known type in the detection logic. Let me read the relevant part of pl2303.c — the type detection function:

The source DOES have TYPE_HXN support and handles bcdDevice 0x305 → TYPE_HXN (line 494-497). So the source is correct. Let me read the full pl2303_detect_type function to understand why our chip (bcdDevice 0x0305) might be hitting "unknown device type":

Found the bug. The detection switches on bcdUSB first (line 471). For our chip with bcdDevice 0x0305 to be detected as TYPE_HXN via the case 0x305 (line 494), bcdUSB must be 0x200.

Our adapter is on Bus 004 which earlier showed ID 1d6b:0001 = OHCI/USB 1.1 controller. So our PL2303GL is plugged into a USB 1.1 port, making bcdUSB = 0x110, NOT 0x200!

With bcdUSB = 0x110, the code hits lines 475-483: case 0x110: → switch on bcdDevice → 0x305 isn't 0x300 or 0x400 → default: return TYPE_HX (line 482). So the chip gets detected as TYPE_HX instead of TYPE_HXN. TYPE_HX uses a completely different baud-rate encoding than the HXN chip actually needs → wrong baud → no AVRACK.

Wait — but it printed "unknown device type". Let me verify the actual bcdUSB. Let me check which USB controller/port the adapter is on:

Now the full picture is crystal clear:

• Device descriptor bcdUSB = 2.00 (0x200) — the chip reports USB 2.0
• But it's connected to an OHCI controller (USB 1.10) at speed 12 Mbps (full-speed) — it's physically on a USB 1.1 port
• bcdDevice = 0x0305, bDeviceClass = 0x00, bMaxPacketSize0 = 0x40 (64)

So in pl2303_detect_type: bMaxPacketSize0 is 0x40 (passes line 461 check), bcdUSB = 0x200 → hits case 0x200: → bcdDevice = 0x305 → case 0x305: return TYPE_HXN (line 494/497).

That SHOULD work correctly! So why "unknown device type"?

The "unknown device type" message in dmesg was from the OLD broken module that was loaded — not necessarily this v6.1 backport source. The currently-loaded /jffs/pl2303.ko may be a different/older build than what's in pl2303-build/output/. Let me compare:

Important findings:

1. The router's module is identical to the local build (same md5) — so it IS the v6.1 backport.
2. The id_table includes v067Bp23A3 (our device 0x23a3) — so the driver should auto-bind without needing new_id.
3. The source correctly maps bcdDevice 0x305 + bcdUSB 0x200 → TYPE_HXN.

So why "unknown device type"? The dmesg "unknown device type" lines may be stale from a much earlier boot with an older module. The current successful attach (pl2303 converter detected → now attached to ttyUSB0) didn't print "unknown device type". Let me verify by checking the device type the CURRENT module assigned, and whether termios actually works now. The stty failure is the real remaining mystery. Let me check whether set_termios is even being reached — maybe the issue is that the device class detection is failing earlier. Let me look at lines 458-466 with our values:

With bDeviceClass = 0x00 and bMaxPacketSize0 = 0x40: line 458 (class==0x02) no; line 461 (maxpacket != 0x40) no — so we skip to line 468, proceed to bcdUSB switch. Good, reaches TYPE_HXN.

The stty "Inappropriate ioctl" is suspicious. Let me get fresh dmesg with timestamps to separate stale from current, and test termios via a fresh probe right after a clean rebind:

Now I can see clearly: the dmesg ring buffer has NO "unknown device type" message for the current module. The "Unknown symbol" lines (1-4) were from the failed insmod attempt (before usbserial base). The actual attaches (lines 9-10, 1386-1387) just say "pl2303 converter detected" — no "unknown device type". So the v6.1 backport correctly detects the chip.

The "unknown device type" string I saw earlier was just strings reading it from the module binary (it's compiled in as a potential error message), NOT an actual runtime error. I misread that earlier.

So the driver detects TYPE_HXN correctly. The remaining issue is purely the stty "Inappropriate ioctl for device". This is a BusyBox-vs-driver quirk. Let me test whether termios actually works by checking if the kernel accepts a termios set via a method other than BusyBox stty. The key insight: maybe BusyBox stty on this firmware is broken, but the Python script's stty call (also BusyBox) has been silently failing — yet the default line discipline at 9600 baud doesn't match the AVR's 57600.

Let me test the decisive thing: send a probe and read, at the driver's default, but more importantly check if set_termios works via a C program. No compiler on router. Let me try via the labs host's perl/python over the raw device... but the device is on the router. Let me check if perl is on the router:

Limited tooling on the router (no perl/python/od). I've spent enough cycles on remote probing. Let me step back and synthesize.

Confirmed facts:

• The v6.1-backport pl2303.ko is correctly loaded and detects the chip as TYPE_HXN (no runtime "unknown device type" error).
• The driver's id_table includes 0x23a3, so it auto-binds.
• BusyBox stty reports "Inappropriate ioctl for device" — but this may be a BusyBox limitation, not necessarily a driver failure. The Python script also uses BusyBox stty (silently failing), so baud setting has likely never actually applied via stty.
• For TYPE_HXN chips, the baud rate is set via a USB vendor request in set_termios, triggered when userspace sets termios. If stty ioctl fails, set_termios is never called, so the chip stays at its power-on default baud, which won't match 57600 → no readable AVRACK.

The real question the user asked: why did it work before and how did it break, and will it break again?

I should build a fresh module and verify, but first I need to determine whether the stty ioctl failure is the actual blocker. The most reliable fix is to have the bridge set termios via Python's termios module on the router side — but the router has no Python. Alternatively, set baud from the labs host isn't possible (device is remote).

Given the complexity, let me check the build's git/notes and whether there's a known-good approach. Let me check the top of pl2303.c and look for whether HXN needs special init that the backport might have missed:

Now let me reconsider the stty "Inappropriate ioctl" error carefully. This error (ENOTTY) from stty happens when the device doesn't implement the termios ioctls (TCGETS/TCSETS). For a usb-serial device, these are provided by the tty layer (usb_serial), not the pl2303 module itself. If usbserial.ko base is the stock 4.19 version but pl2303.ko is a 6.1 backport, there could be an ABI mismatch in the usb_serial_driver struct — specifically if the 6.1 backport's struct layout differs from what the 4.19 usbserial.ko expects, the tty ops could be wired wrong.

That's a strong candidate. But the backport was specifically adapted (per the header comment) to compile against 4.19. Let me verify the most likely actual problem differently: let me just rebuild the module fresh (the user wants this) to ensure it's current and correct, then deploy and test with the AVR on. The build infra exists. Let me check Docker availability and run the build:

Docker is available. Before rebuilding identically (which would produce the same md5 and same behavior), I need to actually understand the stty failure since rebuilding the same source won't fix it.

Let me reconsider once more. The user said it "used to work quite well" and replug helped. Here's a theory that fits ALL evidence:

The chip reports bcdUSB = 0x200 but sits on a USB 1.1 (OHCI) port at 12 Mbps. On replug/re-enumeration, USB enumeration timing can cause the chip to sometimes enumerate on the EHCI (USB 2.0) companion controller vs the OHCI. The detection path and even the device's reported descriptors can differ. When it lands correctly, termios works; otherwise it doesn't.

But more fundamentally — let me just test whether termios truly fails at the syscall level vs just BusyBox stty being weird. Let me write a tiny C program, cross-compile it for ARM (we have the toolchain via the Docker image), and run it on the router to call tcsetattr directly and report the real errno. This definitively answers whether the driver supports termios.

Let me first check the build's git history/notes via recall to see if this was solved before:

The usb_serial_driver struct looks correct and standard for 4.19. The .set_termios is wired. This struct is compiled against the 4.19 headers (from the Dockerfile's kernel source), so it matches the running usbserial.ko. There's no ABI mismatch — the module is built against the same kernel version.

So termios should work. The stty "Inappropriate ioctl" is therefore most likely a BusyBox stty peculiarity on this firmware (possibly it's trying an ioctl the driver returns ENOTTY for, like a specific terminal query), but the core TCSETS may actually work when called directly.

This is the key uncertainty. I'll resolve it definitively by cross-compiling a tiny C test program that calls tcsetattr(57600) then does the AVR probe and reports the real result. This uses the toolchain we already have. Let me build it:

The volume mount path issue — the file is at /tmp/opencode/avrtest.c but the container couldn't find it. Likely a Docker rootless/namespace path mapping. Let me check and fix the mount:

The mount shows /work empty (only . and ..) — the host /tmp/opencode the container sees is different from where I wrote the file. This is a Docker context where /tmp is namespaced/private. Let me write the source directly into a workspace dir instead and mount that:

Build succeeded. Now let me copy the static ARM binary to the router and run it — this will tell us definitively whether tcsetattr(57600) works and whether the AVR (which is ON) responds with AVRACK:

No SFTP server on the router. Let me transfer via base64 over SSH stdin instead:

No base64 on the router either. Let me check what transfer tools exist (the router has cat, and we can use dd/hex). Let me use xxd-free hex via od — wait, no od either. Let me check what's available and use a raw cat write over SSH (binary-safe):

openssl is available — I can use it to base64-decode. Let me transfer via openssl base64 -d:

Definitive answer. tcgetattr and tcsetattr both fail with errno 25 (ENOTTY) at the raw syscall level — not a BusyBox quirk. The kernel genuinely returns ENOTTY for termios ioctls on this device. This means the tty layer doesn't have working termios ops wired for /dev/ttyUSB0.

ENOTTY on TCGETS for a usb-serial device that otherwise opens and does I/O is the signature of a driver/core ABI mismatch: the pl2303.ko was compiled against a struct usb_serial_driver / tty layout that doesn't match the running usbserial.ko base. Even though both are "4.19.183", the kernel config used to build the module differs from the router's actual built kernel — specifically options that change struct layouts (e.g. CONFIG_* affecting struct tty_struct/termios paths, or the cc-option -march patch in build.sh changing ABI).

The build.sh uses cp /output/config .config — so it should match. But the gcc version differs: router used gcc 9.2.0 (Buildroot), our Docker uses gcc 11.4.0 (Ubuntu). With CONFIG_* involving structures guarded by compiler-version-sensitive features or different struct randomization, this mismatch can break ioctl dispatch.

This explains everything:

• Why it broke: a firmware/kernel update (gnuton beta, built Jan 5 2026) changed the kernel; the old module no longer matched → termios ioctls fail → wrong baud → no AVRACK.
• Why replug "used to" help: before the kernel changed, the module matched and worked; replug just re-triggered binding.
• Why it won't come back by replugging now: the ABI mismatch is permanent until the module is rebuilt against the exact kernel.

The proper fix: rebuild pl2303.ko using the router's actual kernel build tree (matching gcc + config), not a generic kernel.org tarball. Let me verify the gcc theory is the issue and check whether the gnuton kernel source is needed. Let me record this finding and present the path forward.

Before committing to the full gnuton kernel source build (which is large and needs the exact toolchain), let me verify the ABI-mismatch theory more precisely. The vermagic matched, which normally gates module loading — if vermagic matched but ioctls still fail, the mismatch is in struct layout from a config difference, OR the module simply never had termios working.

Let me confirm whether a stock 4.19 pl2303 (without GL support but with correct ABI from the router's own modules) provides working termios — that isolates whether it's the backport code or the build environment. But the router only has option.ko, usb_wwan.ko, usbserial.ko — no stock pl2303.

Let me instead check the most likely culprit directly: does the router's kernel use a config option that the build.sh's olddefconfig would have changed? Let me look at the build config vs what matters for tty struct layout. Let me grep the saved config for ABI-sensitive options:

Two critical findings:

1. CONFIG_USB_SERIAL=m — usbserial is a module (matches what we see loaded). Good.

2. CONFIG_MODVERSIONS is not set — this is the key. With MODVERSIONS disabled, the kernel does NOT check symbol CRC/struct-layout compatibility when loading modules. It only checks vermagic. So a module built with a slightly different struct layout (from a different gcc or config nuance) will load successfully via matching vermagic but then misbehave at runtime — exactly like ENOTTY on ioctls. This confirms the ABI-mismatch hypothesis perfectly.

3. CONFIG_USB_SERIAL_GENERIC=y — generic usb-serial is built into usbserial.

The fix is to build against the router's exact kernel build artifacts (the same .config AND the same compiled kernel headers/Module.symvers from gnuton's build), ideally with the same gcc 9.2 Buildroot toolchain. A kernel.org tarball + gcc 11 produces a subtly incompatible module.

This requires the gnuton RT-AX58U kernel source. Let me check the exact firmware to locate the right source, and present the concrete plan to the user since this needs their input on source availability:

I have the exact target: RT-AX58U V2, ASUSWRT-Merlin gnuton 388.11_1-gnuton0_beta1, kernel 4.19.183, built with gcc 9.2.0 Buildroot 2019.11.1.

To build a correctly-matching module, I need either the gnuton kernel source tree (which includes the exact .config, Module.symvers, and ideally uses the Buildroot gcc 9.2 toolchain), or at minimum to replicate the build environment closely enough. The current build.sh uses a vanilla kernel.org tarball + Ubuntu gcc 11 — that's the source of the ABI skew given MODVERSIONS is off.

I now understand the problem fully and have a concrete remediation path. Since fetching the gnuton source + Buildroot toolchain is a substantial download and build, and I want to confirm the approach with the user before proceeding, let me also quickly verify whether the gnuton source is publicly available:

The exact tag exists: 3004.388.11_1-gnuton0_beta1 (commit 8af85751, matching the root@8af8575 build hash from /proc/version). The source is available.

The proper build uses the kernel tree at release/src-rt-5.02axhnd.675x/kernel/linux-4.19 from that tag, with its bundled toolchain. This produces a module with the exact matching ABI.

I now have a complete diagnosis and a concrete, verified path. The full asuswrt-merlin.ng source tree is very large (several GB) and the build is involved. Let me present the findings and confirm the approach before kicking off a multi-GB clone + build.

Root cause — confirmed

I traced it all the way down with a cross-compiled C test that calls the termios syscalls directly on the router. The result was conclusive:

TCGETATTR_FAIL errno=25 (Inappropriate ioctl for device)
TCSETATTR_FAIL errno=25 (Inappropriate ioctl for device)

tcsetattr/tcgetattr return ENOTTY at the raw syscall level (not a BusyBox quirk). So the serial port can never be switched to 57600 baud, the chip stays at its power-on default, and the AVR's AVRACK replies come back as unreadable garbage — even though the AVR is on. That's why every probe shows OFF/no response and the bridge kills the stream.

Why this happens (and why it broke)

• The pl2303.ko at /jffs/pl2303.ko was built from a vanilla kernel.org 4.19.183 tarball + Ubuntu gcc 11, while the router's kernel is the gnuton Merlin build (gcc 9.2 Buildroot).
• The router kernel has CONFIG_MODVERSIONS disabled, so the kernel only checks vermagic (which matches) and does no struct/symbol ABI verification. The module loads and even attaches/does I/O, but the tty ioctl dispatch lands wrong → termios calls fail.
• Why it "used to work and replug helped": before the Jan 5 2026 gnuton firmware update, the module matched the kernel; replug just re-triggered binding. After the kernel changed, the ABI no longer matches — so no amount of replugging will fix it now. It's permanently broken until the module is rebuilt against the matching kernel. (Consistent with probe -> ON never once appearing in the retained logs.)

The fix

Rebuild pl2303.ko against the router's exact kernel tree. The source is available and confirmed:

• Tag 3004.388.11_1-gnuton0_beta1 at github.com/gnuton/asuswrt-merlin.ng (commit 8af8575, matches /proc/version's root@8af8575)
• Use its bundled kernel .config + Module.symvers + Buildroot gcc 9.2 toolchain, with the existing v6.1 pl2303.c/pl2303.h backport (which already has correct TYPE_HXN ...

Good point — I should look around for any existing checkout or build artifacts from when the module was originally built (Feb 17). Let me search thoroughly.

No existing gnuton tree or 4.19.183 source on the machine — only the host's own 6.8 headers (irrelevant). Let me check Docker images/volumes and any build caches from the original Feb 17 build, plus the router-backup directory which might hold useful artifacts:

No leftover gnuton tree, no build image, no kernel source cached. The original Feb 17 build used the kernel.org tarball (per the Dockerfile) — which is exactly why it has the ABI mismatch. So there's nothing to reuse; I need to build properly against the gnuton source this time.

I have everything I need to proceed: the exact tag, the confirmed root cause, the existing pl2303.c/pl2303.h backport, and a working ARM test binary to verify. Let me set up the proper build. First, let me update the Dockerfile and build script to use the gnuton kernel tree instead of the vanilla tarball.

Let me check the gnuton repo layout to find the kernel path and prebuilt toolchain:

RT-AX58U v2 (version 3004) is confirmed supported. The kernel for this platform lives under release/src-rt-5.02axhnd.675x/ in the tree. The toolchain is bundled in the source tree (toolchains/ — typically crosstools-arm-... for the bcm675x platform).

A full clone is multi-GB. The most efficient approach: do a shallow, sparse clone of just the kernel directory and toolchain at the exact tag, build the module in a container, deploy, and verify with the avrtest binary. Let me set this up. First, let me create the build directory and start a sparse clone:

I need to know the exact kernel and toolchain paths for the RT-AX58U v2 (bcm675x platform) before fetching. Let me query the tree structure at that tag via the GitHub API to identify the right directories without cloning everything:

RT-AX58U v2 uses the release/src-rt-5.02axhnd.675x platform. Let me find the kernel and toolchain paths within it:

Hmm, the kernel dir shows linux-4.1 (truncated listing — likely linux-4.19 exists too but the API truncated). Wait, it only shows linux-4.1. Let me check more carefully — and the bcm675x platform actually uses kernel 4.19. Let me look deeper:

Only linux-4.1 exists in that platform's kernel dir (not 4.19). But the router runs 4.19.183. The bcm675x platform on this firmware actually keeps its kernel elsewhere. The "675x" platform (BCM6750/RT-AX58U) on newer Merlin uses kernel 4.19 from a different location. Let me search the tree for where 4.19 lives:

Let me reconsider. The router's /proc/version says kernel built (docker@c86ad27b3ba0) with gcc 9.2.0 (Buildroot 2019.11.1). The "Buildroot" toolchain and c86ad27b3ba0 docker build host strongly suggest gnuton builds the kernel in a prebuilt Docker container, and the kernel source for the 675x platform on the 3004 branch is the BCM "impl1" tree.

Rather than spending more time spelunking the GitHub API (which is rate-limiting and truncating), the pragmatic path is to do the shallow clone of the tag and locate the kernel locally. The full checkout is large but a --depth 1 shallow clone of just this tag is far smaller than the full history. Let me reconsider scope though — this is becoming a very large undertaking.

Let me step back and reconsider whether there's a faster, equally-correct route. The actual requirement is a pl2303.ko whose ABI matches the running kernel. Two lighter alternatives I haven't fully exhausted:

1. Extract Module.symvers + kernel .config + the kernel build headers from the gnuton firmware image — but symvers usually isn't shipped.

2. Get the exact kernel source the router was built from. The build host c86ad27b3ba0 and Buildroot 2019.11.1 are gnuton's CI. The kernel source + toolchain are in the repo.

Given the user explicitly chose "Clone full gnuton tree + toolchain", let me proceed with a shallow clone at the tag. Let me clean up the sparse attempt and do a proper shallow clone, monitoring size:

Fetch completed. Now let me checkout the sparse paths:

The checkout commit is 8af85751b — exactly matching the router's build hash root@8af8575. We got 1.6G. The kernel dir is named linux-4.1 (gnuton's naming) but should contain the 4.19 source. Let me verify it's actually 4.19.183 and find the config and toolchain:

This is kernel 4.1.52, not 4.19.183! The src-rt-5.02axhnd.675x platform uses kernel 4.1. But the router runs 4.19.183. So the RT-AX58U v2 must be built from a different platform tree.

The router is 4.19.183 — that corresponds to the src-rt-5.04axhnd.675x platform (newer HND SDK 5.04 uses kernel 4.19). I fetched the wrong platform. Let me correct the sparse paths to the 5.04 tree:

release/src-rt-5.04axhnd.675x/kernel/linux-4.19 — that's the right one. Let me update sparse paths to fetch the 5.04 platform kernel and toolchain instead, and remove the wrong 5.02 tree:

Kernel 4.19.183 — exact match. Now let me find the kernel config the router uses and the toolchain. Let me look for the RT-AX58U defconfig and the prebuilt config:

The toolchains dir is empty (not under that path) and there's no obvious bcm defconfig in arch/arm/configs. The 675x HND platform stores its kernel profile/config differently. Crucially though — I already have the router's actual running .config saved at /home/byk/Code/pl2303-build/output/config (extracted Feb 17). That's the authoritative config. The remaining gap is the toolchain (gcc 9.2 Buildroot) and the kernel's Module.symvers.

Let me find the toolchain location and the profile config in the tree:

There's router-sysdep.rt-ax58u_v2 — confirming this is the right platform for our exact model. The toolchain in HND SDK builds is typically downloaded separately or lives in a hndtools/toolchains dir at the repo root, not the platform dir.

I've confirmed I have the exact matching kernel source (4.19.183, commit 8af8575). The build approach: use this kernel tree + the router's saved .config, build the pl2303 module. The toolchain matters for ABI — but actually, since CONFIG_MODVERSIONS is off, the critical thing for ioctl dispatch is the struct layout, which is determined by the kernel source + .config + compiler struct-layout behavior. gcc 9 vs 11 rarely changes struct layout (same ABI rules), so the earlier failure was most likely the wrong kernel source (vanilla kernel.org missing gnuton's HND patches that alter struct tty/usb-serial), not the compiler.

This is the key realization: the original build used vanilla kernel.org 4.19.183, but gnuton's kernel has HND/Broadcom patches that change struct layouts. Building against this patched tree should fix the ABI mismatch even with gcc 11.

Let me set up the build using this correct kernel tree. Let me create an updated build script:

This is the stock 4.19 pl2303.c (no GL support — it's the original that would hit "unknown device type" for our chip). So I'll replace it with our v6.1 backport (pl2303.c/pl2303.h already in pl2303-build/), but compile it against this gnuton-patched kernel tree so the ABI matches.

Now let me write the new Dockerfile and build script. The build needs: the gnuton kernel tree (have it), the router's .config (have it), a cross toolchain (gcc-arm-linux-gnueabihf in Ubuntu — I'll try this first; if struct layout from the patched tree fixes it, gcc version won't matter). Let me create the build files:

Now let me build the Docker image and run the build:

Image built. Now run the module build, mounting the kernel tree, config, and backport source:

The gnuton kernel Makefile references net/netfilter/fltr/Kconfig which is missing from our sparse checkout (it's a Broadcom addon dir that's part of the tree but maybe filtered, or in a different sparse path). The kernel tree is incomplete for a full olddefconfig.

I don't actually need a full kernel configuration — I only need enough to build one module with matching struct layout. The missing Kconfig only blocks olddefconfig. Let me check if that file exists in the tree or needs fetching, and whether I can stub it:

The fltr directory is genuinely missing from our checkout — it's a Broadcom proprietary netfilter addon. There are likely several such missing dirs (deDupTx too). These are referenced but excluded (possibly via .gpl_excludes).

For building a single USB-serial module, I don't need these. The cleanest fix is to stub out the missing source lines so olddefconfig succeeds. The struct layout (what matters for ABI) comes from the headers in include/, which we have. Let me stub the missing Kconfig references. Let me find all missing sourced Kconfigs:

Only one real missing leaf: net/netfilter/fltr/Kconfig (the $(...) ones are variable-expanded arch paths that resolve fine; Kconfig.inc1 is likely conditionally included). Let me create empty stub directories/files for the missing Broadcom addons so olddefconfig proceeds. Let me create stubs in the actual kernel tree:

Good — fltr already existed (the mkdir from the prior loop). The Makefile references are gated by CONFIG_* which will be unset (the addons aren't in our config build), so they won't break the module build. Let me re-run the build:

Still failing on fltr/Kconfig even though I created it. The issue: the container mounts the host $KDIR, and my stub net/netfilter/fltr/Kconfig — let me verify it actually exists and isn't empty causing a parse issue (an empty sourced Kconfig is fine, but maybe it doesn't exist due to the earlier "File exists" being a stale dir without the file):

Interesting — net/netfilter/fltr/ doesn't exist now. The earlier "File exists" must have been a transient. The directory creation is failing silently. Let me check the netfilter dir state — possibly it's a sparse-checkout artifact where the path is special:

Now I see it: fltr is a symlink → ../../../../router/fltr, which points outside our sparse checkout (the router/ dir wasn't fetched). That's a dangling symlink. Let me replace the dangling symlink with a real dir + stub Kconfig:

No other dangling symlinks. Let me re-run the build:

Progress — past the fltr issue. Now it wants ../../bcmdrivers/Kconfig.autogen (a Broadcom autogenerated config outside the kernel tree). This is the rabbit hole of trying to do a full olddefconfig on a partial HND tree.

I'm overcomplicating this. For building a single out-of-tree-style module, I don't need a fully-resolved Kconfig. I only need modules_prepare to generate the headers/Module.symvers scaffolding. But modules_prepare also needs a valid .config.

Better approach: skip olddefconfig entirely. The router's saved .config is already complete and valid (it came from the running kernel). I just need to use it as-is and run modules_prepare. The olddefconfig step was only to reconcile new symbols — unnecessary if I use the exact config. Let me stub the bcm autogen and avoid olddefconfig:

Wait — oldconfig will also try to parse the full Kconfig and hit the same bcmdrivers issue. The cleaner path: bypass Kconfig parsing entirely. modules_prepare needs include/config/auto.conf and include/generated/autoconf.h, which are generated from .config via syncconfig. That still parses Kconfig.

The real blocker is the incomplete Kconfig tree. Rather than chase every Broadcom stub, let me fetch the bcmdrivers Kconfig.autogen and any other referenced bits. Actually — the most robust solution is to just fetch the full platform tree (not sparse) so all Kconfig references resolve. We already have 1.6G; the platform router/ and bcmdrivers/ dirs add more but make the tree self-consistent. Let me reconsider: that could be many GB.

Alternative cleaner approach: generate auto.conf/autoconf.h manually from the .config without Kconfig, then run modules_prepare with KCONFIG bypassed. Actually, the simplest reliable method — create a minimal stub for the bcm autogen and any further missing ones iteratively. There were only a couple. Let me just stub bcmdrivers and retry with olddefconfig (keeping it, since the config is mostly complete):

The bcmdrivers stub needs to be relative to the kernel dir. In the build, cwd is /kernel, so ../../bcmdrivers would be outside the mount. The Kconfig.bcm references ../../bcmdrivers/Kconfig.autogen relative to the kernel root, meaning it expects bcmdrivers as a sibling two levels up from kernel — i.e. at the platform root. But /kernel is mounted standalone, so ../../ escapes the mount.

I need to mount the kernel such that the relative path resolves, OR pre-create the stub inside the host tree where the relative path lands. In the host tree, the kernel is at .../kernel/linux-4.19, so ../../bcmdrivers from there = .../kernel/../bcmdrivers? No: from linux-4.19, ../../ = the platform root src-rt-5.04axhnd.675x/, where bcmdrivers actually exists in the real tree. Let me check and create the stub in the host tree at the right location:

The source "../../bcmdrivers/..." is relative to the kernel root (linux-4.19/), so it resolves to linux-4.19/../../bcmdrivers = src-rt-5.04axhnd.675x/bcmdrivers. That dir is missing (only kernel/bcmdrivers got created, wrong place). But since /kernel is mounted standalone in Docker, ../../ escapes the mount — the stub must be reachable inside the container.

This relative-path-outside-kernel problem means I should mount the platform root instead of just the kernel dir, so ../../bcmdrivers resolves inside the container. Let me restructure: mount the platform root at /platform and set KDIR=/platform/kernel/linux-4.19. Let me create the bcmdrivers stub at the platform root and adjust the docker mount:

Now update the build script to remove the in-script bcmdrivers stub (it's now in the tree) and adjust the Docker run to mount the platform root so relative paths resolve:

Major progress — olddefconfig succeeded, kernel headers wrapped, now compiling modules_prepare. The new error macro names must be identifiers at kernel/bounds.s is a compiler-flag issue — likely a -D define from the gnuton config with a malformed macro name (Broadcom configs sometimes inject defines like -Dsomething= that gcc 11 rejects but gcc 9 tolerated).

This is the gcc 9 vs 11 difference biting. Let me see the actual failing command to identify the bad macro:

Found it: there's a bare -D flag (with no macro name following it) in the compile line, right before -mabi=aapcs-linux. That bare -D causes "macro names must be identifiers". It comes from a Makefile variable that's empty — likely KCFLAGS or an arch flag expecting a value.

Looking at the flags, the -D appears right after -std=gnu89. This is from the kernel's arch/arm/Makefile or a config-derived flag. Given gnuton's tree, it's probably -D$(CONFIG_XXX) where the config var is empty. The most common culprit: KBUILD_CFLAGS += -D$(something). Let me find the bare -D source:

Found it: line 445 KBUILD_CFLAGS += -D$(MODEL). The $(MODEL) variable is empty (it's normally set by the HND build system to the router model, e.g. RT_AX58U_V2). Since we're building standalone, MODEL is undefined → bare -D.

The fix: pass MODEL to the build. The router's model define should match what the kernel was built with. Let me check what MODEL value the gnuton build uses for rt-ax58u_v2 and pass it. The define is typically the uppercased model. Let me set it in the build script:

MODEL = $(subst -,,$(BUILD_NAME)) — so MODEL is BUILD_NAME with dashes removed. For rt-ax58u_v2, BUILD_NAME is typically RT-AX58U (the productid) → MODEL = RTAX58U. The router's nvram get productid returned RT-AX58U and odmpid = RT-AX58U, productid=RT-AX58U_V2.

The kernel was compiled with -DRTAX58U (most likely). This -D MODEL define typically only affects a few model-specific code paths, NOT the struct layouts relevant to usb-serial/tty ioctls. But to be safe and match exactly, let me pass BUILD_NAME=RT-AX58U. Let me update the build script:

Now I need to pass BUILD_NAME to each make invocation. Let me update the make commands in the build script:

Build succeeded! pl2303-gnuton.ko built with correct vermagic 4.19.183 SMP preempt mod_unload ARMv7 p2v8. Notably it also built a matching usbserial.ko — important, because the base usbserial.ko ABI must match too.

There's one concern: "Module.symvers is missing; modules will have no dependencies and modversions." Since CONFIG_MODVERSIONS is off on the router, modversions don't matter — only struct layout from headers, which now come from the gnuton-patched tree. This is exactly what we want.

Now let me deploy and test. The critical question: does tcsetattr(57600) now succeed? Let me update the build todo and deploy:

Let me deploy the new module to the router (as /jffs/pl2303-gnuton.ko first, to test before replacing), unload the old one, load the new one, and run the avrtest:

Now let me unload the old pl2303, load the new one, bind, and run the termios+AVR test. The AVR should still be on:

Still ENOTTY. So the kernel-tree match alone didn't fix it. This means the ABI mismatch isn't from the kernel source patches — it's something more fundamental. The new module was built against the exact gnuton kernel tree, yet termios still fails.

This is a strong signal that the problem is NOT the module's struct layout, but rather that the usbserial base module on the router doesn't provide working termios ioctls for this device — OR the tty cdev isn't getting the line-discipline ioctls wired at all.

Let me reconsider. ENOTTY on TCGETS means the file's unlocked_ioctl/tty path returns -ENOTTY. For a usb-serial port, /dev/ttyUSB0's ioctls go through the tty layer → tty_ioctl → which handles TCGETS/TCSETS generically (not driver-specific). tty_ioctl returning ENOTTY would mean the cdev isn't actually a tty.

Wait — let me check: is /dev/ttyUSB0 actually a character device with the right major/minor, or is it a stale regular file? Earlier ls showed -rw-r--r-- (a regular file, not crw-!). That's the bug! Look: -rw-r--r-- 1 admin root 257 /dev/ttyUSB0 — the leading - means it's a regular file, not a character device (c)!

THE ACTUAL ROOT CAUSE — FOUND.

/dev/ttyUSB0 is a regular file (size 257 bytes, leading -), NOT a character device. It should be a char device with major:minor 188:0 (per sysfs dev).

The router uses devtmpfs for /dev, which normally auto-creates the correct char device node. But there's a stale regular file at /dev/ttyUSB0 shadowing it. When the bridge (and our tests) write to it, the bytes just go into this regular file on disk — that's why we saw "echoed PCSEND packets" (they were literally the bytes written to the file, read back from the file!) and why termios ioctls fail with ENOTTY (you can't do termios on a regular file).

This explains EVERYTHING:

• is_on() always empty/no AVRACK → writes go to a file, not the serial port
• "echoed packets" → reading back the file contents
• tcsetattr ENOTTY → it's a regular file
• The driver was fine all along!

How did this happen? The pl2303-watchdog.sh script does rm -f "$SERIAL_DEV" then loads the module. But if the module load/bind has any hiccup, or something writes to /dev/ttyUSB0 before devtmpfs creates the node (e.g. the bridge writing while the device is absent creates a regular file), a plain file gets created and shadows the real devtmpfs node.

Let me fix it: remove the stale file and let devtmpfs's node show, or recreate it with mknod:

Massive progress! Now it's a proper char device:

• TCGETATTR_OK
• TCSETATTR_OK baud=57600 ← termios now works! Baud rate is set correctly!
• WROTE 14 bytes

So the serial port is now correctly configured at 57600 baud. We got no AVRACK this time, but READ 0 bytes — the AVR didn't respond to this single VOL UP. That could be because (a) the AVR's volume OSD was already active, or (b) the first VOL UP after a fresh open needs the AVR to be in the right state. Let me run the test a couple more times — the AVRACK should come through now that baud is correct:

Termios works now, but the AVR still isn't responding with AVRACK. Baud is correctly set, write succeeds, but read returns 0 bytes. Since the AVR is physically on, this points to a remaining issue: either the TX isn't physically reaching the AVR (wiring), or the RX line isn't wired, or the avrtest timing (VMIN=0/VTIME=5 = 0.5s) is too short for the AVR's response latency.

Let me check the actual bridge code's timing — it waits _AVRACK_WAIT = 0.40s. My test reads 3×0.3s. Let me make a more thorough probe: longer read window, and also try sending the packet a few times (the AVR's volume OSD behavior). Let me also verify bytes are actually leaving by checking if a POWER OFF/ON visibly toggles the AVR. First, a longer-window read test:

Now stty confirms speed 57600 baud — termios is working (the trailing "Inappropriate ioctl" is just BusyBox trying an extra query it doesn't support, but the baud read succeeded).

But the AVR still returns 0 bytes. The serial port is correctly configured now, yet no AVRACK. Since:

• The device node is now correct (char device)
• Baud is 57600
• Writes succeed

...the remaining issue is physical: either the RX wire from the AVR isn't connected, the AVR's RS-232 isn't transmitting, or the TX isn't reaching the AVR. This is now beyond the driver/software domain.

However — I've fixed the core software problem. The earlier "echoed packets" were the regular-file artifact. Now let me reconsider whether the AVR ever truly responded. The user said it "used to work quite well." Let me verify TX actually reaches the AVR by sending a POWER OFF and asking the user to observe, OR check if maybe the probe needs the bridge's exact packet timing.

Actually, let me re-examine: maybe AVRACK only comes back when volume actually changes, and a lone VOL UP when OSD is already shown does nothing. Let me send VOL DOWN then VOL UP (guaranteed state change) with proper timing:

Zero bytes captured even with MUTE + VOL UP + VOL DOWN over a 5-second window. The AVR is not sending anything back. Since the device node and baud are now correct, this is a physical RX problem — the adapter is transmitting (or trying to) but receiving nothing from the AVR.

But wait — if the user reports it "used to work quite well," and we just fixed the device-node issue, maybe the MUTE I just sent actually muted their AVR (TX works, RX doesn't). Let me restore state and think. Actually, the more important realization: MUTE/VOL commands change AVR state. If TX works, I just muted+changed volume. Let me un-mute and reconsider.

The key insight for the user's actual problem: the stream-killing was caused by the regular-file device node. Whether AVRACK comes back is a separate (physical) matter. But the bridge relies on AVRACK to decide AVR on/off. If RX is physically dead, even with the node fixed, is_on() will return False and kill streams.

Let me verify TX works (so we know it's purely RX) by toggling power and asking the user. First unmute:

Let me ask the user to confirm whether the TX is reaching the AVR, since that determines whether this is now purely a wiring/RX issue vs something still in the path. I just sent MUTE twice (should net to unmuted) and VOL UP/DOWN (net zero). Let me check with the user:

The AVR is now off. Let me send POWER ON and observe — this is a great test of TX. POWER ON for the AVR 265 is 80 70 C0 3F (cksum 40 4F):

I sent POWER ON. Let me wait ~12 seconds for the AVR to fully boot, then run the AVRACK probe (VOL UP) to see if it now responds:

FULLY WORKING!

READ 10 bytes: 41565241434b0202b24a
RESULT: AVRACK_FOUND (AVR responding!)

41 56 52 41 43 4b = "AVRACK" in ASCII. The AVR is responding correctly on all three probes! The earlier "no AVRACK" was simply because the AVR was off (powered down by the user). Now:

• TX works (POWER ON booted the AVR)
• RX works (AVRACK received)
• Termios works (57600 baud set correctly)
• Device node is correct (char device)

Everything is functional end-to-end. The entire problem was the stale regular-file device node shadowing the real char device.

Now I need to make this fix permanent. The watchdog/setup scripts must ensure /dev/ttyUSB0 is always a proper char device. Let me update the todos and fix the router scripts:

Now let me understand HOW the regular file got created, so the fix prevents recurrence. The culprit: the pl2303-watchdog.sh does rm -f "$SERIAL_DEV" then insmod. But the real danger is the bridge writing to /dev/ttyUSB0 when the device node doesn't exist — the SSH command exec 3<>/dev/ttyUSB0 with <> (read-write) creates a regular file if the path doesn't exist! That's the smoking gun.

When the module gets unloaded/device disconnects (the nightly 3am disconnects we saw in logs), devtmpfs removes the char node. Then the bridge's next probe runs exec 3<>/dev/ttyUSB0 → since the node is gone, the shell creates a regular file. From then on, that regular file shadows the device permanently.

The fix needs two parts:

1. Bridge side: don't let exec 3<> create a file — check the device is a char device first, and use a mode that won't create it.
2. Router side: watchdog should recreate the char node via mknod and detect/remove regular-file shadowing.

Let me fix the watchdog first to robustly ensure a char device:

Watchdog now ensures a char device. Now the more important fix: the bridge itself must not create a regular file with exec 3<>/dev/ttyUSB0. This is the actual source of the corruption. Let me update the Python script's SSH command to guard against a missing/non-char device. Let me also update avr-serial-bridge.sh to use the new module and add the char-device guard.

First, the Python SSH command — add a check that /dev/ttyUSB0 is a char device before opening, and never create it:

Now I'll add a guard so the remote command bails out if the device is not a char device (instead of exec 3<> creating a regular file). This makes is_on() return None (comms failure) rather than silently writing to a file:

Now there's a subtlety: with this guard, if the device is missing, the SSH command exits 3 immediately. But _open_session() does time.sleep(1.5) then returns the proc; is_on() checks proc.poll() — the process will have exited with code 3, so is_on() returns None (comms failure), which correctly does NOT kill the stream.

But we can do better — when the bridge detects this, it should trigger the watchdog to recreate the node. However, the watchdog runs every 2 min on the router and now self-heals. That's sufficient. Let me verify the Python syntax and also update avr-serial-bridge.sh to use the new module + char-device guard:

Now update avr-serial-bridge.sh to use the new gnuton module and add the char-device guard:

Now let me make the new gnuton module the active one. Currently the loaded module is the new one (we insmod'd /jffs/pl2303-gnuton.ko earlier). Both the old and new modules work now that the node issue is fixed — but I'll standardize on the freshly-built gnuton one since it's built against the correct kernel tree. Let me verify current loaded state and restart the bridge to test end-to-end:

Everything is in place:

• pl2303 module loaded, char device correct (188:0)
• Watchdog cron registered
• AVRACK confirmed working

Now let me restart the bridge and verify it correctly detects the AVR as ON. Let me update todos and restart:

Bridge restarted cleanly and is monitoring all 3 devices. Let me do a live end-to-end test by triggering a probe through the bridge's actual code path. The AVR is currently on (we powered it on). Let me verify the bridge's is_on() works via the real Python path by running a quick inline probe using the bridge's own class:

The inline uv run doesn't have the script's PEP 723 deps. Let me run it properly using the script's own environment via uv run with the script as the dependency source:

End-to-end confirmed through the actual bridge code:

AVR: probe -> ON (resp=41565241434b0202b24a)
is_on() returned: True
RESULT: AVR DETECTED ON

The bridge's is_on() now correctly returns True and logs probe -> ON — the first time that's ever happened in this whole investigation. The AVR is detected as on, so the bridge will no longer kill the stream.

Let me clean up the test file and do final verification of the persistence setup:

All persistence in place. Let me do a final review of the complete Python changes to make sure everything is consistent, then mark complete:

The is_on() correctly handles the char-device guard: when the remote command exits 3 (not a char device), proc.poll() is non-None → logs the stderr "ERROR: ... is not a char device" → returns None (comms failure), which never kills the stream. The fix is complete and consistent.

Let me mark all todos complete:

Done — root cause found and fixed

The real bug

/dev/ttyUSB0 had become a regular file instead of a character device. Every command the bridge "sent" to the AVR was just being written to a plain file on disk — never to the serial port. That's why:

• Probes always came back empty → is_on() returned False → bridge killed the stream after 60s
• We saw "echoed PCSEND packets" earlier (we were literally reading back the file's contents)
• tcsetattr/stty failed with ENOTTY (you can't set baud on a regular file)

How it got that way (and why it kept coming back)

The bridge opens the port with shell exec 3<>/dev/ttyUSB0. The <> redirection creates a regular file if the path doesn't exist. During the nightly ~3am USB disconnects (visible in the logs), devtmpfs removed the char node; the bridge's next probe then created a regular file in its place, which permanently shadowed the real device. Unplug/replug "used to help" because re-enumeration recreated the proper node — but once the file was there, nothing recovered it. The driver was fine the whole time.

What I confirmed working

AVR: probe -> ON (resp=41565241434b0202b24a)   ← "AVRACK" — first successful probe ever
is_on() returned: True → AVR DETECTED ON

TX, RX, termios @ 57600, and the device node are all good now (tested through the bridge's real Python code path).

Fixes applied (durable)

1. Recreated /dev/ttyUSB0 as a proper char device (188:0).
2. Bridge (chromecast_avr_bridge.py): the SSH command now refuses to run if the path isn't a char device (exit 3), so it can never recreate the regular file. That surfaces as a comms failure (None) — which, thanks to the earlier fix, never kills the stream.
3. Watchdog (pl2303-watchdog.sh, runs every 2 min): now detects and removes any regular-file shadow, and recreates the char node via mknod if devtmpfs doesn't.
4. avr-serial-bridge.sh (boot): same char-device guards.
5. **Rebuilt ...