- 44net - mailman.ardc.net

Re: [44net] Google indexing
by Rob Janssen 07 May '19

07 May '19

> Rob, > Sorry, I forgot to say which site: separs.ampr.org <http://separs.ampr.org/>. > Yes, there are indexed ampr.org <http://ampr.org/> subdomains, but I don’t seem to be getting my point access. Those domains are older and indexing no longer works. You can keep iterating that, but it is simply not true. You undoubtedly have difficulties and I'm sure they are difficult to solve, but they aren't ampr.org wide. > Eventually according to Google, they will fall off their indexing. Google indexing can no longer reach them or any new site. Maybe your friend has told you that, but he has told you other things that are wrong. So I would not count on that. > 5) I asked Brian to add a TXT entry, as per the Google Search console instructions. It is in fact not required to do that, you can create a textfile with a name that is the same as what you put in the TXT record and it will work the same way. I have added sites to the search console in the past and used that method, it worked fine. > 6) Initialy Brian did not want to do it, saying he didn’t want Google crawling all the 44net IPs Contrary to what some "researchers" (and some of our fellow amateur radio operators) enjoy doing, Google is not portscanning the IP space to find sites to crawl. Google indexes HTTP links and follows them. Of course this takes bandwidth, but that is not much when compared to the many many black-hat and white-hat portscanners. > 9)I attempted to have the Google Search Console crawl the site. It declined indicating "no errors" but an “anomaly” I cannot help you with that. Your site appears OK from the outside, and my site(s) are indexed just fine. There is only one thing I cannot check: there could be some firewall filter that drops Google indexing (usually from 66.249.64.0/19) in the ampr gateway or in another system in the path to you. (our local sites within 44.137.0.0/16 are not routed via that gateway so we are not subject to that filter if it exists) However I don't think that is the case because there are other sites that are being indexed. Rob

4 3

Gateway with Home router running OPENWRT ?
by R P 07 May '19

07 May '19

Hi there Has anyone done / do Gateway with home router running OpenWrt ? If yes I have some questions as the WIKI is not so clear to non software man like me . How the routing made ? does the ADSL interface get the home address (i.e 192.168.1.x in my case) and the lan port get the 44 Net address ? or one Interface deal with Both network like i do in my MikroTik ? what about configuration ? is there any way to do it via the GUI ? or only with the line mode ? I mean that the Router sit on the home DMZ (that supplied from the main home router) and the Adress of the outside world arrive to it for the tunnel from UCSD I saw that there is IPIP Package that support IPIP so what the difference and why the Kernel_ipip mode needed ? and last where can i get executable of the ripd ? i can not compile ... the router planed for the task is D-Link DSL2650 with broadcom 6358 That I Flashed for OpenWRT I have heard that the OPENWRT is not a stable system and get stuck and needed reset here and there can someone confirm that ? Thanks in advance 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] Google indexing
by Rob Janssen 06 May '19

06 May '19

> All,Don't these sites all appear to be indexed in the past?73,- LynwoodKB3VWG > null When checking for a site within our network, I see that Googlebot comes by almost every day, and when I check the site on Google and retrieve the page "from cache", I get pages dated April 9th and 10th. This reconfirms my earlier observation that it may take a couple of weeks for crawled pages to appear on the Google site. Rob

1 0

Google indexing
by lleachii 06 May '19

06 May '19

All,Don't these sites all appear to be indexed in the past?73,- LynwoodKB3VWG null

1 0

Re: [44net] Google indexing
by Rob Janssen 06 May '19

06 May '19

> When one asked what your site was, you didn't reply. If it's va7llb.ampr.org, > it is unreachable from the internet today. That'd stop more than Google > indexer... As we still did not get that information, I checked the DNS zone and there are only two TXT records for google site verification. One is for va4wan.ampr.org and their site is indexed by Google, no problem there. You can lookup site:va4wan.ampr.org to confirm that. (again: the "site:" in that is important, don't omit it) The other is for separs.ampr.org and Google does not yet know about them. So probably he is discussing that. It appears to work OK when visited inside and outside of AMPRnet and its robots.txt also appears OK. I think it is just external linking that is required. Try to get a link to your site from the city website where it had an information page before. Make links from your local club, from private sites of your members, etc. Then Google becomes more convinced that this is a useful site that people may want to visit, rather than some scam that wants to have quick visitors and then disappear. (of which they probably get thousands a day submitted) And of course you need patience. It will not happen overnight. We all know that it is difficult to communicate with them and that they do what they themselves consider appropriate. You will have to live with that, we all do. Rob

1 0

Re: [44net] 44Net Digest, Vol 8, Issue 72
by Roger 05 May '19

05 May '19

Hi all, I’m a bit sorry to have brought the issue of google’s inability to crawl ampr.org subdomains. I thought others might also feel that it would be nice to have their ARES group or other Ham group represented on the Ham network (44Net) for the work to see. Instead it feels like there is no interest at all in figuring out why this happens, instead blaming it on Google, or me for brining the issue forward and trying to contact google for help (you do realize that the only way to actually talk to google is to know someone there, so I’m sorry that I have “a friend” at google that tried to help with some inside information that the google search console does not provide.) Roger VA7LBB > On May 4, 2019, at 12:00, 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. Re: Google indexing (Roger) > 2. Re: Google indexing (Roger) > 3. Re: Google indexing (Steve L) > 4. Re: Google indexing (Rob Janssen) > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

4 4

Re: [44net] Google indexing
by Roger 04 May '19

04 May '19

Rob, When I put ampr.org in the google search almost all come back as first the TLD and wiki. The others are sites talking about ampr.org and the group that are subdomains are old dead links. As I said in the first email, I did consult the google search console and submitted the site. I’ve submitted the site and Brian was kind enough to add. a TXT line (as per google search console) with the code proving I have the right to submit the domain. That is several weeks ago and the search console shows it attempted to crawl. Googles server now (unlike years ago) honor request to not crawl. It attempted the crawl and declined to proceed. You probably know that it’s nearly impossible to contact google for support. Therein lies my luck to have a friend that could look behind the scene at the google server. His answer is that this is not a google problem but an issue with some sort of blocking at the TLD. He just can’t tell what that is except, the google crawler is being told to not crawl subdomains in some way. All I was asking was that if someone more knowledgeable than me with access to the DNS could see what possibly would cause this denial. Have a careful look through the google search response to ampr.org. There are none. Roger. VA7LBB On May 4, 2019, at 02:19, Rob Janssen <pe1chl(a)amsat.org> wrote: >> My friend at google isn’t 100% sure what’s happening > > That is very obvious! > Maybe you should consult the google search engine itself, instead of your friend. > > Enter this in the Google search bar: site:ampr.org > > This returns 17700 results of all kinds of different sites below .ampr.org. > You see the domain names xxxx.ampr.org listed in the results. > > So there really is no problem indexing ampr.org sites. > > I think what you encounter is the difficulty to add a NEW site to the index, not any generic > problem with .ampr.org. > They probably aren't that eager to add a new site, of which you specify only a start URL, to > their index. And rightly so. That capability was likely abused widely. > > Instead, you should (ask to) put links to your site from other sites relevant to the subject > of your own site. E.g. the page of your local club, other people's private sites, etc. > Then, after some time, indexing will occur. > > Rob > > > >

2 1

Re: [44net] Google indexing
by Rob Janssen 04 May '19

04 May '19

> My friend at google isn’t 100% sure what’s happening That is very obvious! Maybe you should consult the google search engine itself, instead of your friend. Enter this in the Google search bar: site:ampr.org This returns 17700 results of all kinds of different sites below .ampr.org. You see the domain names xxxx.ampr.org listed in the results. So there really is no problem indexing ampr.org sites. I think what you encounter is the difficulty to add a NEW site to the index, not any generic problem with .ampr.org. They probably aren't that eager to add a new site, of which you specify only a start URL, to their index. And rightly so. That capability was likely abused widely. Instead, you should (ask to) put links to your site from other sites relevant to the subject of your own site. E.g. the page of your local club, other people's private sites, etc. Then, after some time, indexing will occur. Rob

1 0

Re: [44net] Google indexing
by Roger 04 May '19

04 May '19

Brian, My friend at google isn’t 100% sure what’s happening, just that when the crawler attempts the crawl, it comes back with the same code it gets for a robots.txt or something similar. So to clarify, google claims, something at the “top domain” (their words) has prevented almost all subdomains from being crawled. And whatever that is, it clearly has an affect because I really don’t find any results for ampr.org, except the main site, portal and wiki. Jann: I realize there are many other reasons and uses for amprnet. I was just talking about webserving some sort of content out to the internet at large. The issue I’m having affects anyone using 44Net, including those in your examples, that are wanting it discoverable by the world at large. 73 Roger VA7LBB > On May 2, 2019, at 19:31, Brian Kantor <Brian(a)bkantor.net> wrote: > > Having the robots.txt file at the site AMPR.ORG apply to pages > served by that host is completely reasonable. > > Having the robots.txt file at the site AMPR.ORG apply to pages > served from an entirely separate site called, e.g., VA7LBB.AMPR.ORG > is one of the most colossal pieces of internet engineering stupidity > I have ever encountered. > > Yet it would appear that is what the person at Google is telling > you is happening to your site. > >> From Wikipedia: > "A robots.txt file covers one origin. For websites with multiple > subdomains, each subdomain must have its own robots.txt file. > If example.com had a robots.txt file but a.example.com did not, > the rules that would apply for example.com WOULD NOT APPLY to > a.example.com. In addition, each protocol and port needs its own > robots.txt file; http://example.com/robots.txt does not apply > to pages under http://example.com:8080/ or https://example.com/" > > If that's not what their crawlers are doing, their crawlers are broken. > They broke it, they get to fix it. It's not our problem. > - Brian > > > > >> On Thu, May 02, 2019 at 06:13:40PM -0700, Roger Andrews wrote: >> Hi, >> I recently talked with Brian briefly about this and wanted to >> throw it out to the group. It’s incredibly rare to see any of the >> tunnels that have been created, represented in a Google search. >> While I understand and agree that any site that will become a high >> volume site has no place on Amprnet (we have to share resources) >> it also seems pointless to create a website that is undiscoverable. >> After all, isn’t the primary purpose of a website to share it’s >> content with others. I recently created a website on a 44net gateway >> and after several weeks, (and even convincing Brian to add a meta >> TXT entry allowing me to ask google to crawl), I am not seeing any >> content on Google. I put in a service request to google (not the >> easiest task) and I was advised that robots.txt or some other >> prevention device is blocking indexing all the subdirectories on >> amp.org. I was told that the few gateways that I see in the results >> were likely crawled before the restriction on ampr.org was applied. >> I created the website for our ARES group and placed it on an ampr >> gateway because we don’t have funds, and in reality, see very little >> traffic. We had a .net site last year and averaged about 50 visitors >> a month. My question is - is it really necessary to prevent the >> whole of ampr.org from being crawled (except of course the top >> domain which does show up). So many ip addresses, but almost none >> visible seems a real pity. >> Thanks for listening. My only hope is that this creates a little >> bit of debate around the issue. >> >> 73 >> Roger >> VA7LBB >

2 1

Re: [44net] Google indexing
by Roger 04 May '19

04 May '19

