netcat не друкує відповідь

12

Я намагаюся надсилати команди до порту tcp за допомогою netcatта передачі відповіді
під час запуску netcatта введення команди, вона правильно друкує відповідь, але коли я передаю команду з труби, вона надсилає команду правильно, але не друкує відповідь

Отже, це працює правильно:

netcat  localhost 9009

хоча ця команда просто надсилає команду, але не друкує відповідь:

echo 'my_command' | netcat  localhost 9009

чому?
Як зробити так, netcatщоб надрукувати текст відповіді?

pipe netcat

— RYN
джерело

це , мабуть, трапляється з вами

— Джефф Шаллер

@JeffSchaller: ні! на жаль, використання цих команд не допомагає! цього разу він блокує назавжди!

— RYN

Яку мережу ви використовуєте? На жаль, існує десяток різних варіантів інструменту netcat, і вони не всі поводяться однаково. Також, що на віддаленому кінці?

— Патрік

@Patrick: мій netcat - OpenBSD netcat (Debian patchlevel 1.105-7ubuntu1)версія; а на віддаленому кінці знаходиться telegram-cliна одній машині.

— RYN

Я думаю, що я знайшов сторінку для цієї мережі, але я не бачу жодних прапорів, які б контролювали те, що я підозрюю. Я підозрюю, що щойно netcatотримує EOF на STDIN, що він негайно вимикає обидві сторони розетки, замість того, щоб зробити напівзакриття і чекати, коли віддалена сторона закриє її кінець. Якщо socatє варіант, я б настійно рекомендував його замість цього. Є лише один socat, тому у вас не виникає проблем з переносом, тому що в ньому є десяток різних ароматів, він поводиться набагато здоровіше і легко налаштовується.

— Патрік

8

Як сказав @Patrick, ця проблема, як правило, пов’язана з netcatтим, як вийти, перш ніж відповідь буде надана. Ви виправляєте це, додаючи -q 2в командний рядок, тобто, говорите netcatзависати протягом 2 секунд після виявлення EOF на стандартному вході. Очевидно, ви можете змусити його почекати ще деяку кількість секунд.

— Ральф Ронквіст
джерело

Дякую; -q 2працював, але чи можна це довіряти? це робить веб-запит, я не можу бути впевнений, що 2-х завжди достатньо! можу я ?

— RYN

1

Використовуйте більше число, щоб змусити його чекати довше, або якесь негативне число, щоб змусити його чекати нескінченно. Також є -wможливість пограти. Це все на man ncсторінці звичайно.

— Ральф Ронквіст

5

там написаноinvalid option -- 'q'

— phil294

Я думаю, що гарне наступне питання полягає в тому, що: чому ncвиходить негайно, а не чекати відповіді? Якщо з’єднання все-таки відкрите, має бути можливість змусити ncзачекати, коли воно закриється, а не лише для завершення stdin

— theferrit32

6

Використовуй це:

cat <(echo command) - | nc host port

Проблема полягає в тому nc, що з'єднання буде закрито відразу після закриття stdin, що дуже швидко для простої my_commandструни, і, отже, ніколи не отримує шансу отримати відповідь. (Якщо ви передасте дуже великий файл, ви побачите, що він може отримати відповідь, перш ніж буде відправлено файл).

Введіть за catдопомогою -другого аргументу: він змушує catпрослуховувати stdin, щоб отримати більше вмісту, щоб передати його після того, як він надіслав вміст першого аргументу. Перший аргумент - це лише проходження echoкоманди cat- це також може бути файл із командами a la cat < file - | ....

Як варіант:

(echo command; while true; do sleep 0.01; echo -n "#"; done) | nc host port

Це надсилає необмежену кількість #символів у другому рядку вводу. Використання #творів для bash, як віддалений, який ігнорував би це як коментар. Тут я вибрав невеликий час очікування - 10 мілісекунд, тому він швидше реагує на завершення з'єднання. YMMV.

Недоліком цього може бути той catчи whileцикл і ncпродовжувати працювати, поки ви не потрапите ^Cабо ^Dна оболонку. Це дійсно залежить від віддаленого кінця.

Додавання тайм-ауту за допомогою -w 1(OSX netcat) або -i 1(nmap's ncat) змушує перервати з'єднання та ncчерез 1 секунду, але catтриватиме, поки ви не введете якийсь символ і труба розірветься (я думаю).

Однак це працює, якщо віддалена сторона автоматично закриє з'єднання після отримання та обробки команди - це також закінчить ncклієнт та процес переходу в нього.

Ця відповідь ґрунтується на цій відповіді на ідентичне питання про суперпользователя .

— Олександр Климечек
джерело

{ echo my_command; cat;}зробив би те саме і, можливо, вважати його легше зрозуміти.

— G-Man каже: "Відновіть Моніку"

1

Різні версії OpenBSD-NetCat є виверткий, потребуючи різні комбінації -w <seconds>, -q <seconds>, -Nі навіть необхідні різні аргументи в залежності від того, що працює на іншому кінці з'єднання. Використання параметрів тайм-ауту з певними версіями або серверами спричиняє затримки, а їх використання може призвести до надзвичайно тривалої (нескінченної?) Затримки. І я б очікував різних химерностей з gnu netcat, але не знаю, чи відрізняються вони між його версіями.

Наприклад, версія 1.130_3 від archlinux займає надзвичайно багато часу (назавжди?), Коли я це роблю:

$ echo response | nc -l 9999 &
[1] 15190

$ time echo request | nc localhost 9999
request
response

(wait forever possibly)

Але він працює з -N, доданим або до сервера, або до клієнта.

— Петро
джерело

1

Я знаю, що це трохи старе, але жодна інша відповідь не спрацювала для мене, і це зробило:

echo 'test' | netcat -N $server $port

Зауважте -N:

відключення мережевої розетки після EOF на вході. Деякі сервери вимагають цього, щоб закінчити свою роботу.

Для мене працювали і в Windows, і в Linux.

Примітка. Це копія пасти відповіді, яку я опублікував на повторне запитання .

Я думаю, що це може бути корисним. Моди можуть сміливо редагувати / видаляти, якщо це суперечить політиці чи чомусь.

— yannick1976
джерело