Re: next hop packet loss

2012-08-06 Thread Tom Hill 

Hi Jim,

On 06/08/12 22:27, Jim Ray wrote:

What is the best way to solve this type of problem?


It's not a problem, it's checkpoint purporting to be 'secure' when all 
they're doing is blocking ICMP outright, seemingly.


If I try 'tcptraceroute' (from Linux) it works just fine, bare the 
Above.net hop in the middle that doesn't respond - ignore.


$ sudo tcptraceroute -n checkpoint.com
traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte packets
 1  81.187.203.81  0.719 ms  1.050 ms  1.298 ms
 2  90.155.53.54  30.184 ms  31.604 ms  32.370 ms
 3  90.155.53.43  33.891 ms  35.072 ms  36.021 ms
 4  85.91.238.217  37.016 ms  38.236 ms  39.215 ms
 5  85.91.224.10  40.226 ms  41.358 ms  42.354 ms
 6  212.187.200.145  164.713 ms  164.102 ms  164.020 ms
 7  4.69.139.99  45.316 ms  194.042 ms  194.088 ms
 8  64.125.14.17  194.297 ms  193.943 ms  193.558 ms
 9  64.125.31.198  194.304 ms  194.462 ms  193.560 ms
10  * * *
11  64.125.26.37  288.267 ms  284.237 ms  166.340 ms
12  64.125.24.38  178.571 ms  179.467 ms  156.769 ms
13  64.125.28.238  148.002 ms  147.244 ms  147.501 ms
14  64.125.26.141  206.010 ms  205.574 ms  205.426 ms
15  64.125.28.57  201.753 ms  172.439 ms  174.169 ms
16  64.124.201.230  176.866 ms  172.412 ms  172.510 ms
17  208.185.174.208  173.668 ms  174.310 ms  173.999 ms
18  216.200.241.66   172.504 ms  172.386 ms  172.700 ms


Tom

Re: next hop packet loss

2012-08-06 Thread Jim Ray 
It is a problem with http protocol regardless of ICMP. 

Sent from my iPhone

On Aug 6, 2012, at 5:51 PM, "Tom Hill"  wrote:

> Hi Jim,
> 
> On 06/08/12 22:27, Jim Ray wrote:
>> What is the best way to solve this type of problem?
> 
> It's not a problem, it's checkpoint purporting to be 'secure' when all 
> they're doing is blocking ICMP outright, seemingly.
> 
> If I try 'tcptraceroute' (from Linux) it works just fine, bare the Above.net 
> hop in the middle that doesn't respond - ignore.
> 
> $ sudo tcptraceroute -n checkpoint.com
> traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte packets
> 1  81.187.203.81  0.719 ms  1.050 ms  1.298 ms
> 2  90.155.53.54  30.184 ms  31.604 ms  32.370 ms
> 3  90.155.53.43  33.891 ms  35.072 ms  36.021 ms
> 4  85.91.238.217  37.016 ms  38.236 ms  39.215 ms
> 5  85.91.224.10  40.226 ms  41.358 ms  42.354 ms
> 6  212.187.200.145  164.713 ms  164.102 ms  164.020 ms
> 7  4.69.139.99  45.316 ms  194.042 ms  194.088 ms
> 8  64.125.14.17  194.297 ms  193.943 ms  193.558 ms
> 9  64.125.31.198  194.304 ms  194.462 ms  193.560 ms
> 10  * * *
> 11  64.125.26.37  288.267 ms  284.237 ms  166.340 ms
> 12  64.125.24.38  178.571 ms  179.467 ms  156.769 ms
> 13  64.125.28.238  148.002 ms  147.244 ms  147.501 ms
> 14  64.125.26.141  206.010 ms  205.574 ms  205.426 ms
> 15  64.125.28.57  201.753 ms  172.439 ms  174.169 ms
> 16  64.124.201.230  176.866 ms  172.412 ms  172.510 ms
> 17  208.185.174.208  173.668 ms  174.310 ms  173.999 ms
> 18  216.200.241.66   172.504 ms  172.386 ms  172.700 ms
> 
> 
> Tom
>

