13 Aug
2023
13 Aug
'23
4:57 p.m.
Thank you David.
So this confirms that the the netlink interface has not changed and it
is working.
I have no 5.13 or a similar generation system to check.
@Tony: this would tell me that your issue is probably not related to an
internal ampr-ripd anomaly.
Maybe try to use the main table as a test (nu -t 44 parameter) and see
if the routes appear...
BTW: what is the output of your 'ip route list table 44' command?
Marius, YO2LOJ
On 13/08/2023 20:21, David Ranch via 44net wrote:
Working fine here on 5.15 on a Raspberry Pi:
$ uname -a
Linux ampr2 5.15.76+ #1597 Fri Nov 4 12:11:43 GMT 2022 armv6l GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
$ date
Sun 13 Aug 2023 10:20:09 AM PDT
$ ip route list table 44 | wc --lines
776
$ ls -la /var/lib/ampr-ripd
-rw-r--r-- 1 root root 40252 Aug 13 09:20 encap.txt
--David
KI6ZHD
On 08/13/2023 02:11 AM, Marius Petrescu via 44net wrote:
The command line seems ok (but you can actually drop the password
parameter since the default one is used if not set via -p),
The good question is if the newer kernels changed something in their
netlink behavior...
Could someone confirm if they have ampr-ripd successfully running on
a 5.13 kernel?
On 13/08/2023 04:52, Tony Langdon via 44net wrote:
_______________________________________________
44net mailing list --44net(a)mailman.ampr.org
To unsubscribe send an email to44net-leave(a)mailman.ampr.org Hi Marius, thanks for replying. Here's the
information you requested.
Kernel version:
# uname -a
Linux pridenet1 5.13.0-52-generic #59-Ubuntu SMP Wed Jun 15 20:17:13
UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Command line:
/usr/local/sbin/ampr-ripd -s -r -t 44 -i tunl0 -p pLaInTeXtpAsSwD -a
44.136.76.0/24 <http://44.136.76.0/24> -L vk3jed@qf23dg
On Sun, Aug 13, 2023 at 11:18 AM Marius Petrescu <marius(a)yo2loj.ro>
wrote:
Hi Tony,
The SIGALRM is just the signal sent by the kernel as a result of
a timer
set up by ampr-ripd to trigger 30 sec from receiving the last RIP
routing set and is an expected behavior.
It triggers the purging of obsolete route entries and has
nothing to do
with the update of the routing tables, which happens on the fly
via a
netlink socket during RIP processing on reception.
If the encap.txt is correctly saved, that means that the RIP
data was
parsed successfully and sent to the kernel.
What kernel version do you use?
Can you post your ampr-ripd command line used to start up the
daemon?
Marius, YO2LOJ
On 13/08/2023 02:22, Tony Langdon via 44net wrote:
_______________________________________________
44net mailing list --44net(a)mailman.ampr.org
To unsubscribe send an email to44net-leave(a)mailman.ampr.org Hi,
been having a few issues with IPIP tunnels of late. On my original
server (a R-Pi), which I recently resurrected, ampr-ripd suddenly
started segfaulting on startup for no obvious reason. The old
system
also had a few limitations and an ageing SD card,
so I decided
to move
my gateway to a VPS, and updated the gateway IP
in the portal
accordingly.
I ported my setup to the new server and built the latest (2.41)
ampr-ripd. I've verified that I am receiving the RIP
broadcasts, and
ampr-ripd writes the encap.txt file in
/var/lib/ampr-ripd.
However, I
am not seeing any route updates in table 44 (the
routing table
I use for
ampr routing - I am using the recommended policy
routing).
The only
clue I get as to something not being right is a
line:
SIGALRM received
I'm guessing that signal has something to do with the routing
table not
being updated, but there's no other clues to
help me troubleshoot.
Anyone have any ideas?
--
73 de VK3JED
http://vkradio.com
_______________________________________________
44net mailing list --44net(a)mailman.ampr.org
To unsubscribe send an email to44net-leave(a)mailman.ampr.org