Perrine@LOGICON.arpa (Tom Perrine) (08/15/86)
We are a fairly new BSD site and are encountering some small difficulties. Our current head scratcher involves "talk" and some other similiar programs. When I try to talk to someone I get the screen cleared and then a message "Bad Socket (43)" or somesuch. When I looked this up in intro(2), I discovered that 43 is "Protocol not supported". The system where this occurs is not on a network, although we have been playing with the config file, trying to get this to work. Our config file is as follows: # # FRODO # machine vax cpu "VAX780" ident FRODO timezone 8 dst maxusers 32 options INET config vmunix root on hp controller mba0 at nexus ? disk hp0 at mba? drive 0 disk hp1 at mba? drive 1 controller mba1 at nexus ? master mt0 at mba? drive ? tape mu0 at mt0 slave 0 controller uba0 at nexus ? device dmf0 at uba? csr 0160340 flags 0x00ff vector dmfsrint dmfsxint dmfdaint dmfdbint dmfrint dmfxint dmflint pseudo-device pty pseudo-device loop pseudo-device inet Can anyone guess what we have done wrong? Or is "talk" trying to use some network facility that we need (even for local "talking")? Thanks Tom Perrine
bzs@BU-CS.BU.EDU (Barry Shein) (08/15/86)
Just a few quick notes: TALK is brain-damaged, I would not think of it as a standard utility, it definitely should have been in the 'unsupported' (new) directory, it would have been more honest. The code looks like it was written by a hyperactive 12 year old on a sunday night deadline... HOWEVER, it should work locally. It only uses UDP, even on the local machine, but your config looks like it should work (does local 'tftp' work?, that would be a good test, if not then something is wrong with your UDP.) Also, make sure the talk daemon (talkd) is running as it is what glues connections together tho it doesn't sound like this is the problem. The problems with talk are (some are not really talk): 1. It is full of byte order difficulties, TALK on a VAX cannot speak with TALK on a SUN (for example.) Some people have cleaned this up. 2. If you are running 4.2bsd right out of 'the box' then your 4.2 probably has the udp checksum bug which will further frustrate attempts to speak non-locally to anything but another machine with the same (self-consistent) bug. 3. If you talk to a machine through a gateway and there's another way back the return path for the talk daemon often finds the other way and they can't get the conversation going. At least I'm pretty sure that's what one of my systems people was telling me was the problem a while back, not sure. SOOO...what's the solution? There's a public domain program, 'phone', which does about the same thing (better, I believe it supports multi-way conversations), doesn't have the byte order problems etc. If you want it I could pack it up and mail it to you. We gave up on talk a while ago. As a matter of fact, now that you mention it, I'm going to delete talk and link the command to phone as we get someone going crazy every so often because they unwittingly ran talk. (I did not write phone, just offering to send my copy, it was distributed in the USENET sources distribution so I'm sure it's freely distributeable.) -Barry Shein, Boston University
guy@sun.uucp (Guy Harris) (08/19/86)
> When I try to talk to someone I get the screen cleared and then a > message "Bad Socket (43)" or somesuch. Barry's right, it is a crock. The proper punishment for putting out code that dumps the numerical value of "errno", instead of the appropriate message when it exists, is keelhauling. Behind a land yacht. If they haven't heard of "sys_errlist", what are they doing writing UNIX utilities? > When I looked this up in intro(2), I discovered that 43 is "Protocol not > supported". The system where this occurs is not on a network, although > we have been playing with the config file, trying to get this to work. > > Our config file is as follows: > ... > options INET The only place in a standard 4.2BSD kernel (I presume yours is standard, right?) that gives that error is the "socket" call, and it only gives that error if no protocol of the type asked for exists. "talk" asks for a socket of type SOCK_STREAM in address family AF_INET, and then for a socket of type SOCK_DGRAM in the same address family. The only way that can fail is if you haven't configured in Internet protocol support, but it's there in your config file. It sounds like your kernel build got fouled up somehow, and your kernel isn't in sync with your config file; make *sure* that the module "netinet/in_proto.c" was compiled to make "in_proto.o" and that this module was included in your system. Also make sure that the module "uipc_domain.o", compiled from "sys/uipc_domain.c", has "inetdomain" as an undefined ("nm uipc_domain.o | egrep inetdomain" should find this out). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
naim@nucsrl.UUCP (abdullah) (08/20/86)
Tom Perrine writes: >Our current head scratcher involves "talk" and some other similiar >programs. When I try to talk to someone I get the screen cleared and >then a message "Bad Socket (43)" or somesuch. When I looked this up in >intro(2), I discovered that 43 is "Protocol not supported". The system >where this occurs is not on a network, although we have been playing >with the config file, trying to get this to work. I would speculate that the problem is with /etc/hosts rather than with the configuration file. The reason is that we had similar problems with our 780 running 4.2 (not on any network). The light dawned on me when I read an article by Fred Avolio (ihnp4!decuac!avolio) in net.bugs.4bsd regarding a problem with syslog running on a machine not on a network. Such a machine HAS to have the word "localhost" in it's /etc/hosts entry. The address does not matter (although 0 is probably not a good idea since it is used for something special; I forget what). You should edit your /etc/hosts to put in localhost ; kill your current talk daemon and restart it. Hopefully it will work. Here is our /etc/hosts: # # Host Database # 127.0.0.1 nucsrl localhost Can some guru explain where in the *source* is the presence of localhost checked for? Is it in the network library routines or where ? (certainly not in the source for talk) Naim Abdullah Dept. of EECS, Northwestern University ihnp4!nucsrl!naim
chris@umcp-cs.UUCP (Chris Torek) (08/21/86)
>Tom Perrine writes: >>Our current head scratcher involves "talk" and some other similiar >>programs. ... > In article <2410001@nucsrl.UUCP> naim@nucsrl.UUCP (abdullah) writes: >I would speculate that the problem is with /etc/hosts rather than >with the configuration file. ... I read an article by Fred Avolio [Look, Fred, someone finally spelled your name right! :-)] >(ihnp4!decuac!avolio) in net.bugs.4bsd regarding a problem with >syslog running on a machine not on a network. > Such a machine HAS to have the word "localhost" in its /etc/hosts >entry. The address does not matter (although 0 is probably not a good >idea since it is used for something special; I forget what). However, it should always be 127.0.0.1, lest `martian datagrams' leak out later. You must also be sure to `ifconfig lo0 localhost up' in /etc/rc or /etc/rc.local. Alas, I do not believe that this is related to the talk bug; syslog and talk were both new in 4.2BSD, and the author(s) of talk most likely did not know about syslog. (Indeed, I believe that only sendmail knew of syslog in 4.2BSD.) All of this is quite different in 4.3 (and possibly in Ultrix 1.2 as well). > Can some guru explain where in the *source* is the presence of >localhost checked for? Is it in the network library routines or >where? (certainly not in the source for talk) The syslog routines open an AF_INET connection to `localhost's syslog port. If you have no `localhost' entry, the 4.2BSD syslog that is part of sendmail opens the console instead, then prints a bogus message about not being able to open /dev/console. (As I recall, there were two `syslog's on our 4.2 tapes; at most one of them---the one in sendmail's aux directory---worked at all.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu