srvarma@zookeeper.cns.syr.edu (* Sandeep Varma *) (11/16/90)
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) ============================================================================== X-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.... ---------------------------------------------------------------------------- X-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". ----------------------------------------------------------------------------- X-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. ------------------------------------------------------------------------------ X-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. ------------------------------------------------------------------------------ X-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. ----------------------------------------------------------------------------- X-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 ----------------------------------------------------------------------------- X-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). This is sketchy but hope it's enough. ---------------------------------------------------------------------------- X-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! ---------------------------------------------------------------------------- X-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. ---------------------------------------------------------------------------- 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. --------------------------------------------------------------------------- X-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 ----------------------------------------------------------------------------- X-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... ----------------------------------------------------------------------------- X-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.