Re: next hop packet loss

2012-08-07 Thread tom 
Well, you haven't provided any proof of that. Their website works just
fine for me (TM).

Since your troubleshooting is limited to methods that are blocked by
Checkpoint's network, you might need to revisit how you're going about
diagnosing the problem you're facing.

In any case, I won't be providing any further input following that response.

Tom

> It is a problem with http protocol regardless of ICMP.
>
> Sent from my iPhone
>
> On Aug 6, 2012, at 5:51 PM, "Tom Hill"  wrote:
>
>> Hi Jim,
>>
>> On 06/08/12 22:27, Jim Ray wrote:
>>> What is the best way to solve this type of problem?
>>
>> It's not a problem, it's checkpoint purporting to be 'secure' when all
>> they're doing is blocking ICMP outright, seemingly.
>>
>> If I try 'tcptraceroute' (from Linux) it works just fine, bare the
>> Above.net hop in the middle that doesn't respond - ignore.
>>
>> $ sudo tcptraceroute -n checkpoint.com
>> traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte
>> packets
>> 1  81.187.203.81  0.719 ms  1.050 ms  1.298 ms
>> 2  90.155.53.54  30.184 ms  31.604 ms  32.370 ms
>> 3  90.155.53.43  33.891 ms  35.072 ms  36.021 ms
>> 4  85.91.238.217  37.016 ms  38.236 ms  39.215 ms
>> 5  85.91.224.10  40.226 ms  41.358 ms  42.354 ms
>> 6  212.187.200.145  164.713 ms  164.102 ms  164.020 ms
>> 7  4.69.139.99  45.316 ms  194.042 ms  194.088 ms
>> 8  64.125.14.17  194.297 ms  193.943 ms  193.558 ms
>> 9  64.125.31.198  194.304 ms  194.462 ms  193.560 ms
>> 10  * * *
>> 11  64.125.26.37  288.267 ms  284.237 ms  166.340 ms
>> 12  64.125.24.38  178.571 ms  179.467 ms  156.769 ms
>> 13  64.125.28.238  148.002 ms  147.244 ms  147.501 ms
>> 14  64.125.26.141  206.010 ms  205.574 ms  205.426 ms
>> 15  64.125.28.57  201.753 ms  172.439 ms  174.169 ms
>> 16  64.124.201.230  176.866 ms  172.412 ms  172.510 ms
>> 17  208.185.174.208  173.668 ms  174.310 ms  173.999 ms
>> 18  216.200.241.66   172.504 ms  172.386 ms  172.700 ms
>>
>>
>> Tom
>>
>

RE: next hop packet loss

2012-08-07 Thread Jim Ray 
Sorry, I do not give verbose responses via iPhone on that small device
with my tired old eyes. I ran Wireshark this morning.

Without sniffing packets, the layman's description of problem is "I
can't get to vendor web site, http://www.CheckPoint.com, on Time Warner
Business Class network I use." Hence, http is blocked in addition to
ICMP.

It is what it is. Personally, I plan to use the phone to reach Check
Point since TCP/IP won't work. I also got call back from top local
executive at Time Warner this morning that has known me 17 years,
understands the problem and is trying to help. Again, no emergency here.
Still, I would like it to work and pay extra to have the commercial
connection with service level agreement.

Regards,

Jim Ray, President
Neuse River Networks
2 Davis Drive, PO Box 13169
Research Triangle Park, NC 27709
919-838-1672 x100
www.NeuseRiverNetworks.com


-Original Message-
From: t...@ninjabadger.net [mailto:t...@ninjabadger.net] 
Sent: Tuesday, August 07, 2012 5:38 AM
To: Jim Ray
Cc: Tom Hill; nanog@nanog.org
Subject: Re: next hop packet loss

