Diagnosing Geographical Location / IP Address

We see various problems reported, in Blogger Help Forum: Get Help with an Issue, which may involve geographical or network relationships.

Why can't I regain access to my blog, that I stopped publishing 5 years ago?

and

Why can't I see my blog?

and

Why does my dashboard show up in a language that I can't read?

With questions like these, it helps to know how and where the owner and / or readers of the blog get Internet service.

Geographical location and IP address are useful details, when diagnosing various problems with our blogs.

• Access and authentication.
• Connectivity.
• Language.

Address / location diagnosis is not a difficult procedure, given the right tools. As an example, click on each of these three links, one by one. Print or copy text details, as convenient - then combine and compare the details, from the different services.

• IP-Details.com : Find your IP address Information
• IP Location Finder - Geolocation
• Locate IP Address Lookup Show on Map

There are other similar tools, that I may identify later.

I'll show each location discovery tool, from various geographical locations. This will illustrate the uncertainties of geographical vs geolocated location - and why use of multiple ("redundant") online diagnostic tools is a good idea.

I clicked on each link, twice - while connected differently - and made the screen prints from these geographical locations. I may show additional locations as I use them.

• 22 May, 2016: MacDonalds, Martinez CA
• 23 May, 2016: StarBucks, Martinez CA

"IP-Details.com"
Date: 22 May, 2016
Diagnosed Location: Austin, TX
Geographical Location: MacDonalds, Martinez, CA
IP Address: 64.134.233.29
Provider: MacDonalds

"IP Location"
Date: 22 May, 2016
Diagnosed Location: Valencia, CA
Geographical Location: MacDonalds, Martinez, CA
IP Address: 64.134.233.29
Provider: MacDonalds

"Info Sniper"
Date: 22 May, 2016
Diagnosed Location: (Los Angeles, CA)
Geographical Location: MacDonalds, Martinez, CA
IP Address: 64.134.233.29
Provider: MacDonalds

"IP-Details.com"
Date: 22 May, 2016
Diagnosed Location: Bedminster, NJ
Geographical Location: MacDonalds, Martinez, CA
IP Address: 70.197.3.7
Provider: Verizon Cellular

"IP Location"
Date: 22 May, 2016
Diagnosed Location: Rohnert Park, CA
Geographical Location: MacDonalds, Martinez, CA
IP Address: 70.197.3.7
Provider: Verizon Cellular

"Info Sniper"
Date: 22 May, 2016
Diagnosed Location: (Los Angeles CA)
Geographical Location: MacDonalds, Martinez, CA
IP Address: 70.197.3.7
Provider: Verizon Cellular



---

"IP-Details.com"
Date: 23 May, 2016
Diagnosed Location:
Geographical Location: StarBucks, Martinez, CA
IP Address: 50.247.110.187
Provider: StarBucks

"IP Location"
Date: 23 May, 2016
Diagnosed Location: Menlo Park CA
Geographical Location: StarBucks, Martinez, CA
IP Address: 50.247.110.187
Provider: StarBucks

"Info Sniper"
Date: 23 May, 2016
Diagnosed Location: Milpitas CA
Geographical Location: StarBucks, Martinez, CA
IP Address: 50.247.110.187
Provider: StarBucks

"IP-Details.com"
Date: 23 May, 2016
Diagnosed Location: Bedminster, NJ
Geographical Location: StarBucks, Martinez, CA
IP Address: 70.197.12.193
Provider: Verizon Cellular

"IP Location"
Date: 23 May, 2016
Diagnosed Location: Salinas CA
Geographical Location: StarBucks, Martinez, CA
IP Address: 70.197.12.193
Provider: Verizon Cellular

"Info Sniper"
Date: 23 May, 2016
Diagnosed Location: South San Francisco CA
Geographical Location: StarBucks, Martinez, CA
IP Address: 70.197.12.193
Provider: Verizon Cellular

"IP-Details.com"
Date: 5 June, 2016
Diagnosed Location: Bedminster, NJ
Geographical Location: Martinez, CA
IP Address: 70.213.0.103
Provider: Verizon Cellular

"IP Location"
Date: 5 June, 2016
Diagnosed Location: Berkeley CA
Geographical Location: Martinez, CA
IP Address: 70.213.0.103
Provider: Verizon Cellular

"Info Sniper"
Date: 5 June, 2016
Diagnosed Location: Oakland CA
Geographical Location: Martinez, CA
IP Address: 70.213.0.103
Provider: Verizon Cellular



Geolocation is a useful diagnostic tool, when diagnosing various Blogger problems - but geolocated details, using the above tools (or complementary procedures), need to be persistently cross checked. Tomorrow, or from a different location or service, one may see different results.

Access and authentication.

Sometimes when trying to regain access to a dormant blog, you'll be advised to access from the previously used computer. Google uses location comparisons, as part of demographic authentication.

Connectivity.

Some blog disconnections may have geographical origin. Knowing where you, and other blog readers may be (or appear to be), can be useful in determining a geographical relationship between problems.

Language.

