44net

44net@mailman.ampr.org

4 participants
3198 discussions

Re: [44net] OT: Recommendations for a small to medium size router for a multi-purpose repeater site
by Rob Janssen 11 May '18

11 May '18

I agree with what Marius wrote. Those models will perform very well in a network like that. We use a CCR1009 in our gateway for the 44.137.0.0/16 network (BGP routed on internet) and use it to provide VPN services to users and nodes inside the country, and to feed the radio network as well. The RB1100AHx4 should be equally capable of that. I would avoid the RB3011, should there be a tight budget or should there be a need for smaller devices at other places in the network it is better to use models like RB750Gr3 or the proven RB2011. As with any router and in fact with any device connected to internet, you will have to make sure it runs uptodate software (software can be upgraded for free as long as the device gets software updates, which will be quite some time for these models) and also you have to configure it in a reasonably secure way, e.g. make sure the management interfaces (telnet, ssh, webfig, winbox) are only accessible for your own people and not for the internet at large. This can be done by restricting them to certain interfaces, subnets, individual addresses on internet, and/or by using a VPN for management access. Keeping the management ports (22,23,80,8291) open on internet has proven to be a recipe for disaster. Rob

1 0

Wrong portal entry 44.151.31.6
by Marius Petrescu 11 May '18

11 May '18

Hello, There is a problematic entry in the portal which needs our attention: 44.151.31.6 / 32 via 44.151.31.6, according to the portal allocated to F1SXO, France, Occitanie, Haute Garonne The problem is that the RIP entry 44.151.31.6 via 44.151.31.6 is wrong, ilogical, and creates a routing loop. On Mikrotik routers, this will sow as a flapping of the ampr-44.151.31.6 interface. The solution for the moment is to filter that entry in the RIP filters and delete the 2 routes to it and its associated interface by hand. I had no time to check the behavior on ampr-ripd and amprd systems but is basically lead to the flapping of the route. After correcting this issue in the portal, on these systems, a remove of the static route 44.151.31.6 via default gw should be necessary (ampr-gw and amprd do not remove those static routes - known problem). The final solution is to correct the entry in the portal. Marius, YO2LOJ

2 2

Setting up a tunnel to my BGP's 44net range
by Tony Langdon 09 May '18

09 May '18

Now that my BGP announced 44.x range is up and running, I'd like to be able to make it transparently accessible for tunneled networks. I just need to double check a few things. First, I know I'd need to run ampr-ripd on the box. I also have non-44 net addresses to use as the ipip encap endpoint. What else do I need to do? Do I need to advertise the subnet as "tunneled" in addition to direct in the portal? Anything else? Reason for this is I'm likely to be running services other than Echolink proxies, which may require peer-peer connectivity. Currently, 44.x tunneled addresses connecting to the system would go via their local router, which most likely involves NAT. And on a similar note, is there a way to exclude other directly connected subnets capable of IPIP tunneling from using a tunnel? (since that's obviously not required!) -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

3 6

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 09 May '18

09 May '18

> How does Echolink distinguish "incorrect password" from other > conditions? Or does it assume that if a connection is dropped at a > certain stage, then it's an incorrect password? Well my description was from memory and not entirely correct. There are only two error codes that a proxy server can return to the client, one for "bad password" and the other for "access denied" (i.e. the presented callsign fails the check to the CallsignAllowed or CallsignDenied patterns in the config, usually using wildcard checks like "deny -R" to deny repeaters) However, there is no error code for "proxy busy", a busy proxy simply disconnects new users before they even authenticate. There is also no way to return an error message text, the error is returned as a code and the client issues an appropriate message to the user. So you cannot communicate a more detailed message like "this proxy is reserved for ...". However, you can use a private proxy (different password) to achieve that. > But yes, good idea, I can block incoming connections on TCP 8100 (proxy > port) on the IPs that conferences are using. Thanks for that suggestion. Indeed, when you setup your firewall to just refuse connects from other systems they will believe this proxy is busy. However, when the proxy used by the conference is private and (nearly) always busy, there is not much you need to do as it works fine by default. The worst that could happen is that someone DoS'es you by repeatedly trying to connect to the proxy at a time the conference server isn't connected and then proceed through the authentication as slow as it can, and once it gets disconnected immediately re-connect before the conference had a chance to do that. I have not yet encountered such behaviour. Rob

1 0

Re: [44net] Setting up a tunnel to my BGP's 44net range
by Rob Janssen 09 May '18

09 May '18

