search

wb2osz / direwolf

Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate). For more information, look at the bottom 1/4 of this page and in https://github.com/wb2osz/direwolf/blob/dev/doc/README.md
GNU General Public License v2.0
1.58k stars 306 forks source link

Enhancement: Automatic FX.25 TX activation only if incoming connection sends FX.25 #356

Open piemmm opened 3 years ago

piemmm commented 3 years ago

Use case:

I run a BBS, using direwolf to process the audio Users may be using plain old TNCs or direwolf themselves. I don't want to enable FX.25 TX by default as it effectively halves the channel bandwidth, therefore direwolf is set to receive FX frames (its default), however this means that I never transmit FX.25 packets when I know a connecting station supports it. If a station requires FX.25 to make a reliable connection, then I would like them to be able to use it both ways effectively

Thanks

dranch commented 3 years ago

The challenge here is that you're asking for some sort of MODEM negotiation capabilities. AX.25 v2.1 vs. v2.2 does this via the SABM vs. SAMBE connection flag and there is a bit of control via direwold.conf's "MAXV22" feature but that's on a callsign by callsign basis. FX.25 is a layer down in the stack and currently isn't very configurable today (it's on or off only at the moment). I wonder if something like an RSID ( http://www.w1hkj.com/RSID_description.html ) preamble could be sent before the SABM packet to communicate the desire or requirement of FX.25. This really isn't the purpose of RSID but maybe something could be created that wouldn't interfere / confuse legacy TNCs. This method could also be considered for the new IL2P mode in Direwolf as well.

piemmm commented 3 years ago

Yep, though it should be possible to do relatively transparently as you already can identify FX packets, therefore you should not need to doctor any frames, so it should just be a case of:

'Oh! This station sent an AX25 frame with the FX bit at the end, so it must be FX capable' and 'It's making a connection, so for this station we'll enable FX replies'

You might not even need to track the connection state - if the station is sending FX payloads at the end of the packet, then you could simply enable FX replies to it for a specified time, until it goes away

wb2osz commented 3 years ago

Thanks for the suggestion. Keeping track of which stations are capable of FX.25 is a very good idea.

Unconditionally using FX.25 transmissions to those stations would be wasteful if they did not have any receive errors.

I had a related thought on automatically transmitting FX.25 when it might be beneficial. The connected mode state machine keeps track of transmission retries when a frame does not get acknowledged within the specified timeout. After retrying a couple times, FX.25 transmit could be activated automatically to improve chances of getting the frame through. That would be wasteful if the other station does not recognize FX.25.

Combining these two ideas would be a winning combination.

If the connection state machine, inside of direwolf is being used (i.e. AGW network interface), this is easy. The retry count is already known and we know when the connection ends. If direwolf is being used as a KISS TNC (with the connection state machine in some other application), it would be a lot more difficult to try to reconstruct the connection state by looking at what is going back and forth.

dranch commented 3 years ago

For serial kiss and TCP-KISS users, might there be a mechanism using say kissparms to set various wants like yes/no FX.25, etc?