FX.25[0]: Frame length of N + overhead is too large to encode.

[mrkeuz]

Found this in log.

...
FX.25[0]: Frame length of 238 + overhead is too large to encode.
Unable to send FX.25.  Falling back to regular AX.25.
...

For reproduce you can send ping with large payload (i.e. 300 bytes):

ping -i 1 -s 300 $IP

I've tried:

• Increase/decrease PACLEN n and /etc/ax25/axports paclen. But it was not helps.
• Change FX25_MAX_DATA = 512 in fx25.h (naive). Got next instead:

  FX.25[0]: Could not find suitable format for requested 4 and data length 353.
  Unable to send FX.25.  Falling back to regular AX.25.
  

How it can be fixed and use FX.25 for any packets?

[wb2osz]

That is an inherent limitation of FX.25 as originally specified.
The payload length and number of parity bytes can not exceed the Reed Solomon block size of 255.
PRUG has proposed a method to allow longer packets.
https://web.tapr.org/meetings/DCC_2020/JE1WAZ/DCC-2020-PRUG-FINAL.pptx
I should study that in more detail and build one of theirs for interoperability testing.

[dranch]

It's also worth noting that the maximum PACLEN size (aka MTU) in AX.25 v2.0 is 256 OCTETS or 256 bytes - Section 2.4.7.3 in https://erikarn.github.io/ax25/AX25V20.pdf . AX.25 v2.2, not very clear on the maximum per section 6.7.2.1 - https://www.tapr.org/pdf/AX25.2.2.pdf but if you're using Linux as your base OS, you're going to be using the in-kernel AX.25 stack which is AX.25 v2.1 only and you won't be able to leverage Direwolf's Ax.25 v2.2 stack. Finally, if you are going to consider running IP over AX.25, you will need to lower the IP interface's MTU to be even lower than 256 bytes to handle the IP header overhead and then also consider other overhead say the ICMP header, TCP headers, etc - https://www.tamos.net/~rhay/overhead/ip-packet-overhead.htm

[wb2osz]

AX.25 v2.2 (1998) doesn't have a specific maximum size. The XID frames can be used to negotiate a size depending on capabilities of each end. Dire Wolf has a max of 2k. At the time I thought that would be a good limit because it could easily hold an Ethernet frame.