Skip to content

walgreens.com timeouts

General discussions and other topics.
22 posts Page 2 of 3
Post a reply

Re: walgreens.com timeouts

by mykmelez » Sun Sep 18, 2016 2:30 pm
vbrobert wrote:Looking at https://www.walgreens.com/login.jsp, the jJavascript took a while which is to be expected. It actually took a whopping 3 seconds. When I loaded it from cache, it only took 0.64 seconds for the Javascript. If you are still having issues, try clearing your cache.
I'm still having issues, and clearing my cache doesn't resolve them. Note that it isn't https://www.walgreens.com/login.jsp itself that takes time to load, it's the next page, once you press the Sign In button to sign into the site. It takes several minutes for that page to load.

And after it loads, selecting Your Account > Sign Out takes several minutes to load the "You Are Signed Out" page.
vbrobert wrote:I would also suggest, in Firefox, go to Tools --> Web Developer --> Network and that should give us some more insight.
The Network panel suggests that the requests that block the next page from loading are to URLs of the form:

Code: Select all

https://ecomuem.walgreens.com/dynaTraceMonitor?dtCookie=[elided];dtLatC=[elided];referer=[URL]
(I elided the values of the dtCookie and dtLatC properties to avoid leaking personal information. The referer property's value is https%3A%2F%2Fwww.walgreens.com%2Flogin.jsp when I'm signing in and https%3A%2F%2Fwww.walgreens.com%2Fyouraccount%2Fdefault.jsp when I'm signing out.)

After pressing the Sign In button, the page initiates a few requests that respond quickly, then it initiates a request to the aforementioned URL, which hangs for a while (30 seconds to a minute) before returning zero bytes; after which the page initiates a second request to that URL, which similarly hangs and then returns zero bytes; after which the page initiates a third request, which hangs for a while, after which the next page loads. (It isn't clear what happens to that third request, since Firefox clears the Network panel when the next page loads, so I can't inspect the response.)

When I'm connected via T-Mobile, on the other hand, both signing in and signing out proceed quickly, with the next page loading after a couple seconds. (In this case, I don't have any network logs, since Firefox clears the Network panel before I can inspect the requests made by the previous page.)
by mykmelez » Sun Sep 18, 2016 2:43 pm
Pinging the domain of the URL that stalls on Sonic shows timeouts:
> ping ecomuem.walgreens.com
PING ecomuem.walgreens.com (204.15.116.162): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Whereas on T-Mobile the pings respond:
> ping ecomuem.walgreens.com
PING ecomuem.walgreens.com (204.15.116.162): 56 data bytes
64 bytes from 204.15.116.162: icmp_seq=0 ttl=237 time=143.761 ms
64 bytes from 204.15.116.162: icmp_seq=1 ttl=237 time=114.113 ms
64 bytes from 204.15.116.162: icmp_seq=2 ttl=237 time=106.745 ms
64 bytes from 204.15.116.162: icmp_seq=3 ttl=237 time=97.678 ms
64 bytes from 204.15.116.162: icmp_seq=4 ttl=237 time=79.272 ms
The traceroutes don't reveal any obvious issue, however (to my untrained eye, anyway).

Here's the traceroute on Sonic:
> traceroute ecomuem.walgreens.com
traceroute to ecomuem.walgreens.com (204.15.116.162), 64 hops max, 52 byte packets
1 homeportal (192.168.42.1) 3.915 ms 2.039 ms 2.247 ms
2 50-1-125-1.dsl.dynamic.fusionbroadband.com (50.1.125.1) 19.548 ms 18.986 ms 20.158 ms
3 gig1-36.cr1.colaca01.sonic.net (75.101.36.229) 19.902 ms 18.560 ms 22.403 ms
4 ae2.cr2.colaca01.sonic.net (50.0.79.201) 43.274 ms 31.312 ms 31.979 ms
5 * * *
6 50.ae4.gw.pao1.sonic.net (142.254.58.158) 37.144 ms 20.219 ms 20.184 ms
7 xe-1-0-6.ar1.pao1.us.as4436.gtt.net (69.22.130.85) 22.662 ms 19.595 ms 20.688 ms
8 xe-7-2-0.sjc12.ip4.gtt.net (89.149.130.249) 27.015 ms 20.333 ms 19.905 ms
9 as209.ip4.gtt.net (173.241.130.242) 20.583 ms 24.398 ms 21.361 ms
10 cer-edge-19.inet.qwest.net (67.14.122.141) 71.213 ms 70.601 ms 72.168 ms
11 65.112.65.26 (65.112.65.26) 70.163 ms 72.268 ms 71.030 ms
12 * * *
And here it is on T-Mobile:
> traceroute ecomuem.walgreens.com
traceroute to ecomuem.walgreens.com (204.15.116.162), 64 hops max, 52 byte packets
1 192.168.43.1 (192.168.43.1) 1.690 ms 1.488 ms 1.335 ms
2 10.168.193.186 (10.168.193.186) 29.734 ms 44.806 ms 30.219 ms
3 10.170.214.11 (10.170.214.11) 41.117 ms 45.501 ms 33.061 ms
4 10.164.162.198 (10.164.162.198) 43.313 ms 33.256 ms 48.206 ms
5 10.164.165.27 (10.164.165.27) 49.790 ms 35.171 ms 31.263 ms
6 ae1.mpr4.sjc7.us.above.net (208.185.86.21) 45.745 ms 27.963 ms 55.097 ms
7 ae19.mpr4.sjc7.us.zip.zayo.com (64.125.30.77) 37.127 ms 42.087 ms 36.836 ms
8 sjp-brdr-05.inet.qwest.net (63.146.26.253) 61.529 ms 47.455 ms 38.083 ms
9 cer-edge-19.inet.qwest.net (67.14.122.141) 90.080 ms 85.879 ms 96.620 ms
10 65.112.65.26 (65.112.65.26) 79.518 ms 77.727 ms 122.945 ms
11 * * *
by vbrobert » Sun Sep 18, 2016 3:04 pm
Hmm,

