44net

44net@mailman.ampr.org

3187 discussions

Re: [44net] was Uncle "google" in hamradio network ? Repeater linking

by Steve L

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

9 years, 6 months

Re: [44net] Uncle "google" in hamradio network ?

by Steve L

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

9 years, 6 months

Re: [44net] Uncle "google" in hamradio network ?

by Steve L

I just recently completed an nmap of the routed portions: http://kb9mwr.ampr.org/public/nmap/030516routed.txt http://kb9mwr.ampr.org/public/nmap/030516nmap.txt I did the same thing a few years back but there was that IPIP,<-> BGP problem I too have yacy installed. I just started it back up. I am not to familiar with it, how do it get it to crawl the amprnet?

9 years, 6 months

Re: [44net] Uncle "google" in hamradio network ?

by Steve L

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

9 years, 6 months

Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers

by Rob Janssen

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

9 years, 6 months

Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers

by Rob Janssen

> 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

9 years, 6 months

DMZ or not?

by Rob Janssen

> 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

9 years, 6 months

Re: [44net] ampr-ripd for openwrt

by lleachii＠aol.com

http://44.60.44.10/amprnet_docs/ Should be available at this time to the Internet at-large. - Lynwood KB3VWG

9 years, 6 months

D-Star

by Pedja YT9TP

We are planing on setting up D-Star gateway, so I am reading all I can about it. Here is exception form one tutorial regarding this: "The router for the D-STAR gateway must support a LAN address of 10.0.0.1, with a full class ‘A’ LAN (subnet mask of 255.0.0.0)." Is it just me or this is really strange to force this IP range which will conflict with number of private networks, especially when there is 44net dedicated for ham radio use? Pedja YT9TP

9 years, 6 months

Re: [44net] D-Star

by K7VE - John

Let me explain the whole 10.x.x.x thing for D-STAR. Icom created this to meet concerns of the Japanese postal service, to help mitigate the concerns of TCP/IP over D-STAR displacing the ISP monopoly. In D-STAR, the digital data mode transports Ethernet packets (and in turn TCP/IP) as a payload to D-STAR packets. Routing is done based on the D-STAR addresses which are call signs plus an optional "Terminal ID", essentially an 8 octet address. If you are using the Icom G2 (or V1) gateway software it talks to the Icom RP-2C controller over Ethernet using 172.16.0.x addresses. On the controller you can add up to 4 modules. A module can be a D-STAR voice repeater (2m, 70cm, 23cm) or D-STAR data access point (23cm 128kbps). In theory then you could have up to 4 D-STAR data access points (model RP-2D). As traffic from the RP-2D modules come into the gateway, it assumes it has a unique IP address in the 10.x.x.x range (assigned by a registration process), but routes according the D-STAR addresses. The IP addresses are registered to attempt avoidance of address collisions. So if I as 10.10.10.1 (K7VE) want to contact NN1XYZ (10.3.2.1), the gateway software sends the Ethernet packets from D-STAR address K7VE to D-STAR address NN1XYZ. The 10.x.x.x addresses are also NATed out to the Internet if the destination address is not in the 10.x.x.x range. None of this is used if you are only doing Digital Voice over D-STAR. Everything is routed by callsign and the voice packets do not encapsulate any TCP/IP or Ethernet content (well you could but it is not standard). Now the reality is G2 is closed and largely stagnant, it also runs on Centos 5.x which is losing update support, many data facilities have security concerns if you are hosting with them. The larger network is now running on ircDDB (ircddb.net) using ircddbgateway (see Yahoo! group by the same name). ircDDBGateway is Open Source and is pretty agnostic on Linux distributions as well as being available as a Windows application. ircDDBGateway supports the Icom controller as well as a variety of alternate controller options. I would strongly encourage any new D-STAR install to use ircDDBGateway (or another ircDDB based gateway). You don't have to use the Icom addressing scheme. The RP2C can be on a LAN address. Client stations of the RP2D (ID-1 radios) can then use LAN/DHCP addresses (including 44-net). -- ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays>

9 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net