Jak pobrać plik do hosta, gdy masz tylko konsolę szeregową?


21

Gdy wszystko, co masz, to konsola szeregowa (powiedzmy przez telnet za pośrednictwem serwera terminali), jakie metody można zastosować do przesyłania plików do / z hosta?

Wytnij / wklej działa w przypadku małych / możliwych do wydruku materiałów, a ja grałem z kombinacją uuencode / uudecode (z gzip), które obsługują to, co nie jest drukowalne, ale to wszystko jest bardzo ograniczające.


Biorąc pod uwagę niektóre komentarze, które pozostawiłeś na temat dostępności narzędzi, pomógłbyś nazwać platformę i / lub przedstawić środowisko, w którym się znajdujesz. W przeciwnym razie dostaniesz zapas Kermit / XMODEM / YMODEM / ZMODEMk przez terminal odpowiedzi ...
Avery Payne

Większość dnia spędzam za pudełkiem Solaris. Więc w tych kategoriach, gdyby wszystko, co miałeś, to SUNCreq (a może SUNWCuser), co byś odpowiedział?
Stephen Paul Lesniewski

zaledwie 5 lat spóźnienia: P Teraz możesz zaakceptować moją odpowiedź, ponieważ to było dokładnie to, czego chciałeś ... ale prawdopodobnie nie potrzebujesz dzisiaj.
JM Becker,

Odpowiedzi:


13

Programy konsoli szeregowej¹, których użyjesz na drugim końcu połączenia, będą miały sposób na przesłanie pliku na stronę zdalną. To, jak dokładnie to zrobisz, zależy od zasobów dostępnych w systemie zdalnym.

Mam lrzszlub kermitpo drugiej stronie

Najłatwiejszym przypadkiem jest, jeśli na stronie zdalnej jest zainstalowany solidny program do przesyłania plików binarnych, taki jak lrzszlub kermit. To było kiedyś bardziej powszechne niż dzisiaj, ale twój konkretny system może nadal mieć jeden z nich.

Program konsoli szeregowej, którego używasz po stronie lokalnej, prawie na pewno ma sposób na przesłanie Zmodem lub Kermit, co pozwala wysłać wszystko, czego potrzebujesz bezpośrednio.

W przypadku Zmodem po prostu wpisz rzw zdalnym systemie, który wysyła specjalny ciąg znaków, który lokalny terminal szeregowy powinien zrozumieć, powodując wyświetlenie okna dialogowego wyboru plików.

Kermit jest prostszym protokołem, dlatego w takim przypadku musisz rozpocząć transfer ręcznie.

Nie mam programu do przesyłania plików binarnych, ale mam uuencode/base64

Istnieje wiele korzyści z wykorzystaniem odpowiedniego programu transferu plików binarnych jak lrzszlub kermit: efektywność, sum kontrolnych, automatycznych prób, poronionych wznowienia transferu, wielokrotnego przesyłania plików, itp, ale są to luksusy . Jeśli musisz wysłać tylko jeden plik lub rzadko wysyłasz pliki, możesz uniknąć przesyłania plików ASCII.

Ponieważ protokoły terminali interpretują wiele wartości bajtów występujących w pliku danych binarnych, nie można wysłać pliku bezpośrednio przez to samo połączenie; jeśli to zrobisz, kod emulacji terminalu na obu końcach spróbuje zinterpretować niektóre dane, uszkadzając dane i prawdopodobnie wprowadzając w błąd także kod obsługi terminalu.

Można obejść ten problem, kodując dane binarne w bezpieczny podzbiór ASCII po stronie lokalnej, a następnie przekształcając je z powrotem w surowe dane binarne po stronie zdalnej. To jest to, co uuencodei base64programy zrobić, różnią się tylko drobnymi wyboru algorytmu.

W systemie lokalnym kodujesz plik: ²

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

Następnie wpisz to polecenie w systemie zdalnym i wyślij plik za pomocą funkcji „Przesyłanie ASCII” na lokalnej konsoli szeregowej:

$ cat | uudecode

Po zakończeniu przesyłania pliku naciśnij, Ctrl-Caby wyjść cat. Teraz masz zdekodowany plik w systemie zdalnym, tak jak chcesz.

Ale mam wiele plików do wysłania, a transkodowanie ASCII do druku to ból!

Nie jest trudno załadować się na wyższy poziom technologii. Jeśli zdalny system ma kompilator C, możesz użyć wcześniejszej techniki, aby wysłać zdalnemu systemowi kopię lrzszkodu źródłowego. Po stronie lokalnej:

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

Następnie w systemie zdalnym wpisz to za pomocą programu konsoli szeregowej:

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

Po uruchomieniu pierwszego polecenia wykonaj „przesyłanie ASCII” lrzsz.tgz.uuepliku do systemu zdalnego. Rurociąg akceptuje nieokodowane dane i dekoduje je do binarnego pliku tar, który można rozpakować i skompilować.

Ale nie mam kompilatora C w systemie zdalnym

Jeśli nie mają nawet kompilator na zdalnym systemie, można przejechać skompilować ten rzprogram (lub cokolwiek) w systemie lokalnym i wysłać go do systemu zdalnego przy użyciu powyższej techniki.