Steve, I’m wondering how long ago google crawled your site. You can’t just ask them to crawl a site anymore like the old days. You need to prove ownership before you can request it. According to my friend at google, none of the ampr subdomains have been crawled in a couple years. > On May 2, 2019, at 22:35, Steve L <kb9mwr(a)gmail.com> wrote: > > I have had google crawl and index my ampr.org site. I have since > blocked that though, as I don't really even need what I am running to > be accessible outside of the 44 netspace. > > Keep in mind webservers are just one type of service. My most > frequent non 44 net type of traffic is SMTP. > > If you are trying to get a feel for what is out there, here is a > message from a few years ago. (Note: Most are only accessible from > within the network) > > ---- Begin Forwarded Message ---- >> [44net] 44net cool toys >> Jann Traschewski jann at gmx.de >> Wed Mar 19 15:21:05 PDT 2014 > >> Ok what are people actually DOING over their Internet-connected 44 radio >> net? >> >> VOIP? APRS? Video links? Repeater linking? IP cameras? Remote bases? > > All of them! You might want to click around: > > Web: > http://web.db0avh.ampr.org > http://db0bi.ampr.org > http://db0dah.ampr.org > http://db0eeo.ampr.org > http://db0end.ampr.org > http://db0fhn.ampr.org > http://db0res-svr.ampr.org > http://db0gos.ampr.org > http://db0dz.ampr.org > http://db0ii.ampr.org > http://db0iuz.ampr.org > http://44.225.56.72/cms25 > http://db0kwe.ampr.org > http://srv.db0lj.ampr.org > http://db0nis.ampr.org > http://db0ovn.ampr.org > http://44.225.60.2 > http://db0sda.ampr.org > http://db0ach.ampr.org > http://db0pra.ampr.org > http://websrv.db0pdf.ampr.org > http://db0wet.ampr.org > http://db0ham.ampr.org > http://44.143.10.90 > http://web.oe2xzr.at.ampr.org > http://dm0ha.ampr.org > http://dm0zgw.ampr.org > http://db0erf.ampr.org > http://web.oe5xbl.at.ampr.org > http://web.oe7xci.ampr.at > http://44.168.12.11 > http://server.db0anf.ampr.org > http://www.db0fuz.ampr.org > http://linux.db0zeh.ampr.org > http://monitor.db0mhb.ampr.org > http://db0bul.ampr.org > http://rpt.db0pob.ampr.org > http://db0kpg.ampr.org > http://db0lip.ampr.org > http://44.225.76.161 > http://db0zdf-srv01.db0zdf.ampr.org > http://raspberry.db0abz.ampr.org > http://db0fc.ampr.org > http://cloud.db0fc.ampr.org > http://db0oha.ampr.org > http://dk0mav.ampr.org > > SDR: > http://dstar.db0vox.ampr.org:8901 > http://debian.vm.db0tvm.ampr.org:8901 > http://websdr.db0iuz.ampr.org:8901 > http://websdr.oe4xlc.at.ampr.org > http://db0tv.ampr.org/index.php?option=com_content&task=view&id=38&Itemid=47 > > Fotocam: > http://db0bi.ampr.org/webcam/bielefeld > > Maps: > http://osm.oe2xzr.ampr.at > http://tileserver.db0fc.ampr.org > > Packet Radio: > http://xnet.db0eeo.ampr.org > http://dlc7.oe7xgr.at.ampr.org > http://dlc7.db0kv.ampr.org > http://dhcp200.db0wal.ampr.org > http://db0res-node2.ampr.org > http://pr-srv.db0gis.ampr.org > > APRS: > http://aprs.db0res.ampr.org > > ATV: > http://db0ko.ampr.org > http://testpc.db0res.ampr.org > http://db0ntv.ampr.org > http://db0tv.ampr.org/index.php?option=com_content&task=view&id=71&Itemid=76 > > BBS: > http://db0ii.ampr.org:8080 > http://db0iuz.ampr.org:8080 > > Convers: > http://db0iuz.ampr.org/cgi-bin/dlwwc.php > > DX-Cluster: > http://dxcluster.oe1xhq.ampr.at > http://db0iuz.ampr.org/cgi-bin/spider.cgi > > Pager: > http://db0ii.ampr.org:9080 > http://db0iuz.ampr.org:8081 > http://db0fhn.ampr.org:4780 > > Webcam: > http://webcam.oe1xar.at.ampr.org > http://webcam.oe2xzr.at.ampr.org > http://video.oe5xll.at.ampr.org > http://webcam.oe7xzr.at.ampr.org > http://webcam.oe8xdr.at.ampr.org > http://db0iuz.ampr.org/webcam/webcam_radom.php > http://db0iuz.ampr.org/webcam/webcam_techniker.php > http://srv.db0lj.ampr.org/spycam.html > http://webcam.db0zdf.ampr.org/view/index.shtml > http://webcam.db0pob.ampr.org > > Active Hosts: > http://hamnetdb.net/?m=host&as=0 > > 73, > Jann > DG8NGN > > > -- > Jann Traschewski, Lenbachstr. 6, D-90489 Nuernberg, Germany > Tel.: +49-911-696971, Mobile: +49-170-1045937, E-Mail: jann at gmx.de > Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn > >> On Thu, May 2, 2019 at 8:16 PM Roger Andrews <va7lbb(a)rezgas.com> wrote: >> >> Hi, >> I recently talked with Brian briefly about this and wanted to throw it out to the group. It’s incredibly rare to see any of the tunnels that have been created, represented in a Google search. While I understand and agree that any site that will become a high volume site has no place on Amprnet (we have to share resources) it also seems pointless to create a website that is undiscoverable. After all, isn’t the primary purpose of a website to share it’s content with others. I recently created a website on a 44net gateway and after several weeks, (and even convincing Brian to add a meta TXT entry allowing me to ask google to crawl), I am not seeing any content on Google. I put in a service request to google (not the easiest task) and I was advised that robots.txt or some other prevention device is blocking indexing all the subdirectories on amp.org. I was told that the few gateways that I see in the results were likely crawled before the restriction on ampr.org <http! > ://ampr.org/> was applied. I created the website for our ARES group and placed it on an ampr gateway because we don’t have funds, and in reality, see very little traffic. We had a .net site last year and averaged about 50 visitors a month. My question is - is it really necessary to prevent the whole of ampr.org <http://ampr.org/> from being crawled (except of course the top domain which does show up). So many ip addresses, but almost none visible seems a real pity. >> Thanks for listening. My only hope is that this creates a little bit of debate around the issue. >> >> 73 >> Roger >> VA7LBB >> >> _________________________________________ >> 44Net mailing list >> 44Net(a)mailman.ampr.org >> https://mailman.ampr.org/mailman/listinfo/44net > >

1 0

Re: [44net] Google indexing
by Rob Janssen 03 May '19

03 May '19

I don't think there is an issue with Google indexing, they index my/our servers just fine. As Brian already wrote, a http://ampr.org/robots.txt file should have no effect on that. Besides (at least in the current version) there is nothing in that file that would prevent such indexing aside from a /wp-admin/ directory. What you need for Google indexing is links from other sites, that are already being indexed, that point to you. And some patience. It is not like a newly crawled site will appear in the index the next day. Or even the next week. (maybe they do some re-crawling to avoid indexing scams and other malicious sites) Rob

1 0

Google indexing
by Roger Andrews 03 May '19

03 May '19

Hi, I recently talked with Brian briefly about this and wanted to throw it out to the group. It’s incredibly rare to see any of the tunnels that have been created, represented in a Google search. While I understand and agree that any site that will become a high volume site has no place on Amprnet (we have to share resources) it also seems pointless to create a website that is undiscoverable. After all, isn’t the primary purpose of a website to share it’s content with others. I recently created a website on a 44net gateway and after several weeks, (and even convincing Brian to add a meta TXT entry allowing me to ask google to crawl), I am not seeing any content on Google. I put in a service request to google (not the easiest task) and I was advised that robots.txt or some other prevention device is blocking indexing all the subdirectories on amp.org. I was told that the few gateways that I see in the results were likely crawled before the restriction on ampr.org <http://ampr.org/> was applied. I created the website for our ARES group and placed it on an ampr gateway because we don’t have funds, and in reality, see very little traffic. We had a .net site last year and averaged about 50 visitors a month. My question is - is it really necessary to prevent the whole of ampr.org <http://ampr.org/> from being crawled (except of course the top domain which does show up). So many ip addresses, but almost none visible seems a real pity. Thanks for listening. My only hope is that this creates a little bit of debate around the issue. 73 Roger VA7LBB

4 3

amprd 3.0 released
by Marius Petrescu 02 May '19

02 May '19

Hello, amprd 3.0 is available in the usual locations. http://yo2tm.ampr.org/hamprojects http://www.yo2loj.ro/hamprojects What's new: - Added support for AMPR subnets in ignore list - Added disable/enable option for incoming multicast and broadcast traffic - Added support for selectable PID file In regard of the issues with those ICMP unreachable messages: For those keen ones, I added an optional kernel module, which needs to be compiled and installed (howto is in the module subfolder). Also, there is a new global option in the config file to enable its use. This is a netfilter module which intercepts the IPIP 4 protocol and converts it to protocol 94 and the other way around, circumventing the series 4 kernel behavior that triggered the sending of those messages. So those that want to try it: compile it (you will need to have the kernel toolset and kernel headers installed), install it and enable the use_redirector option. For the rest, the filtering option will still work as expected. Setails are in the readme files. Have fun! Marius, YO2LOJ

1 0

Block or error?
by Marius Petrescu 29 Apr '19

29 Apr '19

I have a question to the sysops running gateways in Europe. Lately, my subnets (44.182.21.0/24, 44.182.20.0/24 and 44.182.21.253 using gw 89.122.215.236 and yo2loj.go.ro) seem to have been lockout from different regions like Germany, Poland, Portugal and Bulgaria, while access from 44.182.21.1/32 still works. Is this intentional or just a configuration issue? Marius, YO2LOJ

3 4

VPN Broken link
by KJ7DMC 22 Apr '19

22 Apr '19

Subject: VPN Hello, Due to some annoying ISP firewalling that I cant control, I'm going to have to VPN into the network, or set up a vps somewhere and vpn into that. Ideally the first option since its cheaper :) The link to www.arrl.org/instructions under this article http://wiki.ampr.org/wiki/AMPRNet_VPN is invalid however. I'm not sure who exactly to contact about this, since I cant find an author's name in the wiki. Any help would be appreciated. Thanks! -Nate

3 2

Re: [44net] AX25 support on Linux based (Raspberry PI) node
by Lorenzo Simoncello 19 Apr '19

19 Apr '19

Il giorno mer 13 mar 2019 alle ore 16:43 Thomas Osterried < thomas(a)osterried.de> ha scritto: > > It's always the best choice to use the official repo. See > http://www.linux-ax25.org/wiki/GIT > http://www.linux-ax25.org/wiki/Compilation > > It would always have been a good idea to send patches upstream. > Since three days ago, the official ax25 site is not available.... are there any news? Very recent, there were some updates... and there was a new release canidates (RC5) - thanks to maintainers :) May be they are are fixing all the issues that have been fixed in the VE7FET repos and also others issues??? At the moment i would like to thanks and i'm hoping something new... Lorenzo iw3her

2 1

Re: [44net] RIP problems?
by Rob Janssen 18 Apr '19

18 Apr '19

> Google says it's my fault; I say Google has its collective head up > its ass in marking a valid email as spam. Their official word is > "Don't act like the bad guys" and you won't have problems. Never > mind that it's 100% RFC-compliant, they say it's bad guy behaviour. I agree. Sending mail to google (and also hotmail/outlook) has become very unreliable. E.g. when using @amsat.org or other forwarding services like @veron.nl or @vrza.nl (Dutch amateur radio societies) it will usually not work. I do not really want to use my ISP mail address, so it looks like I have to register my own domain to get this fixed. For now, I have set an autoreply (from the ISP mail address) encouraging people to use a different address and look in their spambox when they expect a reply. I hear that it is customary in the circles of gmail/hotmail/outlook users to send a Whatsapp message "I have sent you an e-mail"... Rob

1 0

DNS
by monsieurmarc＠btinternet.com 18 Apr '19

18 Apr '19

Hi all, Who do I contact these days about getting a dns entry for 44.131.192.128 All help appreciated. Regards Marc (2W0PNT)