I am able to ping ecomuem.walgreens.com from my Sonic connection. I wonder if that server may be blocking your IP address (possibly IP range). Hop 11 should be 63.73.199.7 and ecomuem.walgreens.com is hop 12. Try pinging 63.73.199.7. If you are able to, I would never suggest doing the following command: nmap -Pn ecomuem.walgreens.com.
Overwatch!
by vbrobert » Sun Sep 18, 2016 3:13 pm
Just found this out,

In the Network Tool click on the settings gear near the top right of the tool and enable persistent logs. That should stop things from clearing.
Overwatch!
by mykmelez » Sun Sep 18, 2016 4:24 pm
vbrobert wrote:In the Network Tool click on the settings gear near the top right of the tool and enable persistent logs. That should stop things from clearing.
Ah, thanks for the tip! I thought there was such a feature, but I couldn't find it.

Ok, enabling that feature allows me to see the result of each of the three requests, and the first two look this:

Code: Select all

      {
        "pageref": "page_1",
        "startedDateTime": "2016-09-18T16:11:07.418-07:00",
        "time": 60619,
        "request": {
          "bodySize": 0,
          "method": "POST",
          "url": "https://ecomuem.walgreens.com/dynaTraceMonitor?dtCookie=…",
          "httpVersion": "",
          "headers": [
            {
              "name": "Host",
              "value": "ecomuem.walgreens.com"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0"
            },
            {
              "name": "Accept",
              "value": "*/*"
            },
            {
              "name": "Accept-Language",
              "value": "en-US,en;q=0.5"
            },
            {
              "name": "Accept-Encoding",
              "value": "gzip, deflate, br"
            },
            {
              "name": "Referer",
              "value": "https://www.walgreens.com/login.jsp"
            },
            {
              "name": "Content-Type",
              "value": "text/plain;charset=UTF-8"
            },
            {
              "name": "Content-Length",
              "value": "342"
            },
            {
              "name": "Origin",
              "value": "https://www.walgreens.com"
            },
            {
              "name": "Connection",
              "value": "keep-alive"
            }
          ],
          "cookies": [],
          "queryString": [
            {
              "name": "dtCookie",
              "value": "…;dtLatC"
            }
          ],
          "postData": {
            "mimeType": "text/plain;charset=UTF-8",
            "params": [],
            "text": ""
          },
          "headersSize": 545
        },
        "response": {
          "status": 0,
          "statusText": "",
          "httpVersion": "",
          "headers": [],
          "cookies": [],
          "content": {
            "mimeType": "text/plain",
            "size": 0,
            "encoding": "base64",
            "text": ""
          },
          "redirectURL": "",
          "headersSize": -1,
          "bodySize": -1
        },
        "cache": {},
        "timings": {
          "blocked": 60367,
          "dns": 252,
          "connect": 0,
          "send": 0,
          "wait": 0,
          "receive": 0
        }
      },
In other words: the request takes about 60 seconds, and it appears to never return a response (so presumably it times out). The third request looks similar, except that it only takes about 13 seconds.
by mykmelez » Sun Sep 18, 2016 4:28 pm
vbrobert wrote:Hmm,

