# ytalk

## wizy

I want to get ytalk up and going.  I merged in ytalk and netkit-talk.

I know I need to do something with in.talkd to get a talk daemon up before ytalk will work.  Anyone want to tell me what to do?

----------

## wizy

Guess im on my own with this one? Seems no one has tried or wants to.  Oh well.

----------

## Ondrej

I'm trying to set it up as well. I was going to have xinetd run the talk deamon when a connection was established. The xinetd.d file I made looked something like this:

```
service talk

{

        id              = talk

        socket_type     = dgram

        protocol        = udp

        user            = root

        wait            = yes

        port            = 517

        disable         = no

        server          = /usr/sbin/talkd

}

```

That didn't work. I added another one for ntalk (no clue what the difference is yet) which listens on port 518, but that didn't help much either.

Guess I'll have to read up more on talk in general. If anyone has it running I'll appreciate their input.

Ondrej

----------

## yold

i am having the same pb  :Sad: 

----------

## ela

I hate to say this, but I've got the same problem, too... Just to keep this thread "alive"...

Ela.

----------

## fmalabre

Me too I have this issue...

I would like to know how I could fix that...

Please help...   :Shocked: 

----------

## meyerm

Hi,

did anybody finally achieved in getting a talkd to run?

Thanks

----------

## ela

Not me.  :Sad: 

----------

## fmalabre

 *meyerm wrote:*   

> did anybody finally achieved in getting a talkd to run?

 

Me neither, but I will wait for Gentoo 1.4 to try again...

Maybe they fixed stuff...

----------

## GotTLoS

hi 

this is not the same as use the talkd but i' m able to use talk command use as demon kotalkd started with xinetd. hope it helps.

hasta

----------

## Uranus

whenever I try to start ktalkd I get:

```
# talkd

Socket operation on non-socket
```

did any of u guys get it running or what?

----------

## Naan Yaar

This error occurs if a server that is meant to start from inetd is started outside of it (e.g., from a console).  You may need to emerge xinetd, e.g., and set it up to start talkd.

 *Uranus wrote:*   

> whenever I try to start ktalkd I get:
> 
> ```
> # talkd
> 
> ...

 

----------

## GotTLoS

My /etc/xinetd.d/talk file looks like this:

```

service talk

{

        id              = talk

        socket_type     = dgram

        protocol        = udp

        user            = root

        wait            = yes

        port            = 517

        disable         = no

        server          = /usr/kde/3/bin/kotalkd

}

```

and talk works just fine.

hasta

----------

## yottabit

I hate to reopen a can of worms here, but it doesn't seem like we have any resolution.

I have merged xinetd, netkit-base, and netkit-talk. I know xinetd is working properly since I have uw-pop3d running successfully. I created /etc/xinetd.d/talk:

```
service talk

{

        id              = talk

        socket_type     = dgram

        protocol        = udp

        user            = root

        wait            = yes

        port            = 517

        disable         = no

        server          = /usr/sbin/talkd

}
```

In /etc/services I have:

```
talk            517/udp
```

I've logged into two terminals (one as root and one as zaphod)Mesg status is "y" on both terminals:

```
hal root # mesg

is y
```

When I execute "talk zaphod" the screen splits like normal, but then the following two messages are displayed:

```
[No connection yet]

