> 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
> >/3) Obtained and compiled Rob Jenssen’s C program, configured it per the instructions. /> I have read the docs, looks pretty straightforward, though I have a bit
> of migration to do - after initial testing, I have several existing
> private proxies to migrate to the binary, then create the public ones on
> the 44.x addresses.
For everyone's info: I have updated the file at http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz
(also available on www.pe1chl.ampr.org on net44) to include an init.d script example and
a logrotate.d config file. Everything else is unchanged.
I welcome corrections or suggestions for changes in the README file when something
is unclear. Make sure you follow everything written in the file as it is now.
(especially the part about sysctl and the proxy_message logging)
I should probably some description of what proxies and relays are and how they are used,
that was already sent to this list however.
Rob
Hello 44net,
Not sure who I should address this issue to but I guess it's to you please
Maiko.
Would someone reassemble the jnos2.0k.tar.gz file to make it easier to
compile and run please? It must be a nightmare for the newbie.
Problem is that the installer2.1 is not included in the jnos2.0k.tar.gz. The
correct files.h is not included, the tun.c file does not work and should be
replaced by tun_sp1l.c under Fedora 26 and others. All these have separate
downloads and driving instructions.
The nos.cfg file does not seem to be included in the 2.1 installer either,
and was recovered from a previous install.
Not to mention the too and froing from my home directory to root after the
install was run.
So on top of all that, and after what seems to be a good compile of
jnos2.0k, the NETROM function still does not work and crashes after the 11th
line of the first nodes transmission. Almost looks like a memory overflow
but there is plenty supplied in the "qlimit"
Have tried jnos2.0k after a fresh installer2.1 and just added netrom and
still crashes the same.
I have tried to get "k" working after many attempts, directory changes, in
root and home, etc, etc but directly replacing the compiled jnos2.0k with
jnos2i or jnos2h exec and netrom works fine.
The last time I tried to capture the crash it locked up the PC.
Is jnos2.0k transportable between directories other than named "jnos" (tried
that)
I currently manually run jnos2i in my home directory under sudo
successfully.
Is anyone else running jnos2.0k netrom successfully and what is the fix
please?
The reason for the revisit to jnos is because I now have 50Mb down and 5Mb
up thru new internet service provider NBN/iinet.
Many thanks
Rob
Vk1kw
All,
I have made some extensive updates and edits to the OpenWRT WIki:
* Routes and rules are now included in the UCI
* The Startup script only sets up the tunnel and ampr-ripd, it has been reduced to 7 lines.
To do:
* Edits if ampr-ripd is added to the OpenWRT repo.
http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT
73,
- Lynwood
KB3VWG
UCSD is swapping out some networking equipment and amprgw (aka
gw.ampr.org, 44.0.0.1) will be unreachable for a while starting
around 7pm Pacific time Thursday (tomorrow). It should take only
a few minutes, but as both the connection and configuration have
to be transferred to the new equipment, there is always the
possibility that it will take longer or something else may go wrong.
- Brian
> The network equipment changeout at UCSD did NOT go well; they are
> still having problems with the network 44 routing into UCSD. There
> is yet no estimated time to repair at this moment. I'll update you
> folks as I learn more.
> As of 1:30 am Pacific time (GMT -7:00), everything is working again.
> - Brian
As you know very well, it always takes more time than estimated...
It affected our gateway since a script that downloads the DNS zone when
modified got stuck, halting a cronjob script that also performs other maintenance
tasks. Modified with some more safeguards... :-)
Rob