- 44net - mailman.ardc.net

Re: [44net] 44.192.0.0/10 sale
by Rob Janssen 21 Jul '19

21 Jul '19

> Please consider using part of the money for reserving us (buying ?) IPV6 address for future use .. I think there is quite universal agreement that we should not buy/reserve special IPv6 addresses as a group but rather everyone should obtain addresses from their own local internet provider and we should arrange some way to distribute the list of IP addresses in use amongst the participants. This makes it unnecessary to use a tunneling system which simplifies the network and makes the routing much faster (no need to go via UCSD anymore!). And these addresses are normally included with your internet service for free. Rob

2 1

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

> I'll +1 your comments and raise you with this: > > As President and engineer of EastNet, let me go over some bullet points > for those especially NOT in our country or region. > > o The average age of those sysops on EastNet is 70+ > o They grew up without technology and are most happy to remain ignorant > about it > o BGP, IPIP, GRE are initial groupings they could care less about. > o Many of these guys can't even type in a URL without their hands held. > o Virtual Private Network to them sounds like the evil doings of the > dark web and they want nothing to do with it. > o If it's not standard equipment from my ISP it must be against my > contract with them. > o If HRO doesn't sell a pre-made appliance to plug in and use for > this amprnet thing then it can't be any good or work. Do you really think that the abundancy of elderly users in the amateur radio community is to be used as a reason not to change anything anymore until they all are dead? Should there be no development anymore just because these people cannot learn? Should we all stand still just because of that? Don't you think that the scarce newcomers we have (and need) will be running away in laughter when they see such statements being made?? > I could go on but I'll stop right there. As Charles tried to mention, > just because a very small percentage of hams are familiar with amateur > IP or amateur wired internet that doesn't mean the bulk of hams are or > that they even wish to learn. Most still immediately think IP = wired > only period and that's not what they took a license test for... and they > find it to actually be offensive in regards to amateur RADIO. If it's > not HF Contesting, it's not "ham radio" it's wire and they don't need > nor want to learn about this... but they do wish to offer the services. I am in no way proposing that any radio amateur is to be joining the AMPRnet! When they are happy working in CW on HF, or to be contesting, just let them do it! The AMPRnet is for those interested in networking and when they ar not interested in amateur IP there is no need for them to become familiar with it. > The current IPIP mesh network does indeed work... I suppose if it works > don't fix it no longer applies? I'm on it and the fact you see this > mail is a PoC it works. That is a very narrowminded view. The fact that you could make it work does not mean that it works for everyone. We sometimes see the struggles here when people try to join, and I can tell you that joining the system I propose (and that we have had running here for several years, and is running in some other regions as well) is much easier to join. There is NO NEED anymore to fiddle with ISP routers to make forwardings or DMZ settings, NO NEED to install specialized software on routers or systems, just buy a suitable router (e.g. the MikroTik hEX, list price $59,95, or even smaller and cheaper models), apply some simple configuration steps that can be written up in a document, and you are online. And you can make a wireless connection to a friend or to some local access point and the routing will be fully automatic. Traffic to your friend will be over your link and other traffic will be via the internet. As an example of what you need to connect this way, this is an example of all configuration required in such a router to connect (an actual export of a router): /interface l2tp-client add allow=mschap2 connect-to=213.222.29.196 disabled=no ipsec-secret=\ HAMNET-L2TP max-mru=1400 max-mtu=1400 name=l2tp-241 password=12345678 \ profile=default use-ipsec=yes user=l2tp-pd2ebh /routing bgp instance set default as=4220401109 router-id=44.137.11.158 /routing bgp network add network=44.137.11.144/28 /routing bgp peer add in-filter=hamnet-in name=gw-44-137 nexthop-choice=force-self out-filter=\ hamnet-out remote-address=44.137.61.254 remote-as=4220406100 ttl=1 \ update-source=l2tp-241 /routing filter add bgp-communities=44137:10050 chain=hamnet-in set-bgp-local-pref=50 add bgp-communities=44137:10200 chain=hamnet-in set-bgp-weight=200 add action=accept chain=hamnet-in prefix=44.0.0.0/8 prefix-length=8-32 add action=accept bgp-as-path=4220406100 chain=hamnet-in prefix=0.0.0.0/0 add action=discard chain=hamnet-in add action=accept chain=hamnet-out prefix=44.0.0.0/8 prefix-length=8-32 add action=accept bgp-as-path=4220406100 chain=hamnet-out prefix=0.0.0.0/0 add action=discard chain=hamnet-out That is all! With this configuration, that user connects to our VPN server with L2TP/IPsec which passes NAT and can be on a dynamic address, advertises the local network and receives the routes. This can be copied to another user and just be modified for the different user,password,AS number, router ID and local network. This is the text version of the configuration, it can be modified in a GUI when desired. Sure you can keep saying "but my 70+ years old users don't understand it and they have their JNOS box running IPIP so they don't want to change that" but do you really think this can be used as a reason to keep everything the same and not to allow others to join much more easily? That is like saying the new hams should learn CW because the old ones also did, and the new digital modes (e.g. FT-8) are evil because the CW operators don't understand them. Rob

3 2

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

> As far as we are thinking about possible evolutions, we can also add new > criteria. Ability to change link "weight" according to link quality (or > other parameters) may be an intesring thing. Well, as soon as something is changed in the protocol you lose the big advantage of running standard protocols available in standard firmware, see the AMPR RIP thing. > I don't know if BGP has some "weight" parameter. OSPF has. It can not > change the weight dynamically, but it's possible to change that weight > by an external script. That's nice, and that's the reason why we choose > OSPF for our "internal" network. I have considered doing similar things in BGP (adjusting prepend or local-pref dynamically based on SNMP monitoring of the link). We have not experimented with OSPF yet, I read in many places that it has problems with scaling when the CPU power on routers is limited (like on old RB750s) Rob

5 7

Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

Now that we are all going to have to dive into our router configurations, wouldn't it be a good time to make some changes that are long overdue? Like getting rid of the IPIP mesh and replace it with something more modern and supported by off-the-shelf routers, works behind NAT, etc? I would say setup some routers with VPN of different types around the world, have everyone connect to there using a suitable VPN protocol, run BGP on it to announce the gateway subnets. A $50 MikroTik can do those jobs, for those that still want to run a JNOS system on MS-DOS they can put one in front of their box and still use it. People are already using it for IPIP mesh, a change in topology would be only a config change for them. And other routers mentioned here can do it too, without having to get external programs installed on them. Those that want direct connection without a centralized system in the path can simply setup a VPN connection between them and configure the BGP peers, it will automatically work. There is no need to use only a single protocol in such a network, only the peers have to agree, so you can select from anything like L2TP/IPsec, OpenVPN, Wireguard, just plain GRE or even IPIP, etc etc. Just at this time I am trying to move my colocated machine that runs as an IPIP mesh member and I face that stupid "protocol 4 is not passed by the firewall" problem again. Arghh!! Also we could get that IPv6 idea going. Remember it has been discussed many times and the only things we still need is some agreement on how to register and distribute the "list of AMPRnet prefixes in IPv6 space". Again that could be done using BGP, no need to setup yet another registration portal with downloadable files. Note that Daniel EA4GPZ put some ideas around IPv6 on his site: https://destevez.net/ipv6-for-amateur-radio/ Rob

9 10

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

> I saw that. Messages are readable on Android, but appears blank in Thunderbird. When we answer, the answer remains blank (but the text is readable in the message source) > Will check... Mail isn't what it used to be. Programs like Thunderbird auto-decide whether to send the mail in text or HTML, and somewhere along there are linebreaks inserted in the messages that I do not insert myself and that do not appear in my Sent folder, which fouls up the layout. I see that with some other people's messages as well, so the fault may be in the mailing list software. The funny thing is that sometimes when my messages, that appear broken when posted, get quoted by other people they suddenly are OK. It is now completely unclear to me whether I am supposed to breakup paragraphs by line or to type everything on a single line. Both ways things are getting fouled up. Rob

4 4

Re: [44net] IPv6 adoption (was: address sale)
by Rob Janssen 21 Jul '19

21 Jul '19

W.r.t. the issue of /64 or smaller addresses, my plan is as follows: - we have a /16 network within AMPRnet (44.137.0.0/16) - it is very easy to get a /48 network in IPv6 (every home customer at my ISP gets one of them, I have one as well. it would be easy to get a /48 assigned to our gateway where 44.137.0.0/16 is BGP routed now - I want to make a 1:1 mapping of every assigned address in our IPv4 subnet to a /16 network within that /48 space. E.g. when we get 1234:5678:abcd::/48 from our ISP, I would map 44.137.0.1 to 1234:5678:abcd:0001::/64, up to 44.137.255.255 mapped to 1234:5678:abcd:ffff::/64 - This means every single address allocated in IPv4 gets a /64 subnet in IPv6, any /28 in IPv4 (common subnet size for hams) gets a /60 subnet, etc. This way, standard practices for using IPv6 addresss can be used, and the proposal of Daniel EA4GPZ can be followed to encode the callsign and service in the lower 64 address bits as desired (for convenience only). We would "just" have to add IPv6 addresses to all routers in our network, but it can be done in an almost automated way because the IPv6 addresses and subnets can be calculated from the IPv4 addresses already configured using a simple tool. Of course it still requires quite some work, and causes double maintenance on things like firewalls and routing filters, so I have not done it yet. But it sure would be possible. Rob

6 7

Re: [44net] IPv6 adoption (was: address sale)
by Rob Janssen 21 Jul '19

21 Jul '19

> > - I want to make a 1:1 mapping of every assigned address in our IPv4 > > subnet to a /16 network within that /48 space. > > E.g. when we get 1234:5678:abcd::/48 from our ISP, I would map > > 44.137.0.1 to 1234:5678:abcd:0001::/64, up to 44.137.255.255 mapped > > to 1234:5678:abcd:ffff::/64 > I'm a bit lost at what you're suggesting, and the practical way it would > be implemented. At first glance, this looks like a recipe for > suboptimal routing to the outside world. The above is an idea how to add IPv6 addresses to the 44.137.0.0/16 network that is BGP connected in a datacenter and where users are connected via VPN and radio paths. The added IPv6 addresses would be from the datacenter space and would be routed along the same paths as the 44.137 traffic. Of course that is suboptimal, but it works for users that do not have IPv6 themselves. > I have 2 AMPRnet IPv4 allocations - one BGP connected, one IPIP > connected. Both sites have IPv6 available. Here, where the IPIP mesh > terminates has a /56. I currently have a /64 on the VPS, but as there's > only one host, it wouldn't be difficult to carve that into AMPRnet and > non AMPRnet parts, because IPs are assigned by hand and are all on the > same interface. In my opinion it is not a good idea to deploy a system based on splitting a /64 net in smaller subnets. You could do that locally, but you would not want to give other local users an IPv6 network that is smaller than a /64. This is going to cause all kinds of difficulties. That is why my intention is to give every user at least a /64. Rob

2 1

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

> > Setting up BGP on a MikroTik is much much much easier than getting > > IPIP mesh to run on anything! > I see an opportunity here to learn BGP. I'm for this idea. I posted an example configuration above. Of course this is not the same as "learn BGP", but I think many users of the current IPIP mesh also did not "learn IPIP" and "learn RIP" but only copied an example configuration and fiddled with it until it worked. Of course when you want to setup a regional VPN server you need some configuration for that as well, but when such a system would be deployed of course examples for that can be given as well. BGP for such a small closed network is not that complicated. Basically every system maintains a TCP connection (port 179) with all its peers, and it sends the networks that it can route. It receives the same information from the other side, and fills the route table. The active route is selected on a couple of criteria, where the least number of hops is usually preferred. It is possible to send tags along each route (called bgp-communities) that can be used to prefer certain routes over others, e.g. to prefer routes over radio when both a radio and a VPN path exist. There are some issues with BGP, e.g. the total lack of security in the protocol. Anyone can claim that they have a subnet and all the others will happily route all traffic for that subnet to them. The routing filters are an attempt to work around the most severe problems, but as can be seen on the internet (which also uses BGP) it is difficult to make it completely failsafe. Also, in our world it is a bit of a nuisance that there is no way to incorporate some form of dynamically determined link quality in the routing decision. Links are either up or down. But for this proposed use (replacement of the IPIP mesh) that is not a problem, it mainly affects the use of BGP on the radio links in our network. Rob

2 1

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

> First thought would be that BGP is too difficult for 90% of the HAM operators. Setting up BGP on a MikroTik is much much much easier than getting IPIP mesh to run on anything! Rob

3 3

AMPRNet Address Sale
by ARDC Board of Directors 21 Jul '19

21 Jul '19

Amateur Radio Digital Communications [ARDC] is a United States charitable 501(c)(3) nonprofit public benefit corporation that has long owned and managed the Internet address space known as the AMPRNet. Nearly 40 years ago, early in the evolution of the Internet, this address allocation was acquired to be used for the mutual benefit of Amateur Radio and digital communications technology. Amateur Radio operators ("hams") use the global radio spectrum set aside for them by international treaty in non-commercial ways to improve engineering, research, experimentation, training, education, and emergency communications. Having the AMPRNet available over the past four decades has facilitated integration of the Internet with radio-based technologies long used by hams. This long term interaction has been key to development of now ubiquitous wireless technology such as WiFi and the ability to browse the Internet or to stream various media to your mobile phone. Over those past decades, a portion of the AMPRNet IPv4 address space has rarely been used, and recent utilization surveys show that it is not likely to ever be needed by hams. Initially free, IPv4 Internet addresses are now highly valuable, and there is an international marketplace in which to sell them. ARDC has sold some of its unused and unneeded address space, but retains a more than ample supply of IPv4 addresses for current and future use by the many Amateur Radio operators worldwide. The sale amounts to some millions of dollars, which will be used in the furtherance of ARDC's continuing public benefit purpose. Before the sale, the AMPRNet consisted of the addresses 44.0.0.0 through 44.255.255.255 (in Internet notation, 44.0.0.0/8). Post-sale, it consists of addresses 44.0.0.0 through 44.191.255.255 (44.0.0.0/9 plus 44.128.0.0/10). The uppermost 1/4 of the former AMPRNet address space (44.192.0.0/10) has been withdrawn from ham radio use and sold to another owner, however over 12 million IPv4 addresses remain for amateur radio use. ARDC will use the proceeds of this address sale to further its mission to support, promote, and enhance Amateur Radio, digital communications, and broader communication science and technology by funding grants and scholarships for scientific research, experimentation, education, open access, and innovation in information and communications technology, with an emphasis on benefiting the international Amateur Radio service. For further information, please see <https://www.ampr.org/amprnet/>. Best wishes and 73, The ARDC Board of Directors

19 30

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

> The IPIP mesh may be non-standard, but it is distributed, without any single point of failure. To get between two points, the two gateways have to have IP connectivity to each other. That's it. The two end-points can troubleshoot directly. > But every proposal I've seen on this list involves adding at least two other ham points of failure. For example, I would presumably connect to some other ham's BGP node and the other end of the connection would do the same. Why? Mainly because it makes it an "outgoing" connection for most people. That means it is not affected by NAT, CGNAT, dynamic addresses, inflexible router firewalls, etc. Getting IPIP to work bidirectionally often requires to setup the internal system as "DMZ" (which in home router speak means that it will receive all incoming traffic not matched by the NAT engine). This can only be done for a single system, and even then it often does not work correctly (e.g. it receives only TCP/UDP and not other protocols). You should not under-estimate the difficulty that IPIP is causing for more and more people. As an example, I am currently trying to migrate my physical colocation server to a VM. The service offered by the hosting company uses Apache Cloudstack. While the VM itself works fine and can load the ipip module, it turns out that Cloudstack cannot allow IPIP ingress in its firewall settings. So I will have to look for another hosting option... By putting VPN servers in datacenters and having the users connect to them, you avoid those problems. Also, using the topology I propose, there is no requirement that the entire network runs a single tunneling protocol or a single topology. Only the peers need to support the same protocol. And it can be a symmetric protocol like IPIP or GRE when you like that better. Also, there is no requirement that there only be a single connection! You can setup crosslinks to wherever you like. There will rarely be traffic to all IPIP mesh peers. There are more than 500 gateways in the list, and when I look in our stats I see we have had traffic to only 23 of them in the past day. Most active gateways can probably point out at most 5 peers to which they have regular traffic. You can setup crosslinks to those. And this system is not dependent on a central RIP sender! Every node is active in distributing its own subnets and receiving the others. There is no need for a portal that registers the subnets, they only need to be configured in the gateway routers. A portal could still be useful as a management system for VPN accounts. Especially at the major hubs, the users need to have a VPN account that assigns them a point-to-point address, and the BGP on that router needs to be configured with the AS number on that address. This could be done using some form of portal and a program that configures the router using its API. That is not mandatory. On our gateway the addition of new users still is done manually. I once have added a large number of skeleton BGP peers and VPN accounts, and when a new user requests a connection I find an available one, enter the username (callsign), a random password, and enable it. In the BGP peer I enter the AS number and enbale it. Done. There always will be some dependencies, but they do not need to be single-point and with some money available they do not need to be only relying on volunteers and unclear situations where some company hosts a service only because a worker there has arranged it. I think it has big advantages over the system we have now. Rob

2 1

Re: [44net] Time to restructure the network?
by Rob Janssen 21 Jul '19

21 Jul '19

Well, I think there are enough examples of how to do it (also already doing it within AMPRnet), lots of people who can contribute knowledge and will volunteer to help, the only thing we lack here in this group is someone (with the appropriate authority) who says "Lets' do that!" and gets everyone moving. That is why these discussions usually go on for a couple of days here, then die out, and nothing ever changes. We are still running the same system as 25 years ago, with only the addition of RIP auto route distribution. This gets worse over time, as those who would like to change things see this and leave, and in the end we only have a number of old hats left who don't change anything. That does not improve our reputation... sometimes newcomers ask "why do we use that method when it is so difficult to implement and it can all be done so much easier", and the only response can be "don't ask...". Rob

4 3

ipset matching
by Rob Janssen 20 Jul '19

20 Jul '19

Because of the current changes, people want to change firewall entries that check an address to be "within AMPRnet". This of course used to be simple, like "-s 44.0.0.0/8" as a matcher in Linux iptables. I already read remarks like "well I just need to split those rules in two, one for 44.0.0.0/9 and another for 44.128.0.0/10". This is not really required. And it is not so easy when the match was in a "not" context, like: ! -s 44.0.0.0/8. Also it makes the firewall rule list longer and maybe less intuitive. Maybe not everyone knows how ipset can be used to match more than one address in the same rule. The ipset program creates "address sets" that can be lists of addresses, networks, portnumbers etc that can then be referenced in a match. For example, create an address set that contains the new AMPRnet ranges: ipset create AMPRnet hash:net ipset add AMPRnet 44.0.0.0/8 ipset add AMPRnet 44.128.0.0/10 ipset add AMPRnet 44.224.0.0/15 (the last one of course has to go, but I kept it there to give our German friends some time to renumber) Now instead of "-s 44.0.0.0/8" you can use: -m set --match-set AMPRnet src Instead of "-d 44.0.0.0/8" it would be: -m set --match-set AMPRnet dst And instead of "! -s 44.0.0.0/8" you still can use the form: -m set ! --match-set AMPRnet (src or dst), so there is no need to change the structure of the rules to work around the problem of not having a "not" operator. Of course you need to arrange for the above commands to be run before the iptables rules are loaded. No problem for me as I have always done that in an own shellscript not using distributor's solutions that use iptables-save or similar. (I prefer to have the possibility to have comments, use variables holding certain addresses and networks, etc) In MikroTik RouterOS the same feature is available as "Address list" in the firewall. You can create an address list and load those subnet values: /ip firewall address-list add address=44.0.0.0/9 list=amprnet add address=44.128.0.0/10 list=amprnet and then use that in filter rules by using Src.Address List instead of Src.Address for the match. Rob

1 0

CIDR Syntax Reminder! 44.192/10 != 44.192.0.0/10
by Jeremy Cooper 20 Jul '19

20 Jul '19

Hey everyone, if you are like me and you’re working to update your firewall rules to carve out the recent subnetwork sale, I’d like to remind you that the proper way to refer to the portion of the network that has been sold is this: 44.192.0.0/10 The converse, “44.192/10” actually expands to "44.0.0.192/10” in some software, and this is probably not what you want! -Jeremy

1 0

Re: [44net] AMPRNet Address Sale
by Rob Janssen 19 Jul '19

19 Jul '19

> But hey, if you'd really like to go back to only one ACL entry, we could > also sell 44.128/10. Then you'd only need 44/9. <-- (note smiley) Actually there would be plenty of space with just the /9 when it had not been all allocated to the US in the beginning. OTOH, had that been the case, we probably had been tempted (or forced) to sell it off (or just release it) much earlier. Rob

2 1

Re: [44net] AMPRNet Address Sale
by Phil Karn 19 Jul '19

19 Jul '19

Let me propose you an idea although it's an off-topic in this list. We have a serious problem in amateur radio regarding digital development. It is software quality, platform independence and openness. I fully agree. If I have any say in this, *all* hardware and software development funded by our grants must be open sourced and made freely available. If you want to keep it proprietary, don't do it with our money. Some of you may have heard of FCC RM-11831, which would effectively ban any air interface on the ham bands that isn't publicly documented. I filed comments stating that while I am personally sympathetic to the principle that all amateur air interfaces should be open, trying to enforce that now with a legal rule would have serious unintended consequences. All three VHF/UHF digital voice modes (D*Star, DMR and Fusion) would be banned because they all use unpublished voice codecs proprietary to Digital Voice Systems Inc. I argue that a much better way to deal with proprietary air interfaces on the ham bands is to beat them at their own game: develop superior open source alternatives and persuade hams to adopt them. This has already been done for low-bit-rate voice coding: VK5DGR has developed the excellent Codec2 and made it freely available. So here is our chance to seriously pursue development of advanced, 21st century digital communication systems that, from the beginning, will be free and open. 73, Phil

2 1

Re: [44net] amprhosts update
by Rob Janssen 19 Jul '19

19 Jul '19

> Seems that mails to ampraddr at ucsd.edu <https://mailman.ampr.org/mailman/listinfo/44net> requesting IN A is not answering. > Or something changed ? Please help Long ago it has been changed to ampraddr(a)gw.ampr.org Rob

2 1

Re: [44net] A few thoughts on recent developments
by Rob Janssen 19 Jul '19

19 Jul '19

> i) Of note: Brian did ask for donations to offset these expenses which > were largely ignored. At that time I actually attempted to make a donation but it got stranded in the payment process. (I did not want to open an account at a US banking company for it, and I did not understand the peculiarities of their banking system. Here, you would simply ask the receiver for their bank account number and transfer the money to it, but there the account number apparently is something you need to keep secret so Brian would not give it to me. Not something particular to ARDC, with AMSAT it went the same way...) Rob

1 0

amprhosts update
by Pedro Converso 19 Jul '19

19 Jul '19

Seems that mails to ampraddr(a)ucsd.edu requesting IN A is not answering. Or something changed ? Please help 73, lu7abf, Pedro

1 0

Re: [44net] IPv6 adoption (was: address sale)
by Heikki Hannikainen 19 Jul '19

19 Jul '19

On Fri, 19 Jul 2019, Phil Karn wrote: > On 7/18/19 23:12, Holger Baust wrote: >> Is there a IPv6 Block registered to HAMs? ... > Most ISPs that natively support IPv6 also support prefix delegation. > They'll typically give you a /64 that you can hand out on your LAN with > DHCPv6 or stateless autoconfiguration (e.g., advertise with the Linux > radvd daemon). Some will give you more than one /64 if you ask, but > nothing actually says you must use a /64 only on a single LAN. You can > always divide it further if you like, and with twice as many bits in the > host part of an IPv6 /64 as in the entire IPv4 address space, this can't > be hard. Some home router firmwares seem to insist on /64 for using the delegation, so it might be tricky on some setups. But should be possible to put together at least on a Linux box with some creative configuration. >> The usage of IPv6 has some problems. First a lot of software has to be >> recompiled or completedly rewritten, > I don't think so. IPv6 has been out for a very long time. Right, for most applications "completely rewritten" is not true; just some small parts need to be rewritten in software which uses older low-level network socket APIs. Applications using higher-level networking APIs (such as "fetch this URL for me please" APIs in libraries and operating systems) don't need to be touched as the code behind those APIs has already been fixed years ago. I've got a lot of experience in IPv6 support validation and configuration at $work, and with my hobby systems too, so I know this from practice. Applications specifically dealing with things as IP address allocation or DNS data manipulation: yes, those need a lot more work. Such as the amprnet address allocation portal. Not a small task. >> the other problem sits between >> several chairs and keyboards. (as in a lot of other internet companies) Right, but this thing needs to be done eventually. The world is moving on. >> Some developers, admins and ops do not understand the new addressing or >> routing and some hardware vendors do not give IPv6 a priority in >> developing... > > As I said, IPv6 is much more widely supported than many people realize > and the only problem is just getting people to turn it on. It's a good idea to check this graph yearly, stare at the growth between 2015 and today for a while, do a little mental extrapolation from there, and think of the consequences: https://www.google.com/intl/en/ipv6/statistics.html Some 25% to 30% of client traffic to Google use IPv6 *today*. Up from 5% at the beginning of 2015. There's some weekly variance due to office/home use if you zoom in (weekends: more IPv6 traffic towards Google). It's getting turned on a lot right now. The wheel is rolling, the momentum is there. As for the difficulty: I didn't find it that hard. The addresses are harder to remember. More cut-n-paste work, but a lot of it can be automated, and DNS help once you bother to set it up. But the routing is... basically just the same as IPv4, just with more bits! Commercial hardware hardware and software vendors are moving pretty fast, and have mostly implemented IPv6 already. All major network operators, ISPs and such absolutely *require* IPv6 support when purchasing anything, and have done so for quite some time. Smaller vendors are lagging more (think of the APRS iGate appliances, remoterig boxes, and other gadgets made for small audiences). But I suspect the ease of setting up direct remote access to those gadgets, thanks to the lack of NAT in IPv6-enabled residential networks, will get that ball moving soon. Just open up the firewall - the thing will have it's own public IPv6 address just like that, no need to do port forwarding! - Hessu, OH7LZB / AF5QT

2 1

Re: [44net] 44.192/10 route looping observation
by Rob Janssen 19 Jul '19

19 Jul '19

> I just noticed that traceroutes from my home to, e.g., 44.192.0.1, get > stuck in a routing loop within the rr.com network. Apparently they have some default routes in a loop... My ISP returns a !N Rob

1 0

44.192/10 route looping observation
by Phil Karn 19 Jul '19

19 Jul '19

I just noticed that traceroutes from my home to, e.g., 44.192.0.1, get stuck in a routing loop within the rr.com network. (I'm on Spectrum Cable, formerly Time Warner Cable which branded its service as "roadrunner" (rr.com). I suppose this means Amazon isn't BGP advertising these addresses yet. Traces to, e.g, 44.0.0.1, 44.64.0.1 and 44.128.0.1 all behave as expected. Just an observation. Phil

2 1

Re: [44net] 44/8
by Bryan Fields 19 Jul '19

19 Jul '19

This is a below an email I sent to the NANOG list. On 7/18/19 10:57 PM, Majdi S. Abbas wrote: > > What's interesting about this is it was not an ARIN allocation, > and the ARDC folks are not the original registrant. This IANA /8 was > initially delegated to a community, not an organization. > > So, to the individuals listed in the blog, that I've excerpted > below, what do you have to say about this? > > Brian Kantor > kc claffy > Phil Karn > Paul Vixie This is par for the course with ARDC. I was a TAC committee member (I resigned in disgust just 15 min ago), and the board has failed to inform anyone this was happening. I discussed this prior as we could lease it, do something with it, make some money from it, and was 100% shot down. This has always been Brian Kantor's private little thing ever since he took over administration of it. This take over was before ARDC existed, and ARDC was never structured to be a proper community focused organization. I'd addressed this at TAPR meetings and NANOG with Brian and KC before. This also over looked the huge conflict of interest in KC being a board member of ARDC and Network Telescope getting a feed of 44/8 direct at no cost. This 44/8 announcement and UCSD routing broke connectivity to directly connected BGP subnets for years. My concern as an ARDC supporter an member is now no planning in the community for this, many people assume 44/8 is going to be licensed amateurs (I have many firewalls with permit 44/8 in them), and no accountability of what ARDC is doing. I believe with Brian retiring from UCSD he's looking for a job and being a board member of a well funded 501(c)3 can be a lucrative job. Also it's 100% broken reverse DNS for all of 44/8. :golf clap: This was theft from the community it was meant to serve. -- Bryan Fields, W9CR Former ARDC TAC member 727-409-1194 - Voice http://bryanfields.net

2 1

Reverse DNS broken
by Michael Fox - N6MEF 19 Jul '19

19 Jul '19

Folks, I'm sure folks will want to express their outrage about the address sale for months. In the meantime, let's focus on what we can control. How do we get reverse DNS working again for the part of 44/8 that wasn't sold? Michael, N6MEF

6 9

Re: [44net] Time to restructure the network?
by Rob Janssen 19 Jul '19

19 Jul '19

> But setting up Marius' script on Mikrotik is easy as pie and it > configures the rest "automagically" whereas configuring BGP on a tik, > although easy for those of us that do such things daily, is not that > easy for non network-technical folks Actually, when you think that setting up Marius' script on Mikrotik is easy, you already know enough about MikroTik to make setting up your router as a VPN client to one or a couple of routers on internet and configuring BGP on those VPN links much easier than that. It would be very easy to write a howto for doing that which includes sample configuration where you only need to fill in some fields like the username and password of your VPN, the AS number assigned to you, and the AS number and net-44 address of your peer. Probably even a script could be written that performs the configuration itself based on the few variables it requires, similar to what Marius' script does when installing it. Rob

1 0

Re: [44net] Time to restructure the network?
by Rob Janssen 19 Jul '19

19 Jul '19

> it's still possible to setup a VPN to a remote host and interface with > the IPIP mesh there. It's not idea, but it's a solution. As long as all > the nearby sites have a route over VPN, it can work. By tuning the VPN > parameters, latency can be kept down. That is what we have operating right now. Our 44.137.0.0/16 network is now BGP announced from a datacenter where we have a MikroTik CCR1009 router that has many users connected via different kinds of VPN (L2TP/IPsec, GRE, GRE/IPsec, GRE6 (GRE over IPv6)) and the users run BGP to announce their subnets and receive our subnet. They can (and do) inter-connect using radio links and setup BGP peering over there as well, so the routing between users can be over radio and towards internet over the VPN. We have some BGP communities to steer the routing, e.g. to prefer a multihop radio path over a path via VPN which is always two hops at most. This router is on the IPIP mesh as well, but when that mesh were to be taken down we only would need to setup some similar VPNs and BGP peerings, of course one to UCSD where a router would be for the space not announced separately (44.0.0.0/9 and 44.128.0.0/10), and anyone in the world would have the possibility to setup a VPN server for some subnet (be it BGP announced or not, that does not matter) and serve their local users from it. Users in a region not covered by such a service could connect to UCSD and have similar performance to what it is now. Those VPN servers do not need to peer with ALL others, but they can peer with a couple of them and we still have redundancy. In addition to this, we also offer OpenVPN VPNs without BGP, for users that are endpoints only. A single fixed address is routed to the VPN client when it is connected. This all is really easy for the users to setup, and when the L2TP/IPsec VPN is used it works over all internet connections even when they have dynamic address, are behind CGNAT, have agressive firewalls, or whatever. Should it prove necessary, an SSL based VPN like SSTP could easily be added (it uses TCP port 443 so it always works, but of course VPNs using TCP transport are to be avoided when possible) BGP in the MikroTik routers is configured in a few mouseclicks or a cut-and-paste of a small text fragment. Set the local AS and ID, add a peer with remote address and AS, set 2 or 3 options, and it works. For best operation, use a small routing filter that can be cut-and-paste. Rob

1 0

Re: [44net] Reverse DNS broken
by Rob Janssen 19 Jul '19

19 Jul '19

> I think this is resolved now. Yes it looks like it is. Can you explain how this affects the content of the 44.rev zone file and the configuration of a DNS server that serves that zone? I now have the 44.in-addr.arpa configured in a local DNS server and loaded with that zonefile as downloaded from the FTP server. Rob

2 1

Re: [44net] Time to restructure the network?
by Borja Marcos 19 Jul '19

19 Jul '19

> On 19 Jul 2019, at 12:13, Marc Williams via 44Net <44net(a)mailman.ampr.org> wrote: > > > From: Marc Williams <monsieurmarc(a)btinternet.com> > Subject: Re: [44net] Time to restructure the network? > Date: 19 July 2019 at 12:13:06 CEST > To: Borja Marcos via 44Net <44net(a)mailman.ampr.org> > > > It seems like a an idea worth exploring I agree. Apart from a slight learning curve, with less "auto configured magic" BGP is actually easier to manage. I think it's worth the slight effort. 73, Borja / EA2EKH

1 0

AMPRNet Address Sale
by Rob Janssen 19 Jul '19

19 Jul '19

>No. >https://portal.ampr.org/networks.php <https://portal.ampr.org/networks.php> > 44.224.0.0 / 15 GERMANY > ..with currently ~9500 assignments. > But that's no unresolvable problem. Just answering here to state that there is a large allocation and we do our best to move. > There's no direct bgp announcement for 44.224/15, and connectivity is done ampr-internal via ipip-mesh. Thus except for the dns reverse resolution, we expect no impact and can move step by step to 44.148/15. > The sold of the /10 netblock we are in is not a showstepper, it just makes (a lot of) work. But we also see the chance to configure things better during the renumbering. That was already going on for a while, wasn't it? Of course I saw this coming, by observing changes in the network assignments... But I wonder if the 44.224.0.0 network wouldn't have been better renumbered to 10.224.0.0, that better reflects the nature of the internet connectivity of that network and probably would solve some problems... You could then setup the new 44.148 space with true routing. Rob

1 0

ARDC and AMPR Reform
by Bryan Fields 19 Jul '19

19 Jul '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 It's clear we will need to engage with legal counsel regarding the corruption inside ARDC and perpetuated by the board. The people involved in this must be called to answer for their treachery. I have created and email list for strategizing and organizing this: http://lists.keekles.org/cgi-bin/mailman/listinfo/44-reform I also call on the community to not be won over by promises of money and grants from ARDC. The leaders think they will buy the community off. This is tainted money and I call on the community to reject it when offered and expose those who take it. 73's - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl0xjNoACgkQYTmgYVLG kUARDA//WJ06KmrXkTiWVsP3osUyEX2HKvJaqGwXYlioEnYHBpeaKYM3wzZRdaO9 /ps9ENc5lSGouKA2Zd9SBUjsKu40VWOT0FUi+CXe49XOL7GZ5X6k75X+hZ4PCsCP 5w+1RUXHOtT3SWIOyVXh0l5uwSOW6azKdVeTFcSGYeyE/lxgsOPwz49CtK6K7DvO O7MxHFbQI2rGCnWmcABuAoz6AImcAFzgGpxe3RwdjWLw+/j7StGyjDT1nEY58cxz AQZParzz/i/eQVZyLI3mBoHfNlKxJvyyeQ0qVbS6phfash2t9I3vnC1NeU6y1JTp yJ5q2B72N2e5cwcVfdtZJzBNIXPmd57LkXr0NijNyzl5cr+OSFwbpYvBa49+hzVR zO4F2RQRvCr1p+i5XZYhH1r+MxaisvcctVzeuMF9Aolz1WoU65AQRqPs/Ek7eefA pXlGd+RAmVlCeoYzhmyzJSqMP0sGneKWH3JmL9xrFhE7jBBLHPEd1TyJxW+mpWLC SSVqTZRVG9Oc7AsQ7DZOtk0GnkW9R5qZTEG0Lnjq/9eTpAaeSZ/viXJYMD/4Kahd QX4Ec21smcw4v7npmGhxAtGvkv//zQsZnMEni51sPdeTa5eZ6+08aEDYvxfRrP8Z W3L3Q6Lw+/LIbgocSu4P73WCAjiS4LAsBCz3Dl0aeHob1V4GQW0= =wmG1 -----END PGP SIGNATURE-----

1 0

Re: [44net] Reverse DNS broken
by Roger 19 Jul '19

19 Jul '19

Well once the reverse DNS is fixed then the next most important thing to do is to figure out how to stop them from selling the rest. Greed can be a terrible thing. Roger VA7LBB > On Jul 18, 2019, at 20:39, Michael Fox - N6MEF <n6mef(a)mefox.org> wrote: > > Folks, > > > > I'm sure folks will want to express their outrage about the address sale for > months. > > > > In the meantime, let's focus on what we can control. How do we get reverse > DNS working again for the part of 44/8 that wasn't sold? > > > > Michael, N6MEF > > > >

2 1

Re: [44net] Where amprhosts ?
by Pedro Converso 19 Jul '19

19 Jul '19

Tks for info, getting err_connection_timeout with ftp://gw.ampr.org/pub/ Can u please attach the file to my email ? Thanks in advance, 73, lu7abf, Pedro On 7/19/19, Steve L via 44Net <44net(a)mailman.ampr.org> wrote: > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

1 0

44/8 Not just for Amateur Radio anymore..
by Fredric Moses 19 Jul '19

19 Jul '19

So reading: https://www.ampr.org/amprnet/ Has raised the following questions.. "Why did you sell? We weren’t ever going to use those addresses, and in today’s marketplace, they could bring in some badly-needed funds.” Really badly-needed funds by who? for what is there some pressing need that the watchers of the 44/8 space had that they didn’t bother to ask the rest of the community? "Who decided to sell these? I didn’t get to vote on it.” It was all hush hush it seems. Because had you brought it to the community that uses the space day in and out it would have been brought with soooo much negativity that people would be asking questions to out the “board” of directors. The asset of 44/8 was for you guys to protect for Amateur Radio as a whole.. It’s not your personal play toy.. You all just thought about yourself’s and not the legacy and future of any grant programs or the like. 44/8 isn’t a personal piggy bank that you just turned it into. And into the largest piggy bank ever for a small group of hams to control at that. Had you really wanted to help Amateur radio you would have worked with the people who use the asset…. Now you have no clue if traffic from 44/8 is Amateur Radio based or not and that’s so screwed up.. -- Fredric Moses - W8FSM - WQOG498 fred(a)moses.bz

2 1

Re: [44net] Where amprhosts ?
by Steve L 19 Jul '19

19 Jul '19

ftp://gw.ampr.org/pub/ On Thu, Jul 18, 2019 at 10:57 PM Pedro Converso via 44Net <44net(a)mailman.ampr.org> wrote: > > > > > ---------- Forwarded message ---------- > From: Pedro Converso <pconver(a)gmail.com> > To: 44net(a)mailman.ampr.org > Cc: > Bcc: > Date: Fri, 19 Jul 2019 00:54:37 -0300 > Subject: Where amprhosts ? > Please where I can get latest amprhosts file ? > > Thanks. > 73, lu7abf, Pedro > > > > ---------- Forwarded message ---------- > From: Pedro Converso via 44Net <44net(a)mailman.ampr.org> > To: 44net(a)mailman.ampr.org > Cc: Pedro Converso <pconver(a)gmail.com> > Bcc: > Date: Fri, 19 Jul 2019 00:54:37 -0300 > Subject: [44net] Where amprhosts ? > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

1 0

Where amprhosts ?
by Pedro Converso 19 Jul '19

19 Jul '19

Please where I can get latest amprhosts file ? Thanks. 73, lu7abf, Pedro

1 0

Re: [44net] Reverse DNS for 44/8 broken
by Bryan Fields 19 Jul '19

19 Jul '19

On 7/18/19 10:38 PM, Alistair Mackenzie via 44Net wrote: > surprised > we have not heard anything about it from Brian You're surprised by that? The ARDC Tech committee has not heard from him in months. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

3 2

Re: [44net] Reverse DNS for 44/8 broken
by Ron Economos 19 Jul '19

19 Jul '19

He did hint at it the other day. But I guess the cat's out of the bag now. Adam (and others), Please don't advertise 44.192.0.0/10. To do so would cause some fairly significant problems. I am preparing a document to explain what's up with this and hope to have it ready in a week or so. I ask your patience. - BrianRon W6RZ On 7/18/19 19:38, Alistair Mackenzie via 44Net wrote: > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

1 0

Reverse DNS for 44/8 broken
by Michael Fox - N6MEF 19 Jul '19

19 Jul '19

Since about noon today (7/18), reverse DNS lookups of 44/8 from the outside world have returned NXDOMAIN. Forward DNS works fine. This is occurring from multiple sites, with multiple service providers. Michael N6MEF

6 6

Setup Gateway on RB951 n2 Mikrotik
by Francesco Ciacco 18 Jul '19

18 Jul '19

Hi everyone, I'm trying to migrate the gateway from linux to mikrotik. Given that on Linux the network traffic 44 takes place regularly, I am instead experiencing a great difficulty in configuring the rb 951 n2 following the directions of the wiki.ampr. There is someone on the list who has set up a rb mikrotik as described by the wiki and works regularly. I state that the ipip interface goes in regular running, the setups checked several times seem made for as requested. Someone can give me some info about it. Greetings Francesco IW8PGT

1 0

Re: [44net] Hamnet Web Page List
by Andrzej 18 Jul '19

18 Jul '19

http://sp.ampr.org http://search.sp.ampr.org czw., 18 lip 2019 o 08:23 Frederic Zulian via 44Net <44net(a)mailman.ampr.org> napisał(a): > > > > ---------- Forwarded message ---------- > From: Frederic Zulian <fzulian(a)gmail.com> > To: 44net(a)mailman.ampr.org > Cc: > Bcc: > Date: Thu, 18 Jul 2019 08:22:41 +0200 > Subject: Hamnet Web Page List > Hello, > > When I'm connected to the Hamnet network how can I know the IP addresses of > existing web pages. > > Is there a list or search engine? > > 73 > -- > Frédéric ZULIAN > -- Pozdrawiam Andrzej (www).

1 0

Hamnet Web Page List
by Frederic Zulian 18 Jul '19

18 Jul '19

Hello, When I'm connected to the Hamnet network how can I know the IP addresses of existing web pages. Is there a list or search engine? 73 -- Frédéric ZULIAN

1 0

Re: Untangle
by lleachii＠aol.com 16 Jul '19

16 Jul '19

Ryan N0JEP, I use OpenWrt with the ampr-ripd daemon. It's open source; but Linux. http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT 73, - Lynwood KB3VWG

1 0

Re: [44net] Questions regarding usage off 44/8 parts outside of ampr.org
by Bryan Fields 16 Jul '19

16 Jul '19

On 7/16/19 11:28 AM, Holger Baust via 44Net wrote: > Hi. > > My company plans to use DC/OS from Mesosphere and DC/OS is using > 44.128.0.0/20 per default for overlay networking. > This seems to have no impact since this overlay nets are only used in > DC/OS clusters and not routed to the Internet, but might lead to > problems in some cases... > > Their documentation with this informations can be found at: > https://docs.mesosphere.com/1.10/networking/virtual-networks/ip-per-contain… You're posting using quoted printable, don't do that. I've fixed your link. > Is this already known? News to me, and a really poor idea. There's other networks which could be used for this, without stepping on allocated space. 44.128.0.0/20 isn't used now, but neither was 1/8 or 5/8. I kinda want to announce 44.128.0.0/20 just to mess with them, might freak out if there's a route to that :) -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

6 5

Re: [44net] Questions regarding usage off 44/8 parts outside of ampr.org
by Brian Kantor 16 Jul '19

16 Jul '19

On Tue, Jul 16, 2019 at 08:28:49AM -0700, Holger Baust via 44Net wrote: > Date: Tue, 16 Jul 2019 08:28:49 -0700 (PDT) > From: Holger Baust <holger(a)dm6hb.de> > To: 44net(a)mailman.ampr.org > Subject: Questions regarding usage off 44/8 parts outside of ampr.org > > Hi. > > My company plans to use DC/OS from Mesosphere and DC/OS is using > 44.128.0.0/20 per default for overlay networking. > This seems to have no impact since this overlay nets are only used in > DC/OS clusters and not routed to the Internet, but might lead to > problems in some cases... > > Their documentation with this informations can be found at: > https://docs.mesosphere.com/1.10/networking/virtual-networks/ip-per-conta= > iner/ > > Is this already known? > > 73, > Holger While I was unaware of DC/OS specifically using this subnet, I do know that for many years software from various companies have used parts of network 44 for "internal-only" networking. In particular, an obsolete document, which is still available via Google searching refers to 44.128.0.0/16 in terms which seem to have lead these firms to believe that it is another RFC1918-style "private network" and they may use it in that way. Most of these firms seem to be ignorant of the various RFC1918 networks that are intended for this use. Many of them should be using the link-local addresses of 169.254.0.0/16, but apparently don't know about them. When contacted by me about the misuse of network 44, some are cooperative and some pull up the obsolete document as justification, while a small number take up a combative stance and tell me to contact their lawyers. Just to make it specific: 44.128.0.0/16 is a subnet currently reserved for testing in the amprnet. It should not be used outside Amateur Radio. - Brian Kantor Network 44 Manager

2 1

Questions regarding usage off 44/8 parts outside of ampr.org
by Holger Baust 16 Jul '19

16 Jul '19

A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: <https://mailman.ampr.org/mailman/private/44net/attachments/20190716/cae6f3b…>

1 0

Re: [44net] Untangle
by Jeff KC9WSJ 16 Jul '19

16 Jul '19

On Fri, 2019-07-12 at 14:15 +0000, Ryan O'Connor via 44Net wrote: > > Has anyone successfully used AMPRNet with an untangle firewall/router > device? I’m trying to ditch the Cisco 2850 for something quieter. > > Ryan I don't want to 'jack this thread, but it might be helpful to hear from others using /any/ of the open source fw/routers available, in particular anything *BSD-based (I was told a long time ago that "friends don't let friends run Linux as a firewall). OSS Platforms that come to mind are pfSense, Untangle, OPNsense, m0n0wall, smoothwall, etc. -- Jeff KC9WSJ <jeff(a)kc9wsj.us>

7 6

Re: [44net] Untangle
by Randy Neals 16 Jul '19

16 Jul '19

Yes, OPNsense is not one of Vultr’s standard images, but I was successful in loading a custom ISO of OPNsense on a Vultr server. I was also successful in getting ZeroTier to work with a customer IP subnet rather than RFC1918 space. My next step in to load the dynamic routing missilery in OPNsense and test originating of a /24 block to Vultr using a private AS number. If that is successful, then I plan to deploy another OPNsense VM at a different Vultr data center. The objective is to have 2 OPNsense gateways, each announcing the same block to Vultr, and extending that /24 via ZeroTier to our client devices. If the OPNsense server fails, the BGP announcement will likely also drop, however the other OPNsense fm in the other data center should pick up the traffic. Randy On Mon, Jul 15, 2019 at 3:51 PM pete M via 44Net <44net(a)mailman.ampr.org> wrote: > > > > ---------- Forwarded message ---------- > From: pete M <petem001(a)hotmail.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Mon, 15 Jul 2019 22:49:32 +0000 > Subject: RE: [44net] Untangle > This sound pretty interresting. > > > > Could this be impremented on a vultur vps? > > > > > > > > > > ________________________________ > De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la > part de Randy Neals <randy(a)neals.ca> > Envoyé : Monday, July 15, 2019 5:04:31 PM > À : AMPRNet working group > Objet : Re: [44net] Untangle > > I'm currently experimenting with OPNSense on a cloud server, with ZeroTier > VPN. > > I'm intending to run OPNSense on a small i386 device at a repeater site, > with VPN back to the cloud server. > Thus extending 44. IP addresses to a variety of radio sites. > > Randy, W3RWN > Seattle. > > On Mon, Jul 15, 2019 at 1:42 PM Jeff KC9WSJ <jeff(a)kc9wsj.us> wrote: > > > On Fri, 2019-07-12 at 14:15 +0000, Ryan O'Connor via 44Net wrote: > > > > > > Has anyone successfully used AMPRNet with an untangle firewall/router > > > device? I’m trying to ditch the Cisco 2850 for something quieter. > > > > > > Ryan > > > > I don't want to 'jack this thread, but it might be helpful to hear from > > others using /any/ of the open source fw/routers available, in particular > > anything *BSD-based (I was told a long time ago that "friends don't let > > friends run Linux as a firewall). > > OSS Platforms that come to mind are pfSense, Untangle, OPNsense, > m0n0wall, > > smoothwall, etc. > > > > -- > > Jeff KC9WSJ <jeff(a)kc9wsj.us> > > > > > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > > > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net > > > > ---------- Forwarded message ---------- > From: pete M via 44Net <44net(a)mailman.ampr.org> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: pete M <petem001(a)hotmail.com> > Bcc: > Date: Mon, 15 Jul 2019 22:49:32 +0000 > Subject: Re: [44net] Untangle > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net > -- Sent from mobile.

1 0

Re: [44net] Comcast Xfinity Routing
by David Ranch 12 Jul '19

12 Jul '19

Hello Nate, >Even in bridge mode I wasn't getting any traffic from AMPRGW. Tomorrow I >will try bridge mode again, it is possible that I may have set up the >firewall rules on my edgerouter incorrectly. I have Comcast Business here to get static IPv4 addresses and it's worth noting that with these cablemodems (a rebadged Cisco DPC3941B), it doesn't support static IPs in bridging. You *must* leave the modem in "Bridge: Off" aka.. NAT mode. In this mode, the inside Ethernet ports or Wifi connections offer both 10.1.0.x NATed address space but also offer my static IP subnet. I infer that for my static addresses, the Comcast box is doing some sort of 1:1 NATing but it does seem to support protocol 4. Externally initiated proto-4 traffic comes in ok so the NATing isn't screwing anything up. A few more things I recently became aware of from a Comcast support rep if it's helpful to you: - When enabling or disabling bridging mode, my external IP would get assigned to vastly different subnets. I have no idea why putting the cablemodem into L2 mode would do this but it does. Something worth considering. - Pseudo mode: It seems that Comcast silently pushes new firmware and does reboots on you. No notifications or release notes are offered up as far as I can tell I noticed the other day that under the bridging configuration area of the cablemodem, it nows shows OFF, Pseudo, ON. I have no idea what this new Pseudo means but it does sound similar to what I described above. - Uptime: I've been having my cablemodem just stop forwarding traffic after about 70 days of uptime. Working fine and fast one minute, zero packet forwarding after that. The front facing LEDs still look happy, web interface still works, but zero forwarding. According to Comcast, they recommend to their users to reboot the cablemodem every 60 days to avoid issues with memory fragmentation. This is pretty lame if you ask me but this is what they told me and it's something I'm looking to automate if I can find a decent way to automate their web interface (no CLI or API interfaces offered). --David KI6ZHD

1 0

Untangle
by Ryan O'Connor 12 Jul '19

12 Jul '19

Has anyone successfully used AMPRNet with an untangle firewall/router device? I’m trying to ditch the Cisco 2850 for something quieter. Ryan Sent from my mobile device. Expect strange words and horrendous misspelling.

1 0

Re: [44net] Comcast Xfinity Routing
by Brian Kantor 12 Jul '19

12 Jul '19

On Fri, Jul 12, 2019 at 02:27:15AM -0700, Nate Sales via 44Net wrote: > Date: Fri, 12 Jul 2019 02:27:15 -0700 > From: Nate Sales <nate.wsales(a)gmail.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Subject: Comcast Xfinity Routing > > Hello, > I'm wondering if anyone here has had success with an IPIP gateway on > Xfinity by Comcast. I haven't had a lot of success with it, and I'm > wondering if even in "bridge" mode the CPE modem/router that they give you > is still blocking protocol 4. > 73, > KJ7DMC Nate: Whatever your current modem configuration is, it's blocking protocol 4 (IPIP). Specifically, a traceroute to your gateway, 157.230.161.245 using ordinary UDP traceroute succeeds. Doing the same thing with protocol 4 (IPIP) gets a "Protocol Unreachable" ICMP return from your gateway. Viz: # traceroute -n 157.230.161.245 traceroute to 157.230.161.245 (157.230.161.245), 64 hops max, 40 byte packets 1 169.228.34.82 0.575 ms 0.569 ms 0.561 ms 2 132.239.255.49 0.223 ms 0.206 ms 0.200 ms 3 132.239.254.162 0.247 ms 0.536 ms 0.235 ms 4 132.239.254.149 0.356 ms 0.393 ms 0.265 ms 5 137.164.23.57 2.871 ms 2.841 ms 2.740 ms 6 137.164.22.46 5.335 ms 137.164.11.2 5.129 ms 137.164.22.46 5.165 ms 7 4.35.156.65 4.972 ms 4.911 ms 4.968 ms 8 * * * 9 4.14.33.70 12.617 ms 19.749 ms 4.14.33.54 14.277 ms 10 * * * 11 * * * 12 157.230.161.245 13.960 ms 12.958 ms 14.074 ms ...and... # traceroute -n -P 4 157.230.161.245 traceroute to 157.230.161.245 (157.230.161.245), 64 hops max, 40 byte packets 1 169.228.34.82 0.613 ms 0.611 ms 0.577 ms 2 132.239.255.49 0.218 ms 0.197 ms 0.215 ms 3 132.239.254.162 0.363 ms 0.227 ms 0.224 ms 4 132.239.254.149 0.364 ms 0.258 ms 0.263 ms 5 137.164.23.57 3.111 ms 3.025 ms 3.108 ms 6 137.164.11.2 5.091 ms 5.122 ms 5.094 ms 7 4.35.156.65 5.219 ms 4.967 ms 4.974 ms 8 * * * 9 4.14.33.70 13.814 ms 13.901 ms 13.844 ms 10 * * * 11 * * * 12 157.230.161.245 14.829 ms !P 14.102 ms !P 13.926 ms !P - Brian

2 1

Re: [44net] Comcast Xfinity Routing
by Brian 12 Jul '19

12 Jul '19

Nate; On Fri, 2019-07-12 at 02:27 -0700, Nate Sales via 44Net wrote: > email message attachment (Comcast Xfinity Routing) > > I'm wondering if anyone here has had success with an IPIP gateway on > > Xfinity by Comcast. I haven't had a lot of success with it, and I'm > > wondering if even in "bridge" mode the CPE modem/router that they give you > > is still blocking protocol 4. I'm on Xfinity and it took me about 2 years to figure out what's going on with them and how to fix it. I wrote a white paper on the topic: https://uronode.n1uro.com/linux/amprcable.html It's a 44-net IP so if you can't see it let me know and I'll send you the text off-list. -- Rain is caused by big, high-pressure areas; cold fronts; warm, moist air; And the first day of your vacation. ----- 73 de Brian N1URO IPv6 Certified SMTP: n1uro-at-n1uro.ampr.org

1 0

Comcast Xfinity Routing
by Nate Sales 12 Jul '19

12 Jul '19

Hello, I'm wondering if anyone here has had success with an IPIP gateway on Xfinity by Comcast. I haven't had a lot of success with it, and I'm wondering if even in "bridge" mode the CPE modem/router that they give you is still blocking protocol 4. 73, KJ7DMC

1 0

Re: [44net] NPR kits for sale! (New Packet Radio)
by Brian 09 Jul '19

09 Jul '19

Pete; I wanted to set something up so I could but his mail server is blocking me. On Tue, 2019-07-09 at 18:28 +0000, pete M via 44Net wrote: > email message attachment (Re: [44net] NPR kits for sale! (New Packet > Radio)) > > -------- Forwarded Message -------- > > From: pete M <petem001(a)hotmail.com> > > To: AMPRNet working group <44net(a)mailman.ampr.org> > > Subject: Re: [44net] NPR kits for sale! (New Packet Radio) > > Date: Tue, 9 Jul 2019 18:28:38 +0000 > > > > When someone will distribute those in north america I am in line for 2! > > > > Tlcharger Outlook pour Android<https://aka.ms/ghei36> > > > > ________________________________ > > From: 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> on behalf of f4hdk <f4hdk(a)free.fr> > > Sent: Tuesday, July 9, 2019 1:28:54 PM > > To: 44net(a)mailman.ampr.org > > Subject: [44net] NPR kits for sale! (New Packet Radio) > > > > Hello, > > > > NPR kits (New Packet Radio) are now for sale from this German web-shop, > > currently shipping to Europe only (EU+EFTA). > > https://shop.thinkstack.de/en/ham-radio/20-new-packet-radio-npr.html > > > > If you have questions about this sale, please contact directly the > > web-shop : mailto:info@thinkstack.de > > > > If you want to sell NPR kits from another region (USA or other > > countries), please contact me directly. > > > > If you have technical questions, please ask me directly on this > > mailing-list. > > > > 73, > > Guillaume F4HDK > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net -- Rain is caused by big, high-pressure areas; cold fronts; warm, moist air; And the first day of your vacation. ----- 73 de Brian N1URO IPv6 Certified SMTP: n1uro-at-n1uro.ampr.org

2 2

NPR kits for sale! (New Packet Radio)
by f4hdk 09 Jul '19

09 Jul '19

Hello, NPR kits (New Packet Radio) are now for sale from this German web-shop, currently shipping to Europe only (EU+EFTA). https://shop.thinkstack.de/en/ham-radio/20-new-packet-radio-npr.html If you have questions about this sale, please contact directly the web-shop : mailto:info@thinkstack.de If you want to sell NPR kits from another region (USA or other countries), please contact me directly. If you have technical questions, please ask me directly on this mailing-list. 73, Guillaume F4HDK

3 2

Re: [44net] Vultr.com - "Invalid BGP RPKI Entries"
by Brian Kantor 08 Jul '19

08 Jul '19

I have heard no other complaints nor has Vultr contacted me. It might have been helpful if you had specified WHICH 44 subnet(s) you think are having problems. - Brian On Sun, Jul 07, 2019 at 05:45:54PM -0400, Ty Bermea via 44Net wrote: > Date: Sun, 7 Jul 2019 17:45:54 -0400 > From: Ty Bermea <ty(a)tybermea.net> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Subject: Re: [44net] Vultr.com - "Invalid BGP RPKI Entries" > > Has anyone else had trouble in the last few days with Vultr suddenly no > longer routing/announcing 44 subnets? > > On Tue, Jun 18, 2019 at 2:42 AM Toussaint OTTAVI <t.ottavi(a)bc-109.com> > wrote: > > > Hi, > > > > Le 17/06/2019 à 23:13, Brian Kantor a écrit : > > > If you are one of the 35 or so people who received a letter from > > > support(a)vultr.com informing you that there is a problem with your > > > subnet RPKI settings, feel free to ignore and discard it. > > > > Thank you for your action. It means we are 35+ using BGP at Vultr for > > $5/month. That's good news :-) > > > > 73 de TK1BI > > > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > > > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

2 3

Vultr.com - "Invalid BGP RPKI Entries"
by Brian Kantor 07 Jul '19

07 Jul '19

If you are one of the 35 or so people who received a letter from support(a)vultr.com informing you that there is a problem with your subnet RPKI settings, feel free to ignore and discard it. There is nothing wrong with your RPKI settings. In fact, most of you don't have any RPKI settings at all. Maybe someday. Vultr has a problem with their audit software which has been sending out false alarms. There appears to be no cause for concern. - Brian

3 2

Ping N1URO - PacComm email
by Nick G4IRX (44.131.x.x) 30 Jun '19

30 Jun '19

Brian N1URO - Have tried to reply to email you sent me about PacComm stuff a week ago but my reply has been returned undeliverable. If you are still interested, please contact me off-list with an alternative address? Thanks, Nick G4IRX

1 0

Re: [44net] Connecting to 44net
by Brian 30 Jun '19

30 Jun '19

