- 44net - mailman.ardc.net

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 09 May '18

09 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 08 May '18

08 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

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

05 May '18

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

3 2

jnos2.0k problems
by vk1kw 02 May '18

02 May '18

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

1 0

Edits to OpenWRT Wiki
by lleachii＠aol.com 01 May '18

01 May '18

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

1 0

GW (amprgw, gw.ampr.org) downtime tomorrow evening
by Brian Kantor 27 Apr '18

27 Apr '18

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

7 11

Re: [44net] GW (amprgw, gw.ampr.org) downtime
by Rob Janssen 27 Apr '18

27 Apr '18

> 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

1 0

Re: [44net] An apology for the Internet from the people who built it
by Rob Janssen 27 Apr '18

27 Apr '18

> Now you got me! Atari ST! I was responsable of the Montreal Atari Club BBS when it was on 8 bit and 16 bit. Still play a few games on my ST emulator.. Remember when we ware able to simulate a MAC with a few roms and a ST? 😉 > OK, back to our regular programing. Think we got back way too far on memory lane for this mailing list 😉 I still have a Mega ST4 with harddisk cabinet and original monitor sitting in a spare room but it rarely gets switched on these days. (those were the newer pizza-box style ST and disk. the disk cabinet in fact is a 44MB swappable plus a fixed disk) This one is fitted with an ethernet adapter I made (a PC ethernet card and adapter board to the internal bus) and I added a driver for it to KA9Q. However, the card has BNC and AUI only and I don't have coax ethernet anymore. Should have an AUI to RJ45 adapter somewhere. Also in storage there is a Mega ST2 with an 8-port Z8530 SCC card that we used for years on a major network node (TCP/IP and NET/ROM)... (of course I had a 520ST as well but that one has long been scrapped) Rob

1 0

Re: [44net] An apology for the Internet from the people who built it
by Rob Janssen 26 Apr '18

26 Apr '18

> Trumpet Winsock :-) > I Installed Windows NT on my 386/40MHz (some 35 3.5 floppy disks) which > barely run on it, but had the necessary dialup software just to download > Trumpet Winsock to use it afterwards on Win 3.1 on the same machine > (only some 15 disks to reinstall)... > Later came Win 3.11 which had a TCP/IP + Internet explorer 3 addon which > made Trumpet Winsock and Mozaic obsolete. > That where times... When I got access to "the Internet" (of course via dialup modem too) I already had a running Linux system with native TCP/IP networking. I installed that in december 1992 on a 486/33 MHz with 16MB RAM. And a QIC cartridge tapedrive, so no messing with floppies. The internet became available for the general public in 1993 here, I joined in 1994. But of course I had been using TCP/IP since 1988 using KA9Q NET on the Atari ST. Rob

2 1

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

26 Apr '18

> I just applied for a /24 out of 44.190/16, to help with this endeavor. > I’ll be announcing the prefix out of a commercial datacenter in Fremont, CA under ASN 7247. > 73, > -jav k4jh Jav is the first one to get his proxies/relays running as a result of this call. He said "This was easy!". Rob

5 5

An apology for the Internet from the people who built it
by Brian Kantor 25 Apr '18

25 Apr '18

Although not directly related to AMPRNet, I found this article quite interesting: http://nymag.com/selectall/2018/04/an-apology-for-the-internet-from-the-peo… - Brian

8 9

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

25 Apr '18

> FYI folks...I used to run proxies on my subnet in the past. The only > issue was, that since subnet is not not BGP, it was intended for your > use only (i.e. not using AMPRGW for Internet, but still able to use > EchoLink). I agree it is probably not a good idea to run proxies or relays on a network only connected via tunnels. That would pose a load on AMPRGW. In that case it would be better to run them there. But other volunteers in that area have now stepped up. > I used the Java JAR that was available form EchoLink (I understand you > have a C program). I also used the Linux version, but the EchoLink > Validators stated that should not be used without permission (and only > for conference servers). The Java version uses lots of resources... The C program was written to mimic the Java version closely but in a more efficient way, both because it is in C and because a single instance can run multiple proxies. Later I received the C source of the relay program from EchoLink and merged its functions with the proxy program so these can both run on the same system. This is in full agreement with EchoLink, and they very much welcome the hosting of proxies and relays around the world to help users that are on limited internet connections or are not proficient in configuring port forwarding on their routers. Fortunately in our circles we have people who understand the internet and its protocols. (vs the applications that are now called "the internet") Rob

1 0

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

25 Apr '18

> >/when the directory server is on AMPRnet, the problem with NAT between /> >/HAMNET and internet disappears / > I'm afraid, it would raise new issues... > For those who are planning to provide echolink proxy services (or any > other useful internet based amateur radio services) within the AMPRNet > by direct BGP, please ask for an /24-allocation within 44.190.0.0/16. > We will promote to all HAMNET users and sysops to route 44.190.0.0/16 to > their ISP rather than to their radio device on the roof. > Best case would be to host such services on non-44 IP-space at all. As you know, I don't agree with that. We should not segregate our addresses into different classes and force everyone into some class depending on what they want to do. It is a stopgap measure that will lead to endless changes and work, and it isn't even clear what "internet based amateur radio services" are exactly. For example, our repeaters are on Echolink on their AMPRnet address, they would be such services, we would have to route part of that space deeply into our network to get "special" addresses all the way there. Not going to happen! At the moment I am in contact with the Jonathan from Echolink and he is interested in setting up more relays as his existing relays in the US are getting overloaded. (he has temporarily moved some US users to our relays in Amsterdam) I think now that this is under change we could suggest moving everything to AMPRnet and it should solve the NAT problem there is now. Maybe the directory server could have both an AMPRnet and a public address to resolve remaining issues. Rob

5 4

Re: [44net] An apology for the Internet from the people who built it
by Rob Janssen 25 Apr '18

25 Apr '18

> "from the people who built it". Really? Gee, I don't remember any of those > names back in the early 80s (except for Stallman, but Emacs is not the > Internet). I fully agree! When I saw the list I immediately thought "those aren't the people who built the internet!" Not even the world wide web. Maybe Web 2.0.

2 1

New Mikrotik Vulnerability
by Nigel Vander Houwen 23 Apr '18

23 Apr '18

Hello All, We’ve (HamWAN) become aware of a new vulnerability on the Mikrotik devices that could allow an attacker to grab passwords off of the devices. If you block WinBox access you should be safe, but I’d recommend upgrading as soon as possible as well. More information about this vulnerability, as well as what versions are impacted, and what the patched version numbers are, are available from Mikrotik here: https://forum.mikrotik.com/viewtopic.php?f=21&t=133533 <https://forum.mikrotik.com/viewtopic.php?f=21&t=133533> Thanks, Nigel

1 0

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

22 Apr '18

> I found your C program in your follow up emails so seemed like I > should have everything I need. Sorry for the confusion, initially I > thought i needed to contact you for the C program. It probably wasn't clear in my first message... there is no need to contact me to deploy Echolink PROXY servers, the C program has been on my server for a long time (others are using it as well) and it can be installed on AMPRnet or commercial IP addresses alike. However, there are already quite some proxy servers and there is no immediate need for new ones, although they are always welcome. The call was mainly to get a number of new RELAY hosting sites, as there are currently not enough of them. Running PROXY servers is a good way to get some experience using the program, making sure it is started automatically and remains running, arranging for the extra addresses on the system (I do that using a script that does "ip addr add 44.137.75.$i dev eth0" in a loop, but it can be handled via the native network management of the distribution just as well. just don't create an extra interface for each) Once that is all clear and comfortable, RELAY servers can be configured (about 10, but in such areas as the US west coast maybe 5 is better as there are several volunteers now) and then you can contact me or K1RFD with the IP addresses so that they are going to get registered so they are really used. This is not required for PROXY servers, these register themselves automatically. Rob

1 0

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

22 Apr '18

> I like to help with this as well. Please let me know the details on how to > setup your C program. I know I am a bad writer, but I'm afraid you have to do with what is already in the README file and what I explained here on the list. Note it isn't really a beginner project, it assumes you are familiar with running a Linux system and compiling your own software on it. As a baseline, you are supposed to know what to do when you find a .tar.gz file and seeing that it contains a README, a .c file, a Makefile and an example configuration file. When there are obvious omissions, I am willing to update the README. Rob

2 1

44net IPIP tunnels may now be illegal in Russia
by Brian Kantor 22 Apr '18

22 Apr '18

44net IPIP tunnels may now be illegal in Russia. This is really not news, in that it's almost a year old, but I just became aware of it: https://www.bleepingcomputer.com/news/government/russia-passes-bill-banning… Russian users of 44net should be aware of this. - Brian

1 0

Echolink proxy/relay hosting
by Rob Janssen 22 Apr '18

22 Apr '18

For some time we have been hosting Echolink proxies and relays on the system that is the gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for that. Such proxies and relays facilitate the use if Echolink by users and repeaters that are behind NAT or are otherwise firewalled. About 100 repeaters around the world use our proxies, and over 600 users of the mobile app use our relays. Each Echolink proxy and relay requires a different IPv4 address. This can be a static address on internet, but often people have no /24 to spare for such things. AMPRnet provides the required address space. (unfortunately with an unintended side-effect, but in general it works well) For performance of the Echolink system it would be best when there are more places with a similar setup, distributed around the globe. Are there other BGP-routed sites outside Europe where such a service could be run? I have written a C program for this, that uses considerably less resources than the original Java software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and 10 relays. Of course it makes some network traffic, about 3 GB/day for the relays and similar for the proxies. When you have your gateway located in a suitable datacenter and are interested in such a setup to facilitate Echolink, please send me an e-mail and I can provide more info. Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would solve the problem there now is with partially connected AMPRnet networks. (when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears) Rob

14 20

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

22 Apr '18

