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?
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 -L vk3jed@qf23dg
On Sun, Aug 13, 2023 at 11:18 AM Marius Petrescu <marius@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:
> 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@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org