On Wed, Mar 13, 2019 at 03:56:16PM +0100, Lorenzo Simoncello via 44Net wrote: [..] It's always the best choice to use the official repo. See http://www.linux-ax25.org/wiki/GIT http://www.linux-ax25.org/wiki/Compilation It would always have been a good idea to send patches upstream. vy 73, - Thomas dl9sau

Hello Lorenzo, In some rare cases, this is correct. Most of the time, the issues experienced are less catastrophic but the overall packet system is still unusable. Examples include: - In an AX.25 connected session (classic packet), the remote user disconnects but the local AX.25 socket is left open forever. At that point, that remote user's CALLSIGN+SSID will never be able to reconnect. - In AX.25 unconnected packets (APRS, etc), there are failures to send packets in specific scenarios - There are more examples I can share if you're interested These kernel maintainers are making changes to adopt newer coding styles for existing routines and their efforts span multiple areas of the kernel. These patches are usually submitted in very large swaths of code areas and some include the packet radio section. I've generally observed these people aren't HAMs and aren't unit testing or regression testing their patched code. The mere fact that code compiles justifies the patch in their minds which is terrible IMHO. Other maintainers have created patches but put in the comments that this change isn't complete and shouldn't be committed yet but they submit the patch anyway. The designated AX.25 kernel maintainers haven't been involved in years now and the the upstream branch maintainers simply accept the patches anyway assuming more patches are on their way but they never come. I've personally tried to find out where some sort of packet unit testing could be put into the Linux development process but I've been unable to get anyone to respond. The closest I've found to all this is the system created by Intel but again, I've been unable to find anyone that will tell me how to author unit tests and get them into their CD pipeline. Nope. Bernard F6BVP did a lot of bisecting and testing work until he found that kernel version. More and more kernel changes have come through the system now so it's not just a matter of backing out those changes. The backouts would need to be ported to be compatible with the new state of the code. No. The issues we've observed is only in the kernel and the userland AX.25 packages. This is still my observed experience. The Official AX25 repos have made some progress but that team continues to refuse important fixes. Some of those refusals might be legitimate on some technical level (maybe their are better ways of getting the same change done) but no attempts by those maintainers are made to rectify the issues and commit them. As such, we fortunately have the VE7FET repo which takes those fixes which repairs the various functionality, and we get a reliable packet solution. I've been personally trying to recruit kernel people to correct these issues for many years now but I cannot report any real progress. I believe we are approaching the point where the in-kernel AX.25 support will completely break At that point, we will need to move to a AX.25 userland solution to continue using Linux at all. This would be something along the lines of all Linux applications would need to get their packet support via something AGW API calls, TCP KISS, etc. If that happens, we will essentially loose all the powerful built-in packet routing abilities of the Linux kernel. This would be very sad but then we could return to using current modern and secure kernels. If anyone believes they can help on this effort to repair the kernel or have in's to other kernel developers who might be willing to help, please send them my email address. I have a fairly detailed set of emails containing various history of the key commits that broke things which might help that person correct those changes and get us back on track. --David KI6ZHD