- 44net - mailman.ardc.net

by Phil Karn

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

6 years

2
1
0 0

Re: [44net] amprhosts update

by Rob Janssen

> 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

6 years

2
1
0 0

Re: [44net] A few thoughts on recent developments

by Rob Janssen

> 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

6 years

1
0
0 0

amprhosts update

by Pedro Converso

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

6 years

1
0
0 0

Re: [44net] IPv6 adoption (was: address sale)

by Heikki Hannikainen

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

6 years

2
1
0 0

Re: [44net] 44.192/10 route looping observation

by Rob Janssen

> 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

6 years

1
0
0 0

44.192/10 route looping observation

by Phil Karn

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

6 years

2
1
0 0

Re: [44net] 44/8

by Bryan Fields

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

6 years

2
1
0 0

Reverse DNS broken

by Michael Fox - N6MEF

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 years

6
9
0 0

Re: [44net] Time to restructure the network?

by Rob Janssen

> 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

6 years

1
0
0 0

Re: [44net] Time to restructure the network?

by Rob Janssen

> 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

6 years

1
0
0 0

Re: [44net] Reverse DNS broken

by Rob Janssen

> 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

6 years

2
1
0 0

Re: [44net] Time to restructure the network?

by Borja Marcos

> 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

6 years

1
0
0 0

AMPRNet Address Sale

by Rob Janssen

>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

6 years

1
0
0 0

ARDC and AMPR Reform

by Bryan Fields

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

6 years

1
0
0 0

Re: [44net] Reverse DNS broken

by Roger

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

6 years

2
1
0 0

Re: [44net] Where amprhosts ?

by Pedro Converso

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 >

6 years

1
0
0 0

44/8 Not just for Amateur Radio anymore..

by Fredric Moses

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

6 years

2
1
0 0

Re: [44net] Where amprhosts ?

by Steve L

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

6 years

1
0
0 0

Where amprhosts ?

by Pedro Converso

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

6 years

1
0
0 0

Re: [44net] Reverse DNS for 44/8 broken

by Bryan Fields

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

6 years

3
2
0 0

Re: [44net] Reverse DNS for 44/8 broken

by Ron Economos

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

6 years

1
0
0 0

Reverse DNS for 44/8 broken

by Michael Fox - N6MEF

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 years

6
6
0 0

Setup Gateway on RB951 n2 Mikrotik

by Francesco Ciacco

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

6 years

1
0
0 0

Re: [44net] Hamnet Web Page List

by Andrzej

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).

6 years

1
0
0 0

Hamnet Web Page List

by Frederic Zulian

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

6 years

1
0
0 0

Re: Untangle

by lleachii＠aol.com

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

6 years

1
0
0 0

Re: [44net] Questions regarding usage off 44/8 parts outside of ampr.org

by Bryan Fields

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 years

6
5
0 0

Re: [44net] Questions regarding usage off 44/8 parts outside of ampr.org

by Brian Kantor

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

6 years

2
1
0 0

Questions regarding usage off 44/8 parts outside of ampr.org

by Holger Baust

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

6 years

1
0
0 0

Re: [44net] Untangle

by Jeff KC9WSJ

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>

6 years

7
6
0 0

Re: [44net] Untangle

by Randy Neals

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.

6 years

1
0
0 0

Re: [44net] Comcast Xfinity Routing

by David Ranch

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

6 years

1
0
0 0

Untangle

by Ryan O'Connor

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.

6 years

1
0
0 0

Re: [44net] Comcast Xfinity Routing

by Brian Kantor

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

6 years

2
1
0 0

Re: [44net] Comcast Xfinity Routing

by Brian

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

6 years

1
0
0 0

Comcast Xfinity Routing

by Nate Sales

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

6 years

1
0
0 0

Re: [44net] NPR kits for sale! (New Packet Radio)

by Brian

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

6 years

2
2
0 0

NPR kits for sale! (New Packet Radio)

by f4hdk

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

6 years

3
2
0 0

Re: [44net] Vultr.com - "Invalid BGP RPKI Entries"

by Brian Kantor

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

6 years

2
3
0 0

Vultr.com - "Invalid BGP RPKI Entries"

by Brian Kantor

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

6 years

3
2
0 0

Ping N1URO - PacComm email

by Nick G4IRX (44.131.x.x)

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

6 years

1
0
0 0

Re: [44net] Connecting to 44net

by Brian

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

6 years

1
0
0 0

44Net VPN?

by KJ7DMC

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

6 years

3
2
0 0

Old Files

by vk2tv

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

6 years, 1 month

1
0
0 0

NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud

by f4hdk

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

6 years, 1 month

5
9
0 0

Re: [44net] IRR Entries for BGP Filtering

by G1FEF

> 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

6 years, 1 month

1
0
0 0

IRR Entries for BGP Filtering

by Jonathan Lassoff

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

6 years, 1 month

8
9
0 0

Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud

by Leon Zetekoff

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

6 years, 1 month

7
10
0 0

Re: [44net] NPR (New Packet Radio) : new firmware with 56kBaud and 120kBaud

by Mark Phillips

".... 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 >

6 years, 1 month

1
0
0 0

Hamnet over 70cm : NPR (New Packet Radio)

by f4hdk

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

6 years, 1 month

