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?
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?
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?
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 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 to44net-leave@mailman.ampr.org
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 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 to44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
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 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 to44net-leave@mailman.ampr.org
44net mailing list --44net@mailman.ampr.org To unsubscribe send an email to44net-leave@mailman.ampr.org
44net mailing list --44net@mailman.ampr.org To unsubscribe send an email to44net-leave@mailman.ampr.org
Hi Marius, yeah it's weird. Manual route entries work fine, just that ampr-ripd is silently not adding its routes. Not having any error messages makes troubleshooting very difficult.
I'll try the main table, but here's my table 44. These routes have been added either in my startampr script or by hand. Ignore the odd /24 within the 44.31 /16, that was due to manual adjustments for unrelated technical issues.
I can give the main table a try as a test (though will have issues operationally).
ip route show table 44 default via 169.228.34.84 dev tunl0 onlink 44.31.0.0/16 via 112.213.34.1 dev eth0 44.31.48.0/24 via 112.213.34.1 dev eth0 44.31.169.0/24 via 10.43.21.3 dev ztc3q6v23i onlink 44.94.17.129 via 112.213.34.1 dev eth0 proto 44 44.136.76.0/24 dev ztuzesnqjd scope link
On Mon, Aug 14, 2023 at 7:58 AM Marius Petrescu via 44net < 44net@mailman.ampr.org> 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 -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
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
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 < 44net@mailman.ampr.org> 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 -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
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
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 44net@mailman.ampr.org 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 <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 to44net-leave@mailman.ampr.org_______________________________________________ 44net mailing list --44net@mailman.ampr.org To unsubscribe send an email to44net-leave@mailman.ampr.org_______________________________________________ 44net mailing list --44net@mailman.ampr.org To unsubscribe send an email to44net-leave@mailman.ampr.org_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org-- 73 de VK3JED http://vkradio.com
44net mailing list --44net@mailman.ampr.org To unsubscribe send an email to44net-leave@mailman.ampr.org
I do, given that it affects routing, which I was doing on the old system.
On 14/8/23 5:34 pm, Marius Petrescu wrote:
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 44net@mailman.ampr.org 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 <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_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org-- 73 de VK3JED http://vkradio.com
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
-
David Ranch -
Marius Petrescu -
Tony Langdon