netcat không in phản hồi

12

Tôi đang cố gắng gửi lệnh đến một cổng tcp bằng cách sử dụng netcatvà phản hồi đường ống
khi tôi chạy netcatvà gõ lệnh của mình, nó sẽ in phản hồi chính xác nhưng khi tôi truyền lệnh từ một đường ống, nó sẽ gửi lệnh chính xác nhưng không in phản hồi

Vì vậy, điều này hoạt động chính xác:

netcat  localhost 9009

trong khi điều này chỉ gửi lệnh nhưng không in phản hồi:

echo 'my_command' | netcat  localhost 9009

tại sao?
Làm thế nào tôi có thể thực hiện netcatđể in văn bản phản hồi?

pipe netcat

— RN
nguồn

điều này có thể xảy ra với bạn

— Jeff Schaller

@JeffSchaller: không! Thật không may, sử dụng các lệnh đó không giúp đỡ! Lần này nó chặn mãi!

— RYN

Bạn đang sử dụng netcat nào? Thật không may, có hàng tá biến thể khác nhau của công cụ netcat và tất cả chúng đều không hoạt động giống nhau. Ngoài ra, những gì là ở đầu xa?

— Patrick

@Patrick: netcat của tôi là OpenBSD netcat (Debian patchlevel 1.105-7ubuntu1)phiên bản; và ở đầu xa là telegram-clitrên cùng một máy.

— RYN

Tôi nghĩ rằng tôi đã tìm thấy một trang người đàn ông cho netcat đó, nhưng tôi không thấy bất kỳ cờ nào sẽ kiểm soát những gì tôi nghi ngờ đang xảy ra. Tôi nghi ngờ rằng một khi netcatnhận được EOF trên STDIN, nó sẽ ngay lập tức tắt cả hai bên của ổ cắm thay vì đóng một nửa và chờ phía từ xa đóng lại. Nếu socatlà một lựa chọn, tôi rất muốn giới thiệu nó thay thế. Chỉ có một socat, vì vậy bạn không gặp phải vấn đề về tính di động khi có hàng tá hương vị khác nhau, nó hoạt động ổn định hơn rất nhiều và có cấu hình cao.

— Patrick

8

Như @Patrick đã nói, vấn đề này thường là do netcatthoát ra trước khi phản hồi được đưa ra. Bạn khắc phục điều đó bằng cách thêm -q 2vào dòng lệnh, tức là yêu netcatcầu treo khoảng 2 giây sau khi phát hiện EOF trên đầu vào tiêu chuẩn. Rõ ràng là bạn có thể làm cho nó chờ một số giây khác.

— Ralph Rönnquist
nguồn

Cảm ơn; -q 2làm việc nhưng nó có thể tin tưởng? nó đang thực hiện yêu cầu web Tôi không thể chắc chắn 2s luôn là đủ! tôi có thể ?

— RYN

1

Sử dụng một số lớn hơn để làm cho nó chờ lâu hơn hoặc một số số âm để làm cho nó chờ vô thời hạn. Ngoài ra còn có -wtùy chọn để chơi với. Đây là tất cả trong man nctrang của khóa học.

— Ralph Rönnquist

5

nó nóiinvalid option -- 'q'

— phil294

Tôi nghĩ rằng một câu hỏi tiếp theo tốt là: tại sao lại ncthoát ra ngay lập tức thay vì chờ phản hồi? Nếu kết nối vẫn mở, cần có một tùy chọn để ncchờ cho nó đóng, không chỉ cho stdin kết thúc

— theferrit32

6

Dùng cái này:

cat <(echo command) - | nc host port

Vấn đề là ncsẽ đóng kết nối ngay lập tức sau khi đóng stdin, rất nhanh cho một my_commandchuỗi đơn giản , và do đó không bao giờ có cơ hội nhận được phản hồi. (Nếu bạn đặt một tệp rất lớn, bạn sẽ thấy rằng nó có thể nhận được phản hồi trước khi gửi xong tệp).

Nhập catvới -đối số thứ hai: Nó làm cho catlắng nghe trên stdin để biết thêm nội dung để chuyển qua sau khi nó đã gửi nội dung của đối số đầu tiên. Đối số đầu tiên chỉ là nhận echolệnh thông qua cat- nó cũng có thể là một tệp với các lệnh của bạn a la cat < file - | ....

Hoặc làm điều này:

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

Điều này sẽ gửi các #ký tự không giới hạn trên dòng thứ 2 của đầu vào. Sử dụng #các tác phẩm cho một bash như remote sẽ bỏ qua điều này như một bình luận. Tôi đã chọn thời gian chờ nhỏ là 10 mili giây ở đây, để nó phản ứng nhanh hơn khi kết thúc kết nối. YMMV.

Nhược điểm của điều đó có thể là điều đó cathoặc whilevòng lặp và nctiếp tục chạy cho đến khi bạn nhấn ^Choặc ^Dtrên vỏ. Nó thực sự phụ thuộc vào kết thúc từ xa.

Thêm thời gian chờ bằng cách sử dụng -w 1(OSX netcat) hoặc -i 1(nmap's ncat) sẽ khiến nó đóng kết nối và ncsau 1 giây, nhưng catsẽ tiếp tục chạy cho đến khi bạn nhập một số ký tự và ngắt ống (tôi nghĩ).

Tuy nhiên, nó hoạt động nếu phía từ xa sẽ tự động đóng kết nối sau khi nhận và xử lý lệnh - điều này cũng sẽ kết thúc ncmáy khách và quá trình đường ống vào nó.

Câu trả lời này dựa trên câu trả lời này cho một câu hỏi siêu người dùng giống hệt nhau .

— Alexander Klimetschek
nguồn

{ echo my_command; cat;}sẽ làm như vậy và có thể được coi là dễ hiểu hơn.

— G-Man nói 'Phục hồi Monica'

1

Phiên bản OpenBSD-netcat khác nhau là kỳ quặc, cần kết hợp khác nhau của -w <seconds>, -q <seconds>, -Nvà lập luận khác nhau thậm chí không cần phụ thuộc vào những gì đang chạy trên đầu kia của kết nối. Việc sử dụng các tùy chọn hết thời gian với các phiên bản hoặc máy chủ nhất định gây ra sự chậm trễ và việc không sử dụng chúng có thể dẫn đến độ trễ cực kỳ dài (vô hạn?). Và tôi sẽ mong đợi những quirks khác nhau với gnu netcat, nhưng không biết liệu chúng có khác nhau giữa các phiên bản của nó không.

Ví dụ phiên bản 1.130_3 từ archlinux mất rất nhiều thời gian (mãi mãi?) Khi tôi làm điều này:

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

$ time echo request | nc localhost 9999
request
response

(wait forever possibly)

Nhưng nó hoạt động với -N được thêm vào máy chủ hoặc máy khách.

— Peter
nguồn

1

Tôi biết điều này hơi cũ nhưng không có câu trả lời nào khác phù hợp với tôi và điều này đã làm:

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

Lưu ý -N:

tắt ổ cắm mạng sau EOF trên đầu vào. Một số máy chủ yêu cầu điều này để hoàn thành công việc của họ.

Làm việc cho tôi trên cả Windows và Linux.

Lưu ý: Đây là một bản sao dán của câu trả lời tôi đã đăng cho một câu hỏi trùng lặp .

Tôi nghĩ rằng điều này có thể hữu ích. Các mod cảm thấy thoải mái khi chỉnh sửa / xóa nếu điều này trái với chính sách hoặc điều gì đó.

— yannick1976
nguồn