Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SABM and SABME swapped in frame.py #17

Open
vk2tds opened this issue Mar 30, 2023 · 1 comment
Open

SABM and SABME swapped in frame.py #17

vk2tds opened this issue Mar 30, 2023 · 1 comment

Comments

@vk2tds
Copy link

vk2tds commented Mar 30, 2023

In the file frame.py, SABM and SABME classes have their modifiers swapped. The correct values should be :-

Class AX25SetAsyncBalancedModeExtendedFrame should have a modifier of MODIFIER = 0b01101111
Class AX25SetAsyncBalancedModeFrame should have a modifier of MODIFIER = 0b00101111

It also appears that the P/F flag needs more investigation, and should possibly be set. The basis for this is that my PicoPacket TNC with 1996 firmware has the P/F bit set. In my case, the picopacket is using 0x3f as the value for SABM.

I suspect that existing code uses a mask to ignore the p/f bit.

Following your code, you could ADD these MODIFIER = 0b01101111 and MODIFIER = 0b00101111 respectively for SABME and SABM.

@sjlongland sjlongland changed the title SABM and SABM swapped in frame.py SABM and SABME swapped in frame.py Mar 30, 2023
sjlongland added a commit that referenced this issue Apr 1, 2023
As observed in actual TNC firmware behaviour.
@sjlongland
Copy link
Owner

So, I had a look… indeed, the AX25BaseUnnumberedFrame class defaults to PF=False, but we can override this in sub-classes.

However, the constructor for AX25BaseUnnumberedFrame was omitting passing pf to the superclass. Thus every U frame generated had PF=False regardless. Oops. :-)

I've now corrected this in the branch. Many thanks for spotting these omissions. There might be other U-frames where PF should be set True instead of the current default… we'll play those by ear I guess. :-)

sjlongland added a commit that referenced this issue Apr 16, 2023
As observed in actual TNC firmware behaviour.
sjlongland added a commit that referenced this issue Oct 11, 2023
As observed in actual TNC firmware behaviour.
sjlongland added a commit that referenced this issue May 4, 2024
As observed in actual TNC firmware behaviour.
sjlongland added a commit that referenced this issue May 4, 2024
As observed in actual TNC firmware behaviour.
sjlongland added a commit that referenced this issue May 4, 2024
As observed in actual TNC firmware behaviour.
sjlongland added a commit that referenced this issue May 4, 2024
As observed in actual TNC firmware behaviour.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants