SUMMARY: 'ping MAIL.MSN.COM' aborts.

From: Frank Pardo (fpardo@tisny.com)
Date: Tue Sep 17 1996 - 16:31:32 CDT


Friends,

The answer is that there's a "new" ICMP message type that Sun's ping
program doesn't know about yet; but GNU ping does.

Many thanks to all who responded, especially Melissa Metz and Paul Kanz,
whose replies were the most interesting and informative. Also to Justin
Young and Melissa Metz for taking the trouble to send 2 replies apiece.

        Leo Anzola Tue Sep 17 14:04 18/671
        Jim Reisert Tue Sep 17 14:26 13/424
        Rich Casto Tue Sep 17 14:51 10/305
        Justin Young Tue Sep 17 14:54 15/530
        Justin Young Tue Sep 17 14:57 12/438
        Paul Kanz Tue Sep 17 15:08 50/1871
        Melissa Metz Tue Sep 17 15:12 19/777
        Ron Loftin Tue Sep 17 15:17 14/601
        Tommy Williams Tue Sep 17 15:21 23/708
        Melissa Metz Tue Sep 17 15:27 13/459
        Edward Grimm Tue Sep 17 16:04 51/2336

========================================================================
        T H E I N Q U I R Y
========================================================================

Date: Tue, 17 Sep 1996 12:38:27 -0400 (EDT)
From: fpardo@tisny.com (Frank Pardo)
Subject: 'ping MAIL.MSN.COM' aborts.

Anyone got an idea why PING-ing Microsoft would cause an abort? (Yes,
droll replies are also welcome.) Here's what happened:

 | => mailq
 | Mail Queue (1 request)
 | --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient-----
 | KAA07025 232 Tue Sep 17 10:46 fpardo
 | (Deferred: Connection refused by mail.msn.com.)
 | campo315@msn.com
 | rmangino@msn.com
 | => ping -s mail.msn.com
 | PING mail.msn.com: 56 data bytes
 | Segmentation Fault
 | => uname -a
 | SunOS garcia 5.4 Generic_101945-10 sun4c sparc
 | =>

For what it's worth, "nslookup" got 3 addresses for this one:

 | => nslookup
 | Default Server: mail.tisny.com
 | Address: 206.71.232.6
 |
 | > mail.msn.com
 | Server: mail.tisny.com
 | Address: 206.71.232.6
 |
 | Non-authoritative answer:
 | Name: mail.msn.com
 | Addresses: 204.95.110.80, 204.95.110.84, 204.95.110.75
 |

Using the IP address instead of the name also got a segmentation fault.

========================================================================
        T H E R E P L I E S
========================================================================

Date: Tue, 17 Sep 1996 13:03:41 -0500 (EST)
From: Leo Anzola <anzolala@wspan-cmd1.panama.army.mil>

My guess is that they have an ICMP firewall in place. This is standard
procedure to protect domains.

........................................................................

Date: Tue, 17 Sep 1996 14:25:40 -0400
From: Jim Reisert <jjr@databook.com>

I dunno, but it happens to me too. I did not get a core file in my
directory, so maybe the segmentation fault was reported by MSN?

........................................................................

Date: Tue, 17 Sep 1996 14:54:31 -0400
From: rich@loopexpert.com (Rich Casto)

It happens to me also, running Solaris 2.5. I have no clue why it
happens. It's no big deal, since the mail gets through eventually.

........................................................................

Date: Tue, 17 Sep 1996 13:55:49 -0500 (CDT)
From: Justin Young <justiny@cluster.engr.subr.edu>

Damn. This is a 2.5.1 thing. AIX doesn't have this problem. However,
that Q@#$!er is definitely behind a firewall!

Methinks sun should investigate!

........................................................................

Date: Tue, 17 Sep 1996 13:58:30 -0500 (CDT)
From: Justin Young <justiny@cluster.engr.subr.edu>

Nope. neither 2.5 nor 2.4 does this. Patch your 2.5.1!!!

........................................................................

Date: Tue, 17 Sep 1996 11:53:58 -0700 (PDT)
From: Paul Kanz <paul@icx.com>

Looks like 'mail.msn.com' will return bogus packets (our they are doing
creative anti-denial of service attacks). If you use GNU ping you'll
get:

<paul@fw>$ ping mail.msn.com
PING Tue Sep 17 12:02:31 1996 upmajb03.msn.com (204.95.110.80): 64 data bytes
UnReachable from 207.68.145.38: len=36 ttl=250 invalid code 13.
UnReachable from 207.68.145.38: len=36 ttl=250 invalid code 13.
UnReachable from 207.68.145.38: len=36 ttl=250 invalid code 13.
^C
----Tue Sep 17 12:02:40 1996 upmajb03.msn.com (204.95.110.80) PING
Statistics----
8 transmitted, 0 received, 100.00% packet loss.
8.749 seconds elapsed, throughput = 0.00 packets/sec; 0.000 bps.

<paul@fw>$ ping 206.71.232.6
PING Tue Sep 17 12:04:33 1996 mail.tisny.com (206.71.232.6): 64 data bytes
EchoReply from 206.71.232.6: len=64 ttl=244 seq=0 time=270.140 ms.
EchoReply from 206.71.232.6: len=64 ttl=244 seq=2 time=205.045 ms.
EchoReply from 206.71.232.6: len=64 ttl=244 seq=3 time=189.923 ms.
EchoReply from 206.71.232.6: len=64 ttl=244 seq=4 time=242.394 ms.
^C waiting for outstanding packets

----Tue Sep 17 12:04:48 1996 mail.tisny.com (206.71.232.6) PING
Statistics----
5 transmitted, 4 received, 20.00% packet loss.
15.490 seconds elapsed, throughput = 0.26 packets/sec; 173.530 bps.
round-trip (ms) min/avg/max = 189.923/226.875/270.140
                var/sdev/skew/kurt = 1318.233/36.307/0.125/0.813

........................................................................

Date: Tue, 17 Sep 96 15:12:17 EDT
From: Melissa Metz <melissa@watsun.cc.columbia.edu>

You probably got a number of replies already, but in case not...

When you ping mail.msn.com (well, when we ping it), a router along the
way returns an "unreachable" failure code of 13, which etherfind says is
"destination unreachable". ping uses the 13 to look in a table of only 6
failure codes, and the segmentation fault is the inevitable result.

Which doesn't explain why the 13 is returned and/or why ping doesn't
understand it. (Is it a new code or just a wrong one?)
/usr/include/netinet/ip_icmp.h lists only the 6 unreachable codes.

........................................................................

Date: Tue, 17 Sep 1996 11:11:56 PDT
From: rloftin@engsys.mc.xerox.com (Ron Loftin)

Good question. My machines with Solaris 2.4 patch Generic_101945-42 just
claim that this address is unreachable on the local subnet. You should
probably consider going to the patch area on SunSolve's Web page and
grabbing some more recent patches. This might help you.

On the lighter side, it may be easier to take note of stuff related to
MicroSlop that does NOT cause an abort/crash/other undesireable result.
:)

........................................................................

Date: Tue, 17 Sep 1996 14:21:10 -0500
From: Tommy Williams <tommy@vumclib.mc.vanderbilt.edu>

I see the same thing trying to get to aol.com:

$ ping users.aol.com
Segmentation Fault (core dumped)
$ uname -a
SunOS www 5.5 Generic_103093-03 sun4m sparc SUNW,SPARCstation-20

I get the same thing on an SS10 running Solaris 2.3

Unfortunately, I don't have a clue what's happening. It must be something
with the way their DNS machines route packets.

I look forward to the summary and see what others say.

........................................................................

Date: Tue, 17 Sep 96 15:27:23 EDT
From: Melissa Metz <melissa@watsun.cc.columbia.edu>

I looked in the TCP book (TCP/IP Illustrated, Volume 2). It says
number 13 is "communication administratively prohibited by filtering".
It must be new, such that ping has not been updated, nor ip_icmp.h up
to Solaris 2.5.1.

........................................................................

From: Edward Grimm <edgrimm@neptune.mtc.ti.com>
Date: Tue, 17 Sep 1996 15:01:57 -0500 (CDT)

I think the typescript would have been more diagnostic if it had another
ping -s which did not seg fault. Unfortunately, to be of more help to
you, other than to say that ping was committing suicide, rather than
talk with MS, I'd need the Solaris ping source code (which I don't
have.)

(Yeah, I know you've run ping countless other times. However, it's
sometimes possible to change something slightly so that it starts
screwing up without you realizing it. It also makes a different
impression on the mind to actually see the difference...)

I also can't test things here, because I'm behind a firewall.

========================================================================

--
  Frank Pardo		<fpardo@tisny.com> 
  System Administrator 
  Transaction Information Systems
  New York City



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:10 CDT