Re: [Wireshark-dev] Fwd: FW: [PATCH] New protocol dissector - Kingfisher

can you please provide some example captures we can test the dissector with you also have to terminate the value_string with a {0,NULL} entry or it may SEGV if you receive a corrupted packet. On 4/18/07, Rob Casey <[EMAIL PROTECTED]> wrote: > Re-sent from Google mail due to local mail server is

Re: [Wireshark-dev] tcp_dissect_pdus not reassembling packet

the tcp reassembly routine ignores packet with an invalid checksum (since the checksum is invalid there is no point in trying to reassemble invalid data) if you want reassembly to work in presence of incorrect tcp checksums youll have to disable tcp checksum verification in preferences. On 4/26

Re: [Wireshark-dev] TCP: what is an out-of-order segment

this is a tricky area for your particular example maybe the heuristics could be changed to detect that eventhough the left edge of the segment went backward and thus could potentially be either a retransmission/fastretransmission or outoforder segment that since it also had a right edge that cov

Re: [Wireshark-dev] protocol question

since all your examples above are widely used and publicly available standardized protocols is there any particular reason why implementation of these protocols would have to be private and not be contributed to wireshark? (those parts that are missing from the existing dissectors that is) On 4

Re: [Wireshark-dev] [Wiresharkl-dev] Adding a dissector for "Analyze->Decode As" only

> From: Guy Harris <[EMAIL PROTECTED] > > Date: Fri, 16 Feb 2007 16:03:41 -0800 > > On Feb 16, 2007, at 3:28 PM, Ravi Kondamuru wrote: > I am trying to write a dissector for a non-standard rpc protocol. Writing a heuristic to automatically identify the protocol is gett

Re: [Wireshark-dev] Patch Netflow v9 to decode Netflow options, and other fixes

I agree that the hex decoding is a bit strange: I still didn't find the right way to do it. So submitted the patch again, this time without the hex decoding stuff. I also fixed the code so that it differs less from the original. Now is it possible to apply the patch? There are other fixes nee

Re: [Wireshark-dev] asn2wrs problem when value needed from tagged type

Hi Anders, you can try to use: #.FN_BODY OrigTransactionID/_untag VAL_PTR = parameter_tvb ... which should modify type inside tag. BTW When you would like to introduce ASN.1 context for BER too, please do not create new one bur use common one for all ASN.1 encodings. Regards, Tomas -Or

[Wireshark-dev] asn2wrs problem when value needed from tagged type

Hi, There is a problem with the tagged type if a value needs to be returned from it. As the following example from TCAP: #.FN_BODY OrigTransactionID VAL_PTR = parameter_tvb tvbuff_t *parameter_tvb; guint8 len, i; proto_item *tid_item; proto_tree *subtree; tid_item = proto_tree_add_text(tree, tvb,

Re: [Wireshark-dev] [Wireshark-commits] rev 21622: /trunk/ /trunk/epan/dissectors/: packet-q932-ros.c packet-q932-ros.h packet-q932.c packet-qsig.c /trunk/asn1/q932/: packet-q932-ros-template.c packet

Kukosa, Tomas wrote: > Sorry, as I have only Windows build environment I missed that > non-Windows makefile is wrong. > The makefile.nmake contains "-p q932.ros -o q932-ros" options making > what you want. > I could change non-Windows makefile but I can not test it. OK, I've checked in a change to

Re: [Wireshark-dev] [Wireshark-commits] rev 21622: /trunk/ /trunk/epan/dissectors/: packet-q932-ros.c packet-q932-ros.h packet-q932.c packet-qsig.c /trunk/asn1/q932/: packet-q932-ros-template.c packet

Sorry, as I have only Windows build environment I missed that non-Windows makefile is wrong. The makefile.nmake contains "-p q932.ros -o q932-ros" options making what you want. I could change non-Windows makefile but I can not test it. -Original Message- From: [EMAIL PROTECTED] [mailto:[

Re: [Wireshark-dev] [Wireshark-commits] rev 21622: /trunk/ /trunk/epan/dissectors/: packet-q932-ros.c packet-q932-ros.h packet-q932.c packet-qsig.c /trunk/asn1/q932/: packet-q932-ros-template.c packet

Kukosa, Tomas wrote: > do not you like dot in protocol name? :-) I don't mind dots in protocol names. I *do*, however, mind when I cd to asn1/q932 and do "make" and it creates files with names other than the ones the dissector have in epan/dissectors, e.g. packet-q932.ros.c rather than packet-