> This is not a special problem for the 44.190 space. It affects every > direct connected 44 announcement for those users that cannot use IPIP > tunneling because they don't have a plain IPv4-connection. In Europe it > is very common to give normal customers a so called "DS-Lite Connection" > or a plain IPv6-connection. Everything that must be reached in the > IPv4-world from those custumers sites mostly goes through this ugly > "carrier-grade-nat (CGN)" which in most cases doesn't work very well for > our special needs. IMHO the preferred solution for this is to setup regional routing points where IPIP (and preferably BGP announcement) is possible, and where those users that have limited internet connections can connect via a VPN technology that still works for them. This way, their HAMNET traffic can be forwarded untranslated. It is the method that we use, and various others do it as well. As was shown before on this thread, VM/VPS services that can be used for this are widely available. And those do not suffer from having CGNAT or dynamic addresses. At least not yet. Rob

1 0

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

22 Apr '18

> Wasn't the idea to 44.190.0.0/16 subnets available via BGP? If so, why > would there be NAT? Of course for directly connected networks there will be no NAT, but there are those networks that are connected to internet via consumer internet connections (and no IPIP tunneling) and the traffic from those networks to the 44.190 space will pass through NAT routers. Rob

2 1

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

21 Apr '18

> I've run several proxies for years, but for this new venture, I will > have to go over to the proxy software that was mentioned here > yesterday. Should free up a bit of RAM to do so, Java is a hog! :) The Java proxy server requires 25-30 MB of memory for each instance, which can run 1 proxy. The C version I wrote uses about 2.5 MB of memory to run 200 proxies and 10 relays in a single process. Rob

2 1

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

20 Apr '18

> Well, I have a VPS in Melbourne, which runs IRLP reflector 9550, among > other things. I currently have a /28 of public (non AMPR) IPs, which > are fully utilisied by Echolink. I could ask about getting a /24 BGP > announced, so I could participate. That would be great! You can start getting a /24 (from your country network or from that 44.190 network, that does not really matter when you are not close to another network like Germany) and setup your system to be on the tunnel mesh. Then you can experiment with the software. In parallel you can get your BGP announcement fixed. > One thing I am not seeing addressed by this proposal is what happens > with the nodes themselves, which are the the most problematic part of > Echolink (and IRLP) due to their incompatibility with NAT (requiring > port forwarding to work at all). That is what the whole proxy/relay thing is about. A proxy lives on a system with unlimited UDP access from/to internet (port 5198/5199) and it also listens on port 8100 (default) for TCP connections from a repeater, link or user who is behind NAT. When a user connects it relays the UDP traffic from those ports to the TCP connection, and vice-versa. So it solves the NAT problem for that specific user, while preserving full functionality (the user behind the proxy can connect to several other stations and accept connections from other stations all at the same time). But a proxy can be used only by one user at the same time, that is why you want like 200 proxies. Proxies register themselves at Echolink.org, and a user wanting to use one can retrieve a list from the server and select one, some clients can automatically pick a non-busy proxy from that list. The Echolinks server sorts the list by geolocation distance to the requester, so your own proxies will appear at the top of the list. At least, when you have setup geolocation properly for your subnet. When you carve your subnet out of a country network this will work automatically when your coordinator has properly registered the country network. When he/she hasn't, your subnet will likely appear as located in San Diego, California. But you can fix that by sending a couple of registration requests to the most important geolocation providers, easlily found by googling for IP geolocation. This is another disaddvantage of the 44.190 space: you will certainly have to solve this problem yourself. A relay is a bit different. It allows only limited functionality: only outgoing connections, only a single destination at a time. It is used by default by the phone apps. A relay can serve multiple users at the same time, but the group of users can only connect to different destinations. When a user of a relay wants to connect to a destination (e.g. a popular repeater) that has already been connected by another user, the relay will refuse the connection and the app will have to hop over to another relay to try it there. That is why it is suggested to run 10 relays at each site. Relays are not automatically registered. They need to be manually registered at Echolink, who will put them in a geo DNS so users will get their address when querying relay.echolink.org and being closest to your relay. Try a dig -t a relay.echolink.org to see what it returns for you (most likely it will return our relays at 44.137.75.x in Amsterdam, not really close for you :-) That is what we are trying to solve by getting some more relays deployed. But first you can experiment with proxies, you can turn them on or off at your own will. Once you have started to run relays you need to take care that they remain running or when you want to quit, to tell that to the Echolink people so they can take them out of the pool, so users will not have to try to reach them in vain (until they try one that still works). Rob

2 1

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

20 Apr '18

> I think original routing methods are not easy to use and have drawbacks : > - eBGP is not available to end-users, or even to small teams or repeater > operators. It requires network skills, and access to telecom operator > data centers. I think end-users or teams should not try to use eBGP unless they want to do it as another learning project as part of their AMPRnet gateway. Announcing your AMPRnet allocation on internet is simply a matter of telling your colocation/VPS hosting company that you have portable address space that you want to announce on internet and route that to your server or router. That is a standard change in their portfolio, they do that for lots of other customers and for them it is a simple matter of configuration in their existing network. They know how to do it and they already monitor it. When you do it yourself, you will have to get an AS, peering, setup your router, cope with the vast amount of routes and the processing and storage they require, etc. Not something to embark on lightly, and usually not necessary at all.

4 6

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

20 Apr '18

> As far as I can tell, one of them (VE7ALB) is in Canada, and the > other three (KK6NEI, K4JH, W6KWF) are in California and plan to > locate their Echolink relays in the same data center in Fremont, > California. I wonder if it would be beneficial for those three to > pool their resources in some way? I agree that is not an optimal situation. It would be better to cooperate and maybe setup 3 or 5 relays each, and some proxies. It can be good to have some redundancy but it makes little sense to have 30 relays and 600 proxies all in the same state. I wasn't aware that this is the case, the USA is big and relays in California, New York and Texas would have been fine :-) Rob

1 0

Echolink proxy/relay hosting
by Rob Janssen 20 Apr '18

20 Apr '18

> I just applied for a /24 out of 44.190/16, to help with this endeavor. > I’ll be announcing the prefix out of a commercial datacenter in Fremont, CA under ASN 7247. I advise you (like is best for everyone who announces 44Net space on BGP) to make the system part of the IPIP tunnel mesh as well. I.e. make a tunl0 interface and run ampr-ripd on it, register it as a gateway using an extra IP address outside the /24 subnet. Add only the routes received over RIP, not a default route to ampr-gw. Of course you have a default route to your BGP router. This ensures that you are reachable for all AMPRnet hosts as well as normal internet systems, even when they cannot route their traffic transparently over internet themselves. It looks like we have 3 interested parties in the US and Canada, which would certainly help out for now. It would be nice if someone in the far east or Australia could join in. We always have a large number of users from Thailand, for example. Rob

3 2

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

20 Apr '18

> One of the main purpose of amateur radio is to experiment new things. > Then, I think it's globally a good idea to experiment new routing > variants, that are more suitable with today and tomorrow usages. Of > course, this will raise compatibility issues and routing problems. But > that's our job to find solutions :-) In general I think that is true. But in this particular case, that experiment is just there to work around unfortunate decisions made in the past. I can understand that it is now a lot of work to re-work the German HAMNET to make it compatible with a plain routed address space, but I do not see it as my responsibility to jump through hoops instead. When it would be a simple change, I would not have a problem. But as it is now, it is just as much work for us to cover their irregularities than it is for them to adapt their network. In that case I favor the "clean solution". > Here, in Corsica, we'll try to adapt our home-made system (OpenVPN > tunnels to two central gateways, and OSPF routing through 10.0.0.0/8 > private addressing) to AMPR addressing. One of the main advantages is > that user connection is very easy (we developed a Plug and Play system > called "TKBox" : an OpenWRT router, which opens VPN tunnels to our two > data centers, in VPN pass-through mode). It's suitable for a remote > location such as our island, because our two data centers will be the > only points of connection with the outside world. All the specific > routing and firewalling has to be tone only there. That is very similar to what we do here on the 44.137.0.0/16 network and you will not encounter the difficulties of NAT when you do it that way. All traffic internal and outside of your network is just plain routed. We use OpenVPN only for end-users that connect to our gateway and get 44Net space but only over the tunnels. However, that is the "novice class" of AMPRnet, we really do not want users to connect that way forever. They should use radio links, and when no access point is available they should get together and establish one. And that is developing rapidly. Of course access points would ideally be linked to other access points via radio, but until their density is sufficient to make that possible we also allow a VPN connection to a central router located in the datacenter, either GRE or L2TP/IPsec, and we run BGP over that connection so it can be used for the connectivity to AMPRnet or as a backup in case their are problems with the radio link. Radio links have preference in the recommended BGP setup. In this network we have untranslated internet access for every station because we do not directly send traffic on a user's internet connection (only the tunneled traffic to the central router that forwards the encapsulated 44Net packets to internet). In my opinion that is the correct way to do it. Of course if you want to setup many gateways like that across a larger country, the practical difficulty is that you need to negotiate BGP routing in many places. It is so much easier to just give in on that and go out via NAT over some local amateur's internet connection. But it causes the problems that Jann is now facing. Rob

2 1

Fwd: Massive IP blockings in Russia
by Brian Kantor 19 Apr '18

19 Apr '18