18 25

Re: [44net] RIP problems?
by Rob Janssen 18 Apr '19

18 Apr '19

> Everyone happy with this? Any comments? It would be nice if the mail had some info about what a gateway is and why you (don't) want it, e.g. with a pointer to the wiki page. I have found that some people add a gateway entry because they think this is some form of registration of their existing (not IPIP mesh) router e.g. connected via radio or via one of the other VPN types we support. They think it would be useful to be registered in some list. That is how the problematic gateway came into existance, and there are several others like that registered in the Netherlands, that did not become problematic only because they had no subnets. When being listed is what they actually want, of course they should not register a gateway. But it is what they do, partly because there is a lack of higher-level explanation of concepts. And after receiving that mail message they probably still don't understand what they are doing wrong. Maybe a pointer to HamnetDB could be useful. Registering there is probably what they want. Rob

5 5

amprd setup issues
by Marius Petrescu 16 Apr '19

16 Apr '19

Hello, To all amprd users (this does not affect setups using the kernel tunnel driver and ampr-ripd). Due to changes in the 4.x kernels, there's a problem with the system replying with "icmp unreachable" to incoming IPIP traffic. This will possible drop incoming traffic, including the RIP broadcasts (resulting in incomplete route tables). Please switch to an ampr-ripd setup or filter outgoing icmp messages on your WAN interface, using a rule like the one below: *iptables -A OUTPUT -o ethX -p icmp --icmp-type destination-unreachable -m state --state RELATED -j DROP* I hope I can find a workaround on this issue. Marius, YO2LOJ

2 3

Re: [44net] RIP problems?
by Rob Janssen 16 Apr '19

16 Apr '19

> If you want to suggest some text I can add it to the template… > Thanks, > Chris I hope a native English speaker can do this... Rob

1 0

Re: [44net] RIP problems?
by Rob Janssen 16 Apr '19

16 Apr '19

> I don't think folks would add a gateway if they haven't been approved for a block. Well, actually they do. The problem is that the visitors of the portal do not know at all what the whole concept of the IPIP tunnel mesh looks like, how it is relevant within AMPRnet, and that it is only one of the options for getting connected. As there is no walk-through explanation of concepts like a registered subnet, a gateway, the resulting IPIP tunnel mesh, etc, people just blindly click on menu items and fill out forms. Then they have a gateway but the still don't understand how that all works. So they close the site and continue to look elsewhere for information, and when they find it they never come back to delete what they created. That is why it is good to remove that crud, but also it would be good to have some more explanatory text and/or pointers to where that can be found. And some warnings that this is not a system to voluntarily register some information about one's station, but that it is actually used for something and that you can actually break things by entering information. (of course we should strive for a situation where one cannot break the network for other users, but still one could break the routing of one's own subnet) Rob

1 0

Re: [44net] amprd setup issues
by Rob Janssen 16 Apr '19

16 Apr '19

> I would replace DROP by REJECT. DROP means the system will wait till the packet times out. > For outgoing connections this may cause issues as the daemon that sends the unreachable will also wait till the packet times out before continuing No, outgoing ICMP "destination unreachable" is not an outgoing connect and it makes no sense to REJECT them... (this kind of packet should not be replied to) Rob

1 0

Re: [44net] RIP problems?
by G1FEF 16 Apr '19

16 Apr '19

> > Given this, perhaps you could add a note suggesting that one or the list > of blocks should be added when they reregister their gateway, that would > eliminate any confusion... just my two cents. This better: —8< SNIP >8--- Hello {givenName}, This is a system generated email from the AMPRNet Portal. This is a courtesy notice to advise you that your gateway entry has been removed. Your gateway was removed by an automated process that looks for gateways that have had no attached subnets for at least one week. Your gateway has met this criteria and has thus been removed. It is important that the Portal data is kept up to date and accurate. If you still want to run a gateway, please feel free to add your gateway back to the Portal. Your gateway's details were: Title: {gwTitle} IP: {gwIP} Host: {gwHost} Notes: {gwNotes} You have the following subnets allocated to you: {listOfSubnets} If you add your gateway back, please ensure that you allocate at least one subnet to it, otherwise this process will remove your gateway again in a week! Kind Regards, The AMPRNet Team —8< SNIP >8—

2 2

Re: [44net] RIP problems?
by Rob Janssen 16 Apr '19

16 Apr '19

What is the final outcome of the discussion? Will any changes be made to the Portal to validate user input for default users? Will there be a change in functionality w.r.t. having gateways with external address within AMPRnet? Will incomplete gateway entries be deleted? I hope we can have some outcome of the bad situation and following discussion, instead of leaving everything as it is. Rob

4 5

Router demo
by Marius Petrescu 16 Apr '19

16 Apr '19

Although I wanted to provide a freely accessible demo for ALL ham operators as an configuration example on an EdgeRouter, I'm starting to have my doubts. Especially to w6ray... What is the use of hanging on a router web interface for 24h now? What new information could it give you by watching its interface? Marius, YO2LOJ

5 9

Re: [44net] RIP problems?
by Rob Janssen 16 Apr '19

16 Apr '19

> I am happy to implement BK’s suggestion to limit the setting up of gateway endpoints that fall within the 44/8 range to co-ordinators. > I am also happy to go through and remove any currently empty/incomplete gateways. Perhaps I could also setup a cronjob that purge such entries on a regular basis, e.g. any that are over a week old with no subnets? > I can implement the above fairly quickly if that is what is wanted? I would certainly appreciate that. Even better would be to implement the addition of a new property 'advanced user' (initially copied from 'co-ordinator' and settable by you and Brian) and also the re-introduction of checking the subnets being routed by the gateway, depending on that property. But even with only the changes mentioned above we should have some improvement in reliability. Brian: I also wonder if the return if ICMP unreachable messages on RIP broadcasts is somehow logged or stored in a form that allows gateways that have done this for extended periods of time to be automatically disabled or deleted. Rob

2 1

EdgeRouter full setup instructions to the Wiki
by Marius Petrescu 14 Apr '19

14 Apr '19

I have added the EdgeRouter full setup instructions to the Wiki. http://wiki.ampr.org/wiki/Setting_up_a_complete_gateway_on_Ubiquiti_EdgeRou… Have fun, Marius, YO2LOJ

1 0

Re: [44net] RIP problems?
by Rob Janssen 11 Apr '19

11 Apr '19

> I would propose an alternate solution. Since the number of such > valid gateways is so very few, perhaps it would work well enough that > someone must *be* a coordinator to set up a gateway whose outside-world > address is in network 44. Note it also involves routing subnets that belong to others... I don't know how difficult it would be to add an extra property to a user record, should be a minute of work in a LAMP environment, I guess. Maybe a shortcut would be to add the "advanced user" property and initially set it equal to the value of the "coordinator" property. Then it can start operation quickly and should it turn out that really users require this without being a coordinator then later some kind of UI can be added to allow setting that. (by the users themselves, by coordinators, or by admins, whatever seems best) Rob

4 3

Re: [44net] RIP problems?
by Rob Janssen 11 Apr '19

11 Apr '19

> I think somewhere less obvious (like under ones user profile) there > should be a place to check a box to enable "advanced user options." > And if that is checked then such abnormal things would be accepted? > Not sure how feasible/easy that sort of thing is for Chris to code though. I think that is actually the best idea. Adding a flag to each user (default false) and using it to enable those things (checks that were present before!) should not be that difficult. At least it should be easier than adding an extra step in the workflow. Rob

5 5

Re: [44net] RIP problems?
by Rob Janssen 10 Apr '19

10 Apr '19

> and who would be responsible for turning the flag on/off? > The user themselves? In which case aren’t we back to square one (with some/most users at least). > or perhaps a coordinator? > Do they want the extra responsibility? When you fear that will be a problem I would suggest to set the flag to false for everyone except experienced users like VE3TOK, DG8NGN, N1URO etc, and await requests to enable it for others. I would be OK with managing that for my area as a coordinator. I don't think that users are especially malicious, they just don't know what they want and what they are doing. An extra procedure provides the opportunity to explain things more clearly (in native language) and most users would not require the extra functions anyway. I also suggest to remove all gateways that have no subnets (those are likely the result of experiments that never went anywhere) and all gateways related to user accounts that have expired. They are easy enough to re-add when desired. There could be logging which gateways returned "ICMP - dest unreach" on the RIP broadcasts, if so those that did so for a long time could be removed as well. Then it is easier to have a closer look at what remains, to check if there are likely config errors. Rob

1 0

MikroTik Discovery Protocol?
by lleachii＠aol.com 10 Apr '19

10 Apr '19

All, I'm getting consistent traffic from these gateways: 19:09:47.158200 IP (tos 0x0, ttl 244, id 38837, offset 0, flags [none], proto IPIP (4), length 150) 89.67.160.225 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 130) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 102 19:10:27.498793 IP (tos 0x28, ttl 241, id 46236, offset 0, flags [none], proto IPIP (4), length 159) 66.109.219.132 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 139) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 111 19:10:37.633539 IP (tos 0x0, ttl 242, id 10069, offset 0, flags [none], proto IPIP (4), length 166) 91.241.24.251 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 146) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 118 19:11:07.231425 IP (tos 0x0, ttl 246, id 59661, offset 0, flags [none], proto IPIP (4), length 174) 72.192.148.49 > 71.246.224.8: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 154) 0.0.0.0.5678 > 255.255.255.255.5678: [udp sum ok] UDP, length 126 Is this a discovery protocol of some sort? Do we have knowledge on how to turn it off? 73, - Lynwood KB3VWG

2 1

Re: [44net] 44Net Digest, Vol 8, Issue 57
by Roger Andrews 09 Apr '19

09 Apr '19

Eloy, I had the same issue and you need to do MSS Clamping. At least that’s what I was told and it fixed mine. Roger VA7LBB > > > > From: Eloy Ritter de Monredont <eritter(a)me.com> > Subject: Re: [44net] RIP problems? > Date: April 7, 2019 at 3:47:13 PM PDT > To: AMPRNet working group <44net(a)mailman.ampr.org> > > > Bob, following your reply I remembered that that the gateway (44.98.7.1) is setup to not respond to pings and that, for now, the 44.98.7.2 is assigned to the WAN interface of a virtual router running Untangle which also does not respond to pings. I though the management interface of the hypervisor was connected and using that IP but that was a confusion on my side, it’s using my ISP’s IP. > I’ll be changing that later on. > > Now the issue is that the virtual machines on the LAN side of the virtual Router do browse the internet fine when the WAN is connected to the VLAN that correspond to my ISP, but when connected to the 44/8 network most sites load well but some don’t, I can ping them though. > The issue is the same using my personal computer when connected to the 44/8 network. > > Anyways, I just wanted to comment on my experience as a new user. I think that it could help improve the site. > The browsing issue could be addressed in a different thread. > > Eloy > W5ERP >

2 1

OpenWRT Routing Daemon
by M6XCV (Mike) 08 Apr '19

08 Apr '19

Hi, A while back I wrote a routing daemon for receiving RIP broadcasts and installing them in to the routing table. I turned this in to a complete setup script which worked on OpenWRT without needing to compile architecture-specific binaries. I kind of stopped working on it after I got it working, as my prefix is BGP routed so I don't have much need for it myself, however I just got back to it and have created a package for easy install. This single package should work on any OpenWRT/LEDE device as it only contains platform independent scripts and dependencies that are in the standard repositories. http://wiki.ampr.org/wiki/RIP44.lua If anyone is interested in testing it, I would appreciate any feedback. If it works well then it might be easier for new users to install than the current OpenWRT instructions requiring a binary build of ampr-ripd. The source is up on github (although technically the package contains the "source", as it's a Lua script!) if anyone wants to take a look. It does a very rudimentary job of executing the required commands to set up the interface, binding to a UDP socket, then parsing the received routes. https://github.com/NotMikeDEV/RIP44/ Thanks, Mike, M6XCV

1 0

Re: [44net] RIP problems?
by Rob Janssen 08 Apr '19

08 Apr '19

> I was just going through some of the portal pages and Chris has some > extensive online help next to the various text/check boxes in the "?" > circles. We can't hold Chris accountable for people not comprehending > what they read on the portal. The online help did seem pretty accurate > and well written. It is not to hold Chris accountable, but some extra text above the form (that also explains what a gateway is and that setting up a one may not be what you want to do as a beginner) could be helpful. Still, there can be problems. > People will always make mistakes. I've seen some enter in their internal > 192 or 10-net space IP as their commercial IP. Perhaps some sort of data > checker can be put in place? That may help. I hope the RFC1918 check is already made. If not it could be added. As I wrote before, there have been reasonable checks in place but people here have asked them to be removed because they wanted to do what the checks prevented. (like setting up a gateway with external address in net-44) Rob

8 8

Re: [44net] RIP problems?
by Rob Janssen 07 Apr '19

07 Apr '19

> If there are any additional checks that can be put into the Portal, I’m happy to add them if we can reach a consensus on what those checks should be... > Regards, > Chris Do you think it is viable to add another manual validation step for any gateway config that has one of these properties: - external gateway address is within 44.0.0.0/8 - advertised subnet is not owned by the gateway operator This would at least prevent mishaps like we had this week, because especially a gateway address within 44.0.0.0/8 should be throughly validated so that it is properly BGP routed to somewhere, and the operator of that destination can properly process the IPIP packets and not route them in a loop. Rob

1 0

Re: [44net] RIP problems?
by Rob Janssen 07 Apr '19

07 Apr '19

> The portal has made it easier for those to request blocks and for > routing to become a bit more efficient through RIP vs having to download > the encap.txt file and having to reload it every so often so the > automation is definitely welcomed in this regard. The whole concept of > ip encapsulation under ip is what confuses most people. Take OpenVPN for > example - people don't want to know it's using ip encapsulation, they > just want to configure it and have it work. Well, that is the issue. We provide OpenVPN certificates for local amateurs to connect to our gateway, and there rarely is any issue with that. (apart from people making 2 connections at the same time, which of course does not work because the certificate is directly bound to the user's IP address) But I think what happens is: people hear about this AMPRnet/HAMNET thing, they google a bit for information, and they get lost in technical documents not in their language, talking about something that is not their expertise, and expecting them to enter information in forms that they do not understand at all. Then it is not so surprising that some bogus information ends up in the system unless validation is improved, either in the software or in a manual step. The whole thing with RIP was definitely a good idea, and much better than regularly downloading and loading an encap.txt file. However, what can be improved is the entering and maintenance of the data that actually gets transmitted there. > That could turn into something a bit too time consuming as well for > those who would be in charge of taking responsibility for the > functioning systems of others such as coordinators. I'm not too worried about that, the assignment of IP addresses is also mostly a manual process here (from mail to hosts file), helped with some scripts to mail the update to the DNS robot and to place updated files on the server. The number of updates is relatively small, I get maybe one a week or up to 3 a week when it is a busy time. For gateways, this should be even less. Rob

3 2

Re: [44net] RIP problems?
by Rob Janssen 07 Apr '19

07 Apr '19

> Rob et al; > This user is flagged RADIO only in his config and should not be a listed > "gateway" at all: > ... > If this is causing an issue, let me know and I'll send him a note asking > him what he's looking to do and point him to a few things that may help > him out. Well, the recurring issue is that users do not really understand the whole system and still are expected to manage it themselves via the portal. This does not work well. They experiment with entering some data, see it appear listed under their account, but do not understand what it is for. They leave it there and move on to another experiment. I do not blame them, it is a complicated matter and there are many options of connecting to the network. On my own pages I strongly advise against using the portal and instead mail me with the request they have, usually they do not want to use IPIP anyway and registering on the portal does more harm than good. Of course it could be improved in the portal user interface, but it has been claimed before that restricting people to making valid entries (i.e. the external gateway address is NOT in net-44 and the advertised subnets are owned by the gateway operator) causes issues in some niche situations. Hence those checks have been removed, and users are no longer guided towards what they should and should not (and probably don't want to) do. Users get an address from me, and register a gateway in the portal with that address as external address (this is what caused the mishap this week!). Moreover, they have to add advertised networks and they do not understand that they first have to request a network to be assigned to them, and they pick a random network from the pulldown list (this happened with the same user). So I am all for a change towards a system where people like coordinators or other experienced users have to validate the entered gateway configuration before it becomes active. But recognizing that this would require more programming work in the portal (and thus in practice will not happen), I am for a reduction of the complexity and vulnerability of the system by removing dangerous capabilities that almost nobody uses, such as having the gateway address within net-44 and the advertisement of networks not owned by the user. They could still be allowed for existing users and could still be modified by administrators of the portal, but not by end-users. Rob

2 1

Re: [44net] RIP problems?
by Brian 07 Apr '19

07 Apr '19

Rob et al; This user is flagged RADIO only in his config and should not be a listed "gateway" at all: 44.118.1.1 2018-03-01 18:16:04 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1403> 44.118.1.2 2018-03-01 18:16:12 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1404> 44.118.1.3 2018-03-01 18:16:19 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1405> 44.130.104.1 2017-10-02 18:34:13 DG8NGN View If this is causing an issue, let me know and I'll send him a note asking him what he's looking to do and point him to a few things that may help him out. I know in Maine, they prefer to use M$ and software that's 100% GUI based. The problem however becomes that the sysop doesn't learn what they're doing because the GUI hides the technical information. -- I won't be like a Texas official and call Ocasio-Cortez a bimbo but she does think Roe vs Wade are two different ways to cross a river. ----- 73 de Brian N1URO IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com

1 0

Re: [44net] RIP problems?
by Rob Janssen 07 Apr '19

07 Apr '19

Well, after a week of frantic searching how this problem came about, it has finally been pinpointed. It turned out to be an unfortunate consequence of someone setting up a bad gateway entry with the external IP within out 44.137.0.0/16 network, combined with strict firewalling that returns ICMP messages on bad traffic, a bug in the handling of those messages, and the way ampr-ripd handles the above type of gateways. Finally when Marius discovered that ICMP messages were going back to the gateway in his test setup, and when this happened amprgw abruptly ended the sequence of RIP packets, combined with the observation that putting delay between the packets actually made things worse, and removing of the bad gateway fixed it, finally lead to resolution of the problem. Now there are some bugs to fix, but also I looked in the gateway list and I found several more of those bad gateways! It looks like the gateway concept is difficult enough for people to understand as it originally was, and adding the possibility to have a gateway address inside net-44 really pushes complexity beyond what can be handled. And because it is (under strict conditions) allowed, the check in the gateway that simply rejects such entries has been removed. Look at what we have now: 44.2.11.1 2018-01-17 20:55:30 KK6NHN View <https://portal.ampr.org/gateways_list.php?a=view&id=1555> 44.2.11.2 2018-01-17 20:56:07 KK6NHN View <https://portal.ampr.org/gateways_list.php?a=view&id=1556> 44.24.172.41 2018-01-04 23:09:44 KG7PNQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1546> 44.24.241.98 2017-04-26 06:31:05 KD7LXL View <https://portal.ampr.org/gateways_list.php?a=view&id=1378> 44.94.17.129 2018-09-04 05:12:02 N0NCE View <https://portal.ampr.org/gateways_list.php?a=view&id=1695> 44.102.222.16 2019-03-24 22:27:29 W8HRV View <https://portal.ampr.org/gateways_list.php?a=view&id=1760> 44.118.1.1 2018-03-01 18:16:04 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1403> 44.118.1.2 2018-03-01 18:16:12 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1404> 44.118.1.3 2018-03-01 18:16:19 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1405> 44.130.104.1 2017-10-02 18:34:13 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1481> 44.130.104.2 2018-04-15 16:36:26 DL2QT View <https://portal.ampr.org/gateways_list.php?a=view&id=1613> 44.130.105.1 2017-10-02 18:35:03 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1482> 44.130.106.1 2017-10-02 18:35:32 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1483> 44.130.107.1 2017-10-02 18:35:55 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1484> 44.131.14.253 2017-05-06 07:29:35 M6XCV View <https://portal.ampr.org/gateways_list.php?a=view&id=1382> 44.136.150.2 2019-03-11 01:55:46 VK4AA View <https://portal.ampr.org/gateways_list.php?a=view&id=1386> 44.137.8.1 2018-10-01 09:41:51 PA0HWB View <https://portal.ampr.org/gateways_list.php?a=view&id=1707> 44.137.44.118 2018-01-14 23:25:39 PD2LED View <https://portal.ampr.org/gateways_list.php?a=view&id=1551> 44.137.48.78 2019-03-01 09:26:45 PE1OWG View <https://portal.ampr.org/gateways_list.php?a=view&id=1806> 44.144.46.240 2017-11-07 13:21:48 ON7AVC View <https://portal.ampr.org/gateways_list.php?a=view&id=1505> 44.151.38.60 2018-05-13 11:24:03 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1631> 44.151.38.61 2018-05-13 11:25:42 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1632> 44.151.38.62 2018-05-13 11:26:32 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1633> 44.159.112.16 2018-08-17 19:28:16 9V1AN View <https://portal.ampr.org/gateways_list.php?a=view&id=1683> Most of them have "no subnets" and I think they were only created by experimenting people who tried some options in the gateway and finally gave up for the day. Only these actually have subnets routed: 44.24.172.41 44.94.17.129 44.130.104.1 44.130.105.1 44.130.106.1 44.130.107.1 44.131.14.253 44.136.150.2 Several of those route a subnet that contains the actual gateway... often subnets so small that they cannot be BGP-routed on internet, so likely invalid as well. This whole thing causes quite some risk of malfunction, loops, etc. as was demonstrated this week. I propose that the existing gateways in the above list with no gateways (those not in the second list) to be removed, and the portal changed to again disallow the creation of new gateways within net-44. Then, the valid users should be encouraged to find a gateway IP outside of net-44 and this whole thing be phased out. Too much time has been wasted on debugging this problem already, and what advantage does it really bring? Rob

4 4

Re: [44net] RIP problems?
by Rob Janssen 06 Apr '19

06 Apr '19

> Until a decision is made about what to do long term here, maybe the AMPR > Portal web interface can change this name from "gateway" to "public > Internet IP (gateway)". I think that would help some people avoid this > issue. Either that, and/or a descriptive text above the form that explains what a gateway is, why you want to have it (and why not), and where to read more about it. There are those "hover" type help texts but I am afraid it is not enough. I think several "gateways" now listed (with no subnets) are the result of people wanting to register/publish their system information in a way that is more like what HamnetDB does. It should be clearer that creating a gateway here actually sets up routes and when done incorrectly can mess things up pretty badly. The announced subnets list has similar risks. For a while it was limited to subnets registered by the person logged in, there were people wanting to route subnets for others (probably to forward them internally) and this check was removed, and now people who do not completely understand what is going on are randomly announcing other people's subnets without anyone knowing. Perhaps best would be when all gateway setup had to be validated by someone with more experience (a coordinator, an old hat in AMPRnet, etc) before it becomes finalized, similar to the subnet allocation. Rob

1 0

Re: [44net] RIP problems?
by Rob Janssen 02 Apr '19

02 Apr '19

Talked to network people at the ISP, they indicate that they have changed something w.r.t. the routing via Eurorings. It should be researched and hopefully fixed. In the meantime I am thinking about relaying the RIP packets from my own colo host to our gateway as an extra safeguard against things like this. I see that ampr-ripd has options -E and -F that should relay the raw packets to a specified address, good. That should work. But I don't think it is possible to make ampr-ripd receive and act upon those relayed packets, isn't it? Should I NAT them at the receiving system so they again have 224.0.0.9 as destination? Has anyone tried such a setup and does it work without nasty issues? (normally all RIP packets will be received twice in this case) Rob

2 1

Fwd: mailman.ampr.org mailing list memberships reminder
by William Lewis 02 Apr '19

02 Apr '19

Does anyone else find it useless to have a password reminder email sent out every month where you're told your password is [****] ? -------- Forwarded Message -------- Subject: mailman.ampr.org mailing list memberships reminder Date: Mon, 01 Apr 2019 05:00:19 -0700 From: mailman-owner(a)mailman.ampr.org To: wlewis(a)acscalifornia.org This is a reminder, sent out once a month, about your mailman.ampr.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. <SNIP> List Password // URL ---- -------- 44net(a)mailman.ampr.org ****

6 7

RIP problems?
by Rob Janssen 02 Apr '19

02 Apr '19

Since yesterday, or maybe earlier, we do not receive the full RIP table anymore and our route table for IPIP routes has almost emptied. A trace of UDP port 520 shows only 2 RIP packets per cycle. Has something changed? Or does this have to be some rate-limiting on the path to here? Rob

5 7

Re: [44net] RIP problems?
by Rob Janssen 02 Apr '19

02 Apr '19

I did further debugging... It is indeed our 213.222.29.194 gateway that has the issue, it misses most of the routes at least since yesterday (I notice because I have some mail in the queue routed over IPIP that has stalled since yesterday). But I do have another independently hosted IPIP host in the Netherlands that receives all the normal routes. It is at IP 89.18.172.156 and is located in another datacenter. So likely it is a routing issue on the internet... Rob

1 0

Linux Gateway Question.
by KJ7DMC 01 Apr '19

01 Apr '19

Hello, I'm setting up a gateway on a linux server, I have added NAT and firewall rules to send protocol 4 over to my server at 10.0.2.1. Here's some output from tcpdump. Does this look right to you? Under it I have the output from ampr-ripd, showing nothing coming in. 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 102 15:41:24.153222 IP (tos 0x50, ttl 242, id 15047, offset 0, flags [none], proto IPIP (4), length 174) ip72-192-148-49.sd.sd.cox.net > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 154) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 126 15:41:35.790028 IP (tos 0x50, ttl 232, id 5104, offset 0, flags [none], proto IPIP (4), length 166) dhcp-91-241-24-251.zc.net.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 146) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 118 15:41:40.735505 IP (tos 0x50, ttl 233, id 5482, offset 0, flags [none], proto IPIP (4), length 150) 89-67-160-225.dynamic.chello.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 130) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 102 15:42:24.169078 IP (tos 0x50, ttl 242, id 15303, offset 0, flags [none], proto IPIP (4), length 174) ip72-192-148-49.sd.sd.cox.net > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 154) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 126 15:42:35.827618 IP (tos 0x50, ttl 232, id 5105, offset 0, flags [none], proto IPIP (4), length 166) dhcp-91-241-24-251.zc.net.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 146) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 118 root@rigel:~/ampr-ripd-2.4# ./ampr-ripd -d -i tunl0 Using gateway 10.0.0.1 for direct 44net endpoints via interface enp2s0. Waiting for RIPv2 broadcasts... Any help would be greatly appreciated. Thanks and 73, -Nate, KJ7DMC

