Как получить файл к хосту, когда все, что Вы имеете, является последовательной консолью?

Возможно, необходимо дать minicom попытку.

Программы последовательной консоли ¹, который Вы будете использовать на другом конце соединения, будут иметь некоторый способ отправить файл удаленной стороне. То, как точно Вы идете об этом, зависит, на каких ресурсах Вы имеете в наличии в удаленной системе.

Я имею lrzsz или kermit на удаленной стороне

Самый легкий случай - то, если у Вас есть основательная программа передачи двоичного файла, установленная на удаленной стороне такой как lrzsz или kermit. Это было еще раз распространено, чем сегодня, но Ваша конкретная система могла бы все еще иметь один из них.

Программа последовательной консоли, которую Вы используете на локальной стороне почти наверняка, имеет способ сделать загрузку Zmodem или Kermit, которая позволяет Вам отправить то, в чем Вы нуждаетесь непосредственно.

В случае Zmodem просто введите rz в удаленной системе, которая отсылает специальную строку, которую локальный последовательный терминал должен понять, заставив ее открыться диалоговое окно средства выбора файла.

Kermit является более простым протоколом, таким образом, необходимо запустить передачу вручную в этом случае.

У меня нет программы передачи двоичного файла, но я действительно имею uuencode/base64

Существует несколько преимуществ для использования надлежащей программы передачи двоичного файла как lrzsz или kermit: эффективность, вычисление контрольной суммы, автоматические повторения, прерванное возобновление передачи, несколько передача файлов, и т.д., но это роскошь. Если только необходимо отправить один файл, или Вы отправляете файлы редко, можно сойти с рук загрузки ASCII.

Поскольку терминальные протоколы интерпретируют многие значения байта, которые происходят в файле двоичных данных, Вы не можете отправить файл непосредственно посредством того же соединения; если Вы сделаете, то код эмуляции терминала любого конца попытается интерпретировать некоторые данные, повреждая данные и вероятно путая терминальный код обработки также.

Вы обходите это путем кодирования двоичных данных в безопасное подмножество ASCII на локальной стороне, затем возвращения его в необработанные двоичные данные по удаленной стороне. Это что uuencode и base64 программы делают, отличаясь только по незначительному выбору алгоритма.

В локальной системе Вы кодируете файл: ²

$ uuencode -o sbf.uue some-binary-file.gz some-binary-file.gz

Затем Вы вводите эту команду в удаленной системе и отправляете файл с помощью функции "ASCII upload" локальной последовательной консоли:

$ cat | uudecode

Когда загрузка файла заканчивается, Ctrl-C хита для выхода cat. Теперь у Вас есть свой декодируемый файл в удаленной системе, как Вы хотели.

Но у меня есть много файлов для отправки, и печатаемым транскодированием ASCII является боль!

Не трудно загрузить себя до более высокого уровня технологии. Если удаленная система имеет компилятор C, можно использовать предшествующую технику, чтобы отправить удаленной системе копию lrzsz исходный код. На локальной стороне:

$ uuencode -o lrzsz.tgz.uue lrzsz-0.12.20.tar.gz lrzsz-0.12.20.tar.gz

Затем в удаленной системе, введите это с помощью программы последовательной консоли:

$ cat | uudecode
^C
$ tar xvf lrzsz-0.12.20.tar.gz
...build lrzsz normally

После запуска первой команды сделайте "загрузку ASCII" lrzsz.tgz.uue файл к удаленной системе. Конвейер принимает кодируемые программой uuencode данные и декодирует их к двоичному файлу tarball для Вас, которых можно распаковать и создать.

Но у меня нет компилятора C в удаленной системе

Если у Вас даже нет компилятора в удаленной системе, можно кросс-скомпилировать rz (или безотносительно), программа в локальной системе и отправляют его в удаленную систему с помощью вышеупомянутой техники.

Сноски:

1. minicom, picocom, PuTTY, VanDyke CRT...

2. Необходимо дать входное имя файла этой версии uuencode дважды, однажды чтобы назвать источник входных данных и снова объявить то, что удаленная система должна назвать файлом, когда это декодирует данные к выходному файлу. Вы могли очевидно хотеть, чтобы удаленная система имела другое имя для своего выходного файла.

   Ваша локальная версия uuencode может вести себя по-другому.

Не знайте, работало ли это, если все, что Вы имели, было последовательной консолью, но если у Вас есть доступ к сети вообще, затем Вы могли бы использовать nc(1) скопировать файлы с помощью TCP/IP.

# WARNING: Depending on your setup, this could make your system unbootable
root@destination-box.local # nc -l 8675 | dd of=/dev/sdXXX
root@source-box.local # dd if=/dev/sdYYY | nc destination-box.local 8675

В вышеупомянутом примере я клонировался sdbYYY от исходного поля до sdaXXX из целевого поля. Мой выбор 8 675 для номера порта TCP был произволен; Вы могли использовать любой порт, к которому у Вас есть доступ. И это не должно быть устройство; это может быть любой файл.

kevin@destination-box.local $ nc -l 12345 >> ~/.ssh/authorized_keys
kevin@source-box.local $ cat ~/.ssh/id_rsa.pub | nc destination-box.local 12345

Во втором примере я скопировал свой открытый ключ RSA (~/.ssh/id_rsa.pub) и добавил его к авторизованному файлу ключей для целевого узла.

Я использовал бы kermit, прародителя filetransfer программ. Мы уже использовали это задолго до того, как был Linux.

В основном вы должны использовать пред-интернет методы для передачи по последовательному tty, и у вас должен быть способ получить передачу на другой стороне. Очевидно, что лучший способ сделать это - использовать ZMODEM, что означает, что вам нужно иметь такой инструмент, как sz уже на принимающей стороне. Однако это не всегда возможно, например, когда принимающей целью является маршрутизатор без сети.

Единственный возможный способ сделать эту передачу - непосредственно по каналу, используя терминал safe ASCII, в предварительно 8-битном чистом стиле. Я собираюсь использовать более современные инструменты, которые, я надеюсь, установлены на большинстве систем.

Sender:

Сначала мы кодируем наш файл

base64 file.tar.gz > file.tar.gz.b64

Теперь убедитесь, что ваша команда com send-file, ascii-xfr, это была моя командная строка подключения

picocom -f n -p n -d 8 -b 115200  --send-cmd "ascii-xfr -snv" /dev/ttyS0

Обычно мы хотим ascii-xfr на принимающей стороне, но поскольку у нас его нет, этот -n обходит это, поддерживая правильные окончания линий.

Receiver:

Теперь, когда мы подключились, перейдите в каталог, в котором вы хотите получить файл.

cd /tmp/
cat > file.tar.gz.b64

На picocom я просто CTRL+a+s и вхожу в полный путь к файлу, который я отправляю. После завершения переноса вам нужно будет CTRL+c, чтобы сломать этот cat.

Теперь мы декодировкаем файл,

base64 -d file.tar.gz.b64 > file.tar.gz

Сделайте все возможное, чтобы убедиться, что файл ИДЕНТИЧен отправленному вами файлу, потому что передача ASCII не имеет защиты контрольной суммы. В моем приемном ящике было sha512sum, но любой команды контрольной суммы было бы достаточно. После того, как вы вручную подтвердите совпадение сумм, вы можете предположить, что перевод был успешным!

Мой способ передачи файла.bin через последовательное соединение заключается в использовании инструмента openSSL, поскольку у меня нет других вариантов кодирования base64 и обратно:

openssl enc -base64 <file.bin > file.b64

Декодировать:

openssl enc -base64 -d <file.b64 > file.bin