Jak przesyłać polecenia do netcata, który pozostanie przy życiu?

echo command | netcat host port

Powoduje to wysłanie polecenia do zdalnego hosta i ponowne odczytanie niektórych danych. Ale po kilku sekundach połączenie zostaje zamknięte. Parametr -w niczego nie zmienił. Używam netcat v1.10 na SuSE 10.1.

Działa to z ncpoleceniem w systemie OS X (zakładając, że polecenie, które chcesz wysłać, znajduje się w pliku):

cat file - | nc host port

(Zasadniczo catzrzuca zawartość pliku na stdout, a następnie czeka na ciebie na stdin).

Według rozszerzenia, jeśli chcesz wysłać polecenie z samej powłoki, możesz to zrobić:

cat <(echo command) - | nc host port

Z ncna Ubuntu:

nc -q -1 host port

Z Ubuntu ncstrony man :

 -q seconds
         after EOF on stdin, wait the specified number of seconds and then quit. If seconds is negative, wait forever.

Zauważ, że dostępne ncopcje różnią się znacznie między dystrybucjami, więc może nie działać na twoją (OpenSUSE).

Znalazłem to:

echo command | netcat host port -

Mój współpracownik wiedział o tym. W ogóle tego nie widzę w dokumentacji.

Nie sądzę, że poradzisz sobie z tym za pomocą netcat lub socat. Właśnie zrobiłem obszerne majsterkowanie z oboma i socat wyglądał najbardziej obiecująco.

Udało mi się skonfigurować socat, aby łączył się ze zdalnym portem TCP i nasłuchiwał na lokalnym gnieździe domeny unix (teoretycznie, aby łącze mogło być cały czas utrzymywane), ale jak tylko proces lokalny został odłączony od gniazda unix (inny socat połączenie gniazda unix ze standardowym wyjściem / wyjściem) zamknęło sesję socat TCP.

Problem polega na tym, że każde połączenie przez netcat / socat tworzy nowe połączenie strumienia TCP z serwerem i zamyka tę sesję strumienia TCP, gdy lokalny koniec się rozłącza.

Myślę, że prawdopodobnie będziesz musiał napisać niestandardowe oprogramowanie proxy, które otworzy połączenie TCP ze zdalnym końcem, a następnie nasłuchuje lokalnie na gnieździe / rurze / fifo lub czymkolwiek, a następnie po prostu wyśle ​​dane w dół istniejącego potoku TCP i zwraca wyniki.

Czy to możliwe, że połączenie jest zamknięte na drugim końcu gniazda?

Domyślnie nczamyka połączenie po zakończeniu, jeśli nie powiesz mu wyraźnie, by nadal nasłuchiwał (z -kopcją):

 -k    Forces nc to stay listening for another connection after its current
       connection is completed.  It is an error to use this option without the
       -l option.

Zobaczyć man nc.1.

Pomyślnie przesyłam strumieniowo dane między dwoma komputerami:

• nadawca:

  while (true); do 
    echo -n "$RANDOM " | nc <host> <port>
  done
  

• odbiorca:

  nc -kl <port> 
  

Metoda Georgesa działa dobrze z interaktywnej powłoki, ale nie pomoże w skryptowaniu, gdy np. Wywołujesz skrypt jako nohup ./script &.

Odkryłem, że zastąpienie stdin manekinem FIFO pomaga.

 mkfifo dummy
 cat command.txt dummy | nc host port

Ponieważ nic nigdy nie zapisuje do FIFO, po wysłaniu pliku catzawiesza się na nim w nieskończoność.

socat„s shut-noneopcja powinna pomóc tutaj:

Changes the (address dependent) method of shutting down the write part of a connection to not do anything.

Prawdopodobnie będziesz również musiał zastąpić domyślny limit czasu przy użyciu -t <timeout>, w przeciwnym razie gniazdo zostanie zamknięte po 0,5 s. Ta opcja zastępuje zachowanie domyślne, czyli:

When one of the streams effectively reaches EOF, the closing phase begins. Socat transfers the EOF condition to the other stream, i.e. tries to shutdown only its write stream, giving it a chance to terminate gracefully. For a defined time socat continues to transfer data in the other direction, but then closes all remaining channels and terminates.

Tak więc polecenie takie jak:

echo 'blah' | socat -t 10 stdio tcp:<addr>:<port>,shut-none

utrzyma gniazdo otwarte przez 10s po wysłaniu „bla”.

Twoje polecenie kończy się, jeśli albo zdalny host zamyka połączenie (lub nie jest osiągalne), albo polecenie przed zakończeniem potoku (podczas gdy netcat nadal wysyła resztę swojej kolejki wejściowej).