WireShark가이 프레임이 재 조립 된 PDU의 TCP 세그먼트라고 생각하는 이유

작은 PCAP 파일을 찾아주세요 여기 내 문제를 설명.

3 방향 TCP 핸드 셰이크가 있고 두 번의 FIX 로그온이 있습니다. (FIX는 거래에 사용되는 프로토콜입니다.) 첫 번째 FIX 로그온 (프레임 4)은 WireShark에서 잘 해석되고 구문 분석되지만 두 번째 로그온 (프레임 6)은로 해석됩니다 TCP segment of a reassembled PDU.

그러나 프레임 6은 재 조립 된 PDU의 TCP 세그먼트 가 아닙니다 . 전체 TCP PDU가 포함되어 있으며 FIX 로그온으로 해석되고 구문 분석되어야합니다. 시퀀스 번호, ACK 번호, IP 총 길이 등이 모두 올바른지 확인했습니다.

프레임 6이 재 조립 된 PDU의 TCP 세그먼트로 해석되는 이유는 무엇입니까?

tcp wireshark

— 랜덤 블루
소스

이로 인해 발생한 문제가 있습니까?

— Nathan C

예,이 모든 프레임을 생성 중이며 분명히 내가 한 일에 문제가 있습니다.

— Randomblue

귀하의 질문에 프레임 4와 6 (및 아마도 인접한 프레임)의 두드러진 세부 사항을 포함시키는 것이 좋습니다. pcap 파일에 대한 링크는 훌륭하지만 소수의 독자 만이 실제로 다운로드하여 보는 경향이 있습니다.

— Skyhawk

언뜻 보면 찾을 수있는 것이 없습니다. 세그먼트 4는 단편화되지 않았다. 프레임 6은 대상에서 왔으며이 프레임 6은 프레임 4의 서버 응답으로 해석되어야합니다. 즉, FIX 로그온이 수행되어야합니다. 권리.

— Soham Chakraborty 2016 년

호스트의 번호가 .76 및 .67 인 것은 약간의 문제입니다.

Wireshark는 프레임 6을 "재 조립 된 PDU의 TCP 세그먼트"라고 부릅니다. 10.10.10.67의 TCP 구현은 프레임 6으로 전송 된 페이로드를 포함하지 않고 페이로드 ( "네이 키드"ACK)없이 ACK를 보내도록 선택하고 있기 때문입니다. 프레임 5의 ACK w (이것은 OS / IP 스택 종속 동작입니다.) 이는 여러 TCP 세그먼트에서 FIX dissector로 페이로드를 전달하는 TCP dissector의 동작을 트리거합니다. 어떤 이유로 든 FIX dissector는 프레임 6을 해석하지 않습니다.

TCP dissector 옵션에서 "subdissector가 TCP 스트림을 세분화 할 수 있도록 허용"옵션을 끄면 Wireshark가이를 다르게 해석한다는 것을 알 수 있습니다.

Wireshark 스크린 샷

여기 같은 일에 대한 와이어 샤크 사용자 목록에서 논의가 .

— 에반 앤더슨
소스