2 1

Brian Kantor could you contact me off-list please
by Ruben ON3RVH 29 Mar '19

29 Mar '19

Hi Brian, I am trying to reach you off-list but the message keeps bouncing at your bkantor.net o365 mailbox due to security settings. I have a question about re-routing my BGP subnet. Would it be possible to contact me off-list please? Thanks! 73, Ruben - ON3RVH

3 11

Vultr & vyos bgp setup
by brian＠binded.net 24 Mar '19

24 Mar '19

Hello All! I just got my /24 setup over at vultr. Im trying to follow a generic VYOS guide to setup bgp. Im getting some errors when trying to setup the bgp network command. Im used to working with cisco stuff, never really configured anything else. Has anyone used VYOS for bgp? Or is there another router OS thats better to use. 73, Brian

7 8

EdgeRouter Gateway question.
by KJ7DMC 23 Mar '19

23 Mar '19

Hello, I have set up my ubiquiti edgerouter according to this guide http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Ubiquiti_EdgeRouter. I have plugged a pc into the new port, and I have internet connectivity, but via my ISP ip address. Here is a traceroute to google, showing that it is hitting the gateway. My PC has a static ip of 44.26.0.170, a mask of 225.255.255.248 and a default gateway of 44.26.0.169. What am I doing wrong? Thanks, -Nate 1 <1 ms <1 ms <1 ms kj7dmc.ampr.org [44.26.0.169] 2 <1 ms <1 ms <1 ms 192.168.2.1 3 10 ms 9 ms 10 ms 96.120.60.77 4 10 ms 9 ms 8 ms ae-118-rur01.beaverton.or.bverton.comcast.net [162.151.125.65] 5 9 ms 10 ms 10 ms ae-51-ar01.beaverton.or.bverton.comcast.net [68.85.146.197] 6 29 ms 24 ms 26 ms be-33490-cr02.sunnyvale.ca.ibone.comcast.net [68.86.92.205] 7 25 ms 25 ms 26 ms be-11025-cr01.9greatoaks.ca.ibone.comcast.net [68.86.87.158] 8 24 ms 24 ms 25 ms be-12544-pe01.9greatoaks.ca.ibone.comcast.net [68.86.87.150] 9 25 ms 24 ms 24 ms fonality-cr01.losangeles.ca.ibone.comcast.net [75.149.228.74] 10 * * * Request timed out. 11 27 ms 26 ms 27 ms 108.170.237.22 12 25 ms 24 ms 24 ms 108.170.242.253 13 28 ms 25 ms 25 ms 216.239.62.41 14 32 ms 33 ms 32 ms 74.125.253.92 15 34 ms 32 ms 42 ms 72.14.239.31 16 33 ms 34 ms 33 ms 108.170.235.3 17 32 ms 32 ms 32 ms 108.170.245.97 18 32 ms 31 ms 31 ms 209.85.242.37 19 32 ms 31 ms 31 ms sea15s07-in-f14.1e100.net [216.58.193.78]

