Feature: Implement connected-mode operation #21
Merged
Conversation
This file contains 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
AX.25 2.2 adds support for modulo-128 frames using a 16-bit control field. The only way to know you're dealing with modulo-128 traffic is by remembering that you negotiated it earlier. Thus we need 8-bit and 16-bit versions of the frame structure to handle the enlarged control field in the modulo-128 case.
This adds untested code for encoding and decoding various frame types related to connected-mode operation.
Add tests whilst we're at it.
Put the majority of the frame logic in the top-level `AX25Frame.decode` method for convenience. We can rely on the fact that the least-significant two bits of a control field are all we need to identify I, S and U frames. Further more, the least significant byte is sent first, so there's sufficient detail at this point to identify the U frames up-front, and with some help, I and S frames too.
We're unlikely to see these, I think most people will have "ugraded" to 2.x by now, and if not, they should be encouraged to do so, but at the very least we can at least ensure we digipeat such frames properly.
The concept here is that `AX25Station` represents the local AX.25 node implemented by the Python application, while `AX25Peer` represents a remote AX.25 TNC. `AX25Station` basically routes according to the source AX.25 address to an appropriate `AX25Peer`. Some garbage collection is implemented to ensure memory isn't exhausted.
Don't check if it's been cancelled, `asyncio` doesn't seem to care.
This calls a remote AX.25 station, very crude at the moment, but it seems to be able to interact with BPQ32.
These are not practically unit testable.
The only time we do an XID is just prior to a connection attempt, we should enforce this to simplify logic.
BPQ32 responds with FRMR, so fallback to AX.25 2.0 seems to work.
Now its purpose makes sense! Not part of the AX.25 2.0 spec, but it seems to make more sense than the other variables for tracking this point.
This runs a program and redirects stdin/stdout/stderr to the packet link. CR is translated to LF and back again.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously,
aioax25only supported UI frames, which was enough to participate on an APRS network, but not enough to be a full fledged AX.25 node.This implements preliminary support for making and accepting AX.25 connections from a remote node.