*BSD News Article 46656


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!zombie.ncsc.mil!news.mathworks.com!gatech!howland.reston.ans.net!xlink.net!zib-berlin.de!news.tu-chemnitz.de!irz401!uriah.heep!bonnie.heep!not-for-mail
From: j@bonnie.heep.sax.de (J Wunsch)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Idea for Talk to PPP host
Date: 10 Jul 1995 09:36:03 +0200
Organization: Private U**x site, Dresden.
Lines: 41
Message-ID: <3tql93$bl3@bonnie.tcd-dresden.de>
References: <3te4fb$mt@news.simplex.nl> <3tkigq$dv0@agate.berkeley.edu> <3tl8hm$9ir@rover.village.org>
Reply-To: joerg_wunsch@uriah.heep.sax.de
NNTP-Posting-Host: 192.109.108.139
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Speaking about talkd: i'm always annoyed about the following problem:


     ~~~~~~~~~~~~~~~~~~~                    /---------------------------\
    ~                   ~                   |                           |
    ~    Internet       ~ <-- SLIP --> 193.175.26.65  uriah.heep.sax.de |
    ~                   ~                  sl0                          |
      ~~~~~~~~~~~~~~~~~~                    |                           |
                                            \--------- 192.168.0.1 -----/
                                                           ed0
                                                            ^
                                                            |
                                                            V
                                                      local ethernet
                                                       (not routed)

Issuing a talk request from uriah.heep.sax.de to someone on the
Internet results in the following: the talk is ``looking for an
invitation on caller's machine'' on the foreign host, but since the
talk protocol uses explicit IP addresses that have been specified by
the sender, it ends up in looking for an `invitation' on address
192.168.0.1, and of course, the remote peer fails to answer to this
address.  This is since talk uses the first address gotten by a
gethostbysomething() call, instead of the address of the interface
where the recipient is being routed through.  (named sorts the address
list to put the `most local' address first, so it's always reporting
the 192.168 address as the first one.  But even changing the sequence
wouldn't actually solve the problem, it would only reverse it: any
host on the Internet could be talked to then, but no host on the local
net.)

Does anybody see a good solution for the problem?  Gathering routing
information via the routing socket seems to be a hard job, with the
additional disadvantage that talk needs to be suid root then.  I could
think of a work^H^H^H^Hhackaround by specifying the local address to
use on the command line of talk, but it's ugly.
-- 
cheers, J"org                      private:   joerg_wunsch@uriah.heep.sax.de
                                   http://www.sax.de/~joerg/

Never trust an operating system you don't have sources for. ;-)