Cathryn; I'm also on Comcast. To let you know in my 4 year battle with them, it took me contacting Cisco direct to find out what the problem was. They simply deploy broken CPE units to the end user by design. What's probably happening is that they disable certain menu functions which allows them to say they don't filter certain things, however the natural behavior of the CPE will still filter. There's 2 solutions available. You may read about them at: https://uronode.n1uro.com/linux/amprcable.html On Sat, 2019-06-29 at 10:51 -0700, Cathryn Mataga via 44Net wrote: > email message attachment (Re: [44net] Connecting to 44net) > > -------- Forwarded Message -------- > > From: Cathryn Mataga <cathryn(a)junglevision.com> > > To: Brian Kantor <Brian(a)bkantor.net>, AMPRNet working group > > <44net(a)mailman.ampr.org> > > Subject: Re: [44net] Connecting to 44net > > Date: Sat, 29 Jun 2019 10:51:06 -0700 > > > > Thanks, this is useful, though is grim news. Last time I talked to > > comcast, basically they had me reset power on my router, over and over, > > for an issue that had nothing to do with my router, until they sent me > > to another phone number that was disconnected. > > > > On 6/29/2019 10:38 AM, Brian Kantor wrote: > > > Cathryn, > > > > > > I see your ping requests arriving at 169.228.34.84 no problem, > > > and they are being encapsulated at sent to 50.79.209.150, again, > > > no problem. Nothing is coming back from 50.79.209.150. > > > > > > This suggests that something is filtering out protocol 4 (IPIP) > > > between 169.228.34.84 and 50.79.209.150. > > > > > > A traceroute from 169.228.34.84 to 50.79.209.150 using ordinary > > > UDP works, completing after 18 hops. The last few hops in that > > > path look like this: > > > > > > 14 162.151.87.226 12.097 ms 12.315 ms 12.088 ms > > > 15 162.151.79.134 12.735 ms 12.744 ms 12.773 ms > > > 16 68.87.227.122 13.080 ms 12.983 ms 12.920 ms > > > 17 * * * > > > 18 50.79.209.150 37.676 ms 42.664 ms 33.084 ms > > > > > > A traceroute from 169.228.34.84 to 50.79.209.150 using protocol 4 > > > (IPIP) does not complete, and there are no responses beyond hop > > > 15. The last few hops are: > > > > > > 12 68.86.84.150 11.117 ms 12.601 ms 12.734 ms > > > 13 68.86.94.154 11.761 ms 11.743 ms 11.340 ms > > > 14 162.151.87.226 12.469 ms 12.162 ms 12.392 ms > > > 15 162.151.79.134 12.757 ms 12.800 ms 12.797 ms > > > 16 * * * > > > 17 * * * > > > 18 * * * > > > > > > This suggests that hop 16, 68.87.227.122, is not accepting/passing > > > protocol 4 packets. The hostname for that host is > > > lag-2-240-acr07.pinole.ca.sfba.comcast.net. > > > > > > I hate to throw you to the wolves of comcast's customer service line, > > > but you may need to find out from them if they suddenly started filtering > > > out inbound IPIP packets at that router. > > > - Brian > > > > > > > > > On Sat, Jun 29, 2019 at 09:50:40AM -0700, Cathryn Mataga via 44Net wrote: > > >> Date: Sat, 29 Jun 2019 09:50:40 -0700 > > >> From: Cathryn Mataga <cathryn(a)junglevision.com> > > >> To: AMPRNet working group <44net(a)mailman.ampr.org> > > >> Subject: Connecting to 44net > > >> > > >> I'm not connected to 44net anymore, when I ping, to me at least, my > > >> outgoing packets look correct, but I get no response ever. > > >> > > >> I'm trying to put together as much as I can. My gateway ips 44.4.28.50 > > >> at 50.79.209.150, I have a static IP. > > >> > > >> I'm current on the portal, far as I can tell with no error messages. > > >> > > >> > > >> ping 44.0.0.1 > > >> PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. > > >> *no response ever > > >> > > >> I see the outgoing, but never the ping back. > > >> > > >> tcpdump -vv -i enp4s0 host 169.228.34.84 > > >> tcpdump: listening on enp4s0, link-type EN10MB (Ethernet), capture size > > >> 262144 bytes > > >> 09:39:25.982188 IP (tos 0x0, ttl 64, id 54479, offset 0, flags [DF], > > >> proto IPIP (4), length 104) > > >> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64, > > >> id 14161, offset 0, flags [DF], proto ICMP (1), length 84) > > >> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 105, > > >> length 64 > > >> 09:39:27.006173 IP (tos 0x0, ttl 64, id 54594, offset 0, flags [DF], > > >> proto IPIP (4), length 104) > > >> hamradio.junglevision.com > amprgw.ucsd.edu: IP (tos 0x0, ttl 64, > > >> id 15137, offset 0, flags [DF], proto ICMP (1), length 84) > > >> ke6i.ampr.org > gw.ampr.org: ICMP echo request, id 25489, seq 106, > > >> length 64 > > >> > > >> I occasionally see one of these, which hints to me that ipip is making > > >> it to my gateway. > > >> > > >> 09:39:15.386222 IP (tos 0x20, ttl 48, id 32657, offset 0, flags [none], > > >> proto IPIP (4), length 60) > > >> amprgw.ucsd.edu > hamradio.junglevision.com: IP (tos 0x0, ttl 237, > > >> id 33644, offset 0, flags [none], proto TCP (6), length 40) > > >> no-reverse-dns-configured.com.46324 > ke6i.ampr.org.finger: Flags > > >> [S], cksum 0x039d (correct), seq 2046795537, win 1024, length 0 > > >> > > >> > > >> ip tunnel list tunl0 > > >> tunl0: any/ip remote any local any ttl 64 > > >> > > >> ifconfig tunl0 > > >> > > >> tunl0: flags=4289<UP,RUNNING,NOARP,MULTICAST> mtu 1480 > > >> inet 44.4.28.50 netmask 255.255.255.255 > > >> tunnel txqueuelen 1000 (IPIP Tunnel) > > >> RX packets 2259 bytes 305270 (298.1 KiB) > > >> RX errors 0 dropped 0 overruns 0 frame 0 > > >> TX packets 2874 bytes 233904 (228.4 KiB) > > >> TX errors 232 dropped 0 overruns 0 carrier 0 collisions 232 > > >> > > >> ifconfig enp4s0 > > >> enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > > >> inet 50.79.209.150 netmask 255.255.255.240 broadcast > > >> 50.79.209.159 > > >> ether 8c:89:a5:64:04:4c txqueuelen 1000 (Ethernet) > > >> RX packets 140452 bytes 25244334 (24.0 MiB) > > >> RX errors 0 dropped 473 overruns 0 frame 0 > > >> TX packets 53461 bytes 5807456 (5.5 MiB) > > >> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > >> > > >> ampr-ripd -d -t 44 -a 44.4.28.50/32 -s -L ke6i@cm87uu > > >> Using gateway 50.79.209.158 for direct 44net endpoints via interface enp4s0. > > >> Calling home > > >> Waiting for RIPv2 broadcasts... > > >> Simple password: *********** > > >> > > >> > > >> ip rule list > > >> > > >> 0: from all lookup local > > >> 44: from all to 44.0.0.0/8 lookup hamradio > > >> 45: from all iif tunl0 lookup hamradio > > >> 45: from 44.4.28.50 lookup hamradio > > >> 32766: from all lookup main > > >> 32767: from all lookup default > > >> > > >> > > >> ip route list table hamradio > > >> 44.0.0.1 via 169.228.34.84 dev tunl0 proto 44 onlink window 840 > > >> 44.2.0.1 via 191.183.136.1 dev tunl0 proto 44 onlink window 840 > > >> 44.2.2.0/24 via 216.218.207.198 dev tunl0 proto 44 onlink window 840 > > >> ... > > >> > > >> I don't think it's a firewall issue, I've turned off firewall and it > > >> doesn't fix anything. > > >> > > >> My route table looks healthy, so I think ampr-ripd is worrking correctly? > > >> > > >> Tried to include as much information as I can, thanks for any help! > > >> > > >> > > >> _________________________________________ > > >> 44Net mailing list > > >> 44Net(a)mailman.ampr.org > > >> https://mailman.ampr.org/mailman/listinfo/44net > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net -- If a rabbit is raised indoors, would it be an ingrown hare? ----- 73 de Brian N1URO IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com

1 0

44Net VPN?
by KJ7DMC 29 Jun '19

29 Jun '19

Hello, This is sort of a follow up to my last email, which I ended up figuring out. This link, http://he.fi/amprnet-vpn/amprnet-vpn-win.zip to download the amprnet crt file is invalid. Any idea where I would obtain that file from? Thanks! -Nate

3 2

Old Files
by vk2tv 26 Jun '19

26 Jun '19

I apologise in advance if this message is misplaced, but I've seen some names/callsigns on the list that go back far enough to possibly have what I'm looking for. Some weeks back I performed some hardware decode comparisons for old packet hardware - MFJ1270B and Tiny2 mk2 TNCs, serial port Baycom modem (TCM3105 based), Baycom USCC>4 card with 1x9k6, 1xAMD7911 and 2xTCM3105 modems, a YAM modem, and some relatively new hardware, the TNCX and Byonics TT4) - with Dire Wolf software decoding, with some surprising results, except for the YAM. Try as I might I couldn't get the YAM to rx data at 9k6, but I was able to tx to the Baycom 9k6 modem which decoded packets. That was after I added external, 5V powers supplies because the comport wasn't up to the task (-5V/+2.8V)! The YAM won't tx or rx at 1k2. I know the YAM is old - about 1998 - and there isn't much information beyond what little I already had for the unit, which was capable of two-way communication (over wire) with the Baycom many years ago, so I know it "did" work. The Wayback Machine provided nothing useful. My request is for any information pertaining to the YAM, and in particular, any mcs configuration files for Linux. I have yam96v13, yam17 and yam1k2b5. My fading memory seems to recall documentation pertaining to faults and modifications, so that could also prove useful .. if any still exists. Thank you for your ears (or is that eyes?) Ray vk2tv

1 0

NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud
by f4hdk 20 Jun '19

20 Jun '19

Hello. I have updated the firmware of my NPR (New Packet Radio) project with 2 expected features, mainly for America: * New modulations (11, 12, 20, 21) for lower datarates, lower bandwidth. Symbol rates: 56kS/s (complies with FCC) and 120kS/s. You now have the choice between 9 modulation parameters, in order to adapt to lots of situations and needs. * Frequency range extended to 420-450MHz instead of previously 430-440MHz I have updated all the documentation accordingly. https://hackaday.io/project/164092-npr-new-packet-radio/ Several people here expected these features. I hope you will enjoy it! 73, Guillaume F4HDK

5 9

Re: [44net] IRR Entries for BGP Filtering
by G1FEF 19 Jun '19

19 Jun '19

> On 19 Jun 2019, at 17:33, チョーチュアン via 44Net <44net(a)mailman.ampr.org> wrote: > > > From: チョーチュアン <quanzhou822(a)gmail.com> > Subject: Re: [44net] IRR Entries for BGP Filtering > Date: 19 June 2019 at 17:33:31 BST > To: AMPRNet working group <44net(a)mailman.ampr.org> > > > IIRC Vultr registers your prefix with the RADb as "Vultr Customer Route" or > something alike. That will make your asn/prefix pair work with most > providers. On the other hand, I met some providers completely ignores the > RADb and/or LoA, and do their own due diligence, I believe there are good > stories behind these practices. Indeed, I have (not so fond) memories of trying to convince some carriers (usually tier 2 / wannabe tier 1’s) that they needed to update their filters so our customers could reach their networks. Those were the days! I guess not much has changed in 20 years. Chris

1 0

IRR Entries for BGP Filtering
by Jonathan Lassoff 19 Jun '19

19 Jun '19

Hello 44Net friends -- I'm operating a BGP-announced subnet of 44/8 for some paging and SDR experiments, and with some new access to other facilities, I'm looking into adding some geographic redundancy for my network, setting up an ASN, and beginning some public peering. However, what I am coming to discover is that Brian's LOA only gets me so far... :) Many networks in Europe are doing proper per-peer prefix filtering, constructed from IRR data in various registries. I would like to get my 44/8 prefix listed in one of these registries with my ASN listed, so that I can get all this automatic filtering working. Generally, most networks seem to be using the RIR-provided IRR registry for this data, which for us in the US and with AMPR would be ARIN. There are also some commercial IRR databases. https://www.radb.net/ seems to be the most-widely mirrored, but it costs ~$500/year to use. As this is just a hobby project for me, it's difficult to justify the costs of a commercial registry. Might it be possible for AMPRNet users to use ARDC's ARIN accounts to list some "inetnum" IRR data for our prefixes? Depending on the outcome, maybe this would be some useful information to list on the FAQ in the Wiki. Thanks, jof

8 9

Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud
by Leon Zetekoff 18 Jun '19

18 Jun '19

hi there...sound good but why aren't we using 2.4 or 5g for high bandwidth backhauls? The hardware is cheap enough and works well. 73 Leon wa4zlw Blandon, PA On 6/16/2019 10:40 AM, pete M via 44Net wrote: > To: > AMPRNet working group <44net(a)mailman.ampr.org> > > > A big thank you for that effort. This will surely start a new boom in "packet radio" in north America. I for one will push to implement the fastest links to our audio links back bones that is all in uhf for our emergency net . That way we will work in Voip rather then analog voice opening the way to many more service at the same time . > > Télécharger Outlook pour Android<https://aka.ms/ghei36> --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

7 10

Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud
by Mark Phillips 17 Jun '19

17 Jun '19

".... may use any technique whose technical characteristics have been documented publicly ...." This mode is documented publicly along with its source code. I'd say we are good. So now it's just the symbol rate and bandwidth issue to overcome. I like the idea of multiple carriers too. Bond them together on demand perhaps? Mark On Mon, Jun 17, 2019 at 4:54 PM Steve L via 44Net <44net(a)mailman.ampr.org> wrote: > > > > ---------- Forwarded message ---------- > From: Steve L <kb9mwr(a)gmail.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Mon, 17 Jun 2019 15:54:13 -0500 > Subject: Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud > and 120kBaud > The rules no longer really specify how you must ID, like pre-1980's. > Basically in this case you ID in the mode > itself, just like D-Star, YSF etc, does. > > If the digital code was unspecified (also allowed) you'd likely have > to default to a CW ID. > > §97.119 Station Identification > > (b) The call sign must be transmitted with an emission authorized for > the transmitting channel in one of the following ways: > > (3) By a RTTY emission using a specified digital code when all or part > of the communications are transmitted by a RTTY or data emission; > > §97.309 RTTY and data emission codes. > > (4) An amateur station transmitting a RTTY or data emission using a > digital code specified in this paragraph may use any technique whose > technical characteristics have been documented publicly, such as > CLOVER, G-TOR, or PacTOR, for the purpose of facilitating > communications. > > On Mon, Jun 17, 2019 at 11:40 AM David Ranch <amprgw(a)trinnet.net> wrote: > > > I'm not an expert on FCC Part 97 and I don't want to derail this > > conversation but I don't think some of these protocols are legally > > self-identifying. > > > > > > > ---------- Forwarded message ---------- > From: Steve L via 44Net <44net(a)mailman.ampr.org> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: Steve L <kb9mwr(a)gmail.com> > Bcc: > Date: Mon, 17 Jun 2019 15:54:13 -0500 > Subject: Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud > and 120kBaud > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

1 0

Hamnet over 70cm : NPR (New Packet Radio)
by f4hdk 08 Jun '19

08 Jun '19

Hello, I am Guillaume, callsign F4HDK, a french amateur-radio operator, and a hacker-maker. I would like to share with you my last project : NPR (New Packet Radio). All documentation is provided here : https://hackaday.io/project/164092-npr-new-packet-radio This solution can transport bi directional IP trafic over 70cm radio links, in a 'point to multipoint' topology, at datarate up to 500kbps. This can be used to increase the range of existing HSMM-Hamnet networks, at lower datarates. It's designed for "access", not backbone, and not designed for H24 use. Its is 100% open-source. Do not hesitate to ask me questions about it. I hope it will interest some people here. 73, Guillaume F4HDK

16 41

Re: [44net] Hamnet over 70cm : NPR (New Packet Radio)
by Rob Janssen 05 Jun '19

05 Jun '19

> On Mon, 3 Jun 2019, David Ranch wrote: > >/(6) A RTTY, data or multiplexed emission using a specified digital code /> >/listed in ?97.309(a) of this part may be transmitted. The symbol rate must not /> >/exceed 56 kilobauds. A RTTY, data or multiplexed emission using an unspecified /> >/digital code under the limitations listed in ?97.309(b) of this part also may /> >/be transmitted. The authorized bandwidth is 100 kHz. / > 56 kilobauds is because the Telebit Trailblazer existed; it used OFDM > and 6 "baud" carriers. The Trailblazer was fast, but it wasn't *that* fast! It actually was like 19200 baud async, internally some 18kbps sync. This was fast compared to the usual V.22bis (2400 bps) modems of the day, but of course later telephone modems appeared that could to 56k. We ran a Unix system with UUCP at work in those days but we could not use modems that fast because the machine wasn't able to handle full 19200 baud async I/O as it could not handle the interrupt load... those were the days. (It was an NCR system with a separate processor for serial I/O, but IBM PC and clones in those days also struggled at 19200, that is why the 16550 chip with hardware FIFO was created...) A couple of years later I bought a ZyXEL U-1496+ modem that also did 19200 over phone lines, and was popular at some local ISPs. Like the Trailblazer it also used a 68000 processor and it cost well over $500 in local currency. I agree that those modems are not going to work over radio. Even on telephone lines they perform lengthy "training" sequences to measure the phase response of the line, and then assume it remains the same over the duration of the call. Rob

1 0

Re: [44net] Telebit Trailblazer over radio
by John Gilmore 05 Jun '19

05 Jun '19

Telebit was doing the modulation in signal processing software in a dedicated big-grasshopper-sized Motorola 68000 chip inside the modem. These days we could do the same modulation in software in just about any chip. But as Brian said, the signal impairments in multi kilometer twisted pair telephone circuits with occasional loading coils, chopped into 56k digital bitstreams and reconstituted at the other end before transiting a different long twisted pair, are very different than the impairments typically experienced when passing a signal thru typical radio circuitry and kilometers of radio "ether" and interference. There's free software for messing with OFDM over narrowband radio (e.g. not WiFi); here are a few starting points: https://github.com/rwth-ti/gr-ofdm https://ro.uow.edu.au/cgi/viewcontent.cgi?article=4984&context=theses https://github.com/kit-cel/gr-lte John

