Четкое понимание сути проблемы - большая половина ее решения.
Если вы хотите, чтобы этот обходной путь работал для вас, вам придется понять, КАК он работает, чтобы, если что-то сломается, вы знали где искать неисправность.
Первый шаг на пути к пониманию проблемы - присвоить всему соответствующие названия.
Итак "локальная" - это машина, которая устанавливает соединение, файлы на ней тоже называются "локальными"; и наоборот - "удаленная" - это машина с другой стороны соединения.
Наша цель - соединить между собой ввод и вывод локального IP-эмулятора, соответственно, с выводом и вводом удаленного IP-эмулятора
Каналами связи между двумя эмуляторами могут быть либо устройства (обычно pppd), либо "текущий терминал (tty)". Первый вариант, практически, невозможен в telnet-соединениях. Второй должен быть достаточно хитрым, потому что, когда вы запускаете локальный эмулятор из командной строки, он подключен к текущему tty пользователя, а не к telnet-сессии; если мы захотим открыть новую сессию (локальную или удаленную) на новом терминале, нам придется синхронизировать запуск и соединение IP-эмуляторов, иначе мусор одного из эмуляторов будет восприниматься как команды на другой стороне - это приведет еще к большему мусору и т.п..
Чтобы все было хорошо, локальный эмулятор должен позволять создавать IP-соединения на уровне ядра, то есть, быть pppd. Однако pppd достаточно глуп - он позволяет создавать соединения только через /dev-устройства или через текущий tty; это должно быть tty, а не парой потоков (pipe) (как все было бы просто!). Он подходит для удаленной стороны - он может использовать tty telnet-сессии; но вот для локальной машины он никак не подходит - он не может запустить telnet-соединения; должен существовать какой-то обходной путь.
Telnet работает почти правильно с парой потоков, хотя он все-таки настаивает на выполнении ioctl с tty, с которым он взаимодействует; использование telnet без tty тоже не совсем правильно, потому что на медленных компьютерах соединение будет прерываться (fwprc 0.1 работал правильно на P/MMX 233, один из 6 раз на 6x86-P200+, и вообще не работал на 486dx2/66).
[Примечание: Если я найду того негодяя (возможно он из фанатов MULTICS, да и в UNIX должны были найтись пара недоумков, скопировавших глупую идею), который изобрел принцип "tty"-устройств - запись и чтение производятся с одним "псевдо"-файлом, вместо того, чтобы иметь одну чистую пару потоков - Я его задушу!]