Re: [Wireshark-dev] 1.12.0rc2 : tshark crash when message is on 3 packets
Le 19/06/2014 00:14, Pascal Quantin a écrit : Indeed the sample code in README.dissector was not updated to make use of the new style dissectors (while packet-PROTOABBREV.c sample code is updated). As Graham stated, the new style (indicating the number of bytes consumed by the dissector) should be used. The old one is still here because not all dissectors were converted to new style (quite a long and painful task... :) ). Pascal. 2014-06-18 23:59 GMT+02:00 Graham Bloice graham.blo...@trihedral.com mailto:graham.blo...@trihedral.com: On 18 June 2014 13:12, wsgd w...@free.fr mailto:w...@free.fr wrote: Le 18/06/2014 00:41, Pascal Quantin a écrit : 2014-06-18 0:11 GMT+02:00 Pascal Quantin pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com: 2014-06-16 22:44 GMT+02:00 wsgd w...@free.fr mailto:w...@free.fr: Hello, My protocol (only to test this problem) specifications : tcp port 20640 message is 5 bytes long command line : tshark -r pb.cap -T text -V -- crash (see pb.1.12.0.txt) ** ERROR:print.c:838:get_field_data: code should not be reached This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. wireshark does not crash and display is ok tshark 1.10.6 does not crash and display is ok (see pb.1.10.6.txt) Plugin dissector code is into packet-tcp-5-bytes.c Regards, Olivier Hi Olivier, thanks for the report. This is a regression introduced by g21e0a63b2 commit for bug 9169. I proposed a fix (not calling the data dissector when a subdissector claims that the current TCP fragment needs more desegmentation) here: https://code.wireshark.org/review/2350 Regards, Pascal. Hi Olivier, as Evan noted in the review of my patch, the data dissector should not even be called as your dissector accepted the packet. It appears that there is a small bug in your current code. In function dissect_tcp_5_bytes(), replacing the line 30: return offset; by return offset + available; does not trigger the crash. With the previous code, your dissector was returning the value 0 for frame 4, like if the packet was rejected. But at the same time you were considering the packet as acceptable and changing the pinfo-desegment_len, leading to an inconsistent state that should have been caught by a missing check in packet-tcp.c Regards, Pascal. Hi Pascal, Ok, my fault. Sorry for the inconvenience. Question : the dissect function must return void or int ? I know both versions exist. Is there one deprecated or one better ? Only void dissect function into http://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html. void dissect function into https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob_plain;f=doc/README.dissector : static void dissect_cstr(tvbuff_t * tvb, packet_info * pinfo, proto_tree * tree) I can't see it in the docs anywhere (which is an omission that should be corrected), but epan\packet.h holds a little information about the types of dissector functions. New code should be using the new dissector type. Graham Thank you both. Olivier ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 1.12.0rc2 : tshark crash when message is on 3 packets
Le 18/06/2014 00:41, Pascal Quantin a écrit : 2014-06-18 0:11 GMT+02:00 Pascal Quantin pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com: 2014-06-16 22:44 GMT+02:00 wsgd w...@free.fr mailto:w...@free.fr: Hello, My protocol (only to test this problem) specifications : tcp port 20640 message is 5 bytes long command line : tshark -r pb.cap -T text -V -- crash (see pb.1.12.0.txt) ** ERROR:print.c:838:get_field_data: code should not be reached This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. wireshark does not crash and display is ok tshark 1.10.6 does not crash and display is ok (see pb.1.10.6.txt) Plugin dissector code is into packet-tcp-5-bytes.c Regards, Olivier Hi Olivier, thanks for the report. This is a regression introduced by g21e0a63b2 commit for bug 9169. I proposed a fix (not calling the data dissector when a subdissector claims that the current TCP fragment needs more desegmentation) here: https://code.wireshark.org/review/2350 Regards, Pascal. Hi Olivier, as Evan noted in the review of my patch, the data dissector should not even be called as your dissector accepted the packet. It appears that there is a small bug in your current code. In function dissect_tcp_5_bytes(), replacing the line 30: return offset; by return offset + available; does not trigger the crash. With the previous code, your dissector was returning the value 0 for frame 4, like if the packet was rejected. But at the same time you were considering the packet as acceptable and changing the pinfo-desegment_len, leading to an inconsistent state that should have been caught by a missing check in packet-tcp.c Regards, Pascal. Hi Pascal, Ok, my fault. Sorry for the inconvenience. Question : the dissect function must return void or int ? I know both versions exist. Is there one deprecated or one better ? Only void dissect function into http://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html. void dissect function into https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob_plain;f=doc/README.dissector : static void dissect_cstr(tvbuff_t * tvb, packet_info * pinfo, proto_tree * tree) Regards, Olivier ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 1.12.0rc2 : tshark crash when message is on 3 packets
On 18 June 2014 13:12, wsgd w...@free.fr wrote: Le 18/06/2014 00:41, Pascal Quantin a écrit : 2014-06-18 0:11 GMT+02:00 Pascal Quantin pascal.quan...@gmail.com: 2014-06-16 22:44 GMT+02:00 wsgd w...@free.fr: Hello, My protocol (only to test this problem) specifications : tcp port 20640 message is 5 bytes long command line : tshark -r pb.cap -T text -V -- crash (see pb.1.12.0.txt) ** ERROR:print.c:838:get_field_data: code should not be reached This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. wireshark does not crash and display is ok tshark 1.10.6 does not crash and display is ok (see pb.1.10.6.txt) Plugin dissector code is into packet-tcp-5-bytes.c Regards, Olivier Hi Olivier, thanks for the report. This is a regression introduced by g21e0a63b2 commit for bug 9169. I proposed a fix (not calling the data dissector when a subdissector claims that the current TCP fragment needs more desegmentation) here: https://code.wireshark.org/review/2350 Regards, Pascal. Hi Olivier, as Evan noted in the review of my patch, the data dissector should not even be called as your dissector accepted the packet. It appears that there is a small bug in your current code. In function dissect_tcp_5_bytes(), replacing the line 30: return offset; by return offset + available; does not trigger the crash. With the previous code, your dissector was returning the value 0 for frame 4, like if the packet was rejected. But at the same time you were considering the packet as acceptable and changing the pinfo-desegment_len, leading to an inconsistent state that should have been caught by a missing check in packet-tcp.c Regards, Pascal. Hi Pascal, Ok, my fault. Sorry for the inconvenience. Question : the dissect function must return void or int ? I know both versions exist. Is there one deprecated or one better ? Only void dissect function into http://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html. void dissect function into https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob_plain;f=doc/README.dissector : static void dissect_cstr(tvbuff_t * tvb, packet_info * pinfo, proto_tree * tree) I can't see it in the docs anywhere (which is an omission that should be corrected), but epan\packet.h holds a little information about the types of dissector functions. New code should be using the new dissector type. Graham ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 1.12.0rc2 : tshark crash when message is on 3 packets
Indeed the sample code in README.dissector was not updated to make use of the new style dissectors (while packet-PROTOABBREV.c sample code is updated). As Graham stated, the new style (indicating the number of bytes consumed by the dissector) should be used. The old one is still here because not all dissectors were converted to new style (quite a long and painful task... :) ). Pascal. 2014-06-18 23:59 GMT+02:00 Graham Bloice graham.blo...@trihedral.com: On 18 June 2014 13:12, wsgd w...@free.fr wrote: Le 18/06/2014 00:41, Pascal Quantin a écrit : 2014-06-18 0:11 GMT+02:00 Pascal Quantin pascal.quan...@gmail.com: 2014-06-16 22:44 GMT+02:00 wsgd w...@free.fr: Hello, My protocol (only to test this problem) specifications : tcp port 20640 message is 5 bytes long command line : tshark -r pb.cap -T text -V -- crash (see pb.1.12.0.txt) ** ERROR:print.c:838:get_field_data: code should not be reached This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. wireshark does not crash and display is ok tshark 1.10.6 does not crash and display is ok (see pb.1.10.6.txt) Plugin dissector code is into packet-tcp-5-bytes.c Regards, Olivier Hi Olivier, thanks for the report. This is a regression introduced by g21e0a63b2 commit for bug 9169. I proposed a fix (not calling the data dissector when a subdissector claims that the current TCP fragment needs more desegmentation) here: https://code.wireshark.org/review/2350 Regards, Pascal. Hi Olivier, as Evan noted in the review of my patch, the data dissector should not even be called as your dissector accepted the packet. It appears that there is a small bug in your current code. In function dissect_tcp_5_bytes(), replacing the line 30: return offset; by return offset + available; does not trigger the crash. With the previous code, your dissector was returning the value 0 for frame 4, like if the packet was rejected. But at the same time you were considering the packet as acceptable and changing the pinfo-desegment_len, leading to an inconsistent state that should have been caught by a missing check in packet-tcp.c Regards, Pascal. Hi Pascal, Ok, my fault. Sorry for the inconvenience. Question : the dissect function must return void or int ? I know both versions exist. Is there one deprecated or one better ? Only void dissect function into http://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html. void dissect function into https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob_plain;f=doc/README.dissector : static void dissect_cstr(tvbuff_t * tvb, packet_info * pinfo, proto_tree * tree) I can't see it in the docs anywhere (which is an omission that should be corrected), but epan\packet.h holds a little information about the types of dissector functions. New code should be using the new dissector type. Graham ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 1.12.0rc2 : tshark crash when message is on 3 packets
2014-06-16 22:44 GMT+02:00 wsgd w...@free.fr: Hello, My protocol (only to test this problem) specifications : tcp port 20640 message is 5 bytes long command line : tshark -r pb.cap -T text -V -- crash (see pb.1.12.0.txt) ** ERROR:print.c:838:get_field_data: code should not be reached This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. wireshark does not crash and display is ok tshark 1.10.6 does not crash and display is ok (see pb.1.10.6.txt) Plugin dissector code is into packet-tcp-5-bytes.c Regards, Olivier Hi Olivier, thanks for the report. This is a regression introduced by g21e0a63b2 commit for bug 9169. I proposed a fix (not calling the data dissector when a subdissector claims that the current TCP fragment needs more desegmentation) here: https://code.wireshark.org/review/2350 Regards, Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 1.12.0rc2 : tshark crash when message is on 3 packets
2014-06-18 0:11 GMT+02:00 Pascal Quantin pascal.quan...@gmail.com: 2014-06-16 22:44 GMT+02:00 wsgd w...@free.fr: Hello, My protocol (only to test this problem) specifications : tcp port 20640 message is 5 bytes long command line : tshark -r pb.cap -T text -V -- crash (see pb.1.12.0.txt) ** ERROR:print.c:838:get_field_data: code should not be reached This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. wireshark does not crash and display is ok tshark 1.10.6 does not crash and display is ok (see pb.1.10.6.txt) Plugin dissector code is into packet-tcp-5-bytes.c Regards, Olivier Hi Olivier, thanks for the report. This is a regression introduced by g21e0a63b2 commit for bug 9169. I proposed a fix (not calling the data dissector when a subdissector claims that the current TCP fragment needs more desegmentation) here: https://code.wireshark.org/review/2350 Regards, Pascal. Hi Olivier, as Evan noted in the review of my patch, the data dissector should not even be called as your dissector accepted the packet. It appears that there is a small bug in your current code. In function dissect_tcp_5_bytes(), replacing the line 30: return offset; by return offset + available; does not trigger the crash. With the previous code, your dissector was returning the value 0 for frame 4, like if the packet was rejected. But at the same time you were considering the packet as acceptable and changing the pinfo-desegment_len, leading to an inconsistent state that should have been caught by a missing check in packet-tcp.c Regards, Pascal. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] 1.12.0rc2 : tshark crash when message is on 3 packets
Hello, My protocol (only to test this problem) specifications : tcp port 20640 message is 5 bytes long command line : tshark -r pb.cap -T text -V -- crash (see pb.1.12.0.txt) ** ERROR:print.c:838:get_field_data: code should not be reached This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. wireshark does not crash and display is ok tshark 1.10.6 does not crash and display is ok (see pb.1.10.6.txt) Plugin dissector code is into packet-tcp-5-bytes.c Regards, Olivier -- Wireshark Generic Dissector http://wsgd.free.fr pb.pcap Description: Binary data Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 1, Ack: 1, Len: 4 Data (4 bytes) 00 0f 00 16 Data: 000f0016 [Length: 4] Frame 2: 72 bytes on wire (576 bits), 72 bytes captured (576 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 5, Ack: 1, Len: 18 [2 Reassembled TCP Segments (22 bytes): #1(4), #2(18)] Data: 000f001600 Data: 008001 Data: 88 Data: 8000a4 Frame 3: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 23, Ack: 1, Len: 4 [2 Reassembled TCP Segments (6 bytes): #2(2), #3(4)] Data: 93e0001000 Frame 4: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 27, Ack: 1, Len: 3 Data (4 bytes) 07 03 01 01 Data: 07030101 [Length: 4] Frame 5: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 30, Ack: 1, Len: 4 [3 Reassembled TCP Segments (8 bytes): #3(1), #4(3), #5(4)] Data: 0703010100 Frame 6: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 34, Ack: 1, Len: 27 [2 Reassembled TCP Segments (30 bytes): #5(3), #6(27)] Data: 11001f0001 Data: 581d66f400 Data: 00 Data: 06 Data: 0004000400 Data: 10 Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 1, Ack: 1, Len: 4 Data (4 bytes) 00 0f 00 16 Data: 000f0016 [Length: 4] Frame 2: 72 bytes on wire (576 bits), 72 bytes captured (576 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 5, Ack: 1, Len: 18 [2 Reassembled TCP Segments (22 bytes): #1(4), #2(18)] Data: 000f001600 Data: 008001 Data: 88 Data: 8000a4 Frame 3: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: 00:00:de:4b:da:02 (00:00:de:4b:da:02), Dst: 00:02:55:76:aa:eb (00:02:55:76:aa:eb) Internet Protocol Version 4, Src: 172.16.3.19 (172.16.3.19), Dst: 172.16.3.18 (172.16.3.18) Transmission Control Protocol, Src Port: 20640 (20640), Dst Port: 36179 (36179), Seq: 23, Ack: 1, Len: 4 [2 Reassembled TCP Segments (6 bytes): #2(2), #3(4)] Data: 93e0001000 Frame 4: 60 bytes on wire (480 bits), 60 bytes captured (480
