daveb@gonzo.UUCP (Dave Brower) (10/17/88)
A number of the machines I use support only the tcp and udp protocols. I'd really like to be able to ping from them. Is there any hope, short of harrassing the vendors? thanks, -dB
egisin@watmath.waterloo.edu (Eric Gisin) (10/19/88)
In article <440@gonzo.UUCP>, daveb@gonzo.UUCP (Dave Brower) writes: > A number of the machines I use support only the tcp and udp protocols. > I'd really like to be able to ping from them. Is there any hope, short > of harrassing the vendors? Yes, port SUN RPC to your machines (see your comp.sources.unix archives). Run the etc/portmap server, this will serve as a RPC/UDP ping server. Then write a 20 line ping client that does an RPC call to the portmapper's NULL procedure (described in the documentation). PC/NFS has this program, they call it nfsping.
cmf@cisunx.UUCP (Carl M. Fongheiser) (10/20/88)
In article <527@mks.UUCP> egisin@watmath.waterloo.edu (Eric Gisin) writes: >In article <440@gonzo.UUCP>, daveb@gonzo.UUCP (Dave Brower) writes: >> A number of the machines I use support only the tcp and udp protocols. >> I'd really like to be able to ping from them. Is there any hope, short >> of harrassing the vendors? > >Yes, port SUN RPC to your machines (see your comp.sources.unix archives). > [more words about RPC and the portmapper] Sure, you could do that, but I think it'd be a LOT easier to implement the UDP echo protocol. Likely to have a lower overhead cost, too. Carl Fongheiser University of Pittsburgh ...!pitt!cisunx!cmf cmf@unix.cis.pittsburgh.edu cmf@pittunix.BITNET
geoff@eagle_snax.UUCP ( R.H. coast near the top) (10/20/88)
In article <527@mks.UUCP: egisin@watmath.waterloo.edu (Eric Gisin) writes: :In article <440@gonzo.UUCP:, daveb@gonzo.UUCP (Dave Brower) writes: :: A number of the machines I use support only the tcp and udp protocols. You mean they're in violation of the RFC's? :-( ICMP is an integral part of IP, and it's got to be in there. Presumably you mean there's no user-accessible interface to ICMP services. :: I'd really like to be able to ping from them. Is there any hope, short :: of harrassing the vendors? : :Yes, port SUN RPC to your machines (see your comp.sources.unix archives). :Run the etc/portmap server, this will serve as a RPC/UDP ping server. :Then write a 20 line ping client that does an RPC :call to the portmapper's NULL procedure (described in the documentation). :PC/NFS has this program, they call it nfsping. Minor nit: "nfsping" actually calls the null procedure of the mount daemon rather than that of the portmapper, since we figured this was more useful to the user. This was probably the wrong choice, since one can find out if the mount daemon is up in a variety of ways (rpcinfo, showmount, etc.). -- Geoff Arnold, Sun Microsystems Inc.+------------------------------------------+ PC Distrib. Sys. (home of PC-NFS) |If you do nothing, you will automatically | UUCP:{hplabs,decwrl...}!sun!garnold|receive our Disclaimer of the Month choice| ARPA:garnold@sun.com +------------------------------------------+
hedrick@athos.rutgers.edu (Charles Hedrick) (10/21/88)
>> A number of the machines I use support only the tcp and udp protocols. >> I'd really like to be able to ping from them. Is there any hope, short >> of harrassing the vendors? I think there is a confusion here. If they support TCP and UDP they have to support IP. (IP is the lower layer on top of which TCP and UDP are implemented.) Ping is implemented using ICMP echo. The IP specifications require all IP implementations to support ICMP echo. Now technically speaking all the spec requires is that your machine must respond to echos sent by other machines. But once the mechanism is present, I'd be a bit surprised if there isn't a way to issue a ping yourself. So I'll bet there's some way to make it work. What implementations are we talking about?
pf@csc.ti.com (Paul Fuqua) (10/22/88)
Date: Thursday, October 20, 1988 6:28am (CDT)
From: geoff at eagle_snax.UUCP ( R.H. coast near the top)
Subject: Re: Dumb question: ping w/o icmp support?
Newsgroups: comp.protocols.tcp-ip
In article <527@mks.UUCP: egisin@watmath.waterloo.edu (Eric Gisin) writes:
:In article <440@gonzo.UUCP:, daveb@gonzo.UUCP (Dave Brower) writes:
:: A number of the machines I use support only the tcp and udp protocols.
You mean they're in violation of the RFC's? :-( ICMP is an integral
part of IP, and it's got to be in there. Presumably you mean there's
no user-accessible interface to ICMP services.
We have a VMS machine running a locally-hacked version of the CMU TCP/IP
package, and it doesn't respond to ICMP echoes, although it does FTP
just fine (albeit slowly). Violation or not, it's all we have and
better than Decnet (for our purposes).
:: I'd really like to be able to ping from them. Is there any hope, short
:: of harrassing the vendors?
There are also UDP and TCP echoes, you might try them.
pf
Paul Fuqua
Texas Instruments Computer Science Center, Dallas, Texas
CSNet: pf@csc.ti.com (ARPA too, sometimes)
UUCP: {smu, texsun, cs.utexas.edu, im4u, rice}!ti-csl!pfmedin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (10/23/88)
There are implementations out there that fail to support ICMP. Some that even fail to support default routes! The vendors out there that sell such 'products' are committing crimes against the Internet community, since we have to debug problems involving such. Some vendors which you wouldn't suspect don't even do ARP! I personally know of several implementations which are broken in the above ways, but I'd probably get sued if I spoke up on the net. I'll let the poor users who got this stuff because of a 'lowest bid' procurement speak up themselves. If any of you vendors that are broken read this note, shame on you for building defective stuff! One thing though, most of these implementations find homes on the MILNET, which still has many hosts directly connected and not relying on gateways as much as the rest of us... I think DARPA missed the boat here; they should have registered TCP/IP as a registered trademark like ADA, and required certification. Milo
budden@tetra.NOSC.MIL (Rex A. Buddenberg) (10/24/88)
Milo, You are correct that ICMP and ARP et al should be part of a minimal spec. No arguments there...just the observation that getting the right set of specs into a contract isn't very easy -- no cookbook for TCP/IP. The GOSIP effort is designed to head off some of those problems. Now, to DARPA's execution. Making TCP/IP a trademark and requiring certification certainly would handle a lot of your concerns, but DARPA is an agancy for advanced research. DCA should be doing this kind of work at the production level, not DARPA. Indeed, they are doing some certification work and the horse is so far out of the barn that trademarking TCP/IP is not fesible now. Note that the Ada Joint Program Office (Ada, not ADA) is in the office of the Secretary of Defense, not DARPA. Rex Buddenberg
mre@beatnix.UUCP (Mike Eisler) (10/25/88)
> In article <527@mks.UUCP: egisin@watmath.waterloo.edu (Eric Gisin) writes: > :In article <440@gonzo.UUCP:, daveb@gonzo.UUCP (Dave Brower) writes: > :: A number of the machines I use support only the tcp and udp protocols. > > You mean they're in violation of the RFC's? :-( ICMP is an integral > part of IP, and it's got to be in there. Presumably you mean there's ^^^^^^^^^^^^^^^^^^^ > no user-accessible interface to ICMP services. It's *got* to be in there? What will happen if I don't implement it? Will the IP police come for me? Or will God send lighting my way? I once implemented a simple UDP and IP for an AT&T 3b15 that was to be used as an NFS server for a LAN of NFS clients. It worked quite well without ICMP. I agree that you probably wouldn't want this implementation on a public network, but it served the customer's limited purposes. -Mike Eisler (For the record, I did this before I came to ELXSI, and all of ELXSI's operating systems implement ICMP.)
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (10/25/88)
In article <8810221819.AA10475@nsipo.arc.nasa.gov> medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes: > >There are implementations out there that fail to support ICMP. [...] > >I personally know of several implementations which are broken in the >above ways, but I'd probably get sued if I spoke up on the net. > Milo I can practically guarantee that: a) those fingered vendors would fix their products b) you would get sued What a shame. The Host Req'ts RFC is a big step forward, even contains an easily abused checklist (as all the authors will take pains over the coming years to point out everytime they speak in public :-), but there is no way anyone can actually *SAY* what their research shows is true, ie vendor X is not in compliance with paragraph 3.1.2.3. (Not without considerable risk.) Well, I shouldn't complain. Just gives me an excuse to go to a conference and have Milo tell me in person what a crock such and such is. A year or so after the Host RFC, maybe we could share LANalyzer (or your favorite Ethernet analyzer) programs that check all the RFC points? Let the LANalyzer do the talking! Probably impractical, but wouldn't be nice to plug a new box into a protocol testing box and watch the red light and the green light? (I know, I'm lazy and no fun at all.)
braden@VENERA.ISI.EDU (10/25/88)
A year or so after the Host RFC, maybe we could share LANalyzer (or your favorite Ethernet analyzer) programs that check all the RFC points? Let the LANalyzer do the talking! Probably impractical, but wouldn't be nice to plug a new box into a protocol testing box and watch the red light and the green light? (I know, I'm lazy and no fun at all.) Kent, Your box is going to have several different shades of yellow lights on it, shading between red and green. It is not a simple world, as the Host Requirements Working Group has repeatedly rediscovered. Bob Braden
wunder@SDE.HP.COM (Walter Underwood) (10/26/88)
I can practically guarantee that:
a) those fingered vendors would fix their products
b) you would get sued
This is silly. I would dearly love to see some of our competitors
sue customers. They'd never sell them a power cord after that.
There is no guarantee they'd fix the problem, either.
This sort of report has been done before, and published as a series
of RFCs. The Smallberg surveys are summarized in RFC-847. They
focussed on Telnet, FTP, and SMTP, but it was the same idea.
If you want to report this stuff, do it this way:
state the CPU, OS, and release of the pinger and pingee,
be prepared to repeat the configuration,
make sure that the product is really advertised as TCP/IP,
report it to the vendor at the same time you tell us.
If the information is true, you don't mis-represent the manufacturer,
and you do not have some other obligation (non-disclosure, procurement
regs), then nobody can complain.
The point about mis-representing the vendor is important. If the
vendor doesn't claim that the product is TCP/IP, then they really
don't have an obligation to meet the specs. It is still safe to point
out, "this is not advertised as TCP/IP, and sure enough, it doesn't
answer ICMP Echo."
An example of something that may use TCP, but isn't advertised as
such, is HP's OfficeShare for PCs. It does disk and printer sharing
for PCs, with a PC or HP3000 server. I suspect that it uses TCP/IP,
but it certianly isn't advertised as something that is supposed to
inter-operate with non-OfficeShare stuff. I've never tried to ping
it, so I don't know if it supports ICMP Echo.
wunderhrp@snoid.CRAY.COM (Hal Peterson) (10/26/88)
Through the magic of IP, any machine that can attach to any LAN anyware can suddenly talk to anything anywhere, and must be a good citizen, expected to put up with delays and ICMPs and other flakinesses that don't happen on the neighborhood Ethernet. The Internet old-timers have used up cases of analgesics trying to ease the headaches caused by implementations that ``you probably wouldn't want on a public network, but serve the customer's limited purposes.'' In some ways we would be far better off with IP police than we have been without them (you can never find one when you need one). Hal -- Hal Peterson / Cray Research / 1440 Northland Dr. / Mendota Hts, MN 55120 hrp%hall.cray.com@uc.msc.umn.edu bungia!cray!hrp (612) 681-3145
henry@utzoo.uucp (Henry Spencer) (10/27/88)
In article <8810251528.AA04950@braden.isi.edu> braden@VENERA.ISI.EDU writes: >Your box is going to have several different shades of yellow lights on it, >shading between red and green... No, better it should have a bar-graph display; all those yellow lights will be hard to tell apart. Now, what units would TCP/IP non-compliance be expressed in? Obviously the technical name of the quantity being measured is something like "bogosity", but what are the units? :-) (By analogy to whetstones and dhrystones and the like, I'm tempted to suggest "Millstones"!) -- The dream *IS* alive... | Henry Spencer at U of Toronto Zoology but not at NASA. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
roy@phri.UUCP (Roy Smith) (10/29/88)
henry@utzoo.uucp (Henry Spencer) writes: > Obviously the technical name of the quantity being measured is something > like "bogosity", but what are the units? :-) Given that the quantity is bogosity, and the universe in which this quantity exists is the swamp, it seems that "the bog" is the obvious name for the unit of measure. Next question; do we define a fixed goodness-to-badness continium with 1 bog being totaly bogus (thus, a 10 decibog box would be 90% in compliance with the specs) or do we define an open-ended scale, on the assumption that no matter how bad something is, somebody will always manage to come along with something worse? -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
jordan@zooks.ads.com (Jordan Hayes) (10/30/88)
Roy Smith <roy@phri.UUCP> writes:
Given that the quantity is bogosity ...
Wasn't it Honeyman who pronounced Mark Horton's old machine (cbosgd)
as "See Bogosity" ...?
/jordanMills@UDEL.EDU (10/30/88)
Henry, As for Millstones as a measure of network bogosity, be advised a wag or two seem to have preempted the term as a measure of gateway throughput. As in your case, the units of measure, as well as the procedures of measurment, are in dispute. The committee convened to settle the issues met in the corner pub, became Millstoned and turned into a puff of hot air. Boy, that was close. Dave
henry@utzoo.uucp (Henry Spencer) (11/01/88)
In article <3575@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > Given that the quantity is bogosity, and the universe in which this >quantity exists is the swamp, it seems that "the bog" is the obvious name for >the unit of measure... Best suggestion I've heard so far. There have been a few truly interesting ones by private mail, but the better ones are unprintable. (Among the also-rans are the "Berkeley", the "ATTIS", and the "Sun".) The "Millstone" is already spoken for, alas: it's the unit of gateway throughput! :-) >Next question; do we define a fixed goodness-to-badness >continium with 1 bog being totaly bogus (thus, a 10 decibog box would be 90% >in compliance with the specs) or do we define an open-ended scale, on the >assumption that no matter how bad something is, somebody will always manage >to come along with something worse? "Decibog" sounds clumsy. I'd propose that the main scale runs from 0 to 10 bog, with higher (and negative) ratings reserved for exceptional cases. -- The dream *IS* alive... | Henry Spencer at U of Toronto Zoology but not at NASA. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
smiddy@SPAM.ISTC.SRI.COM (Richard Smith, smiddy@spam.istc.sri.com) (11/01/88)
People who want to know how it works should visit Milstone, N.J...(:-). Smiddy
henry@utzoo.uucp (Henry Spencer) (11/04/88)
In article <1988Oct31.215228.18443@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>...it seems that "the bog" is the obvious name for >>the unit of measure... > >Best suggestion I've heard so far... Problem (pointed out by Craig Partridge): we really don't want to measure bad network implementations with a unit that sounds too much like Dave Boggs's last name. He's one of the good guys. -- The Earth is our mother. | Henry Spencer at U of Toronto Zoology Our nine months are up. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
Mills@UDEL.EDU (11/06/88)
Henry, Hey, you guys drop Millstones around my neck, howcum Dave Boggs gets relief? Why not invert the measure, so that High Bog stands for squeaky clean and Low Bog stnads for the other kind? The unit, of course, would be the Bogg and calibrated to MTBF. Dave
kent@WSL.DEC.COM (11/08/88)
A long time ago, in a context far, far away, the standard unit of bogosity was declared to be the "lenat". Except that, like the coulomb, 1 lenat is so large that one normally uses the microlenat. We may or may not wish to resurrect this usage.
mckee@MITRE.ARPA (H. Craig McKee) (11/13/88)
>From: kent@wsl.dec.com > >A long time ago, in a context far, far away, the standard unit of >bogosity was declared to be the "lenat". Except that, like the coulomb, >1 lenat is so large that one normally uses the microlenat. I give up, who was Mr/Mrs/Ms/Miss Lenat ? - Craig
LYNCH@A.ISI.EDU (Dan Lynch) (11/14/88)
Dr. Doug Lenat did his thesis work on heuristic methods of proving simple mathematical properties. Doug was not known for tackling easy problems. Nor for shyness. And he was the most voracious user of PDP-10 cycles in the '70s. Dan -------