Seems to me that encap routes learned by rip44 should be fairly
persistant - I'd say they shouldn't expire for a day or three or more.
Perhaps a week?
Unless replaced by a newer route for the same subnet, of course.
That way if the rip sender (amprgw) should happen to go away for a while,
things will still function. And you'd have time to switch over to using
the encap file if the outage were to be prolonged.
There's no harm in having a dormant route in your table for a while when
a gateway permanently goes away.
What's the maximum rip44 route expiration time setting?
You could, of course, decide to NEVER expire them. With daemon
modification, they could be persistent across reboots and only purged
when manually selected.
- Brian
I think the lack of multicast support in some Linux kernel builds
makes the Perl rip44d fail for some users.
Linux 2.6 certainly supports multicast, it's been in the kernel for a
long while (at least in kernel 1.2 it was there, and probably before
that). Some distributions apparently haven't compiled in the multicast
code.
If you're having problems with rip44d not receiving RIP packets, and
you're not one of those having a NAT/DMZ router of some sort in front
of the gateway, please check if your kernel has multicast enabled:
http://unix.stackexchange.com/questions/25872/how-can-i-know-if-ip-multicas…
I can probably add raw socket support to rip44d, mimicking what Marius
did in his C version, to work around it, if this is indeed a problem.
One alternative is to run the C daemon on those systems, of course!
- Hessu, OH7LZB
On Tue, Aug 6, 2013 at 2:08 AM, Brian Rogers <n1uro(a)n1uro.ampr.org> wrote:
> On Sat, 2013-08-03 at 11:46 +0300, Marius Petrescu spake:
>> I added an option to use raw sockets instead of multicast to the daemon.
>> This is needed on systems that do not support multicast properly.
>> On system where it works, there is no need to upgrade.
>
> Thank you Marius - it's definately now doing what it needs to do! Good
> job! With my 10 yr old system running a P-III I'm lucky to have a circa
> 2009 setup running. I don't know why on earth though this 2.6 kernel
> doesn't support multicast.
Hi folks,
So I was able to compile Maiko's latest JNOS code for my RPi and it appears
to function correctly. I have one of John Hansen's TNC-Pi's which also
seems to work using the I2CKISS stuff. I have the AGW remote modem stuff
working. I was even able to get the encap stuff working via my pFsense FW
with the aid of this rather useful posting
http://forum.pfsense.org/index.php?topic=64060.0 and the encap.txt file.
However, whilst I'm receiving UCSD's RIP broadcasts at my FW they are not
making it through to JNOS. I've tried forwarding UDP port 520 however that
does not seem to work as pFsense traps the RIP session as an IPIP session.
This further confuses me as IPIP sessions are correctly sent to JNOS per
the above. I have also tried activating the RIP daemon in pFsense and then
getting JNOS to ask for a RIP update but that doesn't seem to work either.
Ideas?
Thanks
Mark, G7LTT/NI2O
Randolph, NJ
Hi all,
KUDOS to all IP Gurus who helped me reinstall our ATHnet AMPRnet
GATEWAY in Athens, Greece.
Special thanks to Marc, Tom, Brian N1URO and Brian Kantor whose
comments and WEB PAGES helped.
An easy iptables script would also be a good help to us but I think
that I am OK at the moment using UFW and also Brian N1URO's ideas on
how to allow IPIP in my LINUX box using 3 IPTABLES commands I found in
his WEB PAGES/POSTINGS.
Thanks a lot guys. Your help is much appreciated!
--
73 de SV1UY
Demetre Ch. Valaris
IP Coordinator for AMPRnet in Greece
e-mail: demetre.sv1uy(a)gmail.com
Radio e-mail: sv1uy(a)winlink.org
(to use my radio e-mail put //WL2K in the beginning of the subject line)
http://www.qsl.net/sv1uy
By default rip44d is using the interface tunl0, it seems:
my $tunnel_if = 'tunl0';
You seem to be using tun0 in your networking scripts, so i suppose you either need to adjust the default, use the -i option to change the interface used by rip44d, or change the tunnel interface name to match so the rip44d is listening on the right interface.
Pieter.
Sent from a mobile, sorry for any typoes...
Hi all,
After running ripp44d for about I see in my routing table that my own
subnet 44.154/18 is routed to 87.202.40.155 (my ADSL router's dynamic
IP) via tunl0 interface.
Is this right?
--
73 de SV1UY
Demetre Ch. Valaris
IP Coordinator for AMPRnet in Greece
e-mail: demetre.sv1uy(a)gmail.com
Radio e-mail: sv1uy(a)winlink.org
(to use my radio e-mail put //WL2K in the beginning of the subject line)
http://www.qsl.net/sv1uy
44.64.192/24
44.64.193/24
I noted that these networks were in the gateways encap list. It would be
nice to know whom has them so that I can update my NJ co-ordinator records.
Thanks
Mark NI2O
> Subject:
> Re: [44net] IP address management
> From:
> Mark Phillips <g7ltt(a)g7ltt.com>
> Date:
> 08/02/2013 10:57 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> TeemIP
>
>
> Me like!!!!
>
> Might grab this for use at work.
>
> Mark
Indeed, this looks like what we need as a module within portal.ampr.org!
And it saves a lot of work to have something like this.
Rob
> Subject:
> Re: [44net] question regarding amprgw.sysnet.ucsd.edu
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 08/01/2013 03:25 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Wed, Jul 31, 2013 at 06:16:32PM -0700, Blaine Forbort wrote:
>> >My DNS request is still waiting for coordinator approval. I guess I'll
>> >be waiting for that until I can finish off this first step of my
>> >experiment.
> Does that mean that you submitted it via the portal.ampr.org DNS
> function? I'm sorry, that function isn't working yet. I've asked
> for it to be taken off the portal menu until it*is* working as it
> confuses people.
It also needs to be discussed what functionality is required here for both the users
and the coordinator. Sometimes I get requests for approval, and I just looked
in the portal.ampr.org again, but it does not really cover the requirements.
What we need is a request from a user to get one or more addresses allocated,
accompanied by information like region where they live. The coordinator then must
be able to look into the already assigned list of addresses and find an available
address in the correct region (subnet), assign it, and return the address to
the requester.
As it is now, I get requests for 44.137.0.0/16 which makes little sense. Until
now I have a hosts file and I make the assignment by browsing through it in
the editor, and copy/pasting a line. Then I send the corresponding update to
the ampraddr robot. How can we do this in the portal when we abandon the hosts files?
Rob