[This has been forwarded to a number of mailing lists, but in case you haven't already seen it, you may find it of interest. This copy was received from the NANOG list. - Brian] Begin forwarded message: From: Alexander Isavnin <isavnin(a)gmail.com> Subject: [cooperation-wg] Massive IP blockings in Russia Date: April 17, 2018 at 1:36:33 PM EDT To: cooperation-wg(a)ripe.net Dear colleagues! I'm not pleased to inform you that RosComNadzor, a Russian Communication supervisory body, has started blocking huge ranges of IPs belonging to different cloud infrastructures, mostly Amazon and Google Cloud. Those ranges include: 13.52.0.0/14, 13.56.0.0/14, 18.184.0.0/15, 18.194.0.0/15, 18.196.0.0/15, 34.192.0.0/10, 34.240.0.0/13, 34.248.0.0/13, 35.156.0.0/14, 35.160.0.0/13, 35.176.0.0/15, 52.0.0.0/11, 52.192.0.0/11, 52.208.0.0/13, 52.28.0.0/15, 52.58.0.0/15, 54.144.0.0/12, 54.160.0.0/12, 54.228.0.0/15, 54.72.0.0/15, 54.88.0.0/16. Russian ISPs MUST fully block all traffic to such networks. The list is frequently updated and gets automatically propagated to ISP every once in a while, failure to block any address may result in 1500eur fine. The infrastructure listed above is being added to the blocklist under 'counter-terrorist and counter-extremist' order of the General Prosecutor Office, #27-31-2015/Id4082-15, issued in 2015 and often used for blocking an arbitrary unwanted content. The real reason for such blocking is an attempt to cut access to Telegram messenger, which refused to provide end-to-end encryption keys to the Federal Security Service (previously known as KGB). This is a case similar to San-Bernardino shooter's, where the FBI was denied access to the shooter's iPhone, but courts in Russia have made completely opposite decision. Telegram's infrastructure is being blocked by a different decision by RosKomNadzor, #2-1779/2018. Cloud infrastructures are being blocked for massive proxy and VPN hosting used to dodge messenger blocking. It is said, that more Apple and Google networks may be blocked soon for apps updates and push notifications delivery for Telegram. We hope to still have the global IP connectivity to keep you informed about how the situation develops. Do not be surprised if some of your services placed in cloud infrastructures will miss Russian customers. You can monitor the number of IP addresses, domains and URLs to be blocked in Russia at the https://2018.schors.spb.ru/ page (run by the famous ENOG community member Phil Kulin). Detailed information (also via API) is available at the https://reestr.rublacklist.net run by RosKomSvoboda civil society group. Kind regards, Alexander Isavnin Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ----- End forwarded message -----

5 6

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

19 Apr '18

> Thanks for posting this. I didn't know. The last I heard about that, it would be a block at the end of the address range.... because it would be easier to route "everything except this". Apparently it was changed again. (I also didn't know) Rob

1 0

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

19 Apr '18

> I actually have some server resources where I was considering hosting a large echolink proxy service for echolink users however I have run into issues getting fiber providers to bring the ip’s in for me to use.. So I am not sure what my next step should be considering returning my ip’s if I can’t seem to follow through. > By the way I have to use Java for minecraft servers so my 12 core 24 thread should easily handle a bunch of proxy servers.. However if you have some thing that is Linux based and works well I would be all ears to help out the community using the newer code if willing to share.. The proxy/relay server we use can be downloaded from my webserver: http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz It runs on Linux, and probably on BSD as well after some changing of sockopt names. We have been using it for a couple of years. There is one small race condition that I still haven't been able to locate, I plan to try to convert it from the use of select() to using poll() and hopefully get rid of that. But still it runs for months on end, sometimes losing one or two proxies that get stuck in the logon phase. It requires a system with a number of IP addresses that are routable to internet. They can be AMPRnet or other public space. Rob

1 0

Openwrt x86
by pete M 18 Apr '18

18 Apr '18

Hi! I have a dual Nic micro atx MB that I use as my main router on my 120/20 MB residential connection. I was wondering if it would be possible to have a 3rd nic (pcie) that could be use as the apmrnet gateway to hamprnet for my allocation. I dont want to have my local home net available on 44 net but if I need to hook up my segment to the internet I want it to be available. I am not bad on linux, but I am not a network engineer. Been playing with wds ap/station captive portal and modding routers. but this is just over my knowledge base. Anyone willing to help? Thanks Pierre VE2PF

5 13

Unable to rsolve host error in the portal
by R P 17 Apr '18

17 Apr '18

Hi I have entered new ddns.net name to one of the gateways i have installed and while pressing the save button got "unable to resolve host" error The name is resolvable ... Is the Portal lazy ? Any info is welcome Ronen - 4Z4ZQ

2 4

Meraki/MikroTik running ampr-ripd on OpenWRT
by lleachii＠aol.com 16 Apr '18

16 Apr '18

All, I wanted to inform you all - that I have successfully compiled and ran ampr-ripd on a Meraki (Power PC) and MikroTik (Atheros, the binary for my previous routers worked). I have included the PPC binary in the 2.3 TAR on my site (along with x86_64 and Atheros ar71xx). Its only dependency remains: libstdcpp. 73, - Lynwood KB3VWG

2 1

New Global DNS server
by Brian Kantor 05 Apr '18

05 Apr '18

Cloudflare has announced a new internet-wide DNS resolution service. There's a good writeup on it at https://blog.cloudflare.com/dns-resolver-1-1-1-1/ This bit of news isn't much advantage to people on the tunneled AMPRNet, but the writeup is nonetheless interesting. - Brian

10 16

Re: [44net] New Global DNS server -> More about AMPR DNS ?
by Rob Janssen 05 Apr '18

05 Apr '18

> Not much details there. I see DNS updates are to be done by the > coordinators. As they are volunteers, and as they may be very busy, this > may not be compatible with a quick update required by a growing network But you can be the volunteer yourself! > Our plans were to get a subnet large enough for our island, and to > manage the "internal" subnetting locally. You have presented your plans before, and here everyone is wary that a network on a comparatively small and rural territory like Corsica (330.000 inhabitants) only used by radio amateurs is not likely to be as large as you picture it. We all know about the difficulty in getting IPv4 space on internet, but using Net-44 space for a Wireless ISP that just happens to have a couple of radio amateurs in its admin team is not the way to go. So you will have to present convincing evidence that this is not what is going on. > I'm wondering about what would be the best solution : > - Use an independant domain name (ie, "radioamateur.tk") > - Use a subdomain of ampr.org (ie, "corsica.ampr.org"), with a > sub-delegation from the parent "ampr.org" domain > In both solutions, we would have immediate access for local updates, on > our local DNS servers. Different networks prefer and use different solutions. Some use an independent domain, some use sub-delegated subdomains, others are directly under ampr.org. Each of them of course has advantages and disadvantages and each sees it in a different way. On the Dutch network we put our addresses directly under .ampr.org and use the main DNS servers. For updating, I am using a script that automatically sends the updates to the server based on a local hosts file I update with newly assigned addresses. Whenever I run the script, which automatically happens once a day, the diff between the current and previous version is made and all changes are sent to the robot by mail, and appear in the global DNS some minutes later. I also download the zone file and keep it locally for use when the internet connection fails. Systems using our local resolvers (44.137.0.1 and 44.137.0.2) still have .ampr.org resolution, for those addresses not sub-delegated. This way I don't have to worry about providing DNS service on internet (which is a can of worms...) and still everyone has access to our names. Reverse also works, which is usually a problem on the independent networks. Rob

2 1

Re: [44net] New Global DNS server
by Rob Janssen 02 Apr '18

02 Apr '18

> Tell that to Cisco that uses 1.1.1.1 as part of their default config for the wireless access points. It appears that Cisco is well aware of the mistake that they made, and the default has been changed to 192.0.2.1 which is a properly reserved address for this. I see recommendations to change this address dating back to 2010, so by now it should have been changed by most active admins, and if not it will not really break anything unless users are using hardwired DNS settings and use the new 1.1.1.1 service. However, in wireless systems like this, users will likely use DHCP to set their DNS resolvers, and it will work at least until the admin changes the DNS advertised via DHCP and does not realize that 1.1.1.1 is already in use in their own system. I tried reaching the 1.1.1.1 DNS service via 4 different ISPs here in the Netherlands and it works OK on all of them. Apparently the use of 1.1.1.1 in routers is not too big of an issue. Rob

1 0

More on that new global DNS resolver
by Brian Kantor 02 Apr '18

02 Apr '18

Here's another article on the new DNS resolver at 1.1.1.1; apparently they didn't want to publish the article on April 1st to avoid doubts about its authenticity. https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreeme… - Brian

1 0

Re: [44net] New Global DNS server
by Brian 01 Apr '18

01 Apr '18

Bill; A few years back I went to configure my 44.44/16 local net so it included 44.44.44.44. The second it became live, my circuit lost link to it's tiedown due to excessive botnet flood traffic. It seems as if they like to use 44.44.44.44 as a test IP of sorts not knowing it's hitting UCSD. ... just an FYI for ya. Happy Easter/Passover to who it pertains to. --- 73 de Brian, N1URO - supporting packet radio since 1995. sent via axMail-FAX by N1URO.

1 0

Re: [44net] 44Net Digest, Vol 7, Issue 32
by Russ Garber 01 Apr '18

01 Apr '18

Security by obscurity, works every time (for what is debatable :-) Russ k4ziv On 3/30/2018 3:00 PM, 44net-request(a)mailman.ampr.org wrote: > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > > Today's Topics: > > 1. 44net Archives Index (dean .) > 2. 44net Archives Index (dean .) > 3. 44net Archives Index (dean .) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 30 Mar 2018 14:38:56 +0000 > From: "dean ." <remodelguy(a)live.com> > To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org> > Subject: [44net] 44net Archives Index > Message-ID: > <SN1PR15MB0509073EEA669EA64578BF2BB0A10(a)SN1PR15MB0509.namprd15.prod.outlook.com> > > Content-Type: text/plain; charset="iso-8859-1" > > Hello everyone, > > I'm pleased such a community exists. I requested an allocation about three weeks ago and am excited about getting connected! > > The last couple of weekends I put two sdr receivers and a couple of websites up on the public internet for a quick migration to the 44 network when a gateway is received and configured correctly. > > In preparation for things to come, I've looked at the 44net archives, absorbing what I could. In trying to find info about using PFSense and other subjects, I realized how tedious it was to manually open each archive to search every time an answer or guidance was needed - so an index was made. I wrote a script to sort the subjects, etc. Also, each month was dl'd, expanded, and all put into one folder for ease of searching. Now I can search the index or grep all the files with one command. Maybe this exists elsewhere - I couldn't find it. If anyone is interested, here's the index and expanded files through mid-March contained in one folder: > > http://174.71.72.143:8885/files/44archiveMidMar18.tar.xz > > Thank you and 73, > Dean > K4DIN > > >