2 3

AX25 support on Linux based (Raspberry PI) node
by Lorenzo Simoncello 22 Mar '19

22 Mar '19

Hi hoping won't be OT for "44 Net" mailing list, I would like to ask for yours experience with current AX25 support on Debian and specifically on Linux (Raspbian) based (Raspberry PI) node. At the moment my node should have 1 radio port (1 6pack interface to TNC) and one AXIP link via 44 net. In a previuos post I can see some warnings about "... many kernel issues with the AX25 stack and newer kernels that cause the kernel to simply lock, panic, and other nasties ..." and so the downgrade advice. On the other hand I can see AX25 kernel patch mailing list with some recent kernel little patches about AX25 ... someone know the real recent kernels conditions? It is absolutely necessary to downgrade from current stable 4.14.98 to previous 4.1.21 (for example ...)? In this case, is there a more recent "good" downgrade kernel? It is better to use "Jessie" instead of "Stretch" distro? Again about AX25 packages AX.25 Apps, AX.25 Tools, AX.25 Library: It is always the best choise to recompile and use VE7FET packages (thanks to Lee VE7FET for bugs fixed and reorganizing) instead of official repository (APT) ? It's a pity that there is no way to have a single good source ... Thanks for sharing your experience... may help to shorten the time to right configure a new node for more than someone ;) '73 de Lorenzo iw3her

8 13

Re: [44net] BGP routes in RIP transmissions - Using ampr-ripd in parallel with BGP ?
by Rob Janssen 20 Mar '19

20 Mar '19

> This is another drawback : all outgoing traffic (to Internet) has to go > through one of our gateways, and can not be forwareded to Internet > directly by an endpoint via its local (NATted) ISP. Yes of course. In our case that is not very important because our gateway is in a datacenter in Amsterdam, where most of the internet traffic passes anyway, and the ping time to typical internet hosts nearby is like 2ms. I have a 5.5ms ping time to our gateway via my VDSL connection, and ~9ms via the radio links. That isn't an issue. In Germany it should not really be a problem to do it like this, they could have several datacenters across the country too. The trick is of course to find something that is inexpensive enough to pay it out of someone's pocket, as setting up a donation or contribution system is quite difficult, especially in the amateur radio community. (in Dutch a Ham is called "zendamateur" which is often written as "centamateur" in situations concerning financing community projects. it is funny that many amateurs have no problem paying like 2000-4000 euro for a transceiver, but won't consider paying 20 euro/year to sponsor a community project) Rob

3 2

Re: [44net] AX25 support on Linux based (Raspberry PI) node
by Rob Janssen 19 Mar '19

19 Mar '19

> Since many on this group have the peculiar knowledge on AX.25, > on amateur packet radio and related stuff, it could be effective > and proficient to re-compact the efforts to support, repair, > improve and revamp the linux kernel, the NET/NOS and so on. The problem with code in the kernel is that it is very difficult to get any improvements available to the user. Assuming that not everyone wants to compile their own custom kernel from source, you need to get the improvements implemented in the standard kernel and then you have to wait until the distribution(s) of choice add this new fixed kernel into their distribution. Then you have to wait until this distribution is widely used by the users. This can easily take a year, maybe more! And when you discover problems or want to make additions the cycle starts again. Worse: when others make changes and break things, it takes a long time before this impacts users and then again a long time to fix it. So the approach really should be to take the stuff out of the kernel. Or maybe move it into an indepently developed loadable kernel module, maybe via dkms or so. Rob

5 6

Re: [44net] BGP routes in RIP transmissions - Using ampr-ripd in parallel with BGP ?
by Rob Janssen 19 Mar '19

19 Mar '19

> - We are an island, so our network will be managed as a "closed" network, with only two gateways to "the rest of the world", in two data centers located in the two the main cities. It should be possible to get it working correct in that setup. The main problems of the German network are: - the use of many exitpoints towards internet that use consumer lines and NAT - the reliance on consumer routers that offer no flexibility in routing and connection marking (AVM Fritzbox etc) - the separation of different connection technologies in different routing tables evaluated sequentially instead of from smallest subnetsize up - (motivated by some of the above points) the naive routing that does not take connections into account, so it cannot differentiate between outgoing and incoming connections When you (and it looks like you do) abolish those internet connection points with NAT, most of the problems are already solved even in cases where the routing is asymmetrical and not optimal. At least it works. Rob

2 1

Re: [44net] BGP routes in RIP transmissions - Using ampr-ripd in parallel with BGP ?
by Rob Janssen 18 Mar '19

18 Mar '19

> And then you'll have issues in at least parts of the German networks. You will have issues with them no matter what. Their network design just isn't suitable for connection to internet. No matter if you do or don't use tunnels, you will always have issues in some way. Rob

3 2

Re: [44net] AX25 support on Linux based (Raspberry PI) node
by Rob Janssen 18 Mar '19

18 Mar '19

> The challenge is that by loosing the protocol stack in the kernel, all the existing Linux packet applications break. Maybe if a new libax25 library was created that could redirect all those calls to something in userland, that would work but that doesn't exist today. By also moving out of the kernel, we loose most of the advanced routing abilities in playing around with AX25/Netrom/Rose, etc. It should be possible to make a usermode program that handles socket calls made by other programs. I.e. you continue to use a socket interface but the protocols are not in the kernel but in that user program. Solutions like this are used for many exotic services that cannot live in the kernel for maintenance reasons. (although for technological reasons they should be in the kernel) > Btw.. I don't understand your "put only device drivers in the kernel". If we did that for say IPv4, IPv6, etc... that would dramatically reduce the functionality of Linux as it stands today. So much would need to change to accomodate a wholesale shift to Userland. Well of course it has been a discussion since (before) linux was first developed. The monolithic vs microkernel discussion. However, you should not compare it to IPv4 or IPv6. The issue is not whether network protocols technologically belong in the kernel, but whether it is sustainable to keep protocols that are used by about 100 users out of a Linux user population of billions can be kept in the kernel and survive every restructuring of the kernel without being damaged beyond usability because people are making changes and don't (because they cannot) test them in real use. Apparently not. So it is better to go for a solution that works. I have been running my version of NET on top of the kernel SCC card driver for quite some time, and there were no issues like this. It had a separate IP address and was connected to the kernel IP stack via tun/tap. Of course that is not a solution for socket applications using AX.25 but something similar could be done. Rob

2 1

Re: [44net] TAP interface routing
by Rob Janssen 18 Mar '19

18 Mar '19

> I'm writing a DVB-GSE receiver block for GNU Radio. It will be used in a > future software defined DVB-S2 receiver. I've pretty much completed the > block, but I'm stuck on how to forward packets written to the TAP > interface into the Linux network stack. That happens automatically. The tap interface has two sides, one exists as a Linux network interface that you configure just as any network interface and the other side is accessed via the socket in your application. Forwarding is done as on any network: you assign IP addresses and subnet masks to either side and send your packets to addresses living on the other side. Rob

2 1

Bouncing Emails
by William Lewis 17 Mar '19

17 Mar '19

Brian Kantor: I tried sending you two emails (off list). Both got bounced: ----------------------------------------------------------------------------------------------------------------------------- Remote-MTA: dns; bkantor.net Diagnostic-Code: smtp; 550 5.7.1 Disposition Notification Denied:NOYGDB -------------------------------------------------------------------------- Can you contact me off list to verify any change in your email address? Thank you. ------------------------------------------------------------------------ Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) ------------------------------------------------------------------------ This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

