Re: Slip

[roemer@informatik.uni-frankfurt.de]

> > Well, slattach usually does these tty settings, too. In fact slattach
> > does nearly the same as the above script with one exception: It gets
> > the local hosts name via gethostname() and resolves the name into
> > an IP address using gethostbyname().
> 
> As you told me, slattach is intended to run as a daemon while the SLIP
> connection is up. Will slattach restore the attached interface if it
> gets killed? If I use the script to attach the connection and after
> ifconfig sl0 down, there seems to be no way to use sl0 once more and
> the serial device isn't accesible until I reboot.

After having established the SLIP interface, slattach waits in the background
until it receives SIGHUP, SIGINT, SIGQUIT or SIGTERM. Then it shuts down
the interface and exits.

After that the next slattach should reuse sl0 (automagically). If not, then
either sl0 has never come up (check by running ifconfig), or was not shut
down.

If it has never come up, then probably the linkage /dev/tty? <-> sl? (done
by iflink) was not shut down (check this by iflink -i sl?). Then this interface
cannot be reused until the tty is unlinked.

Unlinking is done by first bringing up the interface (ifconfig sl? up) and
then shutting it down (ifconfig sl? down). Recheck the with iflink -i sl?
then (should say "invalid function number").

> > The problem with doing it this way is the following: gethostbyname()
> > uses one of the namservers in /etc/resolv.conf to resolve the hostname into
> > an IP address. But usually the nameserver is one of the hosts on the other
> > side of the slip link that is currently beeing established. So naturally
> > (because the slip link is not yet up!) the resolving fails.
> 
> Urgs. I didn't have a look at the resolver code, but I think, it would
> be a good idea to configure the resolver via /etc/host.conf. There you
> usually can specify the order of /etc/hosts, DNS and NIS consulted to
> resolve the hostnames. Have a look at the resolv+2.1.1 code.

Where can I get it, is it part of BSD (Free* or Net*)?

I have changed the library to first try DNS, if that fails always try
/etc/hosts. NIS is not implemented.

The problem here is that the DNS resolver cannot detect whether a host
specified in /etc/resolv.conf doesn't run a nameserver without timing
out (which can last a long time) if there are more then one namserver
lines in /etc/resolv.conf and all of them are unreachable or don't run
namservers and the like.

> I do not understand why putting localhost in the resolv.conf makes
> sense, since I neither have seen a named for MiNTNet nor does it make
> sense to run such a daemon on an ATARI.

Well, this must not be localhost, but can be any host. But as described
above, problems arise when you have more then one namserver lines and
the connection to them does not work for some reason.

> I have three machines networked at home. A FreeBSD box via ethernet to
> my Sun and the TT connected via SLIP to the Sun. None of them are
> running nameservers. If I connect to the internet, the Sun is
> resolving hostnames via DNS, but all of the machines use /etc/hosts
> first. Perhaps I'll change this behaviour if I get permanently
> connected to the Internet, but I assume most of the ATARIs out there
> will never have a permanent connection to the internet.

I'm not sure if it is best to always try /etc/hosts first. Imagine
there has somewhere been a change host <-> IP address. Thats why DNS
was invented!

But specifying it in /etc/host.conf or somewhere else seems ok.

> > Another problem are the modem2 and serial2 ports of the TT. The will *not*
> > work without hsmodem -- don't ask me why...
> 
> I'll swap the SLIP connection from the Sun to the FreeBSD box as soon
> as I soldered a new nullmodem cable and then I want to use SLIP at
> higher rates than 19200. The FreeBSD machine offers 57600 and 115200
> Baud. Anyone ever tried SLIP with 115200 on a TT?

Sorry, have no TT. But Howard Chu told me about a 56k link TT <-> ka9q.

> > serial1 does not work with a usual null modem, because of the missing DTR/DCD
> > signals.

> I did not understand yet why these signals are needed for a nullmodem
> connection.

Usually the other host on the serial1 connection does not send data until
DataCarrierDetecet gets HIGH (which is connected to DTR of serial1).

> P.S.: Anyone interested in my port of `rdate'?

Why not? :)

Kay.