[44net] Re: ampr-ripd not updating routing table

This may sound very low-tech, but do you run your ampr script as root? On 14/08/2023 05:35, Tony Langdon via 44net wrote: > Hmm, looks like no joy using the main routing table either (I took > out the t 44 from the command line).  I could fudge it with a munge > script, since I have encap.txt, though I'll have to sit down and work > out the munging, since there's no examples that I could find on the > Internet.  Ugly but effective. :D > > > On Mon, Aug 14, 2023 at 7:58 AM Marius Petrescu via 44net > &lt;44net(a)mailman.ampr.org&gt; wrote: > > 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: >>>> 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 >>>> &lt;marius(a)yo2loj.ro&gt; 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(a)mailman.ampr.org >>>> To unsubscribe send an email to 44net-leave(a)mailman.ampr.org >>> >>> >>> _______________________________________________ >>> 44net mailing list -- 44net(a)mailman.ampr.org >>> To unsubscribe send an email to 44net-leave(a)mailman.ampr.org >> >> >> _______________________________________________ >> 44net mailing list -- 44net(a)mailman.ampr.org >> To unsubscribe send an email to 44net-leave(a)mailman.ampr.org > _______________________________________________ > 44net mailing list -- 44net(a)mailman.ampr.org > To unsubscribe send an email to 44net-leave(a)mailman.ampr.org > > > > -- > 73 de VK3JED > http://vkradio.com > > _______________________________________________ > 44net mailing list -- 44net(a)mailman.ampr.org > To unsubscribe send an email to 44net-leave(a)mailman.ampr.org