Hi,
Many years ago we used as main application the terminal to the connections of
the BBS
Currently we use modern solutions in hamradio network such as WIFI and main
application which we use is web browser to see many WWW pages
On our club www page we have small collections urls to others
http://sp2pmk.ampr.org
but it is not good solution
In Europe we have a system with a database of web sites, search engines based
on yacy:
http://search.db0sda.ampr.org/http://web.oe2xzr.ampr.at/http://44.134.190.114/lsp_map.cgi
etc
How to find others www pages outside Europe for examaple in US or others
places
Anybody know or exist similar solution in US ?
It will be fine to travel via 44/8 network and see and read other www
hamradio pages individual or club station. Sometimes we can find on
hamradio amprnet/hamnet www pages interesting information or solution.
--
Waldek sp2ong
There isn't a whole lot of entries in the wiki services list. I am
not sure how many net 44 users are on this list and or know about
that. I personally find wiki markup coding a pain as its not native
to me. Another thing is maybe some people would rather share service
details after a portal login rather than somewhere that gets scraped
by google.
To me it sort of make sense to briefly explain what your doing in the
network allocation area and/or gateway areas of the portal.
In my quest, one thing that caught my eye was this Michigan repeater
linking/microwave project. Mostly because they are closer to me in
Wisconsin.
https://w8cmn.net/tiki-index.php?page=Mi6WAN-MAIN
I recall someone on this list no that long ago from overseas was doing
a similar project with Asterisk/app_rpt and 802.11.
Elsewhere (reddit/slashdot) I recently read about the Mid-Atlantic IP
Network ( I think they aren't using 44net though), same type of thing.
I like the idea, and have been looking to try the Asterisk/Allstar
RTCM to add a voted receive site, but transported over a microwave IP
link.
We just did a tower climb today here in Wisconsin and replaced some
damaged 802.11 gear. And had an offer from a broadcast group for some
tower space. I am hoping 2016 is the year things take off a bit
locally.
Steve
Thanks for the info. Looks like the info I need to use it for our purposes.
Some time back there was a resource list that Jim Fuller maintained
that was handy to list what was all out there.
>HiHi
>Not the whole one, for shure.
>Just your "local area" and then report to the yacy network.
>
>Have a look here after google translated it for you ;-)
>http://www.amateurfunk-wiki.de/index.php/Suchmaschine
>
>73
>2MIC
No, and I'll admit that. That is why I'd like to hear more about how
to configure yacy.
But since there isn't a search engine or otherwise way yet to get an
idea what is on the amprnet and what people are doing on the address
space, I couldn't really think of any other way.
The links below will only be active for a short time, as it's really
only meant for 44net folks to get an idea.
Steve
>> http://kb9mwr.ampr.org/public/nmap/030516routed.txt
>> http://kb9mwr.ampr.org/public/nmap/030516nmap.txt
>
>> I am not to familiar with it, how do it get it to crawl the amprnet?
>
>Is this wise?
>- Brian
I don't understand your consideration of "moving from a star to a mesh".
We ALREADY have a mesh! There is no load to be removed from AMPRGW other
than the routing from/to internet for those that are not directly BGP routed on internet.
When you want a solution for the "single point of failure" for RIP announcements, the
simple solution would be to deploy a second RIP annoucer elsewhere, that sends the
same information as AMPRGW, and takes over when AMPRGW does not send those
announcements. Of course it still needs to be fed with the same topology information,
so it could be tricky to get a solution that does not have any single point of failure, but
your solution of doing BGP over tunnels instead has such information embedded in
the static configuration of all the peers, which is even more difficult to manage.
So it is not really clear to me what such a change really would achieve what we do
not already have.
What is the status of usage of AMPRnet addresses in HSMM? In the past they used
RFC1918 addresses that were automatically allocated. I believe newer versions can
use static addresses that could als well be from NET-44. Is this already in wide use?
Rob
> a.) then how would a new or offline IPIP station connect if AMPRGW were DOWN at the time?
This is not a task of AMPRGR but of portal.ampr.org
> b.) then how do I get routes from AMPRNet without a DIRECT CONNECTION tunl0 connection to AMPRGW?
As I wrote is is possible to deploy a second system that does the RIP announcements
> c.) what if I can directly reach 2 or more AMPR subnets (but not the Internet)?
We already have a large network of radiolinks running here in Europe, and I think also in some
other areas of the world. It does not rely much on the internet, except for DNS. I download
the ampr.org DNS zonefile daily so I have it available when we are offline.
> a.) AMPRGW is currently the only route announcer (but you address that elsewhere)
I think it is important because it is the only weak spot I can see.
> b.) Next, it's not the ideal route to all subnets
Why not?
> c.) this solution addresses the possibility of redundancy to other subnets, as well as AMPRGW
I don't understand. There already is full redundancy. We have a full mesh.
> In planning, it would probably be an alternative to IPIP, and not a replacement. Ideally, there could be a few regional gateways, other stations connecting to one or more regional gateway and to other end-user gateways.
That is how we run the network here. What is your proposed change?
Rob
> I host a 70cm echolink node and did not need to place that PC in the DMZ.
> I did need to forward UDP ports 5198 and 5199 to the PC running echolink. I don't
> remember whether I also forwarded TCP port 5200 or whether that "looked after itself".
You are right, only forwarding 5198 and 5199 UDP is sufficient.
The echolink program also makes outgoing connects to port 5200 on the central server but you
normally don't need to open or forward anything for that, it is just the normal outgoing NAT.
(there are instructions that mistakenly mention port 5200 to be opened, but the program is not
even listening on that)
Rob
