Folks,
Here is the summary of the responses that I got regarding my query to net on
(a) Why a user can't successfully "talk" between a Sun and a 4.3BSD machine (in
either direction) AND (b) Why "Checking for invitation on caller's machine"
occurs sometimes while trying to "talk" between 2 different machines?
My apologies for delay in posting it soon. Hope it helps!
Regards,
Sandeep.
(srvarma@zookeeper.cns.syr.edu)
==============================================================================
>From: auspex!guy@uunet.UU.NET (Guy Harris)
> We are running SunOS 4.0.3 on our Sun-3.60s. We have observed following
> problem while using talk between a sun machine and a 4.3BSD machine. Either
> way, it says "Checking for invitation on caller's machine" and gets stuck
> forever.
It means the SunOS "talk" is *not* a 4.3BSD-flavored one; the 4.2BSD
"talk"/"talkd" and the 4.3BSD one are different, and don't even use the
same port number.
> Does anyone have any clues to what this means? I did RTFM on talk but did
> find anything on this. Incidentally, someone mentioned that talk between
> a Sun and a non-Sun machine is corrected of problems in 4.3BSD.
More correctly, the 4.3BSD "talk" doesn't have the byte-order
dependencies that the 4.2BSD "talk" had and that the SunOS "talk" tries
to compensate for.
> Now I can understand why talk originated from a Sun to a 4.3BSD
> machine still hangs (since sun did not use BSD talk source) but
> why same thing happens when talk originates from a BSD machine?
Because the 4.3BSD "talk" is trying to find a 4.3BSD "talkd" on the Sun,
and not finding it....
----------------------------------------------------------------------------
>From: auspex!guy@uunet.UU.NET (Guy Harris)
> The 4.2BSD machine I mentioned is a Gould NP-1 running their UTX OS (which
> according to their manual was 4.2 based) whereas the 4.3 machine is running
> 4.3BSD itself. So maybe, Gould did not use talk from 4.2BSD and wrote their
> own version which is compatible with 4.3BSD. Just a thought!
Could be. The 4.2BSD "talk" uses UDP port 517; "/etc/services" would
have a line like
talk 517/udp
The 4.3BSD "talk" uses UDP port 518; "/etc/services" would have a line
like
ntalk 518/udp
If there's an "ntalk" line in the UTX system's "/etc/services" file (or
YP map, if it uses YP), then it probably has a 4.3BSD-flavored "talk".
-----------------------------------------------------------------------------
>From: auspex!guy@uunet.UU.NET (Guy Harris)
> Do you know if SunOS 4.1 uses 4.3BSD talk or it still uses old talk (from
> 4.2BSD as does the SunOS 4.0.3)?
Dunno; our one 4.1 machine here has a bad disk. I suspect it still uses
the old "talk", unfortunately.
One headache is that what you really want is a "talk" that first tries
to contact the "ntalk" daemon and, if it finds out that there isn't one
(it turns out that if you do a "connect" on a UDP socket, any ICMP Port
Unreachable errors - which you'll get if you try to send to a port that
nobody's listening on - will be returned on that socket, so you may be
able to discover that there isn't an "ntalk" daemon), falls back on
trying to talk to the old "talk" daemon.
I'd looked into that briefly when I was at Sun, but didn't have time to
implement it. It might also have been too late to get it into 4.0; the
guy who was going to put the 4.3BSD "talk" into 4.0 was too busy on
other things, like porting SunOS to the 68030 chip and the SPARCStation
1 (no, it wasn't me), and that port unfortunately fell through the
cracks.
It was especially unfortunate because AT&T picked up the Sun-modified
4.2BSD "talk", rather than the 4.3BSD "talk", for System V Release 4;
one of these days I may have to try again at making a 4.3BSD-flavored
"talk" that can fall back on the old protocol and work with older
"talk"s, and send it back to Sun and AT&T.
------------------------------------------------------------------------------
>From: jas@proteon.com (John A. Shriver)
Talk as shipped on 4.2bsd had byte order problems. They fixed it in
4.3. The versions are incompatible in either dirction.
------------------------------------------------------------------------------
>From: Mark Tinguely <tinguely@plains.NoDak.edu>
in no dis-respect, but the infamous talk problem has been "talked" about
several times on this group. sun networking code (as well as their OS), is
based on BSD 4.2. But the talk protocol has been re-implemented and even
uses a different port number. this new talk runs on BSD 4.3, 4.3 tahoe, and
4.4 (some 4.4 networking programs have been released).
I keep the old talk in a file called otalk for backward compatibilty to
old encore, sequents and suns that will not migrate to the new talk. Mainly
though our users use the new talk as the default.
the source for talk can be found on uunet (anonymous ftp) in the
bsd/sources/src/networking directory.
-----------------------------------------------------------------------------
>From: David Ross <USERDAR@UALTAMTS.BITNET>
Hi! We've got a network with 4 Suns and 3 NeXT machines here and
we ran into the same problem. What we did was replace Sun's talk
(and talkd) with 4.3tahoe version of talk. I have a copy here, but
I think it's also available at titan.rice.edu.
Yes, the same problem occurs if you originate from the Mach machine
as well (reason why we had to change talkd). It uses different TCP
ports I believe.
-----------------------------------------------------------------------------
>From: Mark J. Kilgard <@rice.edu:mjk@louie.rice.edu>
Sandeep,
>> We are running SunOS 4.0.3 on our Sun-3.60s. We have observed following
>> problem while using talk between a Sun machine and a 4.3BSD machine.
>> Either way, it says "Checking for invitation on caller's machine" and gets
>> stuck forever.
We had a problem with talk not working that turned out to be a bug
in talk - Sun sent us a patch. The problem we had involved the
initiating machine spraying the network with packets to the point
of staturating our entire network making the entire network
on I can't tell if this is your problem or not.
If it is, I can send you details.
- Mark Kilgard
-----------------------------------------------------------------------------
>From: Edward Vielmetti <emv@math.lsa.umich.edu>
get the new talkd from uunet.uu.net. install it as "ntalkd" on the
proper port. (it's in bsd-sources on uunet). byte-order problems.
this is sketchy but hope it's enough.
--Ed
----------------------------------------------------------------------------
>From: remaker@pepsi.AMD.COM (Phillip Remaker)
Simple: BSD talk and SunOS talk are wholly incompatible. We had the
same problem at AMD and at U Penn.
If you learn anything differen, let me know!
-Phil
----------------------------------------------------------------------------
>From: "Anthony A. Datri" <convex!datri@uxc.cso.uiuc.edu>
Talk is not architecture dependent (grumble). There are
arch-independent talks out there, or you can use xtalk if you're running X.
----------------------------------------------------------------------------
>From: Steve Brown <steve@cs.odu.edu>
Sun Sez: ``It don't work''
there ain't no standard talk protocol... thus suns & 4.[2-3]BSD talk won't
work.
---------------------------------------------------------------------------
>From: roberto@bondi.phyast.pitt.edu (Roberto Gomez)
Your may have RTFM, but your sources are MFT (an argentinian dictum,
the best translation I can offer is `pissing off the toilet', if you
know what I mean :-).
There is a 4.2 BSD and a 4.3 BSD talk and they are incompatible (that is,
they won't `talk' to each other). The one Sun uses is the one from 4.2 BSD.
The ``Checking for invitation on caller's machine'' is what you get when
a 4.2 talk tries to chat with a 4.3 one and viceversa. You'll have to install
either a 4.3 talk on the Sun or a 4.2 talk on the other machine.
On the local CIS Ultrix Vax they have the old (4.2) talk installed as `otalk'.
When I start a talk from the Sun, this is what shows up on the the Vax:
Message from Talk_Daemon@unix.cis.pitt.edu at 13:04 ...
talk: connection requested by roberto@bondi.phyast.pitt.edu.
talk: respond with: otalk roberto@bondi.phyast.pitt.edu
Replying with `otalk' works, trying to use `talk' bombs with the
``Checking for invitation on caller's machine'' message.
Hope this clears some of the confusion. -roberto
-----------------------------------------------------------------------------
>From: kucharsk@Solbourne.COM (William Kucharski)
The "Checking for invitation" message usually appears and hangs when talkd
is not being started on the remote machine. This is usually due to a
difference in "well known" port numbers for talk between the two machines,
or because talkd isn't in the target machine's inetd.conf.
Let me know if this info helps you out any...
-----------------------------------------------------------------------------
>From: imp@Solbourne.COM (Warner Losh)
Sun uses old talk, bsd 4.3 uses new talk. they use different udp port
numbers to check for invitations, etc. Your best bet is to grab the
source to ntalk (4.3) from uunet and hack it so that it works on suns.
Then replace the talk that comes with the suns.
============================================================================
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:59 CDT