2010-06-14 40 views
5

Tôi đang làm việc trong môi trường Linux được nhúng.kết nối máy khách telnet dừng nhận dữ liệu, máy chủ vẫn đang gửi

nó khởi chạy một daemon telnet khi khởi động mà đồng hồ trên một cổng cụ thể và khởi chạy chương trình khi nhận được kết nối.

ví dụ:

telnetd -l /usr/local/bin/PROGA -p 1234 

PROGA - sẽ ra một số dữ liệu trong khoảng thời gian bất thường. Khi không xuất dữ liệu, mỗi khoảng thời gian X sẽ gửi chuỗi loại 'nhịp tim' để cho khách hàng biết rằng chúng tôi vẫn đang hoạt động tức là "heartbeat \ r \ n"

Sau một khoảng thời gian ngẫu nhiên, client (sử dụng một phiên bản linux của telnet, đưa ra bởi: telnet xxx.xxx.xxx.xxx 1234) sẽ không nhận được 'nhịp tim \ r \ n'

các dữ liệu khách hàng nhìn thấy:

heartbeat 
heartbeat 
heartbeat 
... 
heartbeat 
[nothing, should have received heartbeat] 
[nothing forever] 

nhịp tim được gửi:

result = printf("%s", heartbeat); 

kết quả kiểm tra, nó luôn có chiều dài heartbeat. Đăng nhập để syslog cho chúng ta thấy rằng printf() đang thực hiện thành công tại các khoảng thích hợp

Tôi đã kể từ khi được thêm vào trong một tcdrainfflush mà cả hai quay trở lại thành công, nhưng dường như không giúp tình hình.

Mọi trợ giúp sẽ được đánh giá cao.

** UDPATE: có hình thu thập từ phía máy chủ. Rất rõ ràng nhịp tim đang được gửi liên tục. Không có Hicups, không có sự chậm trễ. Tìm thấy một cái gì đó thú vị trên máy khách mặc dù. Các khách hàng trong trường hợp thử nghiệm này (telnet trên Ubuntu 9,04) dường như đột nhiên ngừng nhận nhịp tim (như mô tả ở trên). Wireshark xác nhận điều này, tạm dừng lớn trong các gói tin. Vâng, một khi khách hàng đã ngừng nhận nhịp tim, nhấn bất kỳ phím tắt nào (trên máy khách) dường như kích hoạt một lượng dữ liệu từ bộ đệm của khách hàng (tất cả các nhịp đập). Wireshark trên máy khách cũng hiển thị lượng dữ liệu khổng lồ này trong một gói.

Thật không may là tôi thực sự không biết điều này có ý nghĩa gì. Nó có phải là một chế độ dòng on/off điều? Kết thúc dòng (\ r \ n) đang rất rõ ràng.

** Cập nhật 2: chạy netcat thay vì telnetd, sự cố không thể lặp lại được.

+0

các chuỗi khác bạn gửi trông như thế nào? nếu bạn gửi 255 byte nó cần phải được thoát ... – Spudd86

+0

Tôi không nghĩ rằng các chuỗi khác có liên quan, vì lỗi/vấn đề này có thể được sao chép bằng cách chỉ gửi chuỗi 'nhịp tim' hơn và hơn nữa – Tree77

Trả lời

1

Điều đầu tiên tôi cần làm là thoát Wireshark và cố gắng tìm hiểu xem máy chủ có thực sự gửi tin nhắn hay không. Nó sẽ được hướng dẫn để chạy Wireshark tại máy chủ cũng như PC của bên thứ ba. Có điều gì khác biệt về nhịp tim cuối cùng không?


Chỉnh sửa. Vâng, đó là một tìm kiếm thú vị trên máy khách của bạn.

Dường như có một số loại thiết bị đầu cuối theo cách này. Bạn có thể muốn sử dụng chương trình netcat thay vì telnetd. netcat được thiết kế để gửi dữ liệu tùy ý qua một phiên TCP ở chế độ thô, không có bất kỳ định dạng đặc biệt nào và nó có khả năng kết nối một quá trình tùy ý với một ổ cắm. Trên máy Windows, bạn có thể sử dụng PuTTY ở chế độ thô để thực hiện điều tương tự.

Có thể vẫn đáng xem xét lưu lượng truy cập với bên thứ ba giữa máy khách và máy chủ của bạn. Hạt nhân có thể tối ưu hóa việc ghi vào mạng và dữ liệu đệm bên trong. Đó là cách duy nhất để đảm bảo rằng những gì nhìn thấy là những gì thực sự xảy ra trên dây.

+0

Có tôi đã có nghĩ về wireshark để thu thập dữ liệu cách đây một ngày. Tôi có dữ liệu wireshark từ khách hàng. Nó không thấy nhịp tim. Tôi đang làm việc để nhận wireshark từ máy chủ. Sẽ cập nhật câu hỏi khi tôi nhận được dữ liệu đó. Không có gì khác biệt hoặc năng động về nhịp tim. Máy khách Linux (để thử nghiệm) là ứng dụng khách telnet với Ubuntu 9.04 – Tree77

Các vấn đề liên quan