21 Mar
2019
21 Mar
'19
12:24 a.m.
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:
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:
> 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 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.