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