1 0

Wireless lan on 430MHZ ?
by R P 31 Mar '18

31 Mar '18

Hi there Im starting to check the option to install a Wireless lan on 430 MHZ using the Xagyl card ... Has anyone experienced such wireless networks ? Most important to me is the Range and non line of sight operation (especially in mobile) Have anyone done it and can say something on the subject ? https://www.xagyl.com/download/XC420M_Datasheet.pdf XC420M DATASHEET - XAGYL<https://www.xagyl.com/download/XC420M_Datasheet.pdf> www.xagyl.com WWW.XAGYL.COM RADIO SYSTEM INFORMATION Tx/Rx Specification 20MHz Channel Width 432.5MHz and 437.5MHz only DATA RATE MODULATION TX POWER RX SENSITIVITY Thanks Gorward Ronen - 4Z4ZQ

8 9

44net Archives Index
by dean . 30 Mar '18

30 Mar '18

There were concerns that having the data stored in the clear on my site would preset security issues. The file is now encrypted with 7zip which encrypts filenames also with the pass phrase being 44Index0cAM6wJRCI http://174.71.72.143:8885/files/44archiveMidMar18.7z

1 0

44net Archives Index
by dean . 30 Mar '18

30 Mar '18

Please disregard last message.

1 0

44net Archives Index
by dean . 30 Mar '18

30 Mar '18

Hello everyone, I'm pleased such a community exists. I requested an allocation about three weeks ago and am excited about getting connected! The last couple of weekends I put two sdr receivers and a couple of websites up on the public internet for a quick migration to the 44 network when a gateway is received and configured correctly. In preparation for things to come, I've looked at the 44net archives, absorbing what I could. In trying to find info about using PFSense and other subjects, I realized how tedious it was to manually open each archive to search every time an answer or guidance was needed - so an index was made. I wrote a script to sort the subjects, etc. Also, each month was dl'd, expanded, and all put into one folder for ease of searching. Now I can search the index or grep all the files with one command. Maybe this exists elsewhere - I couldn't find it. If anyone is interested, here's the index and expanded files through mid-March contained in one folder: http://174.71.72.143:8885/files/44archiveMidMar18.tar.xz Thank you and 73, Dean K4DIN

1 0

GL-AR300 Mini router support IPIP ?
by R P 29 Mar '18

29 Mar '18

Hi there Does anyone know if this router https://www.gl-inet.com/ar300m/ [https://www.gl-inet.com/wordpress/wp-content/uploads/2017/11/ar300m_shop-1.…]<https://www.gl-inet.com/ar300m/> GL-AR300M – GL.iNet<https://www.gl-inet.com/ar300m/> Let's Get In Touch! For business collaborations, OEM, ODM and bulk orders, please write to: service(a)gl-inet.com www.gl-inet.com support IPIP native (without need to compile and add software to it ) ? Thanks Forward Ronen -4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com www.ronen.org

1 0

Re: [44net] MikroTik worm - please check your RouterOS version!
by Rob Janssen 29 Mar '18

29 Mar '18

> I recommend disabling the access to unneeded management services and to > the remaining ones, restricting the access to them from the networks > used by the administrators. Of course. And we had that already in place on the routers inside our own part of the network (which was deployed to facilitate our co-channel diversity repeater network). However, above I was discussing the settings on our internet gateway. I cannot control what all the individual amateurs, with varying networking skills, do on their routers at home, but by filtering inbound connects to port 8291 I can protect them from the current problem. There now are 430.000 addresses in the scan I did last night. only net-44 addresses: 44.140.129.12 44-25-128-124.ip.hamwan.net[44.25.128.124] 44.34.131.144 But of course, when people start filtering outbound 8291 connections, it is not a complete picture. Rob

1 0

Re: [44net] MikroTik worm - please check your RouterOS version!
by Rob Janssen 29 Mar '18

29 Mar '18

> it is not wise to block port 8291, because the exploitable service is > on http port 80 tcp. The worm uses port 8291 to identify possible victims (when it can connect to port 8291 it assumes there is a MikroTik router on that address), then attacks it on port 80 and some other ports that people may likely have set as an alternative for HTTP access to the router (8080 etc). So blocking port 8291 effectively blocks the worm in its current version, while not destroying the useful port 80. Of course experience with earlier events like this shows that such a worm typically evolves and may skip the port 8291 scan later, rendering this block ineffective. For now, I have blocked access to port 8291 from addresses outside AMPRnet on our gateway. Of course this restriction will be lifted when/if this worm stops operation. It appears to be controlled via a peer-to-peer network and it looks like it is a version of an existing worm that has been active on network cameras/recorders, routers from other manufacturers, etc, all running embedded Linux. Rob

3 2

MikroTik worm - please check your RouterOS version!
by Rob Janssen 28 Mar '18

28 Mar '18

> All these should be good now, I've check the upgrade and it's on the newest > code. Please let me know if you see anything else. I'll run another scan (actually: a trace) tonight. It has to run for about 8-10 hours to catch everything, it appears. I just trace for SYN to port 8291 and get the source addresses. Unfortunately it cannot be done using a simple tshark -i eth0 -f "tcp dst port 8291" because tshark collects session state information and its memory use balloons under the millions of session open attempts it sees. So I use: while true do tshark -i eth0 -f "tcp dst port 8291" -c 20000 | fgrep '[SYN]' | sed -e 's/ ->.*//' -e 's/.* //' >>/tmp/syn8291 done Of course it would also be possible to limit it to AMPRnet: tshark -i eth0 -f "tcp dst port 8291 and src net 44.0.0.0/8" Rob

4 3

acc bitte löschen
by Torsten Rh 28 Mar '18

28 Mar '18

acc bitte löschen mfg DE1TRF

1 0

Re: [44net] MikroTik worm - please check your RouterOS version!
by Rob Janssen 28 Mar '18

28 Mar '18

> A central syslog and firewalled 8291 ports with logging would be a better solution imho :) > Grep seems less of a strain than tshark and would be quicker I imagine If you would want to do this permanently, yes. But this is only something I would run maybe for 3-4 days and then be bored. First night I did the tshark logging without the postprocessing (so file gets the 1-line-per-packet trace info) and it collected 500MB in a single night. Maybe you don't want that all in the syslog... Now I keep only the source addresses, Rob

1 0

Re: [44net] MikroTik worm - please check your RouterOS version!
by Rob Janssen 28 Mar '18

28 Mar '18

> It appears that only these two addresses are still infected: > 44.25.64.73 ether1.ap.beacon.hamwan.net > 44.98.249.7 AP-A-250.tampa.flscg.org A little too optimistic, a longer scan yields this list: 44.140.129.12 44-25-128-124.ip.hamwan.net[44.25.128.124] ether1.ap.beacon.hamwan.net[44.25.64.73] 44.34.131.144 AP-000.StPete.flscg.org[44.98.249.66] AP-120.StPete.flscg.org[44.98.249.67] AP-240.StPete.flscg.org[44.98.249.68] AP-A-250.tampa.flscg.org[44.98.249.7] Rob

2 1

Re: [44net] MikroTik worm - please check your RouterOS version!
by Rob Janssen 27 Mar '18

27 Mar '18

It appears that only these two addresses are still infected: 44.25.64.73 ether1.ap.beacon.hamwan.net 44.98.249.7 AP-A-250.tampa.flscg.org Good work in containing this outbreak... Rob

1 0

Re: [44net] MikroTik worm - please check your RouterOS version! Ryan Elliott Turner ryan.e.t at gmail.com
by Rob Janssen 27 Mar '18

27 Mar '18

> All of the hosts I can control in 44.34/21 have been updated this evening. > Please let me know if you notice any other troublemakers there. Thanks for > the report. This is the latest packet to TCP port 8291 I have seen from addresses in the 44.34 network: 01:13:28.014665 44.34.128.100 04:04:59.569058 44.34.128.101 01:21:03.741867 44.34.128.102 01:11:34.822173 44.34.128.34 00:21:39.834057 44.34.128.35 01:53:00.697869 44.34.128.39 03:36:45.895350 44.34.128.94 07:13:36.922146 44.34.129.114 04:22:32.850903 44.34.129.117 03:32:09.935080 44.34.129.40 02:27:34.360165 44.34.129.41 01:51:02.516010 44.34.129.42 01:18:43.892712 44.34.129.73 Times are UTC+2 When you have updated those devices after those times it should be OK Rob

1 0

Re: [44net] MikroTik worm - please check your RouterOS version!
by Rob Janssen 27 Mar '18

27 Mar '18