16
41
0 0

Re: [44net] Hamnet over 70cm : NPR (New Packet Radio)

by Rob Janssen

> 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

6 years, 1 month

1
0
0 0

Re: [44net] Telebit Trailblazer over radio

by John Gilmore

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

6 years, 1 month

1
0
0 0

Re: [44net] Portal encap file by email option

by Jean Létourneau

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

6 years, 1 month

1
0
0 0

Re: [44net] Portal encap file by email option

by Brian Kantor

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

6 years, 1 month

1
0
0 0

Portal encap file by email option

by R P

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

6 years, 1 month

1
0
0 0

Gateway hostname resolver

by Gustavo Ponza

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

6 years, 1 month

2
1
0 0

Re: [44net] UCSD tunnel behing NAT and Firewall setting ?

by R P

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

6 years, 2 months

1
0
0 0

Re: [44net] Portal API

by G1FEF

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

6 years, 2 months

1
0
0 0

Re: [44net] UCSD tunnel behing NAT and Firewall setting ?

by Michael Cullen

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 >

6 years, 2 months

1
0
0 0

Re: [44net] UCSD tunnel behing NAT and Firewall setting ?

by Steve L

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

6 years, 2 months

1
0
0 0

UCSD tunnel behing NAT and Firewall setting ?

by R P

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

6 years, 2 months

1
0
0 0

Hacked webcam?

by Rob Janssen

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

6 years, 2 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 8, Issue 81

by Roger Andrews

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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Rob Janssen

> 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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Roger

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

6 years, 2 months

2
1
0 0

Portal API

by Nate Sales

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

6 years, 2 months

1
0
0 0

Re: [44net] VPN Question

by Rob Janssen

> 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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Roger

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 >

6 years, 2 months

1
0
0 0

Re: [44net] VPN Question

by Steve L

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

6 years, 2 months

1
0
0 0

Re: [44net] VPN Question

by Rob Janssen

> 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

6 years, 2 months

2
1
0 0

Re: [44net] VPN Question

by Rob Janssen

> 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

6 years, 2 months

5
7
0 0

VPN Question

by KJ7DMC

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

6 years, 2 months

2
1
0 0

Re: [44net] IPv6 on RF - was: 44 net value

by Rob Janssen

> 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

6 years, 2 months

5
4
0 0

Re: [44net] Google indexing

by Rob Janssen

> 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

6 years, 2 months

2
1
0 0

Edgerouter Setup

by Ray Quinn

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

6 years, 2 months

2
1
0 0

Re: [44net] Google indexing

by Roger

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

6 years, 2 months

2
1
0 0

Re: [44net] Google indexing

by Roger

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 >

6 years, 2 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 8, Issue 74

by Roger Andrews

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

6 years, 2 months

10
10
0 0

Re: [44net] Google indexing

by Brian Kantor

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

6 years, 2 months

2
1
0 0

Re: [44net] Google indexing

by Roger

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 >

6 years, 2 months

2
1
0 0

Re: Gateway with Home router running OPENWRT ?

by lleachii＠aol.com

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.

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Roger

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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Roger

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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Ruben ON3RVH

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

6 years, 2 months

2
1
0 0

Re: [44net] Google indexing

by Rob Janssen

> 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

6 years, 2 months

4
3
0 0

Gateway with Home router running OPENWRT ?

by R P

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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Rob Janssen

> 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

6 years, 2 months

1
0
0 0

Google indexing

by lleachii

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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Rob Janssen

> 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

6 years, 2 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 8, Issue 72

by Roger

Hi all, I’m a bit sorry to have brought the issue of google’s inability to crawl ampr.org subdomains. I thought others might also feel that it would be nice to have their ARES group or other Ham group represented on the Ham network (44Net) for the work to see. Instead it feels like there is no interest at all in figuring out why this happens, instead blaming it on Google, or me for brining the issue forward and trying to contact google for help (you do realize that the only way to actually talk to google is to know someone there, so I’m sorry that I have “a friend” at google that tried to help with some inside information that the google search console does not provide.) Roger VA7LBB > On May 4, 2019, at 12:00, 44net-request(a)mailman.ampr.org wrote: > > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > Today's Topics: > > 1. Re: Google indexing (Roger) > 2. Re: Google indexing (Roger) > 3. Re: Google indexing (Steve L) > 4. Re: Google indexing (Rob Janssen) > <mime-attachment> > <mime-attachment> > <mime-attachment> > <mime-attachment> > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

6 years, 2 months

4
4
0 0

Re: [44net] Google indexing

by Roger

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

6 years, 2 months

2
1
0 0

Re: [44net] Google indexing

by Rob Janssen

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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Roger

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

6 years, 2 months

2
1
0 0

Re: [44net] Google indexing

by Roger

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

6 years, 2 months

1
0
0 0

Re: [44net] Google indexing

by Rob Janssen

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

6 years, 2 months

1
0
0 0

Google indexing

by Roger Andrews

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

6 years, 2 months

4
3
0 0

amprd 3.0 released

by Marius Petrescu

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

6 years, 2 months

1
0
0 0

Block or error?

by Marius Petrescu

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

6 years, 2 months

3
4
0 0

VPN Broken link

by KJ7DMC

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

6 years, 3 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net