On Thu, Aug 8, 2013 at 8:21 PM, Michael E. Fox - N6MEF <n6mef(a)mefox.org> wrote:
A couple more questions:
1) Currently, I have the ip munge stuff putting the amprnet routes in a
separate routing table. This makes my main routing table
manageable/readable. Does rip44d put its routes in a separate table or in
the main table?
By default they go in the main table. There's a command line option,
-t <tablename> to make them go to a separate table, I guess most
people use it and have a separate '44' routing table.
2) I'm confused about the update/delete interval.
Some have said they slow
down the deletions to avoid problems with the main gateway (route sender)
going away. But others have said that rip44d doesn't remove routes if it's
not hearing from the route sender. In that case, it would be better not to
delay the deletions. Which is correct?
It'd be better to not delay, I suppose, just because of the (rare?)
case of a specific route getting replaced by a new, wider prefix with
a new destination address.
When initially writing rip44d I put in a longish delete interval just
to be safe, and only later I gathered it'd be smart to move the old
route expiration call to the received packet path, so that it's only
run after packets have been received. I guess the delete time could be
shortened now, if it becomes an issue somehow.
Comment: I did have to chuckle at Heikki's
comment about how important a
quick update would be if people were putting up useful services. To use a
service, I first have to know about it. And I'll probably learn about it
more than 24 hours after it's available. So 15 minutes routing udates don't
help.
Well, at some point, maybe a year after you've learned to love that
hypothetical useful service, the public IP address of the gateway
providing that service will change. Or your own gateway will need to
move to a new ISP. At that point you might appreciate the quick
update!
But what made me chuckle was the suggestion that
people would be
putting up new, useful services. Several on this list keep pushing for a
discussion of new services. But everyone seems to focused on routing.
Routing is probably easier for us than great services, and we have
experience on it already, and it does need some improvements. It
probably doesn't hurt to do that, too.
I run
http://aprs.fi/ myself (wrote it), and some 15000-20000 visitors
find it useful every day (well, at least some of them, I hope). I've
been wondering about bringing it to the amprnet side somehow, so that
it could be accessed from radio-based networks, and I could offer some
extra services (transmitting) to the amprnet clients. The tricky part
is the real-time map - Google Maps doesn't work from the amprnet, and
I'd have to run my own map tile service, which is a largish additional
effort. The rest of the site would work pretty much out of the box.
Ah, advertisements wouldn't work either, but everyone would be OK with
that.
1) Split DNS (yes, this is mostly hidden
infrastructure, but would help
with services that shouldn't be made publically available or with services
that get different treatment depending on if the user is in 44.x or not)
Someone could also run a reverse proxy service of some sort, which
would make non-commercial amateur radio services currently existing on
the Internet visible to the Amprnet, with the consent of the authors
of those sites. Or otherwise help those site owners to make them
available.
An easy-to-use chat service would be cool, too. conversd is a bit
dated although working, IRC is too technical for many (there are only
2 people on #44net channel of the Freenode IRC network). IRC with a
nice web chat interface on top? XMPP with any XMPP chat client + web
chat UI?
- Hessu, OH7LZB