Blogger uses geolocation to determine appropriate local language. Knowing where you are - or appear to be - can be useful in determining why you may be seeing the Blogger dashboard and / or your blog, in a given language.

The bottom line.

Along with blog address / name / URL verification, location diagnosis is a useful procedure - but the results need to be considered discretely.

---

When diagnosing various access / connectivity problems with #Blogger, knowing the IP address and location of the reported problem is useful. It's easy to get the desired details - but the details may need to be verified, carefully.

https://productforums.google.com/d/topic/blogger/4LkxHxYsj1c/discussion

Read More

Effectively Testing Reader Access To Your Blog

People reporting a problem with blog access / performance, in Blogger Help Forum: Get Help with an Issue, will be frequently advised to diagnose their problems using affinity / differential testing.

Some diagnostic advice starts with simple instructions to "clear cache, cookies, and sessions". Some people, alternately, advise "use a different browser" - and test as a reader. These different strategies, seemingly redundant, will frequently lead to different results.

When you test reader access to a blog, some experts will casually advise you to "use a different browser" or "use a second computer".

There are specific reasons why this strategy may or may not be successful, when part of affinity / differential testing. When you test blog access, you're going to see varying reliability - based on a number of browser and reader details.

There are multiple ways to test blog access, of owner vs readers.

Any experienced testing technician knows that the most reliable testing, in affinity / differential analysis, will use identical browsers, on identical and separate computers.

Very few blog owners will have use of a bank of identical computers, for testing. There are alternate possibilities, when identical computers can't be used.

• This browser, in the primary session - after "clear cache, cookies, and sessions".
• This browser, in a secondary session - aka "Incognito" / "Private" browsing.
• A different browser, on the same computer.
• The same branded browser, on a different computer.
• Any browser, on a different computer.

All of these details will be relevant, sometimes - though not always. The differences between "always" and "sometimes" will lead to some testers using incomplete testing techniques - and cause inconsistent results.

This browser, in the primary session - after "clear cache, cookies, and sessions".

The best way to avoid environment based inaccuracy is to re use the environment, sequentially. This approach requires more time - plus development of a testing script, to keep testing procedures consistent.

It is, however, the best way to avoid confusion from inevitable testing variations.

Using the same browser, in the same browser session, one can try using a different identity. This technique starts with the apocryphal instructions to "clear cache, cookies, and sessions".

This browser, in a secondary session - aka "Incognito" / "Private" browsing.

Some browsers support multiple sessions. In Chrome, a secondary session is provided as "Incognito" mode - and in Firefox, a similar (not identical) option is called "Private" browsing. The differences between the "Incognito" and "Private" features are significant - and can cause different testing results.

This blog, displayed in "Incognito" mode.



A different browser, on the same computer.

Each different browser will have differences in the browser itself. Plus, different add-ons and settings, on the different browsers, will produce differing results.

Having both browsers on the same computer will eliminate computer setup differences, present when multiple computers are involved.

The same branded browser, on a different computer.

If the branded browser, on the two computers, is maintained identically, there is a chance for consistent results. Having two different computers involved, however, may offset the consistency gained by using identical browsers.

Any browser, on a different computer.

This is the most inaccurate testing procedure, of the choices listed. Any difference between the browsers, or computers, can lead to inaccuracy.

The differences, in testing, involve multiple details.

• Login identity in use.
• Cookie filters, that block identity.
• Script filters, that block identity access.
• Browser add-ons, that may or may not be present.
• Browser brand and design differences.

Login identity in use.

This is the one difference that you intentionally need, to test the reader experience. In the primary session, you are logged in as the owner. You require at least one secondary session - where you are not logged in as the owner, to test your blog as a reader.

The secondary session is where the need for sequential session reuse - or use of a different browser and / or computer - becomes necessary.

Cookie filters, that block identity.

Many Blogger features - involving both the dashboard, and access to the blog - use cookies to determine identity and permissions. Cookie filters, inappropriately managed, can cause havoc with Blogger. As an example, consider commenting ability, and third party cookies.

Different browsers may have different cookie filter settings. In some cases, identity is not relevant, for testing as a reader.

If you are testing access to a private blog, though, reader identity - which is cookie based - will be essential. A cookie filter involved, with a private blog being tested, will cause problems.

Similarly, testing Google+ comments requires known identity - for both the blog owner and readers. With Google+, identity is essential, to guarantee consistent display of comments.

Script filters, that block identity access.

Many Blogger features - involving both the dashboard, and content in the blog - are JavaScript based. Script filters can cause havoc with Blogger.

Different browsers may have different script filter settings - and different browser brands may have completely different script filters.

Browser add-ons, that may or may not be present.

The Firefox browser does not have native script filters, so many computer owners who use Firefox will add NoScript.

NoScript is a very intense add-on, with a lot of options, and opportunities for confusion. If you were to use Firefox on two different computers, you would need to carefully synchronise NoScript settings on both computers, for reliable testing.

Firefox with NoScript is the best known example - but it's not the only possibility for confusion. Every browser can have script filters, which will make browser to browser testing comparison a challenge.