[Checking for invitation on caller's machine]
```

No notification of the talk request shows up on the other console. Note also that using "write" works just fine:

```
hal root # write zaphod

This is a test.<Ctrl+D>
```

```
Message from root@hal on pts/1 at 18:02 ...

This is a test.

EOF
```

So does anyone have any clues? Obviously something is awry here, and I'd especially like some help figuring it out. Users on my system are complaining for talk/ytalk ...

Cheers!

----------

## nrosier

create a file /etc/inetd.conf with this line:

talk    dgram   udp     wait    root    /usr/sbin/talkd talkd

and launch /usr/sbin/inetd

----------

## Uranus

wooooooooooot that worked  :Very Happy: 

----------

## yottabit

 *nrosier wrote:*   

> create a file /etc/inetd.conf with this line:
> 
> talk    dgram   udp     wait    root    /usr/sbin/talkd talkd
> 
> and launch /usr/sbin/inetd

 

Okay, I've relented and merged inetd alongside xinetd (which I was already using), in another attempt to get the talk daemon running..

I've added the line as quoted above, but talk sessions still don't seem to work.

Any more suggestions?

----------

## yottabit

Hi Folks,

I finally figured out my problem. Not 100% sure how/why this is happening, but talk/ytalk is resolving my computer's hostname to my external FQDN instead of using the local hostname or address, and therefore the request packets get sent to my router, which then firewalls them from coming into the network (it's too stupid to realize the packets came from the internal port, not the external port).

Just to explain more clearly, here's my setup:

hostname: hal

FQDN: hal.jacobmcdonald.net

Internal IP: 192.168.0.10

I'm using NAT on my router... and I'm using dynamic DNS for my domain name. So therefore, the proper FQDN for my external IP address (and domain), at the moment, is rrcs-central-24-123-148-131.biz.rr.com.

For some reason, talk/ytalk acquires the EXTERNAL (rr.com) IP address instead of using the internally defined IP address. So it tries to contact that FQDN, which routes the packets to the router of course, and then the router firewall drops the packet since I don't allow the talk port inbound.

So I had two solutions:

1. Simply open the talk port on the firewall. This is fine for some, but I really didn't want to do that in the interest of security (plaintext you know).

2. Define a global alias for the talk command to use, which will automagically fill in "localhost" for the server name instead of letting the client figure it out by itself. This is accomplished by sticking

```
alias ytalk="ytalk -h localhost "
```

in a profile definition.

And then of course I renamed talk since it sux anyway, and aliased talk to ytalk so users wouldn't know the difference. ;o)

```
alias talk="ytalk "
```

So anyhow, talk/ytalk is running fine now on my system, without even having to open my firewall. Pretty swift, eh?

And if anyone knows why in the hell talk/ytalk would be trying to connect to my external FQDN, plz let me know. ;o)

Hope this helps someone!!!   :Shocked: 

----------

## thequbemaster

i was able to get talk working with inetd but i really wanted to get it working with xinetd. yottabit's instructions were very helpful, but i was still having some trouble. having searched google i finally got talk working and have one thing to add to yottabit's guide:

```

service ntalk

{

        socket_type             = dgram

        wait                    = no

        user                    = root

        server                  = /usr/sbin/in.talkd

        disable                 = no

        only_from               = localhost

} 
```

by changing user to root i was able to get everything working.

i am a newbie, and i'm guessing there's a way to get talk working with the nobody account and that setting user to root is prob not a good idea, but in the environment that i'm using talk in, it's not a risk and i'm gonna keep it like this. unless someone tells how to change it  :Smile: 

hope this helps some of you guys...

----------

## slartibartfasz

is it possible to run a talkd without inetd?

----------

## ProtectR

Ok, had the same problem, now it works

I think I figured out how it works. I don't have a lot of knowledge about how communications work under linux, but here's what I found:

IMPORTANT: The next lines suppose interface eth0 has 192.168.1.1 assigned to, and the hostname is 'einstein'

I found in my logs that if I try to talk to a user using

```

talk username

```

xinetd receives a request from 192.168.1.1. Here's my log:

```

Oct 26 22:46:46 einstein xinetd[2152]: START: ntalk pid=2271 from=192.168.1.1

Oct 26 22:46:46 einstein xinetd[2271]: FAIL: ntalk address from=192.168.1.1

```

Which means that xinetd is rejecting the request.

It also means that the request is made through the 192.168.1.1 address, which is the address binded to the network interface eth0.

The problem is, with the default settings of gentoo, xinetd only accepts requests from localhost (because of of the configuration files:

```

cat /etc/xinetd.conf

# Sample configuration file for xinetd

 

defaults

{

        only_from      = localhost

        instances      = 60

        log_type       = SYSLOG authpriv info

        log_on_success = HOST PID

        log_on_failure = HOST

        cps            = 25 30

}

 

includedir /etc/xinetd.d

```

This is why the xinetd deamon doesn't accept requests to the 518 port.

So we've got three solutions:

1) We make xinetd accept connections from local interfaces by default

2) We make xinetd accept connections from local interfaces only for the talk service

3) We make the process requesting the connection use the localhost (127.0.0.1) interface

1)

The only thing we have to do is to add the calling local interface to the only_from setting. The /etc/xinetd.conf would become, for me:

```

# Sample configuration file for xinetd

 

defaults

{

        only_from      = localhost einstein   # Note the added local interface 'einstein'. We could have put an ip address too, 192.168.1.1 in my case. Buyt einstein is referring to it - I'll get into that soon

        instances      = 60

        log_type       = SYSLOG authpriv info

        log_on_success = HOST PID

        log_on_failure = HOST

        cps            = 25 30

}

 

includedir /etc/xinetd.d

```

That way, all xinetd services will be accepted if they come from a local interface

2)

The second solution is similar. We only add the hostname to file /etc/xinetd.d/talk  :

```

service ntalk

{

#       flags                   = IPv4

        disable                 = no

        socket_type             = dgram

        wait                    = yes

        user                    = nobody

        group                   = tty

        server                  = /usr/sbin/in.talkd

        only_from             += einstein             # This line was added

}

```

That way, only the talk service is affected by the change.

3)

The last way to get around the problem is to use the localhost interface to make the request.

Using ytalk, we could use:

```

ytalk -h localhost protectr

```

which would work, but we would have to use the '-h hostname' parameter everytime. This could be resolved with an alias like:

```

alias localtalk="ytalk -h localhost "

```

The other way to get around this without an alias is by modifying the address the hostname refers to.

Here's why. When you involke talk or ytalk without specifying the interface to use, the program uses the hostname to identify which interface it should use.

So, when I involke 'ytalk protectr', it reads the hostname, which is set to 'einstein' and does a reverse address lookup to find its binded address.

The reverse lookup first looks in the file /etc/hosts to find it. Here's mine:

```

127.0.0.1       localhost

192.168.1.100   planck

192.168.1.1     einstein

```

So the address the program uses will be 192.168.1.1, which is NOT localhost, even if it refers to the same computer. As we said before, the gentoo xinetd default configuration only alows answering to requests made by the localhost, so the requests is rejected.

So, the solution to this problem would be to make my hostname refer to 127.0.0.1, like:

```

127.0.0.1       localhost

192.168.1.100   planck

127.0.0.1     einstein

```

If I want absolutly want to have a name reffering to the 192.168.1.1 address (which is not necessary... but sometimes useful), I just have to set another allias to 192.168.1.1, but with a name other than 'einstein':

```

127.0.0.1       localhost

192.168.1.100   planck

127.0.0.1     einstein

192.168.1.1     newton

```

I hope this helps

----------

## meyerm

Hi,

I won't test it now, but I just wanted to say thank you. I really appreciate people who also try to answer quite old articles  :Smile: 

Marcel

----------

## zrajm

Ytalk worked right out of the box for me.

However when I'm running X and somebody tries to ytalk/talk me I get a notification message in a (more or less) random (x)terminal -- which very seldom the terminal I'm actually using at the moment...

Is there a way to set up some other means of notification. E.g. running a script which beeps, plays a sample pops up a requester, or uses xosd to alert me to the fact that someone wishes to ytalk to me?

That would make ytalk sooo much more usable (to me).

----------

## seank

In my /etc/hosts files my "localhost" entry was as follows: 

```
127.0.0.1 localhost.localdomain localhost
```

 I changed it to 

```
127.0.0.1 localhost
```

 and talk/ytalk works  :Smile: 

----------

## Truckle

Hi,

To get talkd working, just add the line

disable = no

to /etc/xinitd.d/talk, and restart xinitd

Cheers, 

Truckle.

----------

## zpet731

Protectr, just curious why you added "+="?  ie.

 *Quote:*   

> 
> 
> ```
> only_from             += einstein             # This line was added
> ```
> ...

 

It works with or without the plus though.

----------

## zpet731

I would like to know how would I send a message over the network and and make it pop up and xterm on the other end. So far if the user I'm sending the message to doesn't have a term open the message doesn't get sent.

Thanks

----------

## cipherus

I just installed ytalk to replace two people using `write` at eachother (very clumsy way to communicate).  But I see no talkd package, there is a ktalkd but it says it requires kde libs..  This doesn't seem like a console chat daemon, so I'm wondering if there is another talk I'm missing?

----------

## cipherus

Ahaaa, using mostly this thread as a guide and reading it over and over I've finally figured out the way to do this.  So, in appreciation for all you from the distant time traveling past, I did up a quick wiki howto:

http://gentoo-wiki.com/HOWTO_talkd

Now more people can share in your knowledge and easily enjoy the talk goodness.  Woot!

----------