> When you know who owns one of the above systems, please advise them that their router is > compromised and that they have to update it. > As it seems now, updating will also remove the worm, but in my opinion it is safer to cleanly > re-install it using netinstall and restore your backed-up configuration. > (you make backups, don't you??) In the message I used the word "router" a couple of times, but it does not matter if it is a router or WiFi device, they all run the same software. When your device is on the above list, it has already been compromised. (probably at least one device on AMPRnet has been infected from internet and now it is infecting other devices inside AMPRnet, so you can be affected even when you have no internet access at all) However, the good news is that it appears that updating the RouterOS to 6.40.6 (bugfix) or 6.41.3 (current) is going to render the worm ineffective, it appears there is no real need to netinstall. When you have internet access, updating is a simple matter of clicking "check for updates" in the system->packages menu, select "current" or "bugfix" channel and click "download&install". Of course this does not work when you have no internet access, but then you can still download the desired npk files from mikrotik.com, upload them in the device and reboot. Rob

2 1

MikroTik worm - please check your RouterOS version!
by Rob Janssen 26 Mar '18

26 Mar '18

Likely unrelated to the issue with the rogue gateway servers, please note that this weekend an exploit was launched that affects MikroTik routers running RouterOS older than 6.38.5 and that has its webservice (WebFig) open to the outside network. These get infected via the webservice and start a worm that scans for other routers to infect. Once it is inside your network it may propagate to other devices. It will scan for the usual MikroTik configuration interfaces, of which port 8291 (winbox) is most easily identified. (the others, 23, 80 etc are already scanned so often that it is difficult to identify the source) I did a trace of about 10 hours on the 44.137.0.0/16 network and over that period it was scanned by over 345.000 unique IP addresses on the internet, and randomly connecting back to a few of them returns an old version RouterOS every time... Disturbingly, there are also a couple of AMPRnet IP addresses on that list! They are mainly in two different networks. Unfortunately they do not appear in ampr.org reverse-DNS. wlan1.w7hr-sunnyslope.hamwan.net[44.24.240.110] wlan.kd7tqn.hamwan.net[44.24.240.221] wlan1.baldi.we7x.hamwan.net[44.24.240.222] poe.haystack.hamwan.net[44.24.241.41] 44-25-128-124.ip.hamwan.net[44.25.128.124] r1.crystal.hamwan.net[44.25.128.169] lan.r1.beacon.hamwan.net[44.25.64.65] ether1.ap.beacon.hamwan.net[44.25.64.73] 44.34.128.100 44.34.128.101 vrrp.hil.memhamwan.net[44.34.128.102] 44.34.128.103 ptpsco.leb.memhamwan.net[44.34.128.163] ptpazo.leb.memhamwan.net[44.34.128.184] 44.34.128.34 44.34.128.35 44.34.128.36 44.34.128.39 44.34.128.62 44.34.128.94 44.34.128.99 44.34.129.114 44.34.129.117 r2.mno.memhamwan.net[44.34.129.35] ptphil.mno.memhamwan.net[44.34.129.38] sec1.mno.memhamwan.net[44.34.129.40] sec2.mno.memhamwan.net[44.34.129.41] 44.34.129.42 44.34.129.66 44.34.129.67 44.34.129.73 44.34.131.144 AP-120.StPete.flscg.org[44.98.249.67] AP-240.StPete.flscg.org[44.98.249.68] AP-A-250.tampa.flscg.org[44.98.249.7] W9CR-Mgmt.StPete.flscg.org[44.98.249.76] AP-B-330.tampa.flscg.org[44.98.249.8] AP-C-110.tampa.flscg.org[44.98.249.9] 44.103.35.26 44.140.129.12 When you know who owns one of the above systems, please advise them that their router is compromised and that they have to update it. As it seems now, updating will also remove the worm, but in my opinion it is safer to cleanly re-install it using netinstall and restore your backed-up configuration. (you make backups, don't you??) When you run a MikroTik router and have not updated RouterOS, please update it to at least 6.40.6 (select bugfix-only in the updater) or the current version 6.41.3. In the latter case, be aware of the issues around updating from 6.40 to 6.41 in complicated switched configurations. And of course, always configure a firewall that disallows access to the configuration interfaces from the internet, as always for devices like this. Rob

2 1

Re: [44net] gateways without subnets
by Rob Janssen 25 Mar '18

25 Mar '18

.> That is correct - there are plenty of gateways in the portal that have no subnets attached to them, but they are filtered out of the encap list. Ok, then apparently these "rogue gateways" (they happen to be all from Poland) are using some method to use the encap file to load tunnel interfaces and static routes. I had expected them to use the script that Marius wrote for MikroTik, but in that case they would not receive the RIP broadcasts and so would not be able to build all those tunnels (and send MikroTik neighbor discovery on them). I suspect there has been some "how to setup an AMPRnet gateway" doc going around in Poland... Tom SP2L is already looking at it. Maybe you can just remove all gateways that have had no subnets for some time. Although that will likely not fix anything... Rob

3 3

gateways without subnets
by Rob Janssen 25 Mar '18

25 Mar '18

Lately I see a number of gateways that are registered without subnets, but still they send traffic. When tracing it, it appears to be usually traffic like MikroTik neighbor discovery. It gets logged in our firewall because it is IP-encap traffic coming from an address that is not in the IP-encap routing table. And it isn't in the IP-encap routing table because that gateway does not have subnets. Would it be an idea to not send the RIP announcements to gateways without a registered subnet? It would not be useful to them anyway, I think. Rob

4 3

Re: [44net] gateways without subnets
by Rob Janssen 25 Mar '18

25 Mar '18

> The RIP sender sends RIP only to gateways listed in the encap table, > unless a bug has surfaced that I wasn't aware of. That code has been > stable for several years, so I doubt it. Does that table contain only gateways that actually have routes to them? Or is there also a listing for those that only are registered in the portal but with "No subnets"? I wonder how those gateways know the route to us to transmit tunnel data when they do not actually route anything themselves? They appear to be MikroTiks so most likely running the script by Marius YO2LOJ and that would have to receive the RIP data to bring up the tunnels. Rob

3 2

Re: [44net] gateways without subnets
by Rob Janssen 25 Mar '18

25 Mar '18

> Of 688 entries in the ENCAP.TXT table there are 130 that are /32 single > IP host. That's about 19% of all routes that ONLY reach ONE host and do > NOT serve a subnet or provide gateway services for anyone else. > I too wonder why these single host routes are allowed???? I don't see anything wrong with that, this is just a single host on the tunnel network. What I am wondering about is the gateways that do not have anything routed to them at all. Look in the portal and view in subnet mode, there are many gateways that show nothing there. Rob

1 0

Acessing UBNT website from AMPRNET ?
by R P 20 Mar '18

20 Mar '18

Can anyone reach the UBNT.COM web site from AMPRNET ? The site give me timeout Of course its accessible from non ANPRNet address Thanks Forward Ronen - 4Z4ZQ

4 6

Add AX.25 Software to OpenWRT
by lleachii＠aol.com 19 Mar '18

19 Mar '18

Hello all, If anyone is familiar with public software development, I need to get the Linux AX.25 software suite added to OpenWRT. I've successfully generated a makefile and /patches that will compile the current libax25, but have issues with compiling ax25-tools (which needs libax25; but I'm having trouble building individual packages with dependencies in other locations). I haven't tried ax25-apps. OpenWRT already posses kmod-ax25. http://www.linux-ax25.org Very basic for someone who knows. Please contact me. 73, - Lynwood KB3VWG

3 4

Script to transfer routes to HSMM OLSR
by lleachii＠aol.com 19 Mar '18

19 Mar '18

Hey all, We're still working in the Washington, DC area on our HSMM Mesh network. At this point, I've been solving an issue when - those who have gateways and routes to AMPR will properly route. The only solution thus far is - those in the area with direct interconnections to AMPR as well as the Internet, will have to route them (lol). This requires announcing specific routes on the network. Mesh uses OLSR. My plan: - I'll make an Ethernet interface that is on the Mesh, we plan to get an allocation from AMPRNet (soon) for this - I'll run OLSR on this interface The script: - The current dynamic firewall script that now runs (see Wiki), will take the 44 networks and announce them in HNA I need assistance with developing that new portion of the script. I'm currently working on setting up a test to an adjacent HSMM node. Why can't the Mesh speak RIP44? - It will, we plan to setup another service with public keys that will change our DDNS name to the main router, it will start an election for if an Operator looses a good route via their Internet to AMPRGW. - While we plan to run the Mesh's tunnel with BGP eventually, the network will be configured to assume that the route to 0.0.0.0/0 is general on OLSR, and there are multiple gateways, others authorized to announce the Internet will use more specific routes like 0.0.0.0/1 and 128.0.0.0/1...etc...the main router will announce the Internet to the mesh by 255 /8 networks. - This network will be hybrid, unless you connection track the packet, it can return any direction - Masquerade when necessary, lol 73, - Lynwood KB3VWG

1 0

Security hole in mikrotik routers
by R P 18 Mar '18

18 Mar '18

For you (and me) that use Mikrotik routers For AmprNet (but not only for AMPRNet Recommended to Upgrade the latest OS Release Ronen - 4Z4ZQ https://www.securityweek.com/remotely-exploitable-vulnerability-discovered-… Remotely Exploitable Vulnerability Discovered in MikroTik's RouterOS | SecurityWeek.Com<https://www.securityweek.com/remotely-exploitable-vulnerability-discovered-…> www.securityweek.com A MikroTik RouterOS SMB buffer overflow vulnerability (CVE-2018-7445) allows a remote attacker with access to the service to gain code execution on the system.

3 2

44.103/16 Coordinator Request
by Fredric Moses 11 Mar '18

11 Mar '18

Hello, I am wondering if there is a way we can take over as the coordinator for the 44.103/16 Michigan2 Block. Currently all the allocations in this /16 are to our microwave projects here in Michigan and it seems there is an issue with requesting a /24 that will be BGP announced from a separate location then our current allocations. I made a request on 2018-02-07 the coordinator requested I submit a utilization for one of our /19’s. We currently have a /19 /21 /23 /24 in our project now but I responded with the /19’s utilization report as requested. On 2018-02-14 the coordinator responded with : Fred, Your request will be ready RSN (Real Soon Now) I said thanks. On 2018-03-01 I asked for a status update. 2018-03-03 the coordinator responded: I expect next week. That week has now come and gone with no response or allocation. If a coordinator can not be changed out we would be willing to re-ip into a new /16 block that we can issue requests for IP’s in a more timely matter like our HamWAN brothers do out in the western US area. -- Fredric Moses - W8FSM - WQOG498 fred(a)moses.bz

1 0

Wrong encaps?
by Gustavo Ponza 09 Mar '18

09 Mar '18

Hi, to all concerned, found the following errors by making the 'source' of the actual 'encap.txt' file. Can't add route to 44.24.172.40/29 via encap 44.24.172.41 Can't add route to 44.130.104/24 via encap 44.130.104.1 Can't add route to 44.130.105/24 via encap 44.130.105.1 Can't add route to 44.130.106/24 via encap 44.130.106.1 Can't add route to 44.130.107/24 via encap 44.130.107.1 Can't add route to 44.131.14.252/31 via encap 44.131.14.253 Can't add route to 44.136.150/23 via encap 44.136.150.2 -- 73 and ciao, gus i0ojj/ir0aab

3 4

Re: [44net] TNC for Raspberry pi that support 9600 Baud ?
by Rob Janssen 09 Mar '18

09 Mar '18

> At minimum, just a USB sound card ($5 US) and some way to key up your > radio. The Direwolf UserGuide details all this for you. On a Raspberry > Pi, a simple transistor circuit and a GPIO pin off the Pi is all you need. For software guys, it is now possible to make receive-only installations with even less hardware. On our co-channel diversity repeater system we have sites where an RTL DVB-T stick is used with SVXlink "remotetrx" configured to provide a number of virtual NBFM receivers where some of them are connected to the SVXlink master site to receive voice to be transmitted over the repeater, and other virtual receivers are connected via a loopback audio device to a direwolf process used to gateway the received APRS packets to the aprs2.net As the APRS frequency on 70cm is in the process of being changed, we receive on both the old and new frequency and also on 2 different repeater input frequencies, all with a single stick (and a bandpass in front of it, of course). I have even tested an SSB input to the repeater, which worked fine too. It is possible to add receivers and connect them to some application without touching the soldering iron, without even going to the site. It is really wonderful what software can do today... Rob

2 1

TNC for Raspberry pi that support 9600 Baud ?
by R P 08 Mar '18

08 Mar '18

Has anyone know of any TNC model that stick on Raspberry Pi and support 9600 Baud ? The TNC pi2 does not support 9600 according to the seller Please advice Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 11

White space radio
by Steve L 06 Mar '18

06 Mar '18

This radio will be field tested soon at an area school. I look forward to hearing more and will report back when I do: http://www.metricsystems.com/ I figured I'd point it out to the list enough though I suspect the price point is not for the typical radio amateur. It would seem a company making such a thing would have a limited market, so if it could be unlocked to cover ham freq's that might provide a small secondary market. Either way, hams looking to move data might also want to research white space radios as I suspect this sort of thing will be more common. PS: I see the dunderheads in Newington have proposed some changes to the hobby. Sadly anything to do with data/bandwidth isn't part of it.

1 0

FW: Allocation request ON5BAC
by Ruben ON3RVH 05 Mar '18

05 Mar '18

FYI 73, Ruben - ON3RVH From: Bart Cretskens [mailto:bart.cretskens@gmail.com] Sent: maandag 5 maart 2018 13:39 To: Ruben ON3RVH <on3rvh(a)on3rvh.be> Subject: Re: Allocation request ON5BAC Dag Ruben, Sorry, inderdaad, je hebt gelijk, een /29 is goed om mee te starten. Alvast bedankt 73e Bart 2018-03-05 9:23 GMT+01:00 Ruben ON3RVH <on3rvh(a)on3rvh.be<mailto:on3rvh@on3rvh.be>>: Dag Bart, Kan je ons meer detail verschaffen over waarom een /24 aub? Standaard staan we enkel /29 size netwerken toe, dit om het verkwisten van IP adressen te vermijden. Een /24 staan we enkel toe als je zelf de BGP routering naar het internet ervan kan doen. Dus dan heb je een ASN nodig en minstens 2 transit providers die bereid zijn om die /24 voor jou te announcen Alvast bedankt. 73, Ruben - ON3RVH Member of the AMPR ON0 coordinations team

1 0

DMR trafic behave on AmprNet
by R P 02 Mar '18

02 Mar '18

About a year and a half ago I have asked how good will be the AmprNet to use to connect DMR repeaters So finaly i have made a HotSpot and connected it to the AmprNet and it connect to our Server via the AmprNet I use tunnel to UCSD and not BGP so traffic travel to UCSD The results are impressive No problem at all although the latency is big no words loose or packet loss The only thing i see is a bit delay until the Hotspot start to transmit and this is (probably ) because the latency so the PTT command delay a bit It is a high power hotspot consist of a 25 Watt radio connected to a MMDVM system so users use it and i didnt get any complain of any disconnection or any issue of networking or service so far If you are interested the statistic of the MikroTik Router that handle the AmprNet traffic show about 12Kbit/Sec UDP when the data flow from the hotspot to the server Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

1 0

Routing of 44.0.0.0/8 how are routes announced to users?
by Benoit Panizzon 26 Feb '18

26 Feb '18

Dear List I'm pretty newly connected to hamnet, and also work at an ISP. I always assumed 44.0.0.0/8 would not be announced to the internet, but only routed privately on hamnet. Now I see routing issues I don't quite understand as for me this looks like routing is completely broken... On the internet core router I see that 44.0.0.0/8 is being announced by AS7377 (UCSD). But IP Addresses from the swiss HamNet range are not reachable via AS7377. So what is the point announcing the whole range to the internet? There is no 'more specific' route to 44.142.200.1 On the other hand I cannot reach parts of hamnet via hamnet. Take for example the Primary DNS of ampr.org: ampr.org. 3600 IN SOA ampr.org. ampr.org has address 44.0.0.1 1 gateway (157.161.57.65) 2.947 ms 2.887 ms 2.847 ms 2 mikrotik-hamnet.woody.ch (192.168.57.243) 4.937 ms 4.920 ms 4.887 ms 3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 21.810 ms 24.858 ms 29.860 ms 4 bb-hb9am-30.db0wbd.ch.ampr.org (44.224.90.81) 29.847 ms 32.792 ms 32.771 ms 5 wan-db0wbd.hc.r1.ampr.org (44.148.240.45) 78.907 ms 81.925 ms 84.438 ms 6 dc1-dc2.hc.r1.ampr.org (44.148.255.253) 97.808 ms 98.107 ms 113.973 ms 7 wan-db0gw.db0fhn.ch.ampr.org (44.224.122.2) 113.986 ms 113.149 ms 118.384 ms 8 db0fhn.ch.ampr.org (44.130.60.100) 126.890 ms 118.628 ms 137.776 ms 9 * * * My Gateway has a default route to the internet and a static route for 44.0.0.0/8 pointing to my WLAN Link to a 'public' Hamnet AP. So what is the point of having sort of a split-brain situation on the 44.0.0.0/8 hamnet ip range? I 'see' ospf packets on the WLAN link, but they only seem announce the local routes withing the swiss part of hamnet, not the global routes. Sort of makes sense, as you probably would run bgp to interconnect the different hamnet as numbers. So do I need to get an own hamnet as number? As a User?!? Or what mechanism is there supposed to be to tell a user which hamnet ip ranges are reachable via internet and which ones are reachable via hamnet. 73 -Benoit- / HB9EUE

10 23

Anyone running an open AMPR VPN willing to share?
by David Ranch 17 Feb '18

17 Feb '18

Hello Everyone, I'm helping out a local HAM getting an IPIP AMPR setup working but his current AT&T Uverse / Pace s 5862ac unit doesn't seem to be playing nicely. Yeah.. I know.. Shocking! Anyway, touter/NAT mode seems to *only* want to forward TCP/UDP protocols (typical) and it's DMZPlus feature mode seems to be breaking his Wifi network. As we maybe hack with the DMZplus feature tomorrow, I was curious if there is anyone willing to offer up a VPN connection to his Raspberry Pi as a Plab-B: Looking through the archives, there was http://wiki.ampr.org/index.php/AMPRNet_VPN but that link is 404. I know there is also the http://wiki.ampr.org/wiki/AMPRNet_VPN link but I know other HAMs are/were offering less complicated setups. I can help him setup any offering be it IPSEC, SSL-VPN, etc. He's not looking for any sort of performance.. just general IPIP access to play around, etc. at the moment. If already hosting or you're willing to host a solution, let me know. Thanks! --David KI6ZHD

4 3

setting up a Linux gateway with a dynamic public IP
by Kevin Fox 13 Feb '18

13 Feb '18

All the examples I have found have a static public ip, is there a way to do it with a dynamic public ip, my ISP does not assign statics to residential customers. cantantes laudat orbis terrarum

5 6

not understanding something
by Kevin Fox 07 Feb '18

07 Feb '18

I have followed the directions in http://lz4ny.eu/en/amprnet-44-rip/ to setup my GW, but all I get when I run ampr-ripd is the following root@thor:/home/w0kcf# ampr-ripd -d -i tunl0 Using gateway 192.168.1.1 for direct 44net endpoints via interface enp0s18. Waiting for RIPv2 broadcasts... Network configuration is as follows w0kcf@thor:~$ ifconfig enp0s10 Link encap:Ethernet HWaddr 00:14:6c:81:ff:fe inet addr:44.26.1.80 Bcast:44.26.1.95 Mask:255.255.255.240 inet6 addr: fe80::214:6cff:fe81:fffe/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:16335 errors:0 dropped:10870 overruns:0 frame:0 TX packets:58 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1273233 (1.2 MB) TX bytes:6874 (6.8 KB) enp0s18 Link encap:Ethernet HWaddr 00:13:8f:7a:c8:aa inet addr:192.168.1.9 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::213:8fff:fe7a:c8aa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:23028 errors:0 dropped:0 overruns:0 frame:0 TX packets:17964 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6155448 (6.1 MB) TX bytes:2789754 (2.7 MB) What am I missing? 73 Kevin W0KCF

3 2

Mikrotik RouterOS script update
by Marius Petrescu 23 Jan '18

23 Jan '18

Hello, Mikrotik released its new RouterOS version 6.41, with some changes affecting the gateway script. I released an updated script version to address this issue. For those using pre-6.41 ROS, the update is not necessary. If you want to correct the script manually, just delete the line referring to neighbor discovery disabling in the 'add new tunnel' section of the ampr_gw script whic states: /ip neighbor discovery set $gw discover=no As usual, download at: http://www.yo2loj.ro/hamprojects/ http://yo2tm.ampr.org/hamprojects/ Marius, YO2LOJ

4 5

Contact...
by SP2L＠wp.pl 19 Jan '18

19 Jan '18

Hello Jean-Luis Kindly please kontact me off the list. Best regards. Tom – SP2L

2 1

Contact...
by SP2L＠wp.pl 19 Jan '18

19 Jan '18

Hello Jean-Luis / F1GBD Kindly please kontact me off the list. Best regards. Tom – SP2L

1 0

Gateway inside of pfSense DMZ: It WORKS!
by Tom C 08 Jan '18

08 Jan '18

Currently running on a Raspberry Pi in a pfSense DMZ on residential Dynamic IP. Marius’ ampr-ripd compiled with no issue, the scripts from my linux gateway that I worked on with Lynwood work perfectly with no modification. Need to do a little tweaking with iptables firewall as my network implementation is different from what it was when I was running one box. Diagram: (Internet)===<pfSense>==(DMZ)==<Raspberry Pi>==(44.98.63.0/29) - I’m NAT forwarding ipip traffic that hits the pfSense external interface to the DMZ (usb NIC) interface on the Pi. - tunnel script and ampr-ripd run on the pi creating tunl0 on the pi - local AMPR segment on the Pi native interface. - pfSense NATs outbound encapsulated traffic making it appear as if it comes from the pfSense box. - My gateways appears on Marius map. Working on documentation for the wiki and will post by weeks end. —tom -- 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

2 1

Re: [44net] Changes afoot on my gateway (Tom Cardinal)
by Luzemário Dantas 08 Jan '18

08 Jan '18

Hi Tom, Some tome ago I was fiddling with pfSense to make it my gateway. I abandoned this idea because there was a couple of key issues for me: - BSD needs a device for each IPIP tunnel, this gets the things much more harder to setup; - PfSense does not have the protocols used enabled by default, needing manual edit of the web interface after each update. You have to do it by yourself every time; - Linux has ready made scripts to get the job done. These scripts were made by good hams here and tested by several other people. It is easier to create a small virtual machine and put a 256MB RAM Devuan working than creating a gateway using BSD. - PfSense team is minded to get the commercial way of pfSense as a product, so do not expect any support to get the things working. Their support forum is getting more unconcerned every day. If you are still inclined to use some type of BSD firewall as an AMPRNet gateway, I suggest using OPNSense to start. It was a project forked from pfSense, but today have only 10% of original code and have open source as priority yet. Their forum is much more friendly and responsive. OPNSense has all protocols listed in the web interface, so passing IPIP traffic back and forth is more intuitive (I still would not use it as a gateway anyway). Hope this helps, 73 de PT2LDR Luzemario www.luzehost.com.br Em 06-01-2018 18:00, 44net-request(a)mailman.ampr.org escreveu: > Greetings, > I was working with Dan Cooper last spring to turn my pfSense box into > an ampr gateway. At the time I was trying to learn how IPIP worked AND > how BSD (pfSense) worked. I'm pretty well versed in linux... BSD... > not so much. > > At the time I moved to Linux and Lynwood helped me get my head around > how the IPIP tunneling works. After seeing the volume of traffic that > tries to crack into my residential ISP connection (even though it > fails) I've decided to put my ampr gateway into a DMZ. I'm currently > in the process of moving my AMPR gateway into a pfSense DMZ. > > I work in a loosely security related position at work and I'm doing > this as a security measure to knock down some of the noise my Linux > gateway/Router/Firewall/AMPRgateway was seeing, mostly from Russia, > China and other places that I didn't research. My new AMPR gateway > will still be on Linux, actually Raspbian on a Raspberry Pi, but the > only traffic it'll ever see is encapsulated traffic and traffic from > my network because all of the other noise will be filtered by the > pfSense box and won't exist in my DMZ. > > Out of the box the pfSense user interface doesn't have support for > ipencap or AX25. I did a little bit of research (google) and found an > older post on the pfsense forum about which files to edit to add > ipencap and ax25 to the UI. Also, I just asked on the pfSense > subreddit to see if there are any other places within the pfSense UI > to edit which protocols are available for use. > > Is anyone else using this method to NAT forward IPIP traffic to an > internal gateway (in my case using pfSense). I'm looking to find out > if I've missed anything with the port forwarding before I move > forward. I know Brian (N1URO) was working with IPIP tunneling behind a > NAT and I think (THINK) this might work. > > So... here's what I've done. > > pfSense version is 2.4.2p1. File edits follow... > > In file: > /usr/local/www/firewall_nat_edit.php > > On line 708, change: > $protocols = "TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP PIM OSPF"; > > To: > $protocols = "TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP PIM OSPF > IPENCAP AX25"; > > In file: > /usr/local/www/firewall_nat_out_edit.php > > On line 510, change: > $protocols = "any TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP carp pfsync"; > > To: > $protocols = "any TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP carp > pfsync IPENCAP AX25"; > > In file: > /usr/local/www/firewall_rules_edit.php > > Insert as line 1315 and 1316: > 'ipencap' => 'IPENCAP', > 'ax25' => 'AX25', > > -- > Tom / n2xu / MSgt USAF (Ret) / BSCS, CASP

2 1

Changes afoot on my gateway
by Tom Cardinal 08 Jan '18

08 Jan '18

Greetings, I was working with Dan Cooper last spring to turn my pfSense box into an ampr gateway. At the time I was trying to learn how IPIP worked AND how BSD (pfSense) worked. I'm pretty well versed in linux... BSD... not so much. At the time I moved to Linux and Lynwood helped me get my head around how the IPIP tunneling works. After seeing the volume of traffic that tries to crack into my residential ISP connection (even though it fails) I've decided to put my ampr gateway into a DMZ. I'm currently in the process of moving my AMPR gateway into a pfSense DMZ. I work in a loosely security related position at work and I'm doing this as a security measure to knock down some of the noise my Linux gateway/Router/Firewall/AMPRgateway was seeing, mostly from Russia, China and other places that I didn't research. My new AMPR gateway will still be on Linux, actually Raspbian on a Raspberry Pi, but the only traffic it'll ever see is encapsulated traffic and traffic from my network because all of the other noise will be filtered by the pfSense box and won't exist in my DMZ. Out of the box the pfSense user interface doesn't have support for ipencap or AX25. I did a little bit of research (google) and found an older post on the pfsense forum about which files to edit to add ipencap and ax25 to the UI. Also, I just asked on the pfSense subreddit to see if there are any other places within the pfSense UI to edit which protocols are available for use. Is anyone else using this method to NAT forward IPIP traffic to an internal gateway (in my case using pfSense). I'm looking to find out if I've missed anything with the port forwarding before I move forward. I know Brian (N1URO) was working with IPIP tunneling behind a NAT and I think (THINK) this might work. So... here's what I've done. pfSense version is 2.4.2p1. File edits follow... In file: /usr/local/www/firewall_nat_edit.php On line 708, change: $protocols = "TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP PIM OSPF"; To: $protocols = "TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP PIM OSPF IPENCAP AX25"; In file: /usr/local/www/firewall_nat_out_edit.php On line 510, change: $protocols = "any TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP carp pfsync"; To: $protocols = "any TCP UDP TCP/UDP ICMP ESP AH GRE IPV6 IGMP carp pfsync IPENCAP AX25"; In file: /usr/local/www/firewall_rules_edit.php Insert as line 1315 and 1316: 'ipencap' => 'IPENCAP', 'ax25' => 'AX25', -- Tom / n2xu / MSgt USAF (Ret) / BSCS, CASP

5 4

Re: [44net] Mikrotik RouterOS script update
by Rob Janssen 23 Dec '17

23 Dec '17

> You can, but please do not. > It will enable neighbor discovery on new tunnels, which is not desired > and creates useless traffic. > There are no functional changes except this. > Marius, YO2LOJ When researching this matter (I wanted to enable neighbor discover on new L2TP tunnels internal to our network) I found that this command line can disable it by default: /ip neighbor discovery settings set default=no default-for-dynamic=no The "default" is for manually created interfaces like IPIP tunnels, the "default-for-dynamic" is for dynamic interfaces like the server-side of L2TP tunnels. With this command issued once, the discovery should be off on new tunnels on versions < 6.41 However, this command no longer exists in 6.41 ! Now, setting of discovery is done using an interface list with the members of the list participating in discovery (or the non-members, there is an inversion operator) So look in the "ip neighbor" discovery settings to see how the interfaces are now set, there can be an interface list "discover" (the new default) or there can be something like "!dynamic" which results in discovery on all non-dynamic interfaces (the old default). When it says "!dynamic" it is better to change that to "discover" and put only your local interfaces in that list. Rob

1 0

OSPF Multicast traffic from 44.162.0.1
by Marc, LX1DUC 23 Dec '17

23 Dec '17

Good afternoon, I was updating my 44net IPIP Gateway and I noticed I received OSPF Multicast traffic from 44.162.0.1: OSPF hlo (a=254 r=44.162.254.33) (76 bytes) from 44.162.0.1 to 224.0.0.5 on ampr0 Could the OP please de-activate OSPF (or set as passive) on the IPIP interfaces? Vy 73 and merry Christmas de Marc, LX1DUC

1 0

RIP44 vs RIP v2
by Tom Cardinal 22 Dec '17

22 Dec '17

What are the differences between RIP44 and RIP v2? Is the RIP44 protocol documented anywhere? I'm learning more and would like to crack into the differences between the protocols. --tom n2xu

4 4

retirement
by Brian Kantor 21 Dec '17

21 Dec '17

I am retiring from UCSD, after 47 years on campus. My new mailbox is brian _AT_ bkantor.net. Future emails from me will usually come from there, although some may come from my @ucsd.edu address for the next few weeks as I transition various functions to the new mailbox. The old UCSD address will forward to it for a while. I will continue to use the @ampr.org address for some AMPRNet and ARDC business. Amprgw (gw.ampr.org) will continue to operate as it has for some time as part of the CAIDA research group continuing measurement and analysis of dark networks project. No changes in its operation are planned. I will still be managing the amprnet-related portions of the amprgw system, and AMPRNet in general, as before. This mailing list will not be affected, as it is not hosted at UCSD. - Brian

18 17

DMCA
by Brian Kantor 20 Dec '17

20 Dec '17

Those of you in the USA (and elsewhere) who are providing networking services or connectivity to others should be aware of possible liability under the DMCA (Digital Millenium Copyright Act) and similar laws in other countries should one of the people you are providing service to misbehave and commit a copyright violation, such as posting copyrighted material on your or their own server, or operating a peer-to-peer (BitTorrent, etc) node that is distributing copyrighted material. It could be expensive. I recommend you read up on this. A place to start is the Wikipedia article on the OCILLA (Online Copyright Infringement Liability Limitation Act). https://en.wikipedia.org/wiki/Online_Copyright_Infringement_Liability_Limit… Best wishes for a happy holiday season to all. - Brian

2 1

Not a Peep From Coordinator
by Jason Smith 15 Dec '17

15 Dec '17

What steps should be taken to get a hold of my coordinator? I've been trying to get my block back in order for over a month now and I've not made any progress at all. Thanks KD4CBM

2 1

GW Setup Problem
by Barış DİNÇ 13 Dec '17

13 Dec '17

Hi All, I am sure that this question is asked by many newbies but I have to ask it to bring up my gateway... :) I set up a gateway and coordinated the ip allocation with my regional IP coordinator. But, however, testing behind NAT or without NAT (directly machine connected to internet (a server on a colaction ISP)) didn't have success.. using ampr-ripd with compiled DEBUG options I cant get and response from the 44.0.0.1 For testting I just did # ifconfig tunl0 up 44.176.200.1 netmask 255.255.255.255 and tried #./ampr-ripd -d -v -i tunl0 the result is as follows but no success even if I wait for 2 hours... IS THERE A WAY TO TEST THIS RIPD CONNECTION ? (a tool or sniffing with tcpdump..) HOW CAN I BE SURE THAT I AM DOING EVERTHING RIGHT ? Do I have to do something for multicast domain (e.g. 224.0.0.9) Thanks Baris TA7W DEBUG OUTPUT: ------------------------ Using metric 0 for routes. Using TCP window 840 for routes. Using routing table 'main' (254). Can not open encap file for reading: /var/lib/ampr-ripd/encap.txt Max list size: 1000 entries Detected tunnel interface address: 44.176.200.1 Interface detected: lo, IP: 127.0.0.1 Interface detected: eth0, IP: 80.211.231.30 Interface detected: eth1, IP: 0.0.0.0 Interface detected: eth2, IP: 0.0.0.0 Interface detected: tunl0, IP: 44.176.200.1 Assigned tunnel interface index: 5 Local IPs: 127.0.0.1 80.211.231.30 44.176.200.1 NL sending request. NLMSG: get route (26) RTA type: 1 (8 bytes): 8 8 8 8 NL response received. NLMSG: request new route/route info (24) RTA type: 15 (8 bytes): 254 0 0 0 RTA type: 1 (8 bytes): 8 8 8 8 RTA type: 4 (8 bytes): 2 0 0 0 RTA type: 7 (8 bytes): 80 211 231 30 RTA type: 5 (8 bytes): 80 211 231 1 RTA type: 8 (28 bytes): 8 0 2 0 220 5 0 0 8 0 8 0 180 5 0 0 8 0 10 0 64 0 0 0 RTA type: 12 (36 bytes): 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 NL sending request. NLMSG: get route (26) RTA type: 1 (8 bytes): 80 211 231 1 NL response received. NLMSG: request new route/route info (24) RTA type: 15 (8 bytes): 254 0 0 0 RTA type: 1 (8 bytes): 80 211 231 1 RTA type: 4 (8 bytes): 2 0 0 0 RTA type: 7 (8 bytes): 80 211 231 30 RTA type: 8 (28 bytes): 8 0 2 0 220 5 0 0 8 0 8 0 180 5 0 0 8 0 10 0 64 0 0 0 RTA type: 12 (36 bytes): 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Using gateway 80.211.231.1 for direct 44net endpoints via interface eth0. Setting routes (0). Creating multicast RIP UDP listening socket. Setting up multicast interface. Waiting for RIPv2 broadcasts...

5 13

Re: [44net] ping
by Bill Horne W4EWH 02 Dec '17

02 Dec '17

On Mon, Nov 27, 2017 at 10:42:22 AM, Christopher Allsop wrote: >> Has the AMPRNet group considered/have they moved over to an online >> group instead of a mailing list? Perhaps something like Groups.io >> or even a Slack channel may provide some information. Even a Reddit >> group would allow information to be archived and searched later on. >> I've always found email groups to be difficult when you want to >> search for answers to questions already asked. On Mon, Nov 27, 2017 at 10:52 AM, Brian Kantor wrote: > This subject has been discussed to death in this group recently > and the decision was to stay with a mailing list. I propose that we start a Google group that accesses the Yahoo! copy of the rec.radio.amateur.digital Usenet archive and sends all responses to a new Listserv located at the RSGB via RFC1149 encapsulation. That way, we get the best of all possible worlds: a system that reflects ham radio's "can do" attitude and includes all the best parts of the amateur radio and the pigeon fancier hobbies. Bill, W4EWH

3 2

CalAmp Viper SC+
by Michael Fox - N6MEF 30 Nov '17

30 Nov '17

All, I've been looking for a way to get fast enough speed over RF to be able to use some more modern protocols, such as SMTP & POP3 for email with attachments. I had high hopes for some guys in the NW US, but . <sigh>. So, I started looking elsewhere and someone else here mentioned the DataRadio -> CalAmp Gemini. That particular radio was recently discontinued. But I found the CalAmp Viper SC+. There are several models. It can achieve up to 256 kbps, depending on band, channel configuration, etc. We would probably use the radio in the 70 cm band. My assumption was that any emission designators that they might use would most likely not be allowed in FCC Part 97. But they use emission designators .F1D. And what does FCC Part 97 say? 97.305(c): For the 70 cm band, it references 97.309(f)(6) and 97.309(f)(8). 97.309(f)(8): "A RTTY or data emission having designators with A, B, C, D, E, F, G, H, J or R as the first symbol; 1, 2, 7, 9 or X as the second symbol; and D or W as the third symbol is also authorized." How about that!? ...F1D fits that bill. Baud rate is also within FCC limits. So this looks like a real possibility. Price is steep: about $1400 list. But for our purposes, it fills a gap between 1200/9600 packet and WiFi, allowing for field deployment with a simple roll-up J-pole. And provides locations some basic IP connectivity even if they don't have line of sight for WiFi. If you're interested, check it out! BTW, for you non-US guys, they have international certifications. Check out the details via a local distributor. http://www.calamp.com/products/cellular-communication-devices-routers/router s/viper-sc-0 http://www.calamp.com/system/files/resources/hardware-spec-sheets/viperscplu sdatasheet.pdf http://www.calamp.com/references/manuals/Viper_SC_User_Manual.pdf Michael N6MEF

1 0

ping
by Brian 27 Nov '17

27 Nov '17

Is this list still active?

5 7

Re: [44net] Ping
by Brian 27 Nov '17

27 Nov '17

Thanks. I didn't know if the list was very slow (usually U.S. folk share holiday greetings) or if I simply wasn't getting mail.

1 0

Master DNS server for AMPR.ORG and 44.IN-ADDR.ARPA upgraded
by Brian Kantor 08 Nov '17

08 Nov '17

The master DNS server for AMPR.ORG and 44.IN-ADDR.ARPA on gw.ampr.org has been upgraded from ISC bind9.10 to bind9.11. (FreeBSD maintenance of 9.10 is ending in a few months.) This should not affect anyone. Let me know if you suddenly encounter any host or address lookup problems from today on. - Brian

2 1

misconfigured gateways
by Brian Kantor 01 Nov '17

01 Nov '17

There are two gateway systems with misconfigured routing tables that are attempting to route all of net44 through amprgw instead of using mesh connections. These may have a default route instead of using the correct routing table. Whatever the case, they aren't going to have much luck reaching other net44 hosts. Those gateway operators should check their configurations. - Brian Last update at Sun Oct 22 06:30:01 2017 PDT [-0700] gateway inner src #errs indx error type ---------------- ---------------- ----- ---- ------------------------------- 79.0.254.164 44.134.96.1 5408 [ 8] dropped: encap to encap 173.230.244.130 44.68.41.1 1349 [ 8] dropped: encap to encap

2 1

Re: [44net] AMPRnet Allocation for a Club?
by Rob Janssen 25 Oct '17

25 Oct '17

> That is, if your repeaters are at different sites, you'll probably > need different tunnels for each site, and therefore different allocations, > one per site. (It's a restriction of the portal/tunnel system that > you can't further subnet an allocation for different gateways). Really? We do have that, and it appears to work fine... Or has there been a change that disallows new creation of subnets that way?

3 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net