Well, you haven't provided any proof of that. Their website works just
fine for me (TM).

Since your troubleshooting is limited to methods that are blocked by
Checkpoint's network, you might need to revisit how you're going about
diagnosing the problem you're facing.

In any case, I won't be providing any further input following that
response.

Tom

> It is a problem with http protocol regardless of ICMP.
>
> Sent from my iPhone
>
> On Aug 6, 2012, at 5:51 PM, "Tom Hill"  wrote:
>
>> Hi Jim,
>>
>> On 06/08/12 22:27, Jim Ray wrote:
>>> What is the best way to solve this type of problem?
>>
>> It's not a problem, it's checkpoint purporting to be 'secure' when 
>> all they're doing is blocking ICMP outright, seemingly.
>>
>> If I try 'tcptraceroute' (from Linux) it works just fine, bare the 
>> Above.net hop in the middle that doesn't respond - ignore.
>>
>> $ sudo tcptraceroute -n checkpoint.com traceroute to checkpoint.com 
>> (216.200.241.66), 30 hops max, 60 byte packets
>> 1  81.187.203.81  0.719 ms  1.050 ms  1.298 ms
>> 2  90.155.53.54  30.184 ms  31.604 ms  32.370 ms
>> 3  90.155.53.43  33.891 ms  35.072 ms  36.021 ms
>> 4  85.91.238.217  37.016 ms  38.236 ms  39.215 ms
>> 5  85.91.224.10  40.226 ms  41.358 ms  42.354 ms
>> 6  212.187.200.145  164.713 ms  164.102 ms  164.020 ms
>> 7  4.69.139.99  45.316 ms  194.042 ms  194.088 ms
>> 8  64.125.14.17  194.297 ms  193.943 ms  193.558 ms
>> 9  64.125.31.198  194.304 ms  194.462 ms  193.560 ms
>> 10  * * *
>> 11  64.125.26.37  288.267 ms  284.237 ms  166.340 ms
>> 12  64.125.24.38  178.571 ms  179.467 ms  156.769 ms
>> 13  64.125.28.238  148.002 ms  147.244 ms  147.501 ms
>> 14  64.125.26.141  206.010 ms  205.574 ms  205.426 ms
>> 15  64.125.28.57  201.753 ms  172.439 ms  174.169 ms
>> 16  64.124.201.230  176.866 ms  172.412 ms  172.510 ms
>> 17  208.185.174.208  173.668 ms  174.310 ms  173.999 ms
>> 18  216.200.241.66   172.504 ms  172.386 ms  172.700 ms
>>
>>
>> Tom
>>
>

Re: next hop packet loss

2012-08-07 Thread William Herrin 
On Mon, Aug 6, 2012 at 11:27 AM, Jim Ray  wrote:
> I have a Time Warner Business Class connection and am unable to reach
> http://www.checkpoint.com to research product line I wish to carry. I
> did a trace route and confirmed packets are past my network, Time Warner
> network and onto next hop where they execute jump to nowhere
> instruction.
> Here is the tracert just now (it has been failing for weeks):

That's an artifact of Checkpoint blocking pings. Note the difference
between ICMP and TCP-based traceroutes:

traceroute -I 216.200.241.66
traceroute to 216.200.241.66 (216.200.241.66), 30 hops max, 60 byte packets
 1  sark.dirtside.com (70.182.189.216)  0.462 ms  0.494 ms  0.555 ms
 2  10.1.192.1 (10.1.192.1)  9.023 ms  9.197 ms  9.247 ms
 3  ip72-196-255-1.dc.dc.cox.net (72.196.255.1)  15.210 ms  15.497 ms  15.548 ms
 4  mrfddsrj01gex070003.rd.dc.cox.net (68.100.0.141)  13.594 ms
13.765 ms  13.817 ms
 5  68.1.4.139 (68.1.4.139)  14.752 ms  15.016 ms  14.951 ms
 6  ge-8-0-7.er2.iad10.us.above.net (64.125.12.241)  15.075 ms  9.565
ms  9.384 ms
 7  xe-5-1-0.cr2.dca2.us.above.net (64.125.29.77)  33.238 ms  26.629
ms  26.554 ms
 8  xe-2-2-0.cr2.iah1.us.above.net (64.125.30.53)  45.079 ms  45.230
ms  45.264 ms
 9  xe-0-3-0.cr2.lax112.us.above.net (64.125.30.50)  75.982 ms  76.212
ms  76.154 ms
10  xe-2-1-0.cr2.sjc2.us.above.net (64.125.26.30)  93.901 ms  94.044
ms  88.715 ms
11  xe-1-1-0.er2.sjc2.us.above.net (64.125.26.202)  88.542 ms  88.885
ms  90.094 ms
12  64.124.201.230.b709.above.net (64.124.201.230)  89.691 ms  89.060
ms  88.895 ms
13  * * *
14  * * *
15  * * *

traceroute -T -p 80 216.200.241.66
traceroute to 216.200.241.66 (216.200.241.66), 30 hops max, 60 byte packets
 1  sark.dirtside.com (70.182.189.216)  0.487 ms  0.520 ms  0.568 ms
 2  10.1.192.1 (10.1.192.1)  20.018 ms  24.851 ms  25.144 ms
 3  ip72-196-255-1.dc.dc.cox.net (72.196.255.1)  25.415 ms  25.502 ms  25.591 ms
 4  mrfddsrj01gex070003.rd.dc.cox.net (68.100.0.141)  25.139 ms
25.178 ms  25.260 ms
 5  68.1.4.139 (68.1.4.139)  37.509 ms  37.437 ms  37.362 ms
 6  ge-5-3-0.mpr2.iad10.us.above.net (64.125.13.57)  91.097 ms  89.808
ms ge-8-0-7.er2.iad10.us.above.net (64.125.12.241)  24.078 ms
 7  xe-5-1-0.cr2.dca2.us.above.net (64.125.29.77)  26.324 ms  11.950
ms  12.477 ms
 8  xe-2-2-0.cr2.iah1.us.above.net (64.125.30.53)  74.680 ms  74.575
ms  74.355 ms
 9  xe-0-3-0.cr2.lax112.us.above.net (64.125.30.50)  76.781 ms  76.330
ms  76.118 ms
10  xe-2-1-0.cr2.sjc2.us.above.net (64.125.26.30)  100.310 ms  100.026
ms  98.495 ms
11  xe-1-1-0.er2.sjc2.us.above.net (64.125.26.202)  98.631 ms  93.570
ms  94.380 ms
12  64.124.201.230.b709.above.net (64.124.201.230)  94.420 ms  97.053
ms  95.015 ms
13  208.185.174.208 (208.185.174.208)  96.208 ms  96.541 ms  96.384 ms
14  www.checkpoint.com (216.200.241.66)  97.406 ms  97.534 ms  97.891 ms


Since you get all the way to the Checkpoint border, try some basic
diagnostics like:

telnet www.checkpoint.com 80
GET / HTTP/1.1
Host: www.checkpoint.com

Wait for the telnet to succeed before you type GET. Make sure you
press enter twice after the last line. You're hand-jamming an HTTP
request.

If you don't connect then checkpoint is blocking your IP address for
one reason or another. Maybe there are hackers in your neighborhood.
Take it up with them by phone.

If you do connect but get no response to the "get" http request then
most likely checkpoint is blocking all ICMP packets and your path MTU
is smaller than 1500 bytes. The ICMP block prevents the fragmentation
needed message from reaching their web server, so it never figures out
it needs to shorten its packets. If, as a firewall company, they have
made this beginner mistake... 'nuff said.

And of course if you do get complete content back from the web server
then you have some other problem with your PC that's getting in the
way.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: next hop packet loss

