> 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
> 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
> 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
> >/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
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
> 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
> 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
> 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
> 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
> 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