With Chrome, one can select each individual add-on to be present in the secondary session ("Allow in incognito") - and this will create uncertainty. Some advice to "try using a Chrome incognito window" will be successful, with other advice being useless - and the absence or presence of the necessary add-on will be one of the issues.

AdBlock, optionally included in incognito mode, will produce uncertainty in testing - and is a well known script block.



Browser brand and design differences.

Every different browser produces differences in displayed content. Even a formatting discrepancy can lead to difference in test results.

The end results.

Interpreting test results, based on comparison of different browser displays, will be a challenge for anybody trying to produce reliable conclusions. The most reliable results will come from testing using the same browser session, sequentially. This will start with instructions to "clear cache, cookies, and sessions" - a painful but necessary process.

---

Many #Blogger problems need to be diagnosed using repetitive testing, and affinity / differential analysis. People who don't understand organised testing will sometimes recommend testing procedures, such as use of different browser sessions - which will produce inconclusive results.

Read More

Blogger Magic - Using An HTTP Trace

An HTTP trace is a very useful tool, for diagnosing and documenting connectivity issues, and many other blog problems.

I use the Rex Swain HTTP Viewer, for this purpose. HTTP Viewer lets you package a given display, in the URL, so you can give simple instructions (accompanied by an unavoidably complicated link):

Click on the link:

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://klarfamilylife.blogspot.com&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7834.70.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/49.0.2623.112+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

And when the link is clicked, the necessary HTTP trace is displayed. There is no need to provide instructions how to actually enter the necessary values, on the HTTP Viewer home page, to generate the necessary display.

I use the Rex Swain HTTP Viewer, for diagnosing and documenting custom domain, malware, spam classification, and other connectivity issues.

Start by verifying URLs involved.

Whenever possible, make a screen print, and a text copy, of the Blogger dashboard Publishing wizard, at Settings - Basic.

Here's a live example, of HTTP Viewer use.

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://klarfamilylife.blogspot.com&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7834.70.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/49.0.2623.112+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

Start from http://www.rexswain.com/httpview.html.

Note, HTTP Viewer only works in HTTP mode. SSL is not supported. Fortunately, right now, the automatic "http:" to "https:" Blogger redirect, which is not optional, does not affect HTTP Viewer.

Add the URL of the blog, and click on "Submit".

This generates a lot of text. I'm not going to explain all of it, in this post.



Since Blogger blogs have no post limit, I'll have more posts, later, that will involve HTTP Viewer displays.

But here's the second page, of the above display.



And here is the typical excerpt, that I will make, and display.

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://klarfamilylife.blogspot.com&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7834.70.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/49.0.2623.112+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

Sending request:

GET / HTTP/1.1
Host: klarfamilylife.blogspot.com
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7834.70.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 172.217.0.1
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·500·Internal·Server·Error(CR)(LF)

This is an example of a notorious "500 Internal Server Error" - which right now is plaguing various blog owners who have corrupt templates. This is what we see with many blogs, when people report various bX codes, when using several Blogger dashboard pages.

• Template.
• Template - "Customize" (aka "Blogger Template Designer").
• Template - "Edit HTML" (aka "Blogger Template Editor").

Here's a second live example.

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://blogging.nitecruzr.net/&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7834.70.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/49.0.2623.112+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

Here, we have an HTTP trace from this blog, http://blogging.nitecruzr.net/.

And, my typical display - which you might see, as an "HTTP trace excerpt", in a custom domain connectivity diagnosis.

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://blogging.nitecruzr.net/&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7834.70.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/49.0.2623.112+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

Sending request:

GET / HTTP/1.1
Host: blogging.nitecruzr.net
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7834.70.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 74.125.25.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·200·OK(CR)(LF)

<meta·content='blogger'·name='generator'/>(LF)
<link·href='http://blogging.nitecruzr.net/favicon.ico'·rel='icon'·type='image/x-icon'/>(LF)
<link·href='http://blogging.nitecruzr.net/'·rel='canonical'/>(LF)
<link·rel="alternate"·type="application/atom+xml"·title="The·Real·Blogger·Status·-·Atom"·href="http://blogging.nitecruzr.net/feeds/posts/default"·/>(LF)
<link·rel="alternate"·type="application/rss+xml"·title="The·Real·Blogger·Status·-·RSS"·href="http://blogging.nitecruzr.net/feeds/posts/default?alt=rss"·/>(LF)
<link·rel="service.post"·type="application/atom+xml"·title="The·Real·Blogger·Status·-·Atom"·href="https://www.blogger.com/feeds/24069595/posts/default"·/>(LF)

The latter connectivity diagnosis might be a part of my 12 link affinity / differential connectivity test.

My trace excerpts include details which I, personally, decided are most useful for me. You may find additional - or less - details to be useful, for you.

Here, we see just two examples, of my HTTP traces. There are an infinity of possibilities.

---

An online HTTP trace is a useful diagnostic tool, when diagnosing and identifying many different #Blogger problems. Custom domain, malware, spam classification, and other connectivity issues may be diagnosed and documented.

Read More