2012-08-08 Thread Eugeniu Patrascu 
On Tue, Aug 7, 2012 at 4:12 PM, Jim Ray  wrote:
> Sorry, I do not give verbose responses via iPhone on that small device
> with my tired old eyes. I ran Wireshark this morning.
>
> Without sniffing packets, the layman's description of problem is "I
> can't get to vendor web site, http://www.CheckPoint.com, on Time Warner
> Business Class network I use." Hence, http is blocked in addition to
> ICMP.
>

Yesterday, Check Point's website was unreachable from other parts of
the world for some time with intermittent access for around an hour or
so I believe.

Eugeniu

RE: next hop packet loss

2012-08-08 Thread Jim Ray 
They've had me blocked for a few weeks now. I've always been able to
reach it on Verizon network with iPhone, just not with Time Warner
Business Class.

I plan to take advice from kind members of group that offered it and
investigate a little more with Wireshark yet have been in middle of
client migration of aging Exchange 2003 server to 2010 version in the
cloud since Friday. http://www.CheckPoint.com can wait. I had a great
face to face meeting with person from another UTM company this morning
http://www.sophos.com

Regards,

Jim Ray, President
Neuse River Networks
2 Davis Drive, PO Box 13169
Research Triangle Park, NC 27709
919-838-1672 x100
www.NeuseRiverNetworks.com



-Original Message-
From: Eugeniu Patrascu [mailto:eu...@imacandi.net] 
Sent: Wednesday, August 08, 2012 5:07 AM
To: Jim Ray
Cc: t...@ninjabadger.net; nanog@nanog.org
Subject: Re: next hop packet loss

On Tue, Aug 7, 2012 at 4:12 PM, Jim Ray  wrote:
> Sorry, I do not give verbose responses via iPhone on that small device

> with my tired old eyes. I ran Wireshark this morning.
>
> Without sniffing packets, the layman's description of problem is "I 
> can't get to vendor web site, http://www.CheckPoint.com, on Time 
> Warner Business Class network I use." Hence, http is blocked in 
> addition to ICMP.
>

Yesterday, Check Point's website was unreachable from other parts of the
world for some time with intermittent access for around an hour or so I
believe.

Eugeniu

RE: next hop packet loss

2012-08-08 Thread Jim Ray 
telnet www.checkpoint.com 80
GET / HTTP/1.1
Host: www.checkpoint.com

...resolved some information and then lost connection according to this
trailer from the screen scrape:

Re: next hop packet loss

2012-08-08 Thread William Herrin 
On Wed, Aug 8, 2012 at 7:39 PM, Jim Ray  wrote:
> telnet www.checkpoint.com 80
> GET / HTTP/1.1
> Host: www.checkpoint.com
>
> ...resolved some information and then lost connection according to this
> trailer from the screen scrape:
>
>   
>   
>

RE: next hop packet loss

2012-08-11 Thread Keith Medcalf 

Works fine in Firefox for me, and always has (within the limits of the shoddily 
designed website that is).  Nonetheless, I'd never buy anything from them since 
they are an anti-security organization.  Their Web site uses so much gratuitous 
javascript crap and hard-coded assumptions about character cell sizes and pixel 
density that it is completely unuseable.  I have no reason to believe that any 
other product they sell is any better designed -- if you can't create a web 
site that does not require increasing attack surface in order to use it, then I 
would assume that all their products work and are designed the same way, and 
that deployment of any of their products increases attack surface rather than 
decreasing it.

On the other hand they are probably four-colour-glossy-brochure and buzzword 
compliant.  Then again I'm an curmudgeonly old fart that can't even spell dot 
Snot.

---
()  ascii ribbon campaign against html e-mail
/\  www.asciiribbon.org


