44net May 2018

44net@mailman.ampr.org

33 participants
33 discussions

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

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

06 May '18

> Now that my IPs are propagating, I am attempting to convert my existing > 4 private Java proxies to your code. Looks like it is working, but I do > have some questions to avoid potential issues. The old proxies were > defined by IP address - IP addresses are very tightly controlled, > because there's a mix of proxies and Echolink conferences running on the > one machine. My program does not listen on individual addresses. It opens a wildcard socket for each port, receives the traffic and gets the addresses from the OS using special system calls. That way it can run serveral proxies and relays using only very few sockets, improving the efficiency of the select(). You can just move over the existing Java proxies to the C program. Stop the Java proxies and add their addresses to the config file of the C program. I have no experience with conferences, I do not know if they can co-exist on the same machine with the proxies. Probably not. It is probably best to use a separate (virtual) machine for them. However, I am not sure. It could also be that having the software that opens ports at an explicit address and these wildcard ports can co-exist. Rob

4 7

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

05 May '18

> If they both use the same ports they cannot coexist on the same machine. > Ports opened on a wildcard address cannot be used by other programs that want to open the same port on a specific address on the same machine > Ruben - ON3RVH Yeah I sort of remembered that, but I wasn't sure. Thanks. (it might as well have been possible when the kernel first checks the specific address sockets and would fall back to the wildcard socket when none matches) Unfortunately I have no experience with running conference software at all. When a conference can run via a proxy, it can still be done on a single machine! Just configure all the conference addresses as proxies, make these private, and connect the conferences to those. All UDP I/O will be via the wildcard sockets and the TCP connects can be local on the same machine. (selected proxies can be made private by configuring something like Password_51=mysecretpassword while the global setting is Password=PUBLIC) Rob

1 0

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

05 May '18

> Rob and all, > Not sure if my other message got to Rob but sending it here to group. I have sent two mails to you in reply to your direct message. When you do not see them, please check your Spam folder, and if it isn't there please send another direct message and I will send from a different mail address. @amsat.org mail is blocked by some providers. Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net May 2018