1
Java를 사용하여 6633 포트를 열고 OF 패킷을 수신하여 openflow 패킷을 구문 분석합니다.OF_packet_data의 길이가 OF_IN_packet의 전체 길이를 초과합니다
일부 오픈 플로우 PACKET_IN 패킷에 대한 코드가 깨졌습니다. 다음 이미지를 참조하십시오.
저는 미니넷을 사용하여 토폴로지를 시뮬레이션하고 있습니다.
mn --mac --switch ovsk,protocols=OpenFlow13 --controller remote,ip=172.23.107.166,port=6633 --ipbase=2.2.2.0/24 --topo linear,10
Mininet의 vesion : 2.2.1rc1
Openvswitch 버전 : 2.0.2
다음은 Wireshark를 캡처의 스크린 샷이다.
당신은 그 총 길이 (342)를 관찰 할 수는 길이 (170)를 초과한다.
내 자바 코드가 부적절한 데이터 길이 (부적절한 데이터 길이 : 342)로 인해 다음 패킷의 바이트를 파싱하므로 다음 파싱 된 패킷이 손상됩니다.
170 바이트를 읽은 후 구문 분석을 중지해야합니다. 그리고 다음 패킷에 대한 파싱이 시작됩니다.
이유가 무엇일까요?
안녕하세요. Christopher, 버퍼를 170 바이트 세그먼트로 분할 하시겠습니까? 현재, 전체 Openflow 패킷이 분석 될 때, 즉 OFType-OFPacketIn을 포함하여 버퍼의 다음 세그먼트를 구문 분석하기 위해 버퍼가 이동합니다. 패킷 인의 데이터가 한계로 읽 자마자 버퍼가 이동되고 다음 패킷의 위치로 이동합니다 .. 첫 번째 패킷이 올바르게 파싱 된 후 전체 버퍼가 읽히는 문제가 발생합니다 (예 : 모든 후속 세그먼트). 하드 170 바이트 세그먼트 검사가 있어야하며 위치가 다음 세그먼트를 가리키고 있습니까? –
아니요, 어떤 이유로 든이 세그먼트에서 170 바이트/342 바이트가 전송되었으므로 다른 세그먼트에 나머지 172 바이트가 포함됩니다. TCP는 스트리밍 프로토콜이며 세그먼트가 반드시 패킷과 일치하지는 않습니다. 그래서 자바 애플리케이션은 총 길이를 얻기 위해 14 바이트를 먼저 읽은 다음 더 많은 바이트를 읽어야합니다 (이미 총 길이에 포함 된 경우 14 개 미만). 현재 세그먼트에 많은 바이트가 없으면 지금까지 읽은 바이트를 저장하고 342 바이트를 모두 읽을 때까지 읽기를 계속해야합니다. 이 시점에서 전체 페이로드를 갖게됩니다. –
[Openflow spec] [1]을 다시 읽은 후에는 이전 가정이 잘못되었다고 생각합니다. 총 길이는 메시지의 바이트 수로,이 중 "길이"바이트 만 컨트롤러로 전송되었습니다. 이것은 Openflow와 TCP 길이가 일치하고 Wireshark가 잘못된 패킷을 나타냄으로써 패킷이 잘린 경우 일어날 가능성이 높다는 점에서 의미가 있습니다. 그래서 결국 이것은 정상적으로 보일 것으로 예상됩니다. [1] : https : //www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/openflow-spec-v1.3.2.pdf –