I am able to ping ecomuem.walgreens.com from my Sonic connection. I wonder if that server may be blocking your IP address (possibly IP range). Hop 11 should be 63.73.199.7 and ecomuem.walgreens.com is hop 12. Try pinging 63.73.199.7.
Pinging 63.73.199.7 times out:
> ping 63.73.199.7
PING 63.73.199.7 (63.73.199.7): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
vbrobert wrote:If you are able to, I would never suggest doing the following command: nmap -Pn ecomuem.walgreens.com.
I would never do something like that. But if I did, it might look like:
> nmap -Pn ecomuem.walgreens.com

Starting Nmap 7.12 ( https://nmap.org ) at 2016-09-18 16:08 PDT
Nmap scan report for ecomuem.walgreens.com (204.15.116.162)
Host is up (0.12s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
25/tcp closed smtp

Nmap done: 1 IP address (1 host up) scanned in 16.18 seconds
by vbrobert » Sun Sep 18, 2016 4:45 pm
Actually it doesn't look like 63.73.199.7 responds to pings at all so scratch that. You should be able to see it respond using mtr ecomuem.walgreens.com.

What is really interesting is that, given the hypothetical situation, ecomuem.walgreens.com is up according to nmap. Ports 80 and 443 are not showing as open. Again, I would never suggest trying nmap -Pn ecomuem.walgreens.com from your T-Mobile connection. I suspect, if you were to do that, port 80 and port 443 should show open which would confirm that there is some sort of firewall rule on their side keeping you out.

I think trying to get a new IP address would be the next big thing to try though. Do you have a static IP?
Overwatch!
by mykmelez » Sun Sep 18, 2016 10:55 pm
vbrobert wrote:Actually it doesn't look like 63.73.199.7 responds to pings at all so scratch that. You should be able to see it respond using mtr ecomuem.walgreens.com.
I don't see that IP address when I mtr ecomuem.walgreens.com:

Code: Select all

                                                 Packets               Pings
 Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. homeportal                                  0.0%    14    2.3   4.0   1.7  10.9   3.1
 2. 50-1-125-1.dsl.dynamic.fusionbroadband.com  0.0%    14   20.3  21.2  19.2  30.9   2.9
 3. gig1-36.cr1.colaca01.sonic.net              7.1%    14   25.1  20.9  18.9  27.5   2.5
 4. ae2.cr2.colaca01.sonic.net                  0.0%    13   36.3  37.8  27.2  53.2   6.3
 5. ae0.cr2.lsatca11.sonic.net                 30.8%    13  4294. 4399. 4081. 4661. 194.8
 6. 50.ae4.gw.pao1.sonic.net                    0.0%    13   43.4  22.8  19.7  43.4   6.4
 7. xe-1-0-6.ar1.pao1.us.as4436.gtt.net         7.7%    13   19.9  21.2  19.5  25.3   1.4
 8. xe-1-3-2.sjc12.ip4.gtt.net                  7.7%    13   24.3  22.9  20.6  37.6   4.7
 9. as209.ip4.gtt.net                           0.0%    13   20.8  25.2  20.8  33.9   4.6
10. cer-edge-19.inet.qwest.net                  0.0%    13   71.1  71.0  69.5  79.1   2.5
11. 65.112.65.26                                0.0%    13   71.5  71.2  70.3  73.0   0.5
12. ???
vbrobert wrote:What is really interesting is that, given the hypothetical situation, ecomuem.walgreens.com is up according to nmap. Ports 80 and 443 are not showing as open. Again, I would never suggest trying nmap -Pn ecomuem.walgreens.com from your T-Mobile connection. I suspect, if you were to do that, port 80 and port 443 should show open which would confirm that there is some sort of firewall rule on their side keeping you out.
I wouldn't do that, but if I did, then it might look something like this:

Code: Select all

> nmap -Pn ecomuem.walgreens.com

Starting Nmap 7.12 ( https://nmap.org ) at 2016-09-18 22:41 PDT
Nmap scan report for ecomuem.walgreens.com (204.15.116.162)
Host is up (0.13s latency).
Not shown: 998 filtered ports
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 14.04 seconds
vbrobert wrote:I think trying to get a new IP address would be the next big thing to try though. Do you have a static IP?
No, I have a dynamic IP, although it's stable across DHCP renewal.
by virtualmike » Sun Sep 18, 2016 11:33 pm
mykmelez wrote:No, I have a dynamic IP, although it's stable across DHCP renewal.
Temporarily connect to Sonic VPN and try again?
by mykmelez » Mon Sep 19, 2016 12:36 am
virtualmike wrote:
mykmelez wrote:No, I have a dynamic IP, although it's stable across DHCP renewal.
Temporarily connect to Sonic VPN and try again?
That works! Erm, but I'd still rather not have to do this before I use that website. Perhaps it's time to contact Sonic support about the issue?
22 posts Page 2 of 3

Return to “General”