Before reporting any bug, please read G3 for advice
on how to include diagnostic information that will get your bug fixed
as quickly as possible.
If you have a question or answer you think ought to be added to
this FAQ list, mail it to tcptty's maintainer, Stuart C. Eichert, at
tcptty@copera.com.
tcptty is a one-stop solution for connecting two programs via a TCP
connection, when they expect to be using a terminal. I use tcptty on my
Linux box to create a virtual LAN for many instances of the Palm OS Emulator.
I can more easily simulate a network environment where many Palm OS devices
are on the same LAN.
tcptty is open-source
software. It is hoped that other developers find this tool useful and
provide comments and enhancements.
tcptty is licensed under the FreeBSD license. You can read this
license in individual source files.
If you found this FAQ in the distribution, see the README for tcptty's
full feature list.
Yes I will, provided you include enough diagnostic information for me
to go on. Send bugs to tcptty-bugs. When reporting
bugs, please include the following:
Your operating system.
Your compiler version, if you built from source; otherwise, the
name and origin of the RPM or other binary package you installed.
Any command-line options you used.
The output of tcptty -V called with whatever other
command-line options you used.
Often, the first thing I will do when you report a bug is tell you to
upgrade to the newest version of tcptty, and then see if the
problem reproduces. So you'll probably save us both time if you
upgrade and test with the latest version before sending in a
bug report.
If your bug is something that used to work but stopped working when
you upgraded, then you can help pin the bug down by trying intermediate versions of
tcptty until you identify the revision that broke your
feature. The smart way to do this is by binary search on the version
sequence. First, try the version halfway between your last good one
and the current one. If it works, the failure was introduced in the
upper half of the sequence; if it doesn't, the failure was introduced
in the lower half. Now bisect that half in the same way. In a very
few tries, you should be able to identify the exact adjacent pair
of versions between which your bug was introduced -- and with
information like that, I can usually come up with a fix very quickly.
A transcript of the failed session with -v -v (yes, that's
two -v options, enabling debug mode) will almost always be useful.
If you upgraded your tcptty and something broke, you should include
session transcripts with -v -v of both the working and failing
versions. Very often, the source of the problem can instantly
identified by looking at the differences.
Any bug I can reproduce will usually get fixed very quickly, often
within 168 hours. Bugs I can't reproduce are difficult to fix.
By default tcptty listens for connections on INADDR_ANY. If you have
specified a specific IP address to listen on (say 192.168.1.55) then this
IP address must remain valid during the life of tcptty.
Yes. Clients must be able to initiate connections to the specified ip
address and port. If you are not running a firewall this should not be a
problem. tcptty is usually run behind the firewall for clients who are also
behind the same firewall.
The vendor-supplied make on FreeBSD systems can only be used within
FreeBSD's "scope", e.g. the ports collection. Type "gmake" to run GNU
make and better things will happen.
tcptty fork a separate process for executing the command specified (in this
case pppd). tcptty should continue to execute regardless of what
pppd does. The problem is likely somewhere else.
Some platforms take time to cleanup TCP connections. Wait a while and
try again. Also remember not to kill tcptty with kill -9, but rather
kill -TERM, kill -INT, or kill -HUP. tcptty catches these signals and
tries to close sockets and pseudo terminals in an orderly manner. More
work should be done on this code.
This is a feature, not a bug. It's in line with normal practice for
system daemons and allows you to suppress logging by removing the log,
without hacking potentially fragile startup scripts. To get around
it, just touch(1) the logfile before you run tcptty (this will have
no effect on the contents of the logfile if it already exists).
In this case pppd is running over a pseudo terminal, not a real terminal
and thus the baud rate setting will do nothing. To speed up or slow down
the transmission and reception of data between pppd and its client specify
a different value for bufsize and/or interval. To test the
effect of these new values, try pinging the ppp client and take a look at
round trip times. Then try other tests that send different sizes of data.
Simulating a real terminal device with tcptty is not currently possible (at
least on Linux or on any other non real time O/S).
