Improvement idea: allow disabling a KISS TNC

[kotfu]

I have a Kenwood TH-D75, which exposes a KISS TNC over bluetooth. I'm running it on a Raspberry Pi 4 running Raspbian trixie.

I you set up a KISS TNC for a serial device, and that serial device happens to be connected via bluetooth, you'll have a tty like /dev/rfcomm0. Set that up in graywolf, and it works. When you want to disconnect the bluetooth device, it's a bit messy. Graywolf wants to keep /dev/rfcomm0 open so he can keep trying to reconnect. But if the bluetooth device has gone away, ie I turned off bluetooth on the TH-D75, the operating system can't clean everything up because graywolf still has /dev/rfcomm0 open.

The only way I can see to get graywolf to close the device is to delete the KISS interface.

It would be very convenient if you could disable a KISS TNC, whether TCP Server, TCP Client, or Serial, and have graywolf close/release the devices instead of continuing to try to reconnect. That way you could leave the channels and their backers all set up, and turn them on without having to reconfigure them.

[chrissnell]

Walk me through the scenario where you would bring a BT TNC up and down?

[kotfu]

I'm running battery powered in the park with my Raspberry PI and by TH-D75 connected via Bluetooth. The Kenwood needs a battery swap, because I've been operating for 90 minutes and the battery life on that radio 😞. Want to take the TNC down so when the Kenwood loses power, the rfcomm0 device goes away with it, so when I reconnect it can be rfcomm0 again.

To be clear, I didn't test this exact scenario, I can later today. I bumped into this issue while fiddling around testing the new serial TNC support in graywolf.

[chrissnell]

Yeah, test it and see. I think even if GW closes the file descriptor, the OS might still enumerate the re-attached BT connection to a new device file. But, not 100% on that so test it and LMK what it does.

This isn't impossible to implement but adds a significant layer of complexity because the KISS stuff is happening very low in the stack. A lot of things at higher layers (like beacons, messaging, maps, etc) depend on transport layer being functional. If you disable transport, everything above it has to be made aware. It's not impossible, just can be messy and produce strange bugs.

[kotfu]

Test environment: RPi 4 using built-in bluetooth, raspbian trixie, Kenwood TH-D75 using bluetooth TNC

Prep: pair TH-D75 with RPi and trust the pairing, but do not connect the device, verify l2ping

$ bluetoothctl devices Paired
Device 40:79:12:E4:95:9D TH-D75

$ bluetoothctl devices Connected

$ sudo l2ping -c 3 40:79:12:E4:95:9D
Ping: 40:79:12:E4:95:9D from 2C:CF:67:6E:2E:BC (data size 44) ...
44 bytes from 40:79:12:E4:95:9D id 0 time 6.52ms
44 bytes from 40:79:12:E4:95:9D id 1 time 5.46ms
44 bytes from 40:79:12:E4:95:9D id 2 time 6.14ms
3 sent, 3 received, 0% loss

Use rfcomm to bind a tty to the serial service on the TH-D75

$ sudo rfcomm bind /dev/rfcomm0 40:79:12:E4:95:9D 2
$ rfcomm
rfcomm0: 40:79:12:E4:95:9D channel 2 clean

Create KISS TNC serial interface in graywolf:

$ rfcomm
rfcomm0: 40:79:12:E4:95:9D channel 2 connected [tty-attached]

We have a working bluetooth TNC.

Turn off power on Kenwood TH-D75. Then:

$ sudo l2ping -c 3 40:79:12:E4:95:9D
Can't connect: Host is down
$ rfcomm
rfcomm0: 40:79:12:E4:95:9D channel 2 closed [tty-attached]

Graywolf has the tty open and is running through it's fall-back reconnection algorithm:

Turn the TH-D75 back on. Then:

$ sudo l2ping -c 3 40:79:12:E4:95:9D
Ping: 40:79:12:E4:95:9D from 2C:CF:67:6E:2E:BC (data size 44) ...
44 bytes from 40:79:12:E4:95:9D id 0 time 6.05ms
44 bytes from 40:79:12:E4:95:9D id 1 time 6.48ms
44 bytes from 40:79:12:E4:95:9D id 2 time 6.09ms
3 sent, 3 received, 0% loss
$ rfcomm
rfcomm0: 40:79:12:E4:95:9D channel 2 closed [tty-attached]

Edit and save the KISS TNC in graywolf to force it to try and reconnect/reopen now:

rfcomm can't release the device because graywolf has the tty open

$ sudo rfcomm release rfcomm0
$ rfcomm
rfcomm0: 40:79:12:E4:95:9D channel 2 closed [tty-attached]
$ sudo lsof /dev/rfcomm0
COMMAND     PID     USER FD   TYPE DEVICE SIZE/OFF NODE NAME
graywolf  14953 graywolf 13u   CHR  216,0      0t0  703 /dev/rfcomm0
graywolf- 14986 graywolf 13u   CHR  216,0      0t0  703 /dev/rfcomm0

Once you stop graywolf, the tty is released:

$ sudo systemctl stop graywolf
$ rfcomm
$ sudo lsof /dev/rfcomm0
lsof: status error on /dev/rfcomm0: No such file or directory

[chrissnell]

Yeah, I don't dispute that this is a problem, it clearly is! I'm just not sure how much rocket surgery will need to happen to fix this properly. Needs investigation.