19 Mar
2019
19 Mar
'19
4:53 p.m.
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(a)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(a)trinnet.net>
ha scritto:
Hello Lorenzo,
Il giorno gio 14 mar 2019 alle ore 17:42 Marius Petrescu <marius(a)yo2loj.ro>
ha scritto:
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 14.03.2019 17:06, David Ranch wrote:
Il giorno mar 19 mar 2019 alle ore 02:37 vk2tv <vk2tv(a)exemail.com.au> ha
scritto:
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.
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