1 0

TAP interface routing
by Ron Economos 17 Mar '19

17 Mar '19

I'm writing a DVB-GSE receiver block for GNU Radio. It will be used in a future software defined DVB-S2 receiver. I've pretty much completed the block, but I'm stuck on how to forward packets written to the TAP interface into the Linux network stack. I'm guessing some sort of bridge or virtual Ethernet interface is required, but I just can't find a coherent example. I'm hoping the brain trust here on 44net can help. The source code is here: https://github.com/drmpeg/gr-dvbgse/blob/master/lib/bbheader_sink_impl.cc The block parses a baseband header frame from the DVB-S2 receiver, builds an Ethernet frame, and writes it to the tap1 interface. https://github.com/drmpeg/gr-dvbgse/blob/master/lib/bbheader_sink_impl.cc#L… But I want that packet to be injected into the network stack. How can that be done? Ron W6RZ

1 0

Re: [44net] AX25 support on Linux based (Raspberry PI) node
by Rob Janssen 16 Mar '19

16 Mar '19

> Is there a place where we can get the latest unofficial patches? Has anyone considered a fork to keep it relevant to modern kernels? I would say it is best to remove all AX.25 code from the kernel and use one or more userspace programs to provide the functionality instead. It is just too difficult to keep some seldomly used feature working in the kernel working without testing (as outlined by David). And once there is a problem, it is almost impossible to get it fixed and very difficult to propagate fixes to end-user systems. Put only device drivers in the kernel, not the actual protocol code. Rob

2 1

Re: [44net] BGP routes in RIP transmissions - Using ampr-ripd in parallel with BGP ?
by Rob Janssen 14 Mar '19

14 Mar '19

> - May I encounter routing issues with some clients ? > - Is it recommended to deploy ampr-ripd in parallel with BGP ? You won't encounter problems with traffic to other systems on internet and also not with other AMPRnet systems routed via BGP, but some of the traditional AMPRnet networks that are only routed via IPIP will be unreachable when you do not run IPIP tunnels in parallel to your BGP announcement, or at best they will be routed via San Diego, USA which of course affects delay and packet loss values. I cannot judge if this will affect your system. However, when your router system is capable of running ampr-ripd or another solution for IPIP tunnels (e.g. the scripts for RouterOS or the recent solution for Juniper) I think it is always a good idea to install one of them. Rob

3 2

Re: [44net] BGP routes in RIP transmissions -- CANCELLED
by Rob Janssen 14 Mar '19

14 Mar '19

> What's this "snow" thing? And can it be routed over the 44 net? ;P It can sometimes affect the routing over UHF/SHF radio links. But is anyone using those, or is only internet routing used? Here we have had lots of rain and strong winds over the past week. The antennas are shaking and I cannot work on my OSCAR 100 uplink. My WiFi AMPRnet link to the radio tower nearby is affected due to a tree in the path. Rob

2 1

gateway on 0.0.0.0 entry in the portal
by R P 13 Mar '19

13 Mar '19

0.0.0.0 2019-02-16 11:36:03 F4BWT View<https://portal.ampr.org/gateways_list.php?a=view&id=1787> What is that ? Regards Ronen - 4Z4ZQ

2 1

Re: [44net] BGP routes in RIP transmissions -- CANCELLED
by Rob Janssen 13 Mar '19

13 Mar '19

> If you have a 44net subnet behind your router, machines that do not have DNS entries at ampr.org will not be able to reach BGPed networks, because amprgw requires any host passing traffic through it must have such a DNS entry. > At the moment, simply removing the default route in your ampr table solves this and routes those hosts vis ISP NAT. > By automatically creating individual routes for BGP subnets make this a little more diffcult, and breaks existing working setups. Even if this is not a big issue for people with good networking knowledge, it breaks things for those that should have expected a simpler setup and are not profficient in networking, contrary to the initial goal of the proposal. I think it is a little broader than this. When you have a BGP routed subnet yourself, and you run ampr-ripd in parallel to improve connectivity to IPIP-only subnets, you force the traffic to other BGP routed subnets via amprgw where they would much more efficiently be routed directly. (without NAT) Of course a special version of ampr-ripd could be made that ignores those routes when some flag is given. You could release such a version and advertise its existence here, give everyone involved the opportunity to install it, and only then make the change. Rob

8 9

what version NNTP to put in
by R P 13 Mar '19

13 Mar '19

Hi there does anyone know what ver of server (1 2 3) i have to put on my cisco SNTP if i want to use the following NNTP server s ? 44.24.244.4 and 44.60.44.1 Thanks Forward Ronen - 4Z4ZQ

1 0

Re: [44net] 44Net Digest, Vol 8, Issue 35
by Roger 12 Mar '19

12 Mar '19

So I would be one of those with weak networking knowledge :( That said, would the proposed change have improved connectivity? I’m finding that not everyone is able to connect to my tunnel setup. I even noticed 3 days last week where N1URO.amor.org, was not reachable from untunnelled devices, like my cellphone and isp. If the changes would improve connectivity, even if people like me would need some instruction and tutoring, maybe it should be considered. Roger VA7VH > On Mar 12, 2019, at 12:00, 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. Re: BGP routes in RIP transmissions -- CANCELLED > (Toussaint OTTAVI) > 2. Re: BGP routes in RIP transmissions -- CANCELLED (Brian Kantor) > 3. Re: BGP routes in RIP transmissions -- CANCELLED (Marius Petrescu) > <mime-attachment> > <mime-attachment> > <mime-attachment> > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

1 0

Re: [44net] BGP routes in RIP transmissions -- CANCELLED
by Rob Janssen 12 Mar '19

12 Mar '19

> Of course a special version of ampr-ripd could be made that ignores those routes when some flag is given. Or rather: add a flag that specifies an alternate route table number where those routes will be stored instead of the main table or the table specified with -t A special value (0, -1) could be used to entirely ignore those routes. Rob

1 0

BGP routes in RIP transmissions
by Brian Kantor 12 Mar '19

12 Mar '19

Hello, Beginning on March 15th, the pseudo-RIP transmissions from amprgw will include the various subnet prefixes which are being advertised by BGP. They will show a next-hop address of 169.228.34.84, which is amprgw. Marius assures me that this will cause no harm, and will enable tunnel-only AMPRNet hosts to reach those destinations via the tunnel. He says that many tunnel-connected hosts have a semi-default route to amprgw that has to be manually installed when the system is set up; this would now be automatic when employing the various ampr-rip programs. Quoting Marius: So, wouldn't it make sense to publish BGP routed networks that do not have 'tunnel ' set in the portal as RIP routes using amprgw as gateway? This would solve some issues: - Users could actually see all reachable destinations in their route list - Users could easily identify BGP networks by checking 169.228.34.84 as their gateway - they could drop the setting of that 'default' route in the ampr routing table, allowing a (implicit) throw to the main table. This will make it easier to reach local or directly connected ampr networks (which now need routes placed in the ampr table). Also, unknown destinations would be NATed to the system's gateway, without putting any additional traffic to amprgw. - it would also allow to have all routes in a single routing table while being able to reach tunneled and BGPd networks using their AMPR address without policy routing. Existing set-ups would not affected by such a change in any way. Marius, YO2LOJ Please be sure to let me know if there are any problems with this change; it can be reverted in a matter of moments if an unexpected difficulty does arise. - Brian

3 5

Connected via VPN, now what?
by Mike Saeger 07 Mar '19

07 Mar '19

I connected via VPN. IPv4 Address. . . . . . . . . . . : 44.139.11.22 Subnet Mask . . . . . . . . . . . : 255.255.255.252 My DHCP server is 44.139.11.21. I am not able to ping that server. I can't ping ampr.org. Actually, I tried pinging several IP addresses and nothing is returned. I'm trying to figure out if connecting via VPN is of any useful value? Mike N9MS

4 3

Re: [44net] Port-forwarding of 44-addresses
by Rob Janssen 06 Mar '19

06 Mar '19

Marius, Ok that is an interesting solution! It solves the "route lookup" issue, but in the case of using BGP there isalso the issue that BGP only distributes the subnet route when there is an actual matching route in the table that it is managing. Of course this can by circumvented by unchecking the "synchronize" option. And on our local AMPRnet we distribute the default route via the same BGPinstance as the remainder of the routes. So that would have to be changed. I'm inclined more towards a script that reads the interface routes from the main table and copies them into the amprnet table... Rob

1 0

EdgeRouter and EdgeRouterX
by Marius Petrescu 06 Mar '19

06 Mar '19

I updated the startup scripts for the EdgeRouters to properly route back replies of requests from the internet via tunnel. So if you like to use the new setup, download again and reinstall the package... Also, with the new setup, the status wizard also needs to be updated (remove and install). Find the EdgeRouter setup package here: http://www.yo2loj.ro/hamprojects/Ampr_EdgeRouter.tgz (mips64) For the EdgeRouterX setup use this one: http://www.yo2loj.ro/hamprojects/Ampr_EdgeRouterX.tgz (mipsel) Status Wizard: http://www.yo2loj.ro/hamprojects/Ampr_Status_Wizard.tar Marius, YO2LOJ

1 0

Re: [44net] Port-forwarding of 44-addresses
by Rob Janssen 06 Mar '19

06 Mar '19

> The forwarded packets > that were supposed to go to my 'inner' server were also routed back to > the AMPR GW, which of course did not know anything about my local > addresses (192.168...). > However, after adding this line: > ip route add 192.168.19.0/24 dev enp0s6 table 44 > everything felt in place and I'm now a happy man. Unfortunately this is a detail that is soooooo easy to oversee that it frequently happens. But of course it is always educational to encounter this and fix it yourself! E.g. I recently helped someone with a MikroTik router to setup this kind of policy routing and on that router the direct routes to attached interfaces also only appear in the main routing table and not in those additional ones. There really should be an option to do that automatically, but until then indeed you have to add them manually. The kernel would lookup the route in the main table when it cannot find a route in the additional table, but of course that only works when there is no default route there. And autorouting protocols like BGP won't distribute the route when it is in the wrong table. Rob

2 2

Fixed the problem
by Mike Saeger 06 Mar '19

06 Mar '19

There were 2 RSA keys in my n9ms keys file. The 2nd one was the correct one. Then I got an error message telling me that OpenVPN couldn't connect due to a weak algorithm. Adding the following line to the .opvn file fixed it. Mike tls-cipher "DEFAULT:@SECLEVEL=0"

1 0

Trying to use VPN
by Mike Saeger 05 Mar '19

05 Mar '19

I'm already using OpenVPN and it works great. Now, I'm trying to use OpenVPN to establish a tunnel to AMPR.ORG. I followed the instructions at: http://wiki.ampr.org/wiki/AMPRNet_VPN I get the following message in my OpenVpn Log: Tue Mar 05 12:19:13 2019 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead. Tue Mar 05 12:19:13 2019 SIGUSR1[soft,private-key-password-failure] received, process restarting Tue Mar 05 12:19:13 2019 MANAGEMENT: >STATE:1551813553,RECONNECTING,private-key-password-failure,,,,, Tue Mar 05 12:19:13 2019 Restart pause, 5 second(s) --- and it repeats ---

1 0

Port-forwarding of 44-addresses
by Bent Bagger 05 Mar '19

05 Mar '19

Hi I have acquired myself a problem. Recently I decided to move all web services away from the gateway to an ‘inner’ server. This is easily done by using port forwarding in the firewall on the gateway. Thus I forward all web services by using this line: iptables -t nat -A PREROUTING -p tcp -m multiport --dport $Services -d $EXT_IP -j DNAT --to $webserver where $Services is defined as Services="smtp,domain,www,https,submission,imaps", $EXT_IP is my external IP address and $webserver is the IP address of the ‘inner’ server. I do the same for the ampr interface: $iptables -t nat -A PREROUTING -p tcp -m multiport --dport $Services -i ampr0 -j DNAT --to $webserver In this case it is only the www and https services that are relevant since I do not do mail on the 44-address. All of this works of course as it should for ordinary IP addresses (non-44) and it also works fine when comming from a 44-address. Furthermore it works fine when I ping my 44-address from any IP address (which isn't surprising as ICMP is not forwarded). But it fails miserablywhen accessing my 44-address (44.145.40.3) from an ordinary IP address. The incomming request comes nicely in on the ampr interface, but the reply goes out the WAN interface to the Internet at largeand is thus not recognized as a reply on the originating host. I have spent quite a bit of time trying to findout why this is so. I’m convinced it is something in my setup that is the cause of this behavior, but I’m at a loss as what it may be, so I hope some of you eagle-eyed people out there can spot the error. Here are somedetails of my setup. Routing rules: $ip rule list 0: from all lookup local 44: from all to 44.0.0.0 /8 lookup ampr 45: from 44.145.40.3 lookup ampr 32766: from all lookup main 32767: from all lookup default Main routing table: $ip route list default via 86.48.99.33 dev enp0s7 metric 3 127.0.0.0/8 via 127.0.0.1 dev lo 192.168.19.0/24 dev enp0s6 proto kernel scope link src 192.168.19.6 ‘ampr’ routing table (table 44) (excerpts): $ip route list table ampr | head -n4 default via 169.228.34.84 dev ampr0 onlink 44.2.0.1 via 191.183.136.1 dev ampr0 proto 44 onlink window 840 44.2.2.0/24 via 216.218.207.198 dev ampr0 proto 44 onlink window 840 44.2.7.0/30 via 98.208.73.100 dev ampr0 proto 44 onlink window 840 My gateway is a Soekris Net5501 running Gentoo Linux updated to the latest versions last Monday. I do hope I have expressed myself clearly enough and provided details enough so that one of you can point at something and say: ‘there is your error’. If some information is missing or lacking please ask for it and I’ll provide as much as I can. Best 73 de Bent/OZ6BL

3 8

AMPR.ORG for Mesh Network?
by Mike Saeger 05 Mar '19

05 Mar '19

Hi, I'm new to this forum. Several years ago I used Packet Radio and had an IP address (it is still active: n9ms.ampr.org [44.72.58.62]). Now, I'm getting active on the AREDN Mesh Network. I'm wondering if my n9ms.ampr.org would be useful on our mesh network -- maybe it's strictly a Packet Radio thing? I'm just curious. I looked at the Gateway information, but I didn't see anything in there for my IP address -- but I could be wrong. Thanks for your help. Mike N9MS

2 1

Dead gateway, looking for input
by Tom Cardinal 01 Mar '19

01 Mar '19

Greetings, My gateway bit the dust and I need to start from scratch. I have two possible approaches. 1. I have an older Edgerouter Lite. Has anyone cracked the nut on connectivity to other AMPR nodes in the mesh? 2. I’m considering buying a new microtik router. Is there a suggested model? Would like to get back on 44net but want to stay away from the “roll your own” Linux system as Ubuntu has changed their network manager to netplan. Suggestions welcome. — tom Tom Cardinal / MSgt USAF (Ret) / N2XU / BSCS / CASP+

4 25

Do we support GRE?
by Mark Phillips 25 Feb '19

25 Feb '19

Hi folks, Trying to get my pfSense firewall to talk directly on AMPRnet and am wondering about GRE. Do we support this? It looks like the only way I can get pfSense to do AMPRnet is to forward everything to an internal host and do things there. I can do BGP but I don't have enough addresses space for that (I only have a /27). Thanks Mark G7LTT

3 4

Where to get BGP subnet list?
by Steve L 24 Feb '19

24 Feb '19

>From time to time testing various setups I need to determine if the remote 44 host is IPIP or BGP so that I can verify everything is working etc. I used to grep this, but apparently this is not current? http://thyme.rand.apnic.net/current/data-add-ARIN Does anyone know of an up to date source? I used to test new installs against hambook.de.ampr.org (44.225.164.16) as I know this is not reachable via the normal internet, but is via 44net. It used to be via an IPIP tunnel. I don't see it in my routes, so it must be via BGP now, but I don't see it from the above source. Thanks

6 15

Cellular networks
by Roger 24 Feb '19

24 Feb '19

So very sorry everyone. Sometime after I sent my message, the computer I was using for 44Net had issues so everyone that tested found they couldn’t reach me. Please try again, this time; VA7LBB.ampr.org or 44.135.179.19. It is up. Port 80 is open. It does work! It just doesn’t seem to work on Cellular networks. At least not for me. Please let me know what you find, and if you have any suggestions. Roger VA7LBB

5 4

defective entries in the encap file?
by Brian Kantor 24 Feb '19

24 Feb '19

There are a few entries in the encap file which are for subnets that are NOT indicated as tunnel-routed subnets. They are apparently in the portal database with the Tunnel attribute UNchecked, but they have a gateway associated with them. Perhaps this is because they at one time *were* tunnel-routed but converted to direct (BGP) routing. Anyway, I believe they should NOT be in the encap file because they are NOT IPIP tunnel-routed. These are 44.48.8.0/22 44.56.128.0/24 44.131.7.0/24 44.182.62.0/24 If any of these are your network, please delete their association with a gateway, or check the Tunnel box. - Brian

1 0

Cellular networks
by Roger 23 Feb '19

23 Feb '19

Hello, I finally got my AMPRnet tunnel up and running. I have dns and a few A names. Everything seemed fine until I tried reaching one of my machines using my cellphone over the Cellular Network. It just times out. Here’s a test page. Ve7mov.ampr.org. Is this normal. I can’t imagine this is a config problem on my end Thanks Roger VA7LBB

5 4

Re: [44net] IPv6
by Rob Janssen 23 Feb '19

23 Feb '19

> An interesting report on the adoption of IPv6 by the Internet at large. Very interesting indeed! It discusses all those aspects that have slowed down IPv6 adoption. My ISP (which also hosts our gateway system) was amongst the early adopters and I have also experimented early, but abandoned it due to the "no benefits and only problems" situation. But later, when those were mostly cured, I again enabled IPv6 on my network. Problems caused by running dual-stack are now rare, but still it does not really have any benefits. So it is understandable that it is adopted so slowly. Unfortunately it is not only ISPs that affect it. Our beloved router manufacturer MikroTik has mostly left IPv6 as an orphan. There is an add-on package with some basic IPv6 functionality but most of the nice features available everwhere in the system are only for IPv4. This has held me back to experiment with IPv6 on our section of AMPRnet, as these routers are widely used. Rob

1 0

IPv6
by Brian Kantor 23 Feb '19

23 Feb '19

An interesting report on the adoption of IPv6 by the Internet at large. https://www.internetgovernance.org/wp-content/uploads/IPv6-Migration-Study-… - Brian

3 2

How to allow central gateway to support small gateways that use dynamic IP ?
by R P 21 Feb '19

21 Feb '19

Hi there We consider to advertise part of our Country AMPRNET IP Network allocation via BGP to a small DataCenter We want from there to allow users to have a gateways that will have IPIP tunnel to it. By that we will decrease the latency of the IPIP tunnel that goes to UCSD and back and also hopefully get a much bigger bandwidth (from the data center and not from the UCSD limitations) What Do we need to have in the Data Center in order to Support it ? Is there any expert here that may direct the Software person (if it is a software solution) in our team ? to do it ? any info would be appreciated Regards Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> About me . Some of my projects . My Family . My Friends . The Quiz , what is the following Picture ? What I have to say about the Year 2000 bug . Few words in memory of King Hussein (JY1) www.ronen.org

4 5

Can't seem to grasp something
by pete M 20 Feb '19

20 Feb '19

HI every one, I have an alocation and registered a gateway to do ipip encapsulation to finally be able to run a gateway inside my local lan. The gateway is a debain 9 computer with 2 nic. one connected to my lan (eth0) and another wich will have the 44 net address network (eth1) I already put the first adress of the 44 allocation that I have on eth1. eth0 is for now on dhcp. Now I've been reading, reading and re reading the wiki. there are so much stuff that I am lost. In my case, what deamon do I need? looking at this web page: http://www.yo2loj.ro/hamprojects/ so is it ampr-ripd 2.4?? amprd 2.1?? there are also script that I found out about.. http://wiki.ampr.org/wiki/Startampr#Script I got this configured. But I am really not sure of what I am supposed to do with it. And on the wiki page there are allusion to some hourly script running to backup the rip table. where are those? Anyone can point me in the good direction so that I can finally have this running? Thanks Pierre VE2PF

9 18

Allocation
by Michael Beaveridge 18 Feb '19

18 Feb '19

Hi - I requested a block via the portal and I noticed that my call is on gateway list, however I didn’t get any indication that I had sent in the request. I know they said that everything was volunteer and to be patient, but just wondering if my request went in as I didn’t get any email. Thanks. .michael, ve7ki

3 2

Re: [44net] Yahoo.com hangs via 44Net
by Rob Janssen 16 Feb '19

16 Feb '19

> Hi all, > I’m having an issue with my 44Net tunnel. It works beautifully incoming and almost as good outgoing. For some reason, while on a 44Net IP’ed computer, I can’t reach yahoo.com. > All other locations I’ve tried work well and off the 44Net, yahoo.com is reachable. That kind of problems is usually caused by over-active network admins that block all ICMP and thus kill PMTU discovery. You can work around it by doing "TCP MSS clamping" at your end. E.g. when you have a MikroTik router: /ip firewall mangle add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \ protocol=tcp tcp-flags=syn Rob

1 0

Yahoo.com hangs via 44Net
by Roger 15 Feb '19

15 Feb '19

Hi all, I’m having an issue with my 44Net tunnel. It works beautifully incoming and almost as good outgoing. For some reason, while on a 44Net IP’ed computer, I can’t reach yahoo.com. All other locations I’ve tried work well and off the 44Net, yahoo.com is reachable. On the 44Net, it times out. DNS seems find and I can ping the address. I’ve tried both chrome and Firefox and cleared the cache on both. Is anyone else having issues with that site, or any other? Solutions? Roger VA7LBB

1 0

subscribe
by Jean Létourneau 10 Feb '19

10 Feb '19

-- Sysop de: VE2PKT (BBS), VE2PKT-13 (URONode) : VE2RCN-1, VE2RGM-1, VE2RGC-1, VE2RVA-1, (The-Net) : VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway) RF: 147.435 Mhz (1200 Bps), Internet: Telnet://nodes-ve2pkt.dyndns.org <http://xrouter-ve2pkt.dyndns.org> port 23 (Network Node) Telnet://fbb-ve2pkt.dyndns.org port 6300 (FBB BBS) Telnet://ve2pkt.dyndns.org port 9000 (DXCluster) E-Mail: packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam ampr net: ve2pkt(a)ve2pkt.ampr.org Inet: ve2pkt(a)gmail.com

1 0

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 27 Jan '19

27 Jan '19

>Contacting Debian will always yield the same results as they've stated >for decades now. They fix end-user affecting bugs, but they don't >introduce new versions, features, etc. At one time there was the >Debian Volatile project that hosted "fast moving" versions of software >(spamassassin, clamav, etc), But that project was disbanded years ago. It is what most distributions do. And frankly I am not that unhappy with it. Sometimes it is nice to have a recent version of something but when a system is continuously updating everything it requires constant attention because things are breaking all the time. Unfortunately most open source developers do not consider backward compatibility very important, they just declare some feature you are using as "deprecated" and you will have to find a workaround or abandon some functionality. I prefer to do that at my own convenience, not at the time the distribution maintainer forces it upon me. >As of today, the authoritative voice is ISC for whether or not bind >v9.5.x should be used.. and they say don't. Are you using v9.5.5 as >an authoritative server, if so as a master? We are not using version 9.5.5 and I never wrote that. It is version 9.9.5. Rob

2 1

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 27 Jan '19

27 Jan '19

> The problem lies outside of Linux distributions, the problem lies with > over aggressive firewalls (or poorly designed firewalls) that don't > allow or understand DNS Extensions. And with old DNS server versions that do not allow them either, I think. And that seems to be the case for the abovementioned domains. (or there is such an overly agressive firewall in front of them) > This email was sent to you from a Debian Stretch (earlier in the food > chain than Jessie) server using DNS servers running various versions of > Linux DNS software behind simple iptables firewalls that don't strip > off DNS Extension bits. I am running Debian Buster on my own machine at home, even newer, and I have no problems either. But on our AMPRnet gateway (which has Debian Jessie) there is a DNS server/resolver (bind 9.9.5) which logs EDNS warning about the abovementioned domains, and it was my impression that after this flag day those warnings would be turned into errors for those domains. But of course that would only happen when Debian decide to replace the bind package on Jessie with a new version that has been amended according to the message that Brian sent (9.14.0). I am not so convinced that this is going to happen, but I have not researched that fully. When I understand correctly, major resolvers like 1.1.1.1, 8.8.8.8 and 9.9.9.9 would make that change on Feb 1st, so those that use these resolvers will be affected immediately on Feb 1st. Well, we will see. The number of EDNS warnings (and warnings about DNSSEC issues) has gone down quite a bit in the last months, so apparently work has been done in a lot of places already. Rob

3 2

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 26 Jan '19

26 Jan '19

>>/But on our AMPRnet gateway (which has Debian Jessie) />>/there is a DNS server/resolver (bind 9.9.5) / >Ouch. Bind v9.9.5 is ~10 years old... sure Debian applies patches, but >man that's way too old, even ISC would heavily advise against it. Why >can't that gateway be upgraded to Stretch or Buster? I'm willing to >help if help is needed. Debian Jessie is only some 3.5 years old and it is fully supported. We keep it uptodate. When you think the package is too old you better contact Debian instead. I know how to update the system, but it involves work, downtime, and risk. And when I do this on sunday afternoons (a convenient time for me to do it) I get nagged about interruptions in the AMPRnet/HAMnet service during times others are using it. So it has to be planned at some time when it is not used so much and I still have time to do it. Other less critical systems will likely be done first, also to gain experience with this particular version upgrade. >I can assure you that that your thoughts are correct on this. Debian >will patch patch patch bind v9.5.5, right up to the end of LTS support, >but never move to a newer major version. It's not in their mindset to >do such. ;-) It is how most distributions work. What we will have to see is whether they will patch this change into their version of bind or will just ignore it because it is not a security issue. Same for the "stretch" version. The "Buster" version will maybe get an update. But even that is not so certain as it is currently at version 9.11.5 so not the leading version either. Rob

