Hi hoping won't be OT for "44 Net" mailing list, I would like to ask for yours experience with current AX25 support on Debian and specifically on Linux (Raspbian) based (Raspberry PI) node. At the moment my node should have 1 radio port (1 6pack interface to TNC) and one AXIP link via 44 net. In a previuos post I can see some warnings about "... many kernel issues with the AX25 stack and newer kernels that cause the kernel to simply lock, panic, and other nasties ..." and so the downgrade advice. On the other hand I can see AX25 kernel patch mailing list with some recent kernel little patches about AX25 ... someone know the real recent kernels conditions? It is absolutely necessary to downgrade from current stable 4.14.98 to previous 4.1.21 (for example ...)? In this case, is there a more recent "good" downgrade kernel? It is better to use "Jessie" instead of "Stretch" distro? Again about AX25 packages AX.25 Apps, AX.25 Tools, AX.25 Library: It is always the best choise to recompile and use VE7FET packages (thanks to Lee VE7FET for bugs fixed and reorganizing) instead of official repository (APT) ? It's a pity that there is no way to have a single good source ...
Thanks for sharing your experience... may help to shorten the time to right configure a new node for more than someone ;)
'73 de Lorenzo iw3her
On Wed, Mar 13, 2019 at 03:56:16PM +0100, Lorenzo Simoncello via 44Net wrote: [..]
Again about AX25 packages AX.25 Apps, AX.25 Tools, AX.25 Library: It is always the best choise to recompile and use VE7FET packages (thanks to Lee VE7FET for bugs fixed and reorganizing) instead of official repository (APT) ?
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's a pity that there is no way to have a single good source ...
It would always have been a good idea to send patches upstream.
Thanks for sharing your experience... may help to shorten the time to right configure a new node for more than someone ;)
vy 73, - Thomas dl9sau
Thomas et al;
On Wed, 2019-03-13 at 16:44 +0100, Thomas Osterried wrote: <$0.02>
Again about AX25 packages AX.25 Apps, AX.25 Tools, AX.25 Library: It is always the best choise to recompile and use VE7FET packages (thanks to Lee VE7FET for bugs fixed and reorganizing) instead of official repository (APT) ?
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
Debian has dropped some of the packages from your group because when it does come to patches, politics wins over technical issues with the maintainer upstreams and deploying known broken packages does NO ONE any good, nor does it help the growth of the hobby using ax.25/netrom/rose.
It's a pity that there is no way to have a single good source ...
It would always have been a good idea to send patches upstream.
This is not true. I know those who's submitted patches and they get rejected 100% with non-technical reasonings such as not knowing rose or it wasn't developed within the maintainer group. This is not a secret, many know this which is why there's multiple distributions of the exact same packages out there.
Discussions on this are quite old as I'm sure David Ranch will agree. Until the maintainers of the original packages begin to accept patches sent, they could make .diff files themselves from the other releases, test, and incorporate them for better improved "original" release.
Ever since kernel 4.2, the whole ax.25 suite is of no value whatsoever and now people are going round robin blaming others rather than fixing things. Marius made a patch as well, which appears to be working on his site but I do not know if he submitted it to the maintainers. With the history of rejections of patches I wouldn't be surprised if he hasn't. </$0.02>
Hello Lorenzo,
In a previuos post I can see some warnings about "... many kernel issues with the AX25 stack and newer kernels that cause the kernel to simply lock, panic, and other nasties ..." and so the downgrade advice.
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
On the other hand I can see AX25 kernel patch mailing list with some recent kernel little patches about AX25 ... someone know the real recent kernels conditions?
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.
It is absolutely necessary to downgrade from current stable 4.14.98 to previous 4.1.21 (for example ...)? In this case, is there a more recent "good" downgrade kernel?
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.
It is better to use "Jessie" instead of "Stretch" distro?
No. The issues we've observed is only in the kernel and the userland AX.25 packages.
Again about AX25 packages AX.25 Apps, AX.25 Tools, AX.25 Library: It is always the best choise to recompile and use VE7FET packages (thanks to Lee VE7FET for bugs fixed and reorganizing) instead of official repository (APT) ? It's a pity that there is no way to have a single good source ...
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
On 14.03.2019 17:06, David Ranch wrote:
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.
Actually, the described failure IS catastrophic. Since Netrom needs to reuse that callsign-ssid pair.
This is the patch Brian was talking about, and no, I never sent it, since nothing ever seems to get patched there.
Marius, YO2LOJ
Is there a place where we can get the latest unofficial patches? Has anyone considered a fork to keep it relevant to modern kernels? I am not versed in the kernel and have never been successful at getting the ax25 stack working at my location. I gave up years ago because I wasn’t connected in to the group. I have a back burner project to integrate direwolf into my environment on a RasPi as soon as I complete re-establishing my ampr gateway.
— tom Tom Cardinal / MSgt USAF (Ret) / N2XU / BSCS / CASP+
On Mar 14, 2019, at 11:41 AM, Marius Petrescu marius@yo2loj.ro wrote:
On 14.03.2019 17:06, David Ranch wrote: 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.
Actually, the described failure IS catastrophic. Since Netrom needs to reuse that callsign-ssid pair.
This is the patch Brian was talking about, and no, I never sent it, since nothing ever seems to get patched there.
Marius, YO2LOJ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Tom;
On Thu, 2019-03-14 at 12:46 -0500, Tom Cardinal via 44Net wrote:
Is there a place where we can get the latest unofficial patches? Has anyone considered a fork to keep it relevant to modern kernels? I am not versed in the kernel and have never been successful at getting the ax25 stack working at my location. I gave up years ago because I wasn’t connected in to the group. I have a back burner project to integrate direwolf into my environment on a RasPi as soon as I complete re-establishing my ampr gateway.
On https://uronode.sourceforge.net I have an RPI 1 and RPI 3 distro that will work for you. I'd also stay clear of Ubuntu for ham usage. Stay with straight Debian.
Thanks Brian, I was moving away from Ubuntu but just installed a fresh copy because of other issues (political and social issues going on in ZA land where Ubuntu is from.
— tom Tom Cardinal / MSgt USAF (Ret) / N2XU / BSCS / CASP+
On Mar 14, 2019, at 12:57 PM, Brian n1uro@n1uro.ampr.org wrote:
Tom;
On Thu, 2019-03-14 at 12:46 -0500, Tom Cardinal via 44Net wrote: Is there a place where we can get the latest unofficial patches? Has anyone considered a fork to keep it relevant to modern kernels? I am not versed in the kernel and have never been successful at getting the ax25 stack working at my location. I gave up years ago because I wasn’t connected in to the group. I have a back burner project to integrate direwolf into my environment on a RasPi as soon as I complete re-establishing my ampr gateway.
On https://uronode.sourceforge.net I have an RPI 1 and RPI 3 distro that will work for you. I'd also stay clear of Ubuntu for ham usage. Stay with straight Debian. -- I love Tinder. It used to be I could get rejected by about a dozen people a night. Thanks to modern technology I can be rejected by hundreds. It's so much more efficient!
73 de Brian N1URO IPv6 Certified SMTP: n1uro-at-n1uro.ampr.org
I think kernel downgrade to 4.1.21 (or similar) don't solve all issues, net/rom seems works fine but not basic packet: after a while (1 hours?) from reboot, I no longer receive packets from TNC2 AX25 interface, despite I can see DCD ON when TNC is listening to beacon of other stations and also to my axcall answer. The testing conditions are: last Raspbian Stretch, downgrade to kernel 4.1.21 (VE7FET AX25 software suite or base repository (APT) AX25 don't change), vpn to 44 net, 1 axport to serial tnc2 in 6pack mode, and 1 axport axip tunnel - route to another node
I don't know if I've made some mistakes in this trials: it is strange but in another situation (older setup of Raspbian Stretch with 4.9.59 kernel and only one axport to tnc2, and base (APT) ax25 software suite), nothing else, all base ax25 packet works fine and stable.
Suggestions are welcome :)
I can see also that:
1. N1URO have a raspberry PI image ready to use with 4.1.19 (64 bit) kernel and I think official APT AX25 software suite 2. RSBYPI:N1URO-2 active node uses Linux 3.12.22 (32 bit) kernel, I don't know witch AX25 software suite revision it is using 3. Bernard F6BVP raspberry image use 4.1.17, I think it use the VE7FET AX25 software suite
Not yet try to reconfigure and test this images and if above problem still remain... if possibile i prefer to start with base Rasbian Light setup (only text mode) and adding/compiling step by step all necessary software and configurations because I personally need (and like) to learn all single setup passages
In my opinione first we need to know which is the last well working updated and usable kernel + AX25 software suite from your experiences. Otherwise I (and others hams) spend weeks in "waste testing" and this can't help the growth of the hobby and knowledge using ax.25/netrom/rose ecc.
---------------
On the other hands maybe the moment to start speaking and design (first) of the future of AX25 and Linux... I think it is the moment to relive the basic hamradio spirit and collaboration with all possible resources and skills available... There are several spread mods or unofficial revision of source code or some people maybe have self pached the kernel (I can see over 700 active node in the world...) it's a pity if all this work will be lost If people with kernel and ax25 protocol skills are able to organize and coordinate this work, they could also involve those who are less prepared (like me) in minor activities (debugging or verifing code or making some trials) Probaly almost of us have no time, but perhaps together something can be done with due time... I don't know if it's possible, but I'd like to hope
'73 de Lorenzo iw3her
Il giorno gio 14 mar 2019 alle ore 16:09 David Ranch amprgw@trinnet.net ha scritto:
... 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
Il giorno gio 14 mar 2019 alle ore 16:09 David Ranch amprgw@trinnet.net ha scritto:
Hello Lorenzo,
In a previuos post I can see some warnings about "... many kernel issues with the AX25 stack and newer kernels that cause the kernel to simply
lock,
panic, and other nasties ..." and so the downgrade advice.
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 userdisconnects 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 tosend packets in specific scenarios
- There are more examples I can share if you're interested
Il giorno gio 14 mar 2019 alle ore 17:42 Marius Petrescu marius@yo2loj.ro ha scritto:
On 14.03.2019 17:06, David Ranch wrote:
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.
Actually, the described failure IS catastrophic. Since Netrom needs to reuse that callsign-ssid pair.
This is the patch Brian was talking about, and no, I never sent it, since nothing ever seems to get patched there.
Il giorno mar 19 mar 2019 alle ore 02:37 vk2tv vk2tv@exemail.com.au ha scritto:
Thanks David.
We've lost (losing) bragging rights about ax25's tight integration with the Linux kernel, and all the reasons why I ditched Windows in favour of Linux for my packet radio needs back in 1996.
Ray vk2tv
Sorry I didn't explain well in my last email. I try to explain more exactly and more detailed:
These are the modules I load: modprobe 6pack modprobe ax25 modprobe netrom There are 2 axports attach: - sp0 (6pack: kissattach -6 -l /dev/ttyUSB0 sp0 -> TNC2 radio link) - ax0 (axip interface via 44 net: kissattach -m 256 /dev/ptyq1 ax0 ) There is one netrom interface broadcasted both sp0 and ax0.
After a while (1 hours?) from reboot I no longer receive packets (all, both netrom and simple ax25 packet) from interface sp0 despite I can see DCD ON when TNC is listening to beacon of other stations and also to my axcall answer.
All is regular on interface ax0.
The testing conditions are: last Raspbian Stretch, downgrade to kernel 4.1.21 (VE7FET AX25 software suite or base repository (APT) AX25 don't change)
Another testing condition don't have the specific problem of missing listening packets: older setup of Raspbian Stretch with 4.9.59 kernel and only one axport to tnc2, and base (APT) ax25 software suite
Sorry I don't know if it is OT for 44 net mailing list, if not please let me known if there is another more appropriate mailing list
Thanks
'73 de Lorenzo iw3her
Il giorno mar 19 mar 2019 alle ore 17:53 Lorenzo Simoncello < lorenzo.simoncello@gmail.com> ha scritto:
I think kernel downgrade to 4.1.21 (or similar) don't solve all issues, net/rom seems works fine but not basic packet: after a while (1 hours?) from reboot, I no longer receive packets from TNC2 AX25 interface, despite I can see DCD ON when TNC is listening to beacon of other stations and also to my axcall answer. The testing conditions are: last Raspbian Stretch, downgrade to kernel 4.1.21 (VE7FET AX25 software suite or base repository (APT) AX25 don't change), vpn to 44 net, 1 axport to serial tnc2 in 6pack mode, and 1 axport axip tunnel - route to another node
I don't know if I've made some mistakes in this trials: it is strange but in another situation (older setup of Raspbian Stretch with 4.9.59 kernel and only one axport to tnc2, and base (APT) ax25 software suite), nothing else, all base ax25 packet works fine and stable.
Suggestions are welcome :)
On 20/03/19 03:53, Lorenzo Simoncello via 44Net wrote:
If people with kernel and ax25 protocol skills are able to organize and coordinate this work, they could also involve those who are less prepared (like me) in minor activities (debugging or verifing code or making some trials) Probaly almost of us have no time, but perhaps together something can be done with due time... I don't know if it's possible, but I'd like to hope
I don't have the programming skills, but I'd like to be able to do things like test. Reminds me, I need to get my packet gateway up and running. I have all the hardware and gateway software setup, just have to make the cable to connect to a radio. Might even be able to get some locals to join in, we have a pretty good radio club here.
No, those userspace packages do not. I was considering writing up independent regression tests to specifically catch the kernel issues that we're aware of right now but I could never get an answer from various kernel developers of what testing languages the uptream systems use. I tried to find out what the Intel supported harness uses but again, I never got any responses.
--David KI6ZHD
Does the ax25 system/tools have tests? Preferably tests that would catch the current error issues.
A few things stands out to me in your environment:
- How are you powering your Raspberry Pi? Quality power supplies and USB cables are requirements for stabilty
- what kind of serial interface are you using from the Rpi to the TNC2? Have you tried other adapters?
- RFI issues can be random, can take time to manifest, and is hard to prove.
- The use of 6pack. While I understand it can be a superior solution to KISS, it's not commonly used and might be an issue. Can you disable that port and see if you get better uptime without it?
- Are you sure you're still getting data from the TNC2? Try monitoring to see if you're getting data when the DCD light comes on? Something like this would make it easy to see traffic but it's not actually working for me:
strace -f -p `ps ax | grep kissattach | grep -v grep | awk '{print $1}'`
- What kind of AX25 traffic do you have going over the TNC2 or the AXIP tunnel? Connection-less UI AX.25? Connected AX.25? Netrom? ROSE? Flex?
- Since the machine seems to be connected to the Internet, you sure it's not getting hammered with Internet attacks, your file system isn't filling up with logs, etc?
Btw, the 4.1.21 recommendation came from F6BVP. If he's running 4.1.19, maybe there is a specific reason.
--David KI6ZHD
On 03/19/2019 09:53 AM, Lorenzo Simoncello via 44Net wrote:
I think kernel downgrade to 4.1.21 (or similar) don't solve all issues, net/rom seems works fine but not basic packet: after a while (1 hours?) from reboot, I no longer receive packets from TNC2 AX25 interface, despite I can see DCD ON when TNC is listening to beacon of other stations and also to my axcall answer. The testing conditions are: last Raspbian Stretch, downgrade to kernel 4.1.21 (VE7FET AX25 software suite or base repository (APT) AX25 don't change), vpn to 44 net, 1 axport to serial tnc2 in 6pack mode, and 1 axport axip tunnel - route to another node
I don't know if I've made some mistakes in this trials: it is strange but in another situation (older setup of Raspbian Stretch with 4.9.59 kernel and only one axport to tnc2, and base (APT) ax25 software suite), nothing else, all base ax25 packet works fine and stable.
Suggestions are welcome :)
I can see also that:
- N1URO have a raspberry PI image ready to use with 4.1.19 (64 bit) kernel
and I think official APT AX25 software suite 2. RSBYPI:N1URO-2 active node uses Linux 3.12.22 (32 bit) kernel, I don't know witch AX25 software suite revision it is using 3. Bernard F6BVP raspberry image use 4.1.17, I think it use the VE7FET AX25 software suite
Not yet try to reconfigure and test this images and if above problem still remain... if possibile i prefer to start with base Rasbian Light setup (only text mode) and adding/compiling step by step all necessary software and configurations because I personally need (and like) to learn all single setup passages
In my opinione first we need to know which is the last well working updated and usable kernel + AX25 software suite from your experiences. Otherwise I (and others hams) spend weeks in "waste testing" and this can't help the growth of the hobby and knowledge using ax.25/netrom/rose ecc.
On the other hands maybe the moment to start speaking and design (first) of the future of AX25 and Linux... I think it is the moment to relive the basic hamradio spirit and collaboration with all possible resources and skills available... There are several spread mods or unofficial revision of source code or some people maybe have self pached the kernel (I can see over 700 active node in the world...) it's a pity if all this work will be lost If people with kernel and ax25 protocol skills are able to organize and coordinate this work, they could also involve those who are less prepared (like me) in minor activities (debugging or verifing code or making some trials) Probaly almost of us have no time, but perhaps together something can be done with due time... I don't know if it's possible, but I'd like to hope
'73 de Lorenzo iw3her
Il giorno gio 14 mar 2019 alle ore 16:09 David Ranch amprgw@trinnet.net ha scritto:
... 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
Il giorno gio 14 mar 2019 alle ore 16:09 David Ranch amprgw@trinnet.net ha scritto:
Hello Lorenzo,
In a previuos post I can see some warnings about "... many kernel issues with the AX25 stack and newer kernels that cause the kernel to simply
lock,
panic, and other nasties ..." and so the downgrade advice.
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 userdisconnects 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 tosend packets in specific scenarios
- There are more examples I can share if you're interestedIl giorno gio 14 mar 2019 alle ore 17:42 Marius Petrescu marius@yo2loj.ro ha scritto:
On 14.03.2019 17:06, David Ranch wrote:
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 userdisconnects 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.
Actually, the described failure IS catastrophic. Since Netrom needs to reuse that callsign-ssid pair.
This is the patch Brian was talking about, and no, I never sent it, since nothing ever seems to get patched there.
Il giorno mar 19 mar 2019 alle ore 02:37 vk2tv vk2tv@exemail.com.au ha scritto:
Thanks David.
We've lost (losing) bragging rights about ax25's tight integration with the Linux kernel, and all the reasons why I ditched Windows in favour of Linux for my packet radio needs back in 1996.
Ray vk2tv
-
Bill Vodall -
Brian -
David Ranch -
Lorenzo Simoncello -
Marius Petrescu -
Thomas Osterried -
Tom Cardinal -
Tony Langdon