fix(kiss): default serial and usb-serial interfaces to TNC mode#449
Open
chrissnell wants to merge 1 commit into
Open
fix(kiss): default serial and usb-serial interfaces to TNC mode#449chrissnell wants to merge 1 commit into
chrissnell wants to merge 1 commit into
Conversation
A serial or usb-serial KISS interface connects to a device that IS the radio (hardware TNC, LoRa modem, radio with a built-in KISS TNC), yet it defaulted to Modem mode while tcp-client and bluetooth default to TNC. In Modem mode a hardware TNC's received frames are routed into the TX governor instead of the iGate/digi/map -- the operator sees no packets -- and TX fails with 'no backend registered for channel'. This is the recurring 'network KISS works but serial receives nothing' report. Give serial/usb-serial the same TNC default tcp-client already has: - Shared predicate configstore.KissTypeDefaultsTnc(type) drives the Mode=tnc + AllowTxFromGovernor default in dto.KissRequest.ToModel and normalizeKissInterface. - Kiss.svelte applies the same default in the UI (the UI always sends mode explicitly, so it, not the backend default, is the operative path for interactive creation). - Migration 26 (kiss_serial_tnc_default) repairs existing serial/ usb-serial rows stuck at the modem default, skipping modem-backed channels exactly as migration 20 does for tcp-client. An explicit Mode is still honored, and validateKissInterface still rejects tnc+governor-TX on a modem-backed channel, so the rare soundmodem-over-serial setup must pick Mode=modem explicitly. Go + web build and tests pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
"Network KISS works fine but serial receives nothing." Confirmed root cause: a mode-default asymmetry.
tcp-clientandbluetoothdefault to TNC mode, but serial and usb-serial defaulted to Modem. A serial/USB interface connects to a device that is the radio (hardware TNC, LoRa modem, radio with built-in KISS TNC), so Modem mode is wrong for it:no backend registered for channel.This is the same trap the LoRa-Pi reporter hit, and it explains why network (tcp-client, auto-TNC) worked while serial (defaulted Modem) didn't.
Fix
Give serial/usb-serial the same TNC default tcp-client and bluetooth already have (invariant 16b):
configstore.KissTypeDefaultsTnc(type)-- one shared predicate (true fortcp-client/serial/usbserial) now drives theMode=tnc+AllowTxFromGovernordefault in bothdto.KissRequest.ToModelandnormalizeKissInterface.Kiss.svelte-- the new-row$effectapplies the same default when the operator selects serial/usb-serial. The UI always sendsmodeexplicitly, so this is the operative path for interactive creation; the backend default is the API/programmatic backstop.kiss_serial_tnc_default) -- repairs existing serial/usb-serial rows stuck at the modem default, skipping any modem-backed channel exactly as migration 20 does for tcp-client.An explicitly supplied
Modeis still honored verbatim, andvalidateKissInterfacestill rejectstnc+governor-TX on a modem-backed channel -- so the rare legitimate "graywolf-as-soundmodem over a serial/PTY link" setup must pickMode=modemexplicitly (same tradeoff tcp-client already made).Verification
go build ./...,go vet-- cleango test ./pkg/configstore/... ./pkg/webapi/... ./pkg/app/... ./pkg/kiss/...-- pass (incl. newTestMigrateKissSerialTncDefaultand DTO serial-default cases)npm run build+npm test(463/463) -- passWiki invariant 16b updated (now covers all three hardware-TNC types, the shared predicate, and migration 26).