> -Original Message-
> From: Jim Ray [mailto:j...@neuse.net]
> Sent: Saturday, 11 August, 2012 10:36
> To: smbmanagedservi...@yahoogroups.com
> Cc: nanog@nanog.org; david.herr...@twcable.com
> Subject: RE: [SMBManagedServices] RE: next hop packet loss
>
> Get a load of this:
>
> New version of Firefox works fine. Methinks Mozilla released a turd.
>
>
> -Original Message-
> From: smbmanagedservi...@yahoogroups.com
> [mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of James_TDS
> Sent: Friday, August 10, 2012 11:47 AM
> To: smbmanagedservi...@yahoogroups.com
> Subject: RE: [SMBManagedServices] RE: next hop packet loss
>
> As I said I suspect Checkpoint is "breaking the Internet" in an attempt
> to block various DDOS attacks. The failure of tracert and ICMP is not
> isolated to Checkpoint and Above.net as I had a similar problem with a
> local TW customer on a static IP. Because their in house router was down
> and not responding to anything TW would drop the Tracert long before it
> even came close to my client. I gave them heck about this as it made it
> impossible to remotely monitor the customer because when the customer
> calls and says the "Internet is down" the first thing I do is tracert to
> their IP. When I see the route die in another city that tells me the ISP
> is having issues vs. the route dying one hop out from my customer's IP.
> They gave me some crap about active routing and such. Put anything on
> that IP and have it respond to pings and the route will complete.
>
> As I said Telnet checkpoint.com 80 fails for me but SLChecker works so
> again it's probably some DDOS thing and they are checking user agents
> before replying and I assume SLCheck mimics IE or something. Handy tool.
>
>
>
> -Original Message-
> From: smbmanagedservi...@yahoogroups.com
> [mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of Jim Ray
> Sent: Friday, August 10, 2012 8:23 AM
> To: smbmanagedservi...@yahoogroups.com
> Subject: RE: [SMBManagedServices] RE: next hop packet loss
>
> I am stumped why http://www.checkpoint.com won't resolve with Firefox
> yet will with Internet Explorer and Safari. I know Microsoft won't let
> you do what you need to do with Firefox yet am surprised with Check
> Point.
>
> Above.net is not echoing ICMP, though, before one reaches Check Point.
>
> >From the NANOG group, I found out it is possible to use command line
> switch to specify type of traffic and to get around ICMP issue.
> Apparently, TCP works; however, another person said UDP is preferred
> embodiment.
>
> This test resolved web site yet resulted in lost connection:
>
> telnet www.checkpoint.com 80
> GET / HTTP/1.1
> Host: www.checkpoint.com
>
> I captured packets with Wireshark yet did not see anything that jumped
> out at me as root cause for failure.
>
> Meanwhile back at the ranch, my friend brought over business card for
> Check Point representative, and I plan to pick up the phone and call
> thereby bypassing TCP/IP in its entirety.
>
>
> -Original Message-
> From: smbmanagedservi...@yahoogroups.com
> [mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of James_TDS
> Sent: Thursday, August 09, 2012 10:50 AM
> To: smbmanagedservi...@yahoogroups.com
> Subject: RE: [SMBManagedServices] RE: next hop packet loss
>
> Go back a few post and see where I mentioned that the hop in question
> was not responding to the ICMP request, it wasn't down they just refuse
> to echo.
>
> Probably a more valid test would have been:
>
> telnet checkpoint.com 80
> GET
>
> However I just tested that as well and Checkpoint doesn't respond
> correctly. Not sure what they are doing on the frontend but they ar

RE: [SMBManagedServices] RE: next hop packet loss

2012-08-11 Thread Jim Ray 
Get a load of this:

New version of Firefox works fine. Methinks Mozilla released a turd.


-Original Message-
From: smbmanagedservi...@yahoogroups.com
[mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of James_TDS
Sent: Friday, August 10, 2012 11:47 AM
To: smbmanagedservi...@yahoogroups.com
Subject: RE: [SMBManagedServices] RE: next hop packet loss

As I said I suspect Checkpoint is "breaking the Internet" in an attempt
to block various DDOS attacks. The failure of tracert and ICMP is not
isolated to Checkpoint and Above.net as I had a similar problem with a
local TW customer on a static IP. Because their in house router was down
and not responding to anything TW would drop the Tracert long before it
even came close to my client. I gave them heck about this as it made it
impossible to remotely monitor the customer because when the customer
calls and says the "Internet is down" the first thing I do is tracert to
their IP. When I see the route die in another city that tells me the ISP
is having issues vs. the route dying one hop out from my customer's IP.
They gave me some crap about active routing and such. Put anything on
that IP and have it respond to pings and the route will complete.

As I said Telnet checkpoint.com 80 fails for me but SLChecker works so
again it's probably some DDOS thing and they are checking user agents
before replying and I assume SLCheck mimics IE or something. Handy tool.



-Original Message-
From: smbmanagedservi...@yahoogroups.com
[mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of Jim Ray
Sent: Friday, August 10, 2012 8:23 AM
To: smbmanagedservi...@yahoogroups.com
Subject: RE: [SMBManagedServices] RE: next hop packet loss

I am stumped why http://www.checkpoint.com won't resolve with Firefox
yet will with Internet Explorer and Safari. I know Microsoft won't let
you do what you need to do with Firefox yet am surprised with Check
Point. 

Above.net is not echoing ICMP, though, before one reaches Check Point.

>From the NANOG group, I found out it is possible to use command line
switch to specify type of traffic and to get around ICMP issue.
Apparently, TCP works; however, another person said UDP is preferred
embodiment.

This test resolved web site yet resulted in lost connection:

telnet www.checkpoint.com 80
GET / HTTP/1.1
Host: www.checkpoint.com

I captured packets with Wireshark yet did not see anything that jumped
out at me as root cause for failure.

Meanwhile back at the ranch, my friend brought over business card for
Check Point representative, and I plan to pick up the phone and call
thereby bypassing TCP/IP in its entirety.


-Original Message-
From: smbmanagedservi...@yahoogroups.com
[mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of James_TDS
Sent: Thursday, August 09, 2012 10:50 AM
To: smbmanagedservi...@yahoogroups.com
Subject: RE: [SMBManagedServices] RE: next hop packet loss

Go back a few post and see where I mentioned that the hop in question
was not responding to the ICMP request, it wasn't down they just refuse
to echo. 

Probably a more valid test would have been:

telnet checkpoint.com 80
GET

However I just tested that as well and Checkpoint doesn't respond
correctly. Not sure what they are doing on the frontend but they are
breaking Internet "rules" probably in an effort to not be DDOS'd. I
checked again with SLChecker and it responds correctly so they are
likely not responding to Telnet because it doesn't send a user agent ID.


-Original Message-
From: smbmanagedservi...@yahoogroups.com
[mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of Jim Ray
Sent: Thursday, August 09, 2012 8:39 AM
To: smbmanagedservi...@yahoogroups.com
Cc: Herring, David
Subject: [SMBManagedServices] RE: next hop packet loss

Hey, I get the idgit award for this one. Time Warner's next hop that was
dropping packets was really a situation where next hop was not
responding to ICMP from tracert. Neither of us was able to diagnose the
problem until last night when I found out Safari pulled up
http://www.checkpoint.com from same network and Firefox on PC did not.

So, apparently, Check Point does not like Firefox. Internet Explorer
worked.

Meanwhile back at the ranch, I have learned about TCP switch in tracert
thanks to peers here and on NANOG and have gotten down and dirty with
Wireshark.

Regards,

Jim Ray, President
Neuse River Networks
2 Davis Drive, PO Box 13169
Research Triangle Park, NC 27709
919-838-1672 x100
www.NeuseRiverNetworks.com


-Original Message-
From: Herring, David [mailto:david.herr...@twcable.com]
Sent: Thursday, August 09, 2012 7:54 AM
To: Jim Ray; Adrian Bool
Subject: RE: next hop packet loss

  Got it.. no worries.. I know we are not always the best either!

  What would be great- that you let the below be known to your user
group?
  I know we let them know when we thought it was Business class
problem...



David Herring