> Now that my BGP announced 44.x range is up and running, I'd like to be > able to make it transparently accessible for tunneled networks. I just > need to double check a few things. > First, I know I'd need to run ampr-ripd on the box. I also have non-44 > net addresses to use as the ipip encap endpoint. What else do I need to > do? Do I need to advertise the subnet as "tunneled" in addition to > direct in the portal? Anything else? That is all you need to do. There is no need to setup policy routing ("ip rule") in this case, and also you should not add any static routes such as a default route for AMPRnet traffic. Only use the routes provided by ampr-ripd and load them into the main table. Indeed you need to check "tunneled" in the portal. It is a desirable step for any BGP advertised subnet, not only for the echolink proxies, to do this. It will allow communication with those that are "only" on the tunnel mesh (i.e. they do not route towards internet, or do NAT when routing to internet), and it is more efficient than doing that via another gw like ampr-gw. And it is quite a simple setup. Of course you should also consider the effect on the firewall settings. Rob

2 1

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 09 May '18

09 May '18

> One thing I would like to be able to do with the proxy server is have a > whitelist and blacklist of local IPs, so no one can accidentally DoS a > conference running on the same server, or find themselves with a non > functional proxy (and a lot of head scratching!), because the UDP ports > are being used by a conference. If they connect on a blacklisted IP, > the proxy would simply issue an error saying connection is not permitted > (since the TCP side can safely be opened, this should work). Proxy servers do not issue error messages. They only thing they can do when they don't want your connection is to simply close it immediately, or refuse it entirely. You can solve that in the firewall. However, when you want to reserve a proxy for a conference or other usage, you can simply set a different password than PUBLIC for it. That will make it a private proxy which can only be used by a user or service who knows the password. (and it will not appear in the proxy list) Rob

2 1

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 08 May '18

08 May '18

> >/I think your best and safest bet would be to find a conference server /> >/that can use a proxy. /> I don't understand what you mean, this looks self evident to me. What I mean is: is the conference server that you want to use configurable so that it does not open a set of UDP sockets, but instead connects to a proxy server you specify (address, port and password) ? If so, just configure it to connect to one of the proxies you run in elproxy on the same machine and there will be no issue and no uncertainties. Of course, when it works directly on a set of UDP ports without disturbing the proxies and relays running on the wildcard socket on the same machine, that is fine as well. Rob

2 1

OpenWRT Pull Request and question about ampr-ripd
by lleachii＠aol.com 08 May '18

08 May '18

All, I hope some of you may be more familiar whit getting software added to Open Source projects than I am. Is this the primary location for the ampr-ripd makefile, or does anyone else maintain the makefile elsewhere? https://github.com/rufty/ampr-openwrt Also, in my ampr-ripd, I require the following line to compile for OpenWRT: #define IPPORT_ROUTESERVER 520 This is not reflected by a patchfile. Has anyone had success compiling ampr-ripd for OpenWRT without adding the line above? 73, - Lynwood KB3VWG

2 2

Re: [44net] OpenWRT Pull Request and question about ampr-ripd
by Rob Janssen 08 May '18

08 May '18

> All, > I hope some of you may be more familiar whit getting software added to Open Source projects than I am. Is this the primary location for the ampr-ripd makefile, or does anyone else maintain the makefile elsewhere? > https://github.com/rufty/ampr-openwrt <https://github.com/rufty/ampr-openwrt> I use the makefile supplied by the maker in the source .tgz file supplied on his site: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.3.tgz I have found no need to apply any patch. > Also, in my ampr-ripd, I require the following line to compile for OpenWRT: > #define IPPORT_ROUTESERVER 520 That define is normally found in this file: /usr/include/netinet/in.h Maybe you can suggest the author to add this in the code: #ifndef IPPORT_ROUTESERVER #define IPPORT_ROUTESERVER 520 #endif Rob

1 0

Re: [44net] Echolink proxy/relay hosting
by Rob Janssen 07 May '18

07 May '18

> I have seen that with tbd, which opens 5198 and 5199 UDP on 127.0.0.1 > for commands and chat respectively, while the default configuration has > Echolink listening on 5198 and 5199 on 0.0.0.0, so there is hope. Will > have to test further, though I was able to connect from my new proxy to > one of the conferences on the same box. I think your best and safest bet would be to find a conference server that can use a proxy. A service connected via a proxy has full functionality (this is different from a relay) and there is really no disadvantage to having a service connected to a proxy hosted on the same machine. Doing this, only the elproxy program has to open sockets for 0.0.0.0:5198 and 0.0.0.0:5199 and there are no conflicts. Of course it would still be interesting to know if a program can be listening e.g. on 44.128.0.1:5198 (UDP) while another program on the same machine is listening on 0.0.0.0:5198 and will receive all UDP to port 5198 except to address 44.128.0.1 Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net