2 1

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 26 Jan '19

26 Jan '19

> Rob, > Both domains you speak of do not rely on AMPRnet DNS infrastructure > So Brandmeister and Dstar.su are not effected by any DNS issues within AMPRnet > 73s, > Rudy (PD0ZRY) That is exactly what I wrote: it is not related to 44Net. There is nothing we can do about it. But it is related to amateur radio and it could affect people reading the list because they are involved in amateur radio networking. So it is good to know it so we know where we could look when problems appear. See the topic of this thread: DNS Flag Day, Feb 1st, 2019. that is when problems could occur. Although I don't expect that all the Linux distribution maintainers will suddenly rush out resolver updates on Feb 1st, especially not on stable versions. So it could take longer until it becomes visible in our network. It will likely hit those that use 8.8.8.8 sooner than e.g. the resolver on our gateway (44.137.0.1) which will only get updated once Debian Jessie receives an update. Rob

2 1

Re: [44net] DNS Flag Day, Feb 1st, 2019
by Rob Janssen 25 Jan '19

25 Jan '19

While not really related to 44Net, note that there are serious issues with the DNS servers used by amateur radio related services like brandmeister.network dstargateway.org dstar.su etc. Not much we can do about it, but at least it is known... Rob

4 4

Wiki - Firewall ipset Bogons
by LLEACHII＠aol.com 24 Jan '19

24 Jan '19

All, The ipset firewall script I posted included my subnet. The error was fixed from an unedited copy/paste operation. 73, - Lynwood KB3VWG

2 3

DNS Flag Day, Feb 1st, 2019
by Brian Kantor 23 Jan '19

23 Jan '19

Quoting from the web site at https://dnsflagday.net/ What is happening? The current DNS is unnecessarily slow and suffers from inability to deploy new features. To remediate these problems, vendors of DNS software and also big public DNS providers are going to remove certain workarounds on February 1st, 2019. This change affects only sites which operate software which is not following published standards. Are you affected? On that web page, there is a Domain Owner's test. I have already tested AMPR.ORG, and it passes except for one test on one of our secondary servers times out. I am working with the person who so kindly runs that secondary server [in Thailand] to get this fixed. Please don't run any more tests on the AMPR.ORG domain. But if *you* operate servers for a subdomain of ampr.org, such as 'se.ampr.org', you may wish to test your subdomain and see if there are things you need to fix. In fact, the "se.ampr.org" subdomain does indeed have a few problems that probably should be addressed. (In particular, it looks like the DNS server software for that domain may not be listening on the IPv6 addresses for those servers.) - Brian

2 1

AMPRNet OVPN portal still working?
by Mark Phillips 11 Jan '19

11 Jan '19

Hi Folks, I've had need to try the Open VPN portal located at aprs.fi today but I failed to connect. Is it still functioning? Thanks Mark NI2O/G7LTT

2 1

Re: [44net] security reminder : Sharing best practices and tools ?
by lleachii＠aol.com 11 Jan '19

11 Jan '19

1. As you all observed yesterday, I still run OpenWrt - currently on a Cisco Meraki MX60W device. I also use OpenWrt to create a separate VLAN for AMPRLAN traffic (those configs are in the Wiki). I can use routing, masquerade and NAT in another VLAN - if I need to temporally assign a device a 44 Public IP for testing and use. 2.I am running the firewall on my tunnel, which is iptables and zone-based in OpenWrt. Only relevant inbound ports for known services are allowed (e.g. 80/tcp for HTTP from 0.0.0.0/0 and 53/udp for DNS from 44.0.0.0/8). For additional security, I use a script ran with ampr-ripd updates - to only allow Pings and IPENCAP traffic from the IPs located in the Portal (script available on the Firewall Wiki page - someone offered an update to the script, but it has not yet been tested or implemented in the one found at the Wiki). I currently only use Apache, HTML and some PHP on the visible web server. The "largest" concern here is the PHP-based APRS Code recovery tool (someone in this forum previously helped me better sanitize the input, as to prevent command injections). 3.I do monitor traffic with softflowd package in OpenWrt. I collect and record the data with NfSen (http://nfsen.sourceforge.net). I also run snmpd for bandwidth statistics. * Would you be willing to share the SANS IP script you have?* What threats does this list block? 4.PFsense also implements Snort, perhaps you can route traffic through a Virtual Machine to test? 5.When needed, I previously used a firewall rule that only allows x SYNs from given IP in x minutes. If greater than x attempts - REJECT. 6.Regarding DNS, I do not open my server to the outside world. Only those at 44.0.0.0/8 are able to reach and use it.

2 4

security reminder
by Brian Kantor 11 Jan '19

11 Jan '19

Folks, Please remember that when you set up a host, computer, or device on the AMPRNet, it is exposed to the big bad evil environment of the Internet without any form of protection such as a firewall or traffic filter, UNLESS YOU PROVIDE IT. In recent days we've had a some more complaints about systems being used as DNS amplification attack vectors, others as having been compromised and turned into a spam bot, and so on. I wish these were unusual events, but they're not rare enough. Yes, you're being thrown into the network security swamp, and having to learn to swim while trying to keep your head above water. Please be careful. Practice safe networking! - Brian

3 4

Re: [44net] security reminder : Sharing best practices and tools ?
by Rob Janssen 11 Jan '19

11 Jan '19

I think that script is OK, except of course this line: AMPRGW="<AMPRGW>" Should be edited to the actual address of AMPRGW instead of that <AMPRGW>. I think it is better to just put the literal address in the example code as this kind of substitutions confuses people. When it changes, the Wiki can be updated. It is of course also possible to look it up using DNS but that will require another dependant package e.g. "dig" and again may confuse people. >I tested it and it seems to work. Also believe diffutils doesn't need to > be installed, either. I'll update the OpenWrt Wiki. Correct, the diffutils was only required for the iptables version which uses the diff command to generate changes once the table is initially loaded instead of replacing it from zero every time as the ipset version does. > I only noted it in this particular best practices/tools thread due to > messages in SEP2018: Yes that was a case where I actually received some "malicious" IPIP traffic, but ir happens quite seldomly. Of course it never hurts to lock down as well as possible, but I wanted to indicate that installing this filter is not the full response to the security reminder that Brian posted. I hope people do not think "Oh, Brian posted a security advisory and now there is this script that I do not yet have so let's install it so my system is secured", as this is only a very small and probably insignificant part of that whole security solution. When someone wants quick-and-dirty solutions to the security problem, it is much better to install some firewall rules according to this pattern: - accept ESTABLISHED/RELATED - accept new outgoing traffic - accept new incoming traffic matching some specific addresses/ports/protocols - drop everything else It is usually easiest to have two of those rulesets, one that applies to traffic incoming on the internet interface (where you want to accept protocol 4 using your ipset and not much else) and one that applies to traffic incoming on the tunnel interface (where you are basically handling AMPRnet traffic and may allow a bit more, but often you allow more from 44.0.0.0/8 than from other addresses). How complicated that ends up to be is of course dependent on what services your system(s) should expose, but at least it drops everything that you usually do not want to serve to the outside, like SNMP and DNS. Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net