Przypisy:

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

  2. Musisz podać nazwę pliku wejściowego do tej wersji uuencodedwa razy, raz, aby nazwać źródło danych wejściowych, i jeszcze raz zadeklarować, co system zdalny powinien wywołać plik, gdy dekoduje dane do pliku wyjściowego. Można sobie wyobrazić, że system zdalny ma inną nazwę dla pliku wyjściowego.

    Twoja lokalna wersja uuencodemoże zachowywać się inaczej.


Fantastycznie, miałem nadzieję, że to pytanie zawiera odpowiedź dotyczącą Kermita! +1;)
Tim

To dobra odpowiedź, podoba mi się sekcja „Ale nie mam”. Niestety, zatrzymuje się na dość popowych materiałach i nie schodzi zbyt głęboko. Tworzenie binarnych plików wykonywalnych dla różnych architektur z tylko kodów ASCII ktoś? Oto bootstrap: retrocomputing.stackexchange.com/questions/4672/…
pfalcon

5

Zasadniczo musisz korzystać z metod sprzed internetu, aby przesyłać dane za pośrednictwem łącza szeregowego, i musisz mieć sposób na otrzymanie przelewu po drugiej stronie. Oczywiście najlepszym sposobem na to jest użycie ZMODEM, co oznacza, że ​​musisz mieć narzędzie takie jak szjuż po stronie odbierającej. Jednak nie zawsze jest to możliwe, na przykład, gdy odbiorcą jest router bez sieci.

Jedynym możliwym sposobem wykonania tego transferu jest bezpośrednio kanał, przy użyciu bezpiecznego ASCII terminala, w czystym stylu sprzed 8-bitów. Użyję bardziej nowoczesnych narzędzi, które, mam nadzieję, są zainstalowane na większości systemów.

Nadawca:

Najpierw kodujemy nasz plik

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

Teraz upewnij się, że twoje polecenie wysyłania pliku com to ascii-xfr, to była moja linia poleceń połączenia

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

Zwykle chcemy ascii-xfrpo stronie odbierającej, ale ponieważ go nie mamy, -ndziała to w ten sposób, zachowując prawidłowe zakończenia linii.

Odbiorca:

Po nawiązaniu połączenia przejdź do katalogu, w którym chcesz odebrać plik.

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

Na Picocom, po prostu CTRL + A + S i podaj pełną ścieżkę pliku, który wysyłam. Po zakończeniu przesyłania musisz nacisnąć CTRL + c, aby to przerwać cat.

Teraz dekodujemy plik,

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

Zrób wszystko, co możliwe, aby sprawdzić, czy plik jest IDENTYCZNY w stosunku do tego, który wysłałeś, ponieważ transfer ASCII nie ma ochrony sumy kontrolnej. Moje pole odbiorcze miało sha512sum, ale wystarczyło dowolne polecenie sumy kontrolnej. Po ręcznym potwierdzeniu zgodności sum możesz założyć, że transfer się powiódł!


(A dwa lata później ...) z mojego doświadczenia, że ​​muszę przenosić pliki między systemami, które munge kończą linie (dzięki Microsoft!), Kodowanie / dekodowanie base64 nie dba o styl zakończenia linii. \r\nlub po prostu \noba działają, nawet jeśli zostaną „naprawione” po drodze. Nie przypominam sobie od razu, czy jest to standard base64, czy tylko narzędzia, których użyłem, ale podejrzewam, że to w rzeczywistości standardowe zachowanie.
Andrew Henle,

5

Może powinieneś spróbować Minicom .


Czy to nie wymaga czegoś takiego jak „sx” lub „sz” na hoście źródłowym?
Stephen Paul Lesniewski

4
Nie, minicom obsługuje własne pliki xfers. sx, sy, sz i rx, ry, rz to osobne programy, zwykle znajdujące się w pakietach o trafnych nazwach lszrz lub coś w tym rodzaju. Chociaż sugerowałbym użycie sz i rz. Mały, prosty i robi to, co robi. Minicom to emulator całego terminalu.
reiche

4
Ta odpowiedź jest nieprawidłowa. Minicom spawnuje Lrzsza do przesyłania plików. Minicom nie może i nie obsługuje własnych transferów plików.
Jonathan Cline IEEE

5

Nie wiem, czy to zadziałałoby, gdybyś tylko miał konsolę szeregową, ale jeśli w ogóle masz dostęp do sieci, możesz użyć nc(1)do kopiowania plików za pomocą 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

W powyższym przykładzie sklonowałem sdbYYYz pola źródłowego do sdaXXXpola docelowego. Mój wybór 8675 dla numeru portu TCP był arbitralny; możesz użyć dowolnego portu, do którego masz dostęp. I to nie musi być urządzenie; może to być dowolny plik.

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

W drugim przykładzie skopiowałem mój klucz publiczny rsa ( ~/.ssh/id_rsa.pub) i dodałem go do pliku kluczy autoryzowanych dla hosta docelowego.


5
Czy mogę zasugerować duży czerwony znak ostrzegawczy nad twoim pierwszym pomysłem? Jakaś samotna dusza z sercem do nauki może wykonać coś takiego w nadziei na skopiowanie tylko plików, bez uprzedniego przeczytania najpierw pierwszego akapitu :)
reiche

2

Użyłbym kermitowi , dziadkowie programów FileTransfer. Użyliśmy tego już na długo przed pojawieniem się Linuksa.


ahh tak .. Pamiętam, że to robię, ale w tym przypadku Kermit nie jest instalowany na hoście źródłowym.
Stephen Paul Lesniewski
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.