1 0

Re: [44net] Portal encap file by email option
by Jean Létourneau 04 Jun '19

04 Jun '19

My guess it depend how many updates their information. On Tue, Jun 4, 2019 at 3:51 AM R P via 44Net <44net(a)mailman.ampr.org> wrote: > > > > > ---------- Forwarded message ---------- > From: R P <ronenp(a)hotmail.com> > To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Tue, 4 Jun 2019 07:49:41 +0000 > Subject: Portal encap file by email option > Hi there > I have noticed that there is option to get the encap file by email > does anyone know how often the file change a day ? (if i chose to get it "when file change" ) ? > Thanks forware > 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 > > > > [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > > > ---------- Forwarded message ---------- > From: R P via 44Net <44net(a)mailman.ampr.org> > To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org> > Cc: R P <ronenp(a)hotmail.com> > Bcc: > Date: Tue, 4 Jun 2019 07:49:41 +0000 > Subject: [44net] Portal encap file by email option > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net -- 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 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] Portal encap file by email option
by Brian Kantor 04 Jun '19

04 Jun '19

Because some of the gateways have dynamic IP addresses, the file can change often, sometimes as often as once an hour. - Brian On Tue, Jun 04, 2019 at 07:49:41AM +0000, R P via 44Net wrote: > From: R P <ronenp(a)hotmail.com> > Subject: Portal encap file by email option > > Hi there > I have noticed that there is option to get the encap file by email > does anyone know how often the file change a day ? (if i chose to get it "when file change" ) ? > Thanks forware > 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

Portal encap file by email option
by R P 04 Jun '19

04 Jun '19

Hi there I have noticed that there is option to get the encap file by email does anyone know how often the file change a day ? (if i chose to get it "when file change" ) ? Thanks forware 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 [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>

1 0

Gateway hostname resolver
by Gustavo Ponza 30 May '19

30 May '19

Hi, after a change of my dynamic IP address happened yesterday afternoon the 44net gateway remained on my expired IP, so after a double check after several hours confirm that failure still remains. May you check about it? TNX -- 73 and ciao, gustavo i0ojj/ir0aab/ir0eq

2 1

Re: [44net] UCSD tunnel behing NAT and Firewall setting ?
by R P 23 May '19

23 May '19

To all I have checked the issue more deeply with two different routers and two different homes that get internet feed My home use Cable modem that on its DMZ sit a MikroTik Router . Even when the cable modem set to no DMZ at all i still get amprnet traffic to my home and all is working fine but if i point on the DMZ to a PC that have a web server and from outside world surf to my publiic IP i get the web server respond but if i shut the DMZ the web server is not answering to requests anymore so the DMZ mechanism, is functioning but it turn out that for the ipip tunnel the DMZ dont effect at all it has been tested with two different modems in two different internet feeds and two AMPRNET networks my cable modem modem work as a Router and do NAT for the Internet to Private addresses (192.168.1.x) and the MOkroTik router sit on this address and do the IPIP tunnel to UCSD The other home use modem that is used as a transparent mode and connected to first mikrotik that makes the NAT for the Private network (10.0.0.x) and after this modem there is additional mikrotik that do the IPIP to UCSD and it work without any DMZ or Port redirection I dont know to explain it but that is the facts and its hard to argue with that currently at my home the DMZ point to a computer that do Echolink bridge to our NatoinWide DMR system and not to the router that do the IPIP and i have a working AMPRNET .... Regards Ronen -4Z4ZQ ________________________________ From: 44Net <44net-bounces+ronenp=hotmail.com(a)mailman.ampr.org> on behalf of Michael Cullen via 44Net <44net(a)mailman.ampr.org> Sent: Tuesday, May 21, 2019 7:09 AM To: AMPRNet working group Cc: Michael Cullen Subject: Re: [44net] UCSD tunnel behing NAT and Firewall setting ? _________________________________________ 44Net mailing list 44Net(a)mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net

1 0

Re: [44net] Portal API
by G1FEF 21 May '19

21 May '19

Hi Nate, I can certainly add this to the TODO list if it is of interest. Regards, Chris > On 13 May 2019, at 22:22, Nate Sales via 44Net <44net(a)mailman.ampr.org> wrote: > > > From: Nate Sales <nate.wsales(a)gmail.com> > Subject: Portal API > Date: 13 May 2019 at 22:22:55 BST > To: AMPRNet working group <44net(a)mailman.ampr.org> > > > Hello, > Is there any plan to make the API more complete? It would be really cool to > be able to update gateways and such programatically. > 73, > -Nate > > > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

1 0

Re: [44net] UCSD tunnel behing NAT and Firewall setting ?
by Michael Cullen 21 May '19

21 May '19

I use IPIP behind a NAT by forwarding all IPIP traffic to a particular host - it’s a separate protocol so quite easy to do actually. On Mon, 20 May 2019 at 17:18, Steve L via 44Net <44net(a)mailman.ampr.org> wrote: > > > > ---------- Forwarded message ---------- > From: Steve L <kb9mwr(a)gmail.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Mon, 20 May 2019 11:14:45 -0500 > Subject: Re: [44net] UCSD tunnel behing NAT and Firewall setting ? > IPIP requires Protocol 4 forwarding (or DMZ) at the firewall to the > gateway. > > OpenVPN handshakes are about every 5 seconds, between the client and > server. The client creates and maintains an active connection to the > server at all times. This allows the server to track a reverse way > back to the client. > > Since we are decentralized, meaning we don't all reach each other thru > a central server, we'd have to have maintain handshaking to each other > ampr gateway. I forget what Brian last said there were in terms of a > number of IPIP gateways, but that would obviously be a lot of data, > and thus not practical. > > The only other VPN like architecture that I know of that works like > what we are doing is Tinc, as it supports mesh routing too. But I > haven't played with it yet. > > Your other option is to setup a VPS, bring in a subnet via BPG, and > then used whatever method you like (OpenVPN, etc) to bring it from the > VPS to your firewall restricted gateway. A solution that John, K7VE > has been pointing out (https://groups.io/g/net-44-vpn) > > Steve > > > On Mon, May 20, 2019 at 1:41 AM R P via 44Net <44net(a)mailman.ampr.org> > wrote: > > ---------- Forwarded message ---------- > > From: R P <ronenp(a)hotmail.com> > > To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org> > > Cc: > > Bcc: > > Date: Mon, 20 May 2019 06:37:54 +0000 > > Subject: UCSD tunnel behing NAT and Firewall setting ? > > Hi there > > I know that VPN can be done behind firewall NAT (from the client side) > > Can the IPIP be made (from the gateway side) behind a Firewall (that > allow any traffic outbound) and a NAT ? > > Untill few month ago my gateway sited on the DMZ and it worked > > But i had changed the DMZ to point another IP and it seems that the > IPIP still work .. I wonder if it is a router problem or the IPIP can > pass thru like a VPN can pass > > Thanks For any Info > > ronen- 4Z4ZQ > > > > ---------- Forwarded message ---------- > From: Steve L via 44Net <44net(a)mailman.ampr.org> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: Steve L <kb9mwr(a)gmail.com> > Bcc: > Date: Mon, 20 May 2019 11:14:45 -0500 > Subject: Re: [44net] UCSD tunnel behing NAT and Firewall setting ? > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

1 0

Re: [44net] UCSD tunnel behing NAT and Firewall setting ?
by Steve L 20 May '19

20 May '19

IPIP requires Protocol 4 forwarding (or DMZ) at the firewall to the gateway. OpenVPN handshakes are about every 5 seconds, between the client and server. The client creates and maintains an active connection to the server at all times. This allows the server to track a reverse way back to the client. Since we are decentralized, meaning we don't all reach each other thru a central server, we'd have to have maintain handshaking to each other ampr gateway. I forget what Brian last said there were in terms of a number of IPIP gateways, but that would obviously be a lot of data, and thus not practical. The only other VPN like architecture that I know of that works like what we are doing is Tinc, as it supports mesh routing too. But I haven't played with it yet. Your other option is to setup a VPS, bring in a subnet via BPG, and then used whatever method you like (OpenVPN, etc) to bring it from the VPS to your firewall restricted gateway. A solution that John, K7VE has been pointing out (https://groups.io/g/net-44-vpn) Steve On Mon, May 20, 2019 at 1:41 AM R P via 44Net <44net(a)mailman.ampr.org> wrote: > ---------- Forwarded message ---------- > From: R P <ronenp(a)hotmail.com> > To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Mon, 20 May 2019 06:37:54 +0000 > Subject: UCSD tunnel behing NAT and Firewall setting ? > Hi there > I know that VPN can be done behind firewall NAT (from the client side) > Can the IPIP be made (from the gateway side) behind a Firewall (that allow any traffic outbound) and a NAT ? > Untill few month ago my gateway sited on the DMZ and it worked > But i had changed the DMZ to point another IP and it seems that the IPIP still work .. I wonder if it is a router problem or the IPIP can pass thru like a VPN can pass > Thanks For any Info > ronen- 4Z4ZQ

1 0

UCSD tunnel behing NAT and Firewall setting ?
by R P 20 May '19

20 May '19

Hi there I know that VPN can be done behind firewall NAT (from the client side) Can the IPIP be made (from the gateway side) behind a Firewall (that allow any traffic outbound) and a NAT ? Untill few month ago my gateway sited on the DMZ and it worked But i had changed the DMZ to point another IP and it seems that the IPIP still work .. I wonder if it is a router problem or the IPIP can pass thru like a VPN can pass Thanks For any Info 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

Hacked webcam?
by Rob Janssen 15 May '19

15 May '19

To whom it may concern: It looks like the system at 44.170.109.92, DNS name 9a5c-webcam.ampr.org, has been affected by a worm of some kind. It is scanning the IP space to find new victims. Another thing is that the routing to here is strange. It appears to be on BGP routed space, but the traffic is received via IPIP tunnel. (so it is being rejected anyway, but that is how I encountered it in the logs) Rob

2 1

Re: [44net] 44Net Digest, Vol 8, Issue 81
by Roger Andrews 14 May '19

14 May '19

Brian, Thanks for noticing that block. Unfortunately, something is still blocking Google. Their “Live Test” still comes back with a crawl anomaly. In they documents they claim that their bots can come from a wide array of ip addresses and that they don’t publish them. Is it possible that there is another ip or block that has been blocked off, that you might be able to be opened. At least long enough to see if that fixes the problem. Google won’t say what all their googlebot IPs are but I found this: Known Googlebots: 64.233.160.0 64.233.191.255 66.102.0.0 66.102.15.255 66.249.64.0 66.249.95.255 72.14.192.0 72.14.255.255 74.125.0.0 74.125.255.255 209.85.128.0 209.85.255.255 216.239.32.0 216.239.63.255 Google owns these (maybe google bots) 64.18.0.0/20 64.18.0.0 - 64.18.15.255 64.233.160.0/19 64.233.160.0 - 64.233.191.255 66.102.0.0/20 66.102.0.0 - 66.102.15.255 66.249.80.0/20 66.249.80.0 - 66.249.95.255 72.14.192.0/18 72.14.192.0 - 72.14.255.255 74.125.0.0/16 74.125.0.0 - 74.125.255.255 108.177.8.0/21 108.177.8.0 - 108.177.15.255 172.217.0.0/19 172.217.0.0 - 172.217.31.255 173.194.0.0/16 173.194.0.0 - 173.194.255.255 207.126.144.0/20 207.126.144.0 - 207.126.159.255 209.85.128.0/17 209.85.128.0 - 209.85.255.255 216.58.192.0/19 216.58.192.0 - 216.58.223.255 216.239.32.0/19 216.239.32.0 - 216.239.63.255 2001:4860:4000::/36 2001:4860:4000:0:0:0:0:0 - 2001:4860:4fff:ffff:ffff:ffff:ffff:ffff 2404:6800:4000::/36 2404:6800:4000:0:0:0:0:0 - 2404:6800:4fff:ffff:ffff:ffff:ffff:ffff 2607:f8b0:4000::/36 2607:f8b0:4000:0:0:0:0:0 - 2607:f8b0:4fff:ffff:ffff:ffff:ffff:ffff 2800:3f0:4000::/36 2800:3f0:4000:0:0:0:0:0 - 2800:3f0:4fff:ffff:ffff:ffff:ffff:ffff 2a00:1450:4000::/36 2a00:1450:4000:0:0:0:0:0 - 2a00:1450:4fff:ffff:ffff:ffff:ffff:ffff 2c0f:fb50:4000::/36 2c0f:fb50:4000:0:0:0:0:0 - 2c0f:fb50:4fff:ffff:ffff:ffff:ffff:ffff I will certainly be very respectful of the bandwidth. As I said before, we really don’t get a lot of hits and the site is more for our members than anyone else (plus the occasional new person wanting to join). Someone mentioned that my page size is a bit large. Yes, I do have some Javascript and it does make it appear as though the page size is 3mb, but that is a deceptive assessment. That 3mb includes a jQuery library, that most people already have in their cache, since so many people are using jQuery. In actual fact, if jQuery is on your machine (Likely) the actual page size is in the mid kbs. A quote from jQuery Doc: "If you serve jQuery from a popular CDN such as Google's Hosted Libraries or cdnjs, it won't be redownloaded if your visitor has been on a site that referenced it, from the same source (as long as the cached version has not expired).” Thanks for trying to help me resolve this. Roger VA7LBB > On May 14, 2019, at 12:00 PM, 44net-request(a)mailman.ampr.org wrote: > > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > Today's Topics: > > 1. Portal API (Nate Sales) > 2. Re: Google indexing (Brian Kantor) > 3. Re: Google indexing (Rob Janssen) > > From: Nate Sales <nate.wsales(a)gmail.com> > Subject: Portal API > Date: May 13, 2019 at 2:22:55 PM PDT > To: AMPRNet working group <44net(a)mailman.ampr.org> > > > Hello, > Is there any plan to make the API more complete? It would be really cool to > be able to update gateways and such programatically. > 73, > -Nate > > > > > From: Brian Kantor <Brian(a)bkantor.net> > Subject: Re: [44net] Google indexing > Date: May 13, 2019 at 2:25:38 PM PDT > To: AMPRNet working group <44net(a)mailman.ampr.org> > > > On Mon, May 13, 2019 at 11:58:18AM -0700, Roger wrote: >> I wanted to thank everyone for their help with the google issue I’m having. It is not resolved but I’ve made some discoveries. It looks like a fair number of the ampr.org sites that come up on google may in fact be done via BGP. Rob’s is and the others that I did a traceroute on, terminate on an address that is not 44. >> But that said, I now think this is a 100% Google issue. I don’t know what kind of stupidity they are up to but Yandex and Bing, have no problems indexing my site. I have read of others having similar issues. Bing and Yandex actually use Google’s same system for verification and they crawl just fine. >> >> 73 >> Roger >> VA7LBB > > After Roger mentioned that AMPRNet BGP-advertised web sites were > getting indexed, but not very many others, and then someone posted > that Google's indexing bots often run in the IP address range > 66.249.x.x, I took a look at the ingress filter in amprgw. > > 66.249.90.x and 66.249.91.x were indeed blocked. > > I have unblocked them. Roger, you may see Google crawling your web > site from addresses in those subnets now. If you have some way to > stimulate them to do so, you might want to try that. > > I don't know how among many possible ways that those addresses got > on the blocking list, as it was too long ago for the current logs > to reflect it. > - Brian > > > > > > > From: Rob Janssen <pe1chl(a)amsat.org> > Subject: Re: [44net] Google indexing > Date: May 14, 2019 at 11:01:09 AM PDT > To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org> > > >> 66.249.90.x and 66.249.91.x were indeed blocked. > > Ahh... that explains a lot! > >> I don't know how among many possible ways that those addresses got >> on the blocking list, as it was too long ago for the current logs >> to reflect it. > > Maybe there was "a lot" of traffic? Possibly also "a lot" in terms of those days. > > But of course everyone running a website on an IPIP tunneled ampr.org site has some > responsibility in this. Make sure when you have areas with lots of data, those large > files are not indexed. This can be done using robots.txt files, headers in the page > content, etc. > > E.g. you run a site with equipment schematics. You have some text pages with indexes > and a lot of huge PDF files with the scanned schematics themselves. It is not difficult > to make Google (and other crawlers) index only the text index files and not the PDFs. > > Or you have a local amateur group site and it has lots of photographs and maybe even > video of the fieldday or other events. It is possible to make the huge 30-megapixel > photographs and the video not being indexed and only index the text content and maybe > the thumbnails. > > When this is done in a responsible manner, indexing the websites that are behind IPIP > tunnels should not cause much more "useless traffic" than there already is due to > jerks like shodan.io, stretchoid.com and the like. > (those are scanning the entire IP range, not just websites that have been announced > to Google or are linked from other sites) > > Rob > > > > > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

1 0

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

14 May '19

> 66.249.90.x and 66.249.91.x were indeed blocked. Ahh... that explains a lot! > I don't know how among many possible ways that those addresses got > on the blocking list, as it was too long ago for the current logs > to reflect it. Maybe there was "a lot" of traffic? Possibly also "a lot" in terms of those days. But of course everyone running a website on an IPIP tunneled ampr.org site has some responsibility in this. Make sure when you have areas with lots of data, those large files are not indexed. This can be done using robots.txt files, headers in the page content, etc. E.g. you run a site with equipment schematics. You have some text pages with indexes and a lot of huge PDF files with the scanned schematics themselves. It is not difficult to make Google (and other crawlers) index only the text index files and not the PDFs. Or you have a local amateur group site and it has lots of photographs and maybe even video of the fieldday or other events. It is possible to make the huge 30-megapixel photographs and the video not being indexed and only index the text content and maybe the thumbnails. When this is done in a responsible manner, indexing the websites that are behind IPIP tunnels should not cause much more "useless traffic" than there already is due to jerks like shodan.io, stretchoid.com and the like. (those are scanning the entire IP range, not just websites that have been announced to Google or are linked from other sites) Rob

1 0

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

13 May '19

Hi All! I wanted to thank everyone for their help with the google issue I’m having. It is not resolved but I’ve made some discoveries. It looks like a fair number of the ampr.org sites that come up on google may in fact be done via BGP. Rob’s is and the others that I did a traceroute on, terminate on an address that is not 44. But that said, I now think this is a 100% Google issue. I don’t know what kind of stupidity they are up to but Yandex and Bing, have no problems indexing my site. I have read of others having similar issues. Bing and Yandex actually use Google’s same system for verification and they crawl just fine. 73 Roger VA7LBB On May 9, 2019, at 02:09, Rob Janssen <pe1chl(a)amsat.org> wrote: >> Now that I know where to look.. PMTU has caused me a lot of headache >> lately. I believe it could be the problem. Sending large packets to >> 44.135.179.28 yields no reply. tracepath does send back need to frag, >> but when TTL expires at amprgw.ucsd.edu. I believe amprgw.ucsd.edu >> should send back need-to-frag for higher TTLs as well. > > That is always a bit tricky, often those packets *are* sent back but they > are blocked somewhere closer to the client, and/or the TCP stack of the > system does not process them in a reasonable way. > > It is possible to work around that by adjusting the MSS of a TCP SYN > passing the point where outgoing MTU is smaller than incoming MTU > (incidentally something that I invented and implemented in NET in 1995, > but later almost any router and routing software started to support it) > so as a result the TCP segments sent by the endpoints will be smaller and > won't need to be fragmented. > > Roger can do that on his own server, e.g. like this: > > iptables -t mangle -A INPUT -p tcp --syn -j TCPMSS --set-mss 1400 > iptables -t mangle -A OUTPUT -p tcp --syn -j TCPMSS --set-mss 1400 > > Or on a router/gateway along the path (using FORWARD instead of INPUT/OUTPUT). > > However, I'm not convinced that this is the problem as the site works OK > for me over internet. Why wouldn't it work for Google then? > > Rob > >

2 1

Portal API
by Nate Sales 13 May '19

13 May '19

Hello, Is there any plan to make the API more complete? It would be really cool to be able to update gateways and such programatically. 73, -Nate

1 0

Re: [44net] VPN Question
by Rob Janssen 11 May '19

11 May '19

> we have a very similar system here in Italy. Nice! > looking at the high number of access requests, in the end, > the actual number of OMs whom is using the system is very low. > Many of them looses interest or request the access just as a "nice to > have". That is always a bit of a problem. People ask for a certificate, connect to the server and then they think "well, what do I do next?" or "what can I do now that I cannot do on internet?". There are some information sites having small lists of sites that can be visited and some search engines, and I have proposed to setup a more standardized and automated website to find running services and a description what they offer, but I do not consider it my task (as an address coordinator and admin for part of the systems) to build and maintain that. Others can pick up that part of the work. Without a clear description of what we can do with the network, it is not surprising that not everybody keeps using it. But it looks like you have quite some connected users too! Good! Rob

1 0

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

11 May '19

Thanks everyone for the MTU discussion/ suggestions on the google issues. I’ll try adjusting the MTU. The https issue only just started. I had a letsencrypt certificate and auto-renew screwed up and I haven’t had a chance to fix it. That wasn’t a problem when I started this google thread, so won’t be the main issue with google. Roger. VA7LBB On May 9, 2019, at 04:35, Scott Nicholas <scott.nicholas(a)scottn.us> wrote: >> However, I'm not convinced that this is the problem as the site works OK >> for me over internet. Why wouldn't it work for Google then? > > We have to speculate somewhat..I don't know what the crawler uses for > TCP stack. I know each OS is different in the ways it deals with MTU > and blackholes. > I did a wireshark capture on my Windows desktop and show a lot of > black/red. I lowered my MTU by 40 and re-tried and there was lots of > green. > The TCP MSS coming from the web server was already lowered by 20. I > don't know what it looks like on the far end. I'm also speculating > that it's not getting ICMP or seeing a lower MSS for me. > > Another reason I saw red -- a few links point to HTTPS and it is not > enabled. Fix that, and set a lower MTU on the host, and we'll at > least fix *some* problem. Maybe not the Googling indexing one. :) > > Regards, > Scott >

1 0

Re: [44net] VPN Question
by Steve L 11 May '19

11 May '19

Nate, Sorry, I'll have to update that page to make it more clear. The purpose of it for setting up your own Open VPN server that uses LoTW certificates to mimic what Heikki is doing. When you are running a sever then obviously you are in control of the address range it offers as part of the dynamic assignment. When you are the client/ end-user then obviously no. Steve, KB9MWR On Fri, May 10, 2019 at 7:27 PM Nate Sales via 44Net <44net(a)mailman.ampr.org> wrote: > > > > > ---------- Forwarded message ---------- > From: Nate Sales <nate.wsales(a)gmail.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: > Bcc: > Date: Fri, 10 May 2019 17:24:47 -0700 > Subject: Re: [44net] VPN Question > Thank you for explaining, I totally misunderstood the purpose. Either way, > thanks for the quick responses, I really appreciate it. I was mainly > looking at https://qsl.net/k/kb9mwr//wapr/tcpip/lotw-vpn.html which led me > to believe that was possible. > -Nate > > > On Fri, May 10, 2019 at 2:28 PM Heikki Hannikainen <hessu(a)hes.iki.fi> wrote: > > > > > Hi, > > > > No. If you're using ipencap to join the amprnet tunnel mesh, you don't > > need to use my VPN service. > > > > If you use the VPN, you can't use ipencap at the same time. > > > > With the VPN you get a single tunnel to the Amprnet, and you'll be > > assigned a dynamic 44.139.11.x IP address during the VPN session. > > > > It is not possible to route your own 44.x.y.z subnet via this VPN. You're > > limited to communicating with the dynamic 44.139.11.x address assigned to > > you by the VPN server. Sorry! > > > > > > On Fri, 10 May 2019, Nate Sales wrote: > > > > > Ok thank you! So the ip in the 44.139.11.x range becomes the gateway, > > then > > > just set up ipencap like normal? > > > -Nate > > > > > > On Fri, May 10, 2019 at 8:29 AM Heikki Hannikainen <hessu(a)hes.iki.fi> > > wrote: > > > > > >> On Thu, 9 May 2019, Ruben ON3RVH wrote: > > >> > > >>> If the subnet is routed to the openvpn server, the openvpn server can > > >>> route that network to the endpoint. > > >> > > >> This particular openvpn server (that I run) does not offer such a > > service. > > >> It allows you to get connected to AMPRnet, but I don't have the time to > > do > > >> custom configurations to route subnets or do other per-user manual > > >> tweaking at this time. > > >> > > >> So, Rob's "You can't" answer is correct. You'll get the dynamic > > >> 44.139.11.x IP address and you can use that to communicate with the > > >> amprnet. Sorry! > > >> > > >> - Hessu > > >> > > >> > > >>> On 9 May 2019, at 11:14, Rob Janssen <pe1chl(a)amsat.org> wrote: > > >>> > > >>>>> I cant figure out where to go > > >>>>> from here. Can anyone point me in the right direction in how to get > > the > > >>>>> routes set up for my little subnet? > > >>>> > > >>>> You can't. > > >>>> Such a VPN offers you a connection, with an IP, and routes traffic for > > >> that IP to you. > > >>>> You cannot route arbitrary subnets over that because you cannot setup > > >> routes on the VPN server > > >>>> pointing to your subnet. > > >>>> > > >>>> If that is what you want, you need to setup a gateway on the IPIP > > >> tunnel mesh. > > >>>> Or, find someone else who has done that and arrange for some VPN > > >> between you two. > > >>>> > > >>>> Rob > > >> > > >> _________________________________________ > > >> 44Net mailing list > > >> 44Net(a)mailman.ampr.org > > >> https://mailman.ampr.org/mailman/listinfo/44net > > >> > > > > > > > - Hessu > > > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net > > > > > > ---------- Forwarded message ---------- > From: Nate Sales via 44Net <44net(a)mailman.ampr.org> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Cc: Nate Sales <nate.wsales(a)gmail.com> > Bcc: > Date: Fri, 10 May 2019 17:24:47 -0700 > Subject: Re: [44net] VPN Question > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

1 0

Re: [44net] VPN Question
by Rob Janssen 11 May '19

11 May '19

> Correct. Your approach saves you a lot of work in maintaining custom > configs. They are a lot of work, if you have a lot of users. Indeed. We offer OpenVPN connectivity to our local hams (the Netherlands) using certificates created especially for that. The users get their fixed IP derived from the certificate subject name (looked up in DNS/hosts) so they also can run services under their own callsign. There are 220 valid certificates at this time, and always about 20 systems connected plus those that connect when required. Those that want to route subnets can get a GRE(6) or L2TP/IPsec tunnel and run BGP over that. There currently are 34 users of that service, 30 of them are connected. This mode is also used to provide connectivity to regional clusters of systems that are not yet connected by radio all over our country. It requires some one-time setup but at least there is no maintenance when users want to announce more subnets etc. Of course more systems like this could be setup in other countries/regions to serve those that are on dynamic IP, are behind CGNAT, can only use IPv6, etc. A "cloud" hosted Linux (virtual) machine with a fixed IP is all that you really require, a service from the ISP to BGP-announce a subnet and route that to you is a good addition. Alternatively you could use something like a MikroTik, Edgerouter or Juniper instead of the Linux VM. A little less flexible in some areas but easier to setup and maintain. Rob

2 1

Re: [44net] VPN Question
by Rob Janssen 11 May '19

11 May '19

> I cant figure out where to go > from here. Can anyone point me in the right direction in how to get the > routes set up for my little subnet? You can't. Such a VPN offers you a connection, with an IP, and routes traffic for that IP to you. You cannot route arbitrary subnets over that because you cannot setup routes on the VPN server pointing to your subnet. If that is what you want, you need to setup a gateway on the IPIP tunnel mesh. Or, find someone else who has done that and arrange for some VPN between you two. Rob

5 7

VPN Question
by KJ7DMC 10 May '19

10 May '19

Hello, I have obtained the certificates and have openvpn all set up. I am able to connect, and I see the interface like so: 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 44.139.11.14 peer 44.139.11.13/32 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::302f:bedc:d77a:c5d6/64 scope link flags 800 valid_lft forever preferred_lft forever Now I'm a bit stuck. I've consulted a few posts, both www.qsl.net/kb9mwr/wapr/tcpip/lotw-vpn.html and www.qsl.net/kb9mwr/wapr/tcpip/oh7lzb.html but I cant figure out where to go from here. Can anyone point me in the right direction in how to get the routes set up for my little subnet? Thanks so much and 73, -Nate

2 1

Re: [44net] IPv6 on RF - was: 44 net value
by Rob Janssen 10 May '19

10 May '19

> While both my node software and my servers are all dual stacked as well, > the issue with using IPv6 on RADIO (UHF/VHF/HF) is a bit of a challenge > but do-able. Of couse "over radio" is not the same thing as "over AX.25"... These days, radio links on our net-44 network are mostly/all WiFi links and they would have no issue with IPv6. AX.25 and IPv6 have other incompatibilities than ARP. The minimum MTU requirement and the concern about efficiency at low bitrates are other things to worry about. But what is mainly holding me back to deploy IPv6 now is: - double effort of network administration for dual-stack - limited support in our favourite routers (MikroTik) - lack of immediate need, because we have not run out of IPv4 space and can still assign usable subnets to everyone who wants them (so no NAT required) So while I do have IPv6 deployed here at home, I while I don't rule out the deployment of IPv6 on our radio network, I don't consider it a high-priority thing. When doing it, I would get a /48 from our ISP, and then make a 1:1 mapping between already assigned IPv4 addresses within 44.137.0.0/16 and /64 nets within that space. So everyone who has a single address gets a corresponding /64 net and everyone who has a /28 subnets gets a /60 from that, without requiring any mechanism other than a simple document explaining the mapping. All places where IPv4 addresses and networks have been configured would get the corresponding IPv6 address. Probably I would go with encoding callsigns and service names into the lower 64 bits as proposed by Daniel EA4GPZ. And for distributing a "list of valid prefixes" amongst those that would like to be able to classify addresses as "within AMPRnet" or "outside AMPRnet" (now done by checking for 44.0.0.0/8, which of course does not really work as Brian Kantor already mentioned), I would propose setting up multihop BGP peering using private AS numbers between gateway hosts that want to advertise (and receive) the list of prefixes. But again, it is not on my list of things to do this year. Keeping everyone focused on building a working and expanding IPv4 network is more important, IMHO. Rob

5 4

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

09 May '19

> Now that I know where to look.. PMTU has caused me a lot of headache > lately. I believe it could be the problem. Sending large packets to > 44.135.179.28 yields no reply. tracepath does send back need to frag, > but when TTL expires at amprgw.ucsd.edu. I believe amprgw.ucsd.edu > should send back need-to-frag for higher TTLs as well. That is always a bit tricky, often those packets *are* sent back but they are blocked somewhere closer to the client, and/or the TCP stack of the system does not process them in a reasonable way. It is possible to work around that by adjusting the MSS of a TCP SYN passing the point where outgoing MTU is smaller than incoming MTU (incidentally something that I invented and implemented in NET in 1995, but later almost any router and routing software started to support it) so as a result the TCP segments sent by the endpoints will be smaller and won't need to be fragmented. Roger can do that on his own server, e.g. like this: iptables -t mangle -A INPUT -p tcp --syn -j TCPMSS --set-mss 1400 iptables -t mangle -A OUTPUT -p tcp --syn -j TCPMSS --set-mss 1400 Or on a router/gateway along the path (using FORWARD instead of INPUT/OUTPUT). However, I'm not convinced that this is the problem as the site works OK for me over internet. Why wouldn't it work for Google then? Rob

2 1

Edgerouter Setup
by Ray Quinn 09 May '19

09 May '19

I have followed Marius' instructions and have my EdgeRouter X working and passing traffic via 44net. Thank you, Marius! My issue is this: I am using 44.2.10.1 for the tunnel, 44.2.10.2 for the computer (a Raspberry Pi 3), and 44.2.10.3 for JNOS using a point to point tunnel. I have the following routing in the EdgeRouter: w6ray@edgerouter:~$ sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 104.49.12.134 0.0.0.0 UG 0 0 0 eth1 44.2.10.0 0.0.0.0 255.255.255.248 U 0 0 0 eth2 44.2.10.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun44 44.2.10.8 44.2.10.9 255.255.255.248 UG 0 0 0 eth3 104.49.12.128 0.0.0.0 255.255.255.248 U 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 44.2.10.0/29 eth2 is for the local 44net. I use the 44.2.10.8/29 on eth3 for the Ubiquity microwave link to the repeater site where the TNC's and radios are, among other things (DSTAR, DMR, etc.) I can use the link's LAN 172.16.0.0/16 instead of the 44.2.10.8/29, I just need to figure out how to route traffic. (The link radios have IP aliases in the 44.2.10.8/29) I do not wish these to be accessible outside my network. The 104.49.12.128/29 on eth0 is my public network address. 192.168.1.0/24 on eth0 is so I can access the Edgerouter from the local LAN. While I would like for JNOS to be accessible outside 44net, it is not required. I would like to allow our local hams who do not have a TNC access. I would, however, like to be able to access the Internet from the Pi (44.2.10.2) so I can use my browser to do searches, and update the OS via apt. My question is "How do I accomplish this? Do I have the EdgeRouter X set up correctly with the proper address(es)? SJVBBS w6ray.ampr.org -- --- If the right side of the brain controls the left side of the body, then only left-handed people are in their right minds. _____ , |[][]| ,__| ______| | ,__/__]|| ________ | D8 | |__!___!!`--'L_______\ |__________|() ___________ "(_)[___]====(_)(_)=| \_(___________)_/__/=(_)===(_)~' 73 de Ray Quinn W6RAY GMRS - WQTX645 Visalia, CA USA DM06ii

2 1

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

09 May '19

Oops! I don’t know why all of a sudden my phone picked a different address. Strange. Anyway. Sorry. Roger VA7LBB > On May 8, 2019, at 18:07, Roger <ve7wwd(a)rezgas.com> wrote: > > Hi all, > Just a reminder that Google has already told me where the issue originated. It’s not with content. It’s not with speed. It’s not the time my site has been up. It’s an anomaly between google and me. They just can’t or won’t tell me what that anomaly is. But it has nothing to do with content or anything like that. > > Roger. > >> On May 7, 2019, at 16:56, David McAnally <david.mcanally(a)gmail.com> wrote: >> >> Roger, >> >> May I suggest looking at your web site home page load / rendering >> performance? I tried loading your page in the Google Page speed Insights >> <https://developers.google.com/speed/pagespeed/insights/> tool. It will >> not complete loading your URL for analysis, returning the much too common >> NO_FCP error message. (see their tool's references for details on FCP. I >> was able to load your URL in the analyze.websiteoptimization.com tool, >> which shows the page is almost 3MB in size, mostly images and javascript, >> which may be slowing the page load/rendering. While 3MB may not seem all >> that much in today's fast networks, home page size and load times have been >> known to cause crawling index systems to skip the site due their limited >> budget in time and resources. Poor performance scripting can be an issue >> too. If your network route to users, or in this case analysis tool, crosses >> a slower network gateway, the size of your page and content rendering >> performance could have even more impact. Don't know if improving page >> performance will make Google indexing happier, but can't hurt to try. >> >> At one time I had access to better tools for web site analysis, but I've >> retired, so I no longer get to play with that stuff. >> >> Regards, >> David M. >> WD5M >> > >

2 1

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

08 May '19

David, I thought of that and last week for 4 days I had nothing but a simple index.html (everything else moved out) the google tool did the same thing with a 3kb page. Yet the siteliner.com tool (which is very similar) does not return that error on the large page, and in fact analyses the site very quickly. I’m starting to suspect this is all Google’s problem. > On May 7, 2019, at 16:56, David McAnally <david.mcanally(a)gmail.com> wrote: > > Roger, > > May I suggest looking at your web site home page load / rendering > performance? I tried loading your page in the Google Page speed Insights > <https://developers.google.com/speed/pagespeed/insights/> tool. It will > not complete loading your URL for analysis, returning the much too common > NO_FCP error message. (see their tool's references for details on FCP. I > was able to load your URL in the analyze.websiteoptimization.com tool, > which shows the page is almost 3MB in size, mostly images and javascript, > which may be slowing the page load/rendering. While 3MB may not seem all > that much in today's fast networks, home page size and load times have been > known to cause crawling index systems to skip the site due their limited > budget in time and resources. Poor performance scripting can be an issue > too. If your network route to users, or in this case analysis tool, crosses > a slower network gateway, the size of your page and content rendering > performance could have even more impact. Don't know if improving page > performance will make Google indexing happier, but can't hurt to try. > > At one time I had access to better tools for web site analysis, but I've > retired, so I no longer get to play with that stuff. > > Regards, > David M. > WD5M >

1 0

Re: [44net] 44Net Digest, Vol 8, Issue 74
by Roger Andrews 08 May '19

08 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. Eventually according to Google, they will fall off their indexing. Google indexing can no longer reach them or any new site. It doesn’t matter if you have links, Google can’t index ampr.org <http://ampr.org/> subdomains so when it follows thew link, it’ll fail to index. And here is how I know that: 1) I created the Gateway. 2) I created the website separs.ampr.org <http://separs.ampr.org/> 3) I logged into the “Google Search Console” 4) I could not have Google verify site ownership. It seemed block to them. 5) I asked Brian to add a TXT entry, as per the Google Search console instructions. 6) Initialy Brian did not want to do it, saying he didn’t want Google crawling all the 44net IPs 7)I assured him that it was only for site verification and they would only crawl my site. 8) he agreed and through the Google Search Console I had the site ownership Verified. 9)I attempted to have the Google Search Console crawl the site. It declined indicating "no errors" but an “anomaly” 10) I tried quite a few times: a) as the site is now (declined “anomoly”). b) I tried with deleted my robots file. (declined “anomoly”) c) I tried by removing everything in my public_html directory and added only a file index.html file (declined “anomaly”) 11) I added a sitemap.xml to the search console (and the Google Search Console downloaded it. It then said it would not index because of an “anomoly” . 12) The Google Search Console will not index and always says it is due to an “anomoly” It makes it clear it is "not an error". The site is accessible, but an “anomoly” stops the index. 13) This is where I contacted "my friend” (more of an associate rally) and I asked her what an “anomoly” would be. She checked and said the “anomoly” is related to either DNS, Meta header, or robots.txt in the TDL (ampr.org <http://ampr.org/>) preventing Google from indexing. She made it clear that Google tries very hard to honor any setting that suggests the site does not want indexing. So that’t where the “friend” comes into play. I’m sure you all know that under normal circumstances there is no possibility to contact Google. I was fortunate I had someone I could ask. I’d hoped her information would help sort this out. 14) She also advised me that a quick look at ampr.org <http://ampr.org/> subdomains that have been indexed (those that you’ve suggested prove indexing works) are well over 1 year old (usually 2 or more.) Those sites will not be reindexed as things stand today, unless the “anomoly” is corrected. New sites will not be indexed - ever! (unless something changes and regardless of how many links you have on other sites) I couldn’t get her to tell me exactly what the problem is because I don’t own ampr.org <http://ampr.org/>. Probably because she is only an associate that I met twice and doesn’t really know me that well. I don’t own ampr.org <http://ampr.org/> after all. So I’m hoping this clarified the issue. Please add your own site to the search console and see what I mean. If you can get it to index, then I’d like to know what is different between yours and mine. 73 Roger VA7LBB > On May 6, 2019, at 12:00 PM, 44net-request(a)mailman.ampr.org wrote: > > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > Today's Topics: > > 1. Re: Google indexing (Rob Janssen) > 2. Re: 44Net VPN? (Heikki Hannikainen) > 3. Google indexing (lleachii) > > From: Rob Janssen <pe1chl(a)amsat.org> > Subject: Re: [44net] Google indexing > Date: May 6, 2019 at 2:27:24 AM PDT > To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org> > > >> 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 > > > > > > From: Heikki Hannikainen <hessu(a)hes.iki.fi> > Subject: Re: [44net] 44Net VPN? > Date: May 6, 2019 at 3:09:50 AM PDT > To: AMPRNet working group <44net(a)mailman.ampr.org> > > > On Tue, 30 Apr 2019, KJ7DMC wrote: > >> Hello, >> This is sort of a follow up to my last email, which I ended up figuring >> out. This link, http://he.fi/amprnet-vpn/amprnet-vpn-win.zip to download >> the amprnet crt file is invalid. Any idea where I would obtain that file >> from? > > Hi, > > The download links for the VPN config files work again now. Sorry for the website outage; server migration taking a bit longer than expected due to Real Life Events (TM). :) > > The included certificates are signed with weaker-than-desired hash algorithms, and modern TLS/VPN software are beginning to reject them. I suppose I'll have to make new ones soon and publish new config files along with them. The security issue is not that huge on AMPRnet use, but it'd be nice if it worked out of the box. > > - Hessu > > > > > > From: lleachii <lleachii(a)aol.com> > Subject: Google indexing > Date: May 6, 2019 at 11:45:48 AM PDT > To: 44net(a)mailman.ampr.org > > > All,Don't these sites all appear to be indexed in the past?73,- LynwoodKB3VWG > null > > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

10 10

Re: [44net] Google indexing
by Brian Kantor 08 May '19

08 May '19

Note that large web pages being retried over an IPIP tunnel via UCSD are bound to encounter packet loss, which will greatly impact performance. It's not a high bandwidth path, folks. And never will be. - Brian On Tue, May 07, 2019 at 06:56:44PM -0500, David McAnally via 44Net wrote: > Date: Tue, 7 May 2019 18:56:44 -0500 > From: David McAnally <david.mcanally(a)gmail.com> > To: AMPRNet working group <44net(a)mailman.ampr.org> > Subject: Re: [44net] Google indexing > > Roger, > > May I suggest looking at your web site home page load / rendering > performance? I tried loading your page in the Google Page speed Insights > <https://developers.google.com/speed/pagespeed/insights/> tool. It will > not complete loading your URL for analysis, returning the much too common > NO_FCP error message. (see their tool's references for details on FCP. I > was able to load your URL in the analyze.websiteoptimization.com tool, > which shows the page is almost 3MB in size, mostly images and javascript, > which may be slowing the page load/rendering. While 3MB may not seem all > that much in today's fast networks, home page size and load times have been > known to cause crawling index systems to skip the site due their limited > budget in time and resources. Poor performance scripting can be an issue > too. If your network route to users, or in this case analysis tool, crosses > a slower network gateway, the size of your page and content rendering > performance could have even more impact. Don't know if improving page > performance will make Google indexing happier, but can't hurt to try. > > At one time I had access to better tools for web site analysis, but I've > retired, so I no longer get to play with that stuff. > > Regards, > David M. > WD5M

2 1

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

08 May '19

Pete, Mine is https with a valid letsencrypt. They will not index. Sent from my iPhone > On May 7, 2019, at 10:25, pete M <petem001(a)hotmail.com> wrote: > > If I am not crazy. Google wont index new web site if not https. > > Télécharger Outlook pour Android<https://aka.ms/ghei36> > > ________________________________ > From: 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> on behalf of Rob Janssen <pe1chl(a)amsat.org> > Sent: Tuesday, May 7, 2019 12:10:52 PM > To: 44net(a)mailman.ampr.org > Subject: Re: [44net] Google indexing > >> 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 > > > > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net >

2 1

Re: Gateway with Home router running OPENWRT ?
by lleachii＠aol.com 07 May '19

07 May '19

Ronen, I run OpenWrt as my home router and AMPR Gateway. I created a separate VLAN for AMPRLAN (per the Wiki). The routing information and configs are listed on the WIki. Ampr-ripd must be cross-compiled (information on Wiki). Otherwise, I can only assist by providing a copy if your CPU device target is apm821xx or ar71xx (your device appears to be a mips_mips32). Roger, VA7LBB also runs OpenWrt, he may have ampr-ripd compiled for another target already. I've ran OpenWrt on: Western Digital, X86_64, Meraki and MikroTik devices. I've never had stability issues with it. Although, your router's last supported version is 10.03, I would advise using a device that can run the current 18.06.2 and newer releases. Regarding LAN IPs, you can also customize NATs for any local IP you wish to use AMPR. Such a config is more complex, and I have not configured that for normal use. I wrote the wiki when only ampr-ripd or rip44d were available, using kmod-ipip allows you to firewall ALL traffic on the tunnel interface (your option). If you have another border router doing DMZ, just forward IPENCAP (IP Protocol No.4) to the OpenWrt device. If you have any more questions regarding the OpenWrt Wiki, let me know. 73, - Lynwood KB3VWG PS: https://openwrt.org/toh/hwdata/d-link/d-link_dsl-2650ubrud Per the Techdata page, your device only has 300 MHz processor, 32 MB RAM and 8 MB flash. You should be OK on flash; but CPU and RAM may be a limitation. Also be advised, OpenWrt doesn't fully support the closed source Broadcom WiFi driver.

1 0

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

07 May '19

John, and everyone else that says to just wait. It’s been 4-5 weeks at least. Again, I talked to google. They will not index. Sent from my iPhone > On May 7, 2019, at 11:00, K7VE - John <k7ve(a)k7ve.org> wrote: > > Google indexes both http and https sites -- it is giving more 'points' to > https (e.g. they rank higher in the index) -- the top result for site:*. > ampr.org is http://vkfaq.ampr.org which was last cached on April 8th. > (Note: https://vkfaq.ampr.org is returning a security cert for a different > site, the author should set up his server to return a proper cert for vkfaq > -- it can be obtained at https://letsencrypt.org, set up to auto renew the > cert). > > Setup your site in https://search.google.com/search-console and wait a few > days to see if it shows up. > > [I do some of this from time to time as part of my job running IT/Web > Development/Telecom for an eCommerce company - > https://mavericklabel.com/company/about-maverick.html] -- btw, if you need > ID stickers for your equipment, we also have https://idmystuff.com > > ------------------------------ > John D. Hays > K7VE > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> > <http://www.facebook.com/john.d.hays> >

1 0

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

07 May '19

It’s been 4 weeks, and yes they crawl. They are crawling mine daily. I can see that in the Google Search Console. They won’t index though and that’s the important bit. Roger On May 6, 2019, at 12:22, Rob Janssen <pe1chl(a)amsat.org> wrote: >> 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

Re: [44net] Google indexing
by Ruben ON3RVH 07 May '19

07 May '19

Time limit is when the content on the site was updated Ruben - ON3RVH > On 7 May 2019, at 19:37, Bill Vodall via 44Net <44net(a)mailman.ampr.org> wrote: > > <mime-attachment> > _________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net