Re: [Wireshark-dev] Undissected reserved fields
+1. Would use this API if added (especially if it could be used for bitfields). -Sean On Fri, Feb 27, 2015 at 01:06:04PM -0800, Guy Harris wrote: > > On Feb 27, 2015, at 10:28 AM, Jeff Morriss wrote: > > > My opinion (which I've voiced on this list many times over the past ~10 > > years) is that such fields SHOULD be dissected. Even better they should > > have an Expert Info if they are supposed to be 0 and aren't (Guy had > > suggested on a bug or somewhere that we should have an API with a name that > > includes "mbz"--for Must Be Zero--which would add the Expert Info > > automatically). > > It was in the thread that started here: > > https://www.wireshark.org/lists/wireshark-dev/201402/msg00131.html > > and I suggested both proto_tree_add_spare() (for fields that are spare and > *not* required to be zero) and proto_tree_add_mbz() (for fields that *are* > required to be zero) in > > https://www.wireshark.org/lists/wireshark-dev/201402/msg00135.html > > Neither of those take an hf_ value as an argument, so they don't clutter the > list of filterable fields with a bunch of individual values for each set of > spare bits; to look for "must be zero but isn't", you'd look for the expert > info. > ___ > Sent via:Wireshark-dev mailing list > 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 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] Undissected reserved fields
On Feb 27, 2015, at 10:28 AM, Jeff Morriss wrote: > My opinion (which I've voiced on this list many times over the past ~10 > years) is that such fields SHOULD be dissected. Even better they should have > an Expert Info if they are supposed to be 0 and aren't (Guy had suggested on > a bug or somewhere that we should have an API with a name that includes > "mbz"--for Must Be Zero--which would add the Expert Info automatically). It was in the thread that started here: https://www.wireshark.org/lists/wireshark-dev/201402/msg00131.html and I suggested both proto_tree_add_spare() (for fields that are spare and *not* required to be zero) and proto_tree_add_mbz() (for fields that *are* required to be zero) in https://www.wireshark.org/lists/wireshark-dev/201402/msg00135.html Neither of those take an hf_ value as an argument, so they don't clutter the list of filterable fields with a bunch of individual values for each set of spare bits; to look for "must be zero but isn't", you'd look for the expert info. ___ Sent via:Wireshark-dev mailing list 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] Undissected reserved fields
To me this is a granularity/filter issue. For dissectors that I don't personally use (but want to increase filterability), I try to put as many reserved bytes into a single hf_ field, mostly out of laziness (for those that care more about the protocol to clean up/decide granularity). But it does give other users of the dissector a chance to find them with "myprotocol.reserved". Is that better than "myprotocol && _ws.reserved"? not sure. For dissectors I personally use, I still usually don't create an individual reserved field for each place one could be, so if I want to find "all" I don't have a really long filter. You also want consistency so that all protocols use the same convention, so we don't end up with "myprotocol.reserved" for some cases and requiring "myotherprotocol && _ws.reserved" in others. Since we're already far down the "myprotocol.reserved" road now, I'd prefer to stay there rather than update all of the current reserved fields. -Original Message- From: Evan Huus To: Developer support list for Wireshark Sent: Fri, Feb 27, 2015 2:55 pm Subject: Re: [Wireshark-dev] Undissected reserved fields Should Wireshark have an internal _ws.reserved FT_BYTES field and a proto_tree_add_reserved(tvb, offset, len) API? On Fri, Feb 27, 2015 at 2:36 PM, Jeff Morriss wrote: > +1 > > On 02/27/15 14:04, mman...@netscape.net wrote: >> >> What I've done is usually setup a FT_UINT32 and/or a FT_BYTES (with >> different abbreviations) and that's usually inclusive enough (maybe if >> I'm feeling generous setup a FT_UINT8 though FT_UINT32). If dissectors >> only have FT_UINT8 "reserved" fields, then I just add that. But I >> rarely look to give each reserved field a unique name. >> -Original Message- >> From: Graham Bloice >> To: Developer support list for Wireshark >> Sent: Fri, Feb 27, 2015 1:43 pm >> Subject: Re: [Wireshark-dev] Undissected reserved fields >> >> How do we handle the case where a protocol has many reserved fields, do >> they each need an hf and a name? > > > ___ > Sent via:Wireshark-dev mailing list > 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 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 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] Undissected reserved fields
Should Wireshark have an internal _ws.reserved FT_BYTES field and a proto_tree_add_reserved(tvb, offset, len) API? On Fri, Feb 27, 2015 at 2:36 PM, Jeff Morriss wrote: > +1 > > On 02/27/15 14:04, mman...@netscape.net wrote: >> >> What I've done is usually setup a FT_UINT32 and/or a FT_BYTES (with >> different abbreviations) and that's usually inclusive enough (maybe if >> I'm feeling generous setup a FT_UINT8 though FT_UINT32). If dissectors >> only have FT_UINT8 "reserved" fields, then I just add that. But I >> rarely look to give each reserved field a unique name. >> -Original Message- >> From: Graham Bloice >> To: Developer support list for Wireshark >> Sent: Fri, Feb 27, 2015 1:43 pm >> Subject: Re: [Wireshark-dev] Undissected reserved fields >> >> How do we handle the case where a protocol has many reserved fields, do >> they each need an hf and a name? > > > ___ > Sent via:Wireshark-dev mailing list > 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 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] Undissected reserved fields
+1 On 02/27/15 14:04, mman...@netscape.net wrote: What I've done is usually setup a FT_UINT32 and/or a FT_BYTES (with different abbreviations) and that's usually inclusive enough (maybe if I'm feeling generous setup a FT_UINT8 though FT_UINT32). If dissectors only have FT_UINT8 "reserved" fields, then I just add that. But I rarely look to give each reserved field a unique name. -Original Message- From: Graham Bloice To: Developer support list for Wireshark Sent: Fri, Feb 27, 2015 1:43 pm Subject: Re: [Wireshark-dev] Undissected reserved fields How do we handle the case where a protocol has many reserved fields, do they each need an hf and a name? ___ Sent via:Wireshark-dev mailing list 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] Undissected reserved fields
What I've done is usually setup a FT_UINT32 and/or a FT_BYTES (with different abbreviations) and that's usually inclusive enough (maybe if I'm feeling generous setup a FT_UINT8 though FT_UINT32). If dissectors only have FT_UINT8 "reserved" fields, then I just add that. But I rarely look to give each reserved field a unique name. -Original Message- From: Graham Bloice To: Developer support list for Wireshark Sent: Fri, Feb 27, 2015 1:43 pm Subject: Re: [Wireshark-dev] Undissected reserved fields How do we handle the case where a protocol has many reserved fields, do they each need an hf and a name? -- Graham Bloice ___ Sent via:Wireshark-dev mailing list 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 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] Undissected reserved fields
On 27 February 2015 at 18:28, Jeff Morriss wrote: > On 02/27/15 11:40, Dario Lombardo wrote: > >> I'm playing with the "undissected bytes" functionality of wireshark, >> patching some dissectors that clearly lack some fields. But now I've >> found some of them that fall in a "grey area" and I'd lilke to discuss >> with other devels the best way to go on. >> >> I've found that many dissectors lack decoding of "reserved/unused" >> fields. An example of them is the ISL dissector and an example file >> is provabis.pcap (found it in the wiki). >> This field is reserved but is part of the specifications of the protocol >> (have a look here >> http://www.cisco.com/c/en/us/support/docs/lan-switching/ >> 8021q/17056-741-4.html). >> It is clearly stated that the field is 0x0 in ethernet, but can have >> values in token ring or FDDI. >> >> So the general question is: is it correct to leave "reserved/unused" >> fields udecoded? Or would it better to decode them as described in the >> actual specifications (reserved of unused)? >> > > My opinion (which I've voiced on this list many times over the past ~10 > years) is that such fields SHOULD be dissected. Even better they should > have an Expert Info if they are supposed to be 0 and aren't (Guy had > suggested on a bug or somewhere that we should have an API with a name that > includes "mbz"--for Must Be Zero--which would add the Expert Info > automatically). > > Why do I have this opinion? > > Because most of the time the specs say "must be set to 0 on transmission > and ignored on receipt" but I have seen *numerous* cases of senders that > *don't* set the field to 0 talking to receivers that *don't* ignore it. Of > course the result is an interop problem. (As a result of these I've > committed changes to several dissectors to dissect spare fields; in some > cases I think Expert Infos are also raised.) > How do we handle the case where a protocol has many reserved fields, do they each need an hf and a name? -- Graham Bloice ___ Sent via:Wireshark-dev mailing list 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] Undissected reserved fields
On 02/27/15 11:40, Dario Lombardo wrote: I'm playing with the "undissected bytes" functionality of wireshark, patching some dissectors that clearly lack some fields. But now I've found some of them that fall in a "grey area" and I'd lilke to discuss with other devels the best way to go on. I've found that many dissectors lack decoding of "reserved/unused" fields. An example of them is the ISL dissector and an example file is provabis.pcap (found it in the wiki). This field is reserved but is part of the specifications of the protocol (have a look here http://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html). It is clearly stated that the field is 0x0 in ethernet, but can have values in token ring or FDDI. So the general question is: is it correct to leave "reserved/unused" fields udecoded? Or would it better to decode them as described in the actual specifications (reserved of unused)? My opinion (which I've voiced on this list many times over the past ~10 years) is that such fields SHOULD be dissected. Even better they should have an Expert Info if they are supposed to be 0 and aren't (Guy had suggested on a bug or somewhere that we should have an API with a name that includes "mbz"--for Must Be Zero--which would add the Expert Info automatically). Why do I have this opinion? Because most of the time the specs say "must be set to 0 on transmission and ignored on receipt" but I have seen *numerous* cases of senders that *don't* set the field to 0 talking to receivers that *don't* ignore it. Of course the result is an interop problem. (As a result of these I've committed changes to several dissectors to dissect spare fields; in some cases I think Expert Infos are also raised.) ___ Sent via:Wireshark-dev mailing list 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] Undissected reserved fields
I'm playing with the "undissected bytes" functionality of wireshark, patching some dissectors that clearly lack some fields. But now I've found some of them that fall in a "grey area" and I'd lilke to discuss with other devels the best way to go on. I've found that many dissectors lack decoding of "reserved/unused" fields. An example of them is the ISL dissector and an example file is provabis.pcap (found it in the wiki). This field is reserved but is part of the specifications of the protocol (have a look here http://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html). It is clearly stated that the field is 0x0 in ethernet, but can have values in token ring or FDDI. So the general question is: is it correct to leave "reserved/unused" fields udecoded? Or would it better to decode them as described in the actual specifications (reserved of unused)? Thanks for sharing your point of view!! Dario. ___ Sent via:Wireshark-dev mailing list 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] Menagerie
On Fri, Feb 27, 2015 at 10:20 AM, Christopher Maynard wrote: > Evan Huus writes: > >> I have a local copy that I grabbed by logging into the host server - >> I've created a torrent of it (attached) which I am currently seeding, >> so you should be able to grab it from me (and if you do, please seed >> to others in return!). >> >> Gerald hopefully this is OK, as far as I know all of the relevant >> captures are publicly available on Bugzilla or the wiki anyways. >> >> Evan >> >> P.S. This is a snapshot of the menagerie as of today, of course. > > I believe some of the capture files have been marked as "private" and should > not be distributed. At the very least, I would recommend holding off on > publishing any torrent until that can be verified. They are still publicly exposed every time the fuzz-bot finds a bug in our dissection of one of them (unless it knows which ones those are, and files the bugs as core-only)? If they are truly private, they should be moved to a separate part of the menagerie that is not fuzzed regularly. > Also, some time ago, the folks at cloudshark offered a cloudshark appliance > to the Wireshark project. I would much rather see Wireshark take advantage > of something like that than making the menagerie capture files in a way such > as this or how Jakub did years ago. That would certainly be more convenient. > - Chris > > See also: http://goo.gl/oixnSm > > > ___ > Sent via:Wireshark-dev mailing list > 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 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] Menagerie
Evan Huus writes: > I have a local copy that I grabbed by logging into the host server - > I've created a torrent of it (attached) which I am currently seeding, > so you should be able to grab it from me (and if you do, please seed > to others in return!). > > Gerald hopefully this is OK, as far as I know all of the relevant > captures are publicly available on Bugzilla or the wiki anyways. > > Evan > > P.S. This is a snapshot of the menagerie as of today, of course. I believe some of the capture files have been marked as "private" and should not be distributed. At the very least, I would recommend holding off on publishing any torrent until that can be verified. Also, some time ago, the folks at cloudshark offered a cloudshark appliance to the Wireshark project. I would much rather see Wireshark take advantage of something like that than making the menagerie capture files in a way such as this or how Jakub did years ago. - Chris See also: http://goo.gl/oixnSm ___ Sent via:Wireshark-dev mailing list 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] Menagerie
On Fri, Feb 27, 2015 at 3:36 PM, Evan Huus wrote: > I have rsync set up via ssh to the host server, but I'm pretty sure we > can't just give everyone ssh access :) > > Yes of course :). Maybe a public interface like http (or even rsync should be unautenticated, but I have no personal experience using it). For now, hopefully this torrent file works better. > Unfortunately bittorrent is often used for illegal purposes, so in many (enterprise) environments it is forbidden. ___ Sent via:Wireshark-dev mailing list 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] Wireshark crash after removing if(tree)
Hi pascal,
I saw I do have errors due to sdu length. But it was showing packet
malformed. I set many break points an d found every tree produced the
error access violation. In the debug I could see.
I had errors on my code in one function and I have disabled it and seen. So
that's the reason wanted to ask any other possible way to solve this.
Example :
Move all my functions inside my dissect function. So I can put everything
under if (tree) . I do not know it is right or it Will work. I thought of
asking suggestions.
I saw there was a question same issue last time some one posted but there
was no answer so I thought some one may had this problem earlier and help
me.
Thanks pascal.
Raj
On 27 Feb 2015 22:25, "Pascal Quantin" wrote:
>
> Le 27 févr. 2015 14:38, "Raj sekar" a écrit :
> >
> > Hi
> >
> > I am developing custom dissector and i was having issues on reassembly
> >
> > with help from PASCAL i have found my reassembly is not working because
> of if(tree) and if i remove if(tree) i can able to open my pcap file only
> in debug mode (Edit -> preference -> console window = always debugging).
> and i can able to see my reassembly successful. but not in normal mode.
> >
> > i ran MSVC debugger and found the error in trees
> >
> > in dissect function under if(tree)
> >
> > iam calling functions 8+ different functions. in debuggger i could see
> all my sub trees and other trees returning error
> >
> > ALL trees getting CXX0030 ERROR Mnt tree 0x null pointer. First
> child Last child Next Parent Fino Data
> >
> > All the trees have this same error.
> >
> > my code is some thing like this
> >
> > dissect function { if (tree){ call function1(passed tree); call
> function2(passed tree); } } function1 (){ used tree created subtree
> function3 (passed subtree) } function2(){ used tree created subtree
> function4 (passed subtree) } function 4(){ reassembly code here.. }
> >
> > I have used wireshark build 1.11.3 and also i hae tried 1.12.3 both are
> getting same issue .
> >
> > Some one please suggest what i can do with this ? any suggestions to
> overcome from this.
>
> As you seem to deliberately ignore what I already wrote you, I will quote
> myself again:
> "If you read the documentation found in the doc folder of Wireshark source
> code, you will see that this is normal to have tree == NULL on first pass
> and this is gracefully handled by proto_tree_add_XXX functions with recent
> versions of Wireshark (I do not know whether this was the case with older
> versions of Ethereal as they are obsolete since years).
> On subsequent passes, tree will be not NULL. Please refer to the
> documentation for further understanding."
> You told me that your code is triggering malformed packets and starts
> access violation, but despite my numerous requests asking you to do step by
> step debugging to identify the root cause, it seems like you have not done
> it (no I do not believe a NULL tree is an issue unless you try to do
> something very bad with it).
> If someone feels courageous enough to provide support, feel free :) On my
> side I give up here.
> >
> > I have posted the question here
> >
> >
> https://ask.wireshark.org/questions/40125/wireshark-crash-after-removing-of-iftree
> >
> > Please help.
> >
> > Thanks
> >
> > Best Regards
> > Raj
> >
> >
> >
> ___
> > Sent via:Wireshark-dev mailing list
> > 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
> 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
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] Menagerie
On Fri, Feb 27, 2015 at 3:19 PM, Ed Beroset wrote: > > From the originally sent torrent, it seems to be 1.88G. I'm interested in > this too and could seed pretty much perpetually once we get it started. > I would rather prefer a rsync-compatible interface. The scenario I'm figuring out is that a devel downloads the entire set the first time, then just downloads the new files. Rsync would be perfect for that. ___ Sent via:Wireshark-dev mailing list 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] Wireshark crash after removing if(tree)
Le 27 févr. 2015 14:38, "Raj sekar" a écrit :
>
> Hi
>
> I am developing custom dissector and i was having issues on reassembly
>
> with help from PASCAL i have found my reassembly is not working because
of if(tree) and if i remove if(tree) i can able to open my pcap file only
in debug mode (Edit -> preference -> console window = always debugging).
and i can able to see my reassembly successful. but not in normal mode.
>
> i ran MSVC debugger and found the error in trees
>
> in dissect function under if(tree)
>
> iam calling functions 8+ different functions. in debuggger i could see
all my sub trees and other trees returning error
>
> ALL trees getting CXX0030 ERROR Mnt tree 0x null pointer. First
child Last child Next Parent Fino Data
>
> All the trees have this same error.
>
> my code is some thing like this
>
> dissect function { if (tree){ call function1(passed tree); call
function2(passed tree); } } function1 (){ used tree created subtree
function3 (passed subtree) } function2(){ used tree created subtree
function4 (passed subtree) } function 4(){ reassembly code here.. }
>
> I have used wireshark build 1.11.3 and also i hae tried 1.12.3 both are
getting same issue .
>
> Some one please suggest what i can do with this ? any suggestions to
overcome from this.
As you seem to deliberately ignore what I already wrote you, I will quote
myself again:
"If you read the documentation found in the doc folder of Wireshark source
code, you will see that this is normal to have tree == NULL on first pass
and this is gracefully handled by proto_tree_add_XXX functions with recent
versions of Wireshark (I do not know whether this was the case with older
versions of Ethereal as they are obsolete since years).
On subsequent passes, tree will be not NULL. Please refer to the
documentation for further understanding."
You told me that your code is triggering malformed packets and starts
access violation, but despite my numerous requests asking you to do step by
step debugging to identify the root cause, it seems like you have not done
it (no I do not believe a NULL tree is an issue unless you try to do
something very bad with it).
If someone feels courageous enough to provide support, feel free :) On my
side I give up here.
>
> I have posted the question here
>
>
https://ask.wireshark.org/questions/40125/wireshark-crash-after-removing-of-iftree
>
> Please help.
>
> Thanks
>
> Best Regards
> Raj
>
>
>
___
> Sent via:Wireshark-dev mailing list
> 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
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] Menagerie
The size is not huge. Why not just host it on the wireshark main site? Torrent is amazing, but I think it is needed only when the size is really huge. On Fri, Feb 27, 2015 at 3:17 PM, Evan Huus wrote: > 1.8 GB > > I think it's a routing problem, not a torrent problem, I probably need > to open a hole in my firewall or something. I'm at work now anyways, > so I'll look at it again tonight unless somebody beats me to it. > > Evan > > On Fri, Feb 27, 2015 at 9:07 AM, Dario Lombardo > wrote: > > Should be supported by your torrent client (maybe create torrent or > > something). Once you succeded, send us the torrent. > > How large it is? > > > > On Fri, Feb 27, 2015 at 2:42 PM, Evan Huus wrote: > >> > >> Although it seems it's not working for me to download on my laptop - I > >> need to figure out how to properly create/host/seed a torrent I > >> guess... > >> > >> Evan > >> > >> On Fri, Feb 27, 2015 at 8:26 AM, Evan Huus wrote: > >> > I have a local copy that I grabbed by logging into the host server - > >> > I've created a torrent of it (attached) which I am currently seeding, > >> > so you should be able to grab it from me (and if you do, please seed > >> > to others in return!). > >> > > >> > Gerald hopefully this is OK, as far as I know all of the relevant > >> > captures are publicly available on Bugzilla or the wiki anyways. > >> > > >> > Evan > >> > > >> > P.S. This is a snapshot of the menagerie as of today, of course. > >> > > >> > On Fri, Feb 27, 2015 at 8:00 AM, Dario Lombardo > >> > wrote: > >> >> On Fri, Feb 27, 2015 at 1:55 PM, Evan Huus > wrote: > >> >>> > >> >>> > >> >>> I'm not sure if there is a more convenient way to download the > entire > >> >>> menagerie available to the general public. > >> >> > >> >> > >> >> Who can know that? Gerald maybe? It would be very useful when > >> >> conducting > >> >> large scale tests to have access to a local copy of them, just like > the > >> >> buildbot. > >> >> > >> >> > >> >> > ___ > >> >> Sent via:Wireshark-dev mailing list > > >> >> 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 > >> 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 > > 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 > 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 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] Menagerie
Dario Lombardo wrote: >Should be supported by your torrent client (maybe create torrent or >something). Once you succeded, send us the torrent. >How large it is? >From the originally sent torrent, it seems to be 1.88G. I'm interested in >this too and could seed pretty much perpetually once we get it started. Ed ___ Sent via:Wireshark-dev mailing list 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] Menagerie
1.8 GB I think it's a routing problem, not a torrent problem, I probably need to open a hole in my firewall or something. I'm at work now anyways, so I'll look at it again tonight unless somebody beats me to it. Evan On Fri, Feb 27, 2015 at 9:07 AM, Dario Lombardo wrote: > Should be supported by your torrent client (maybe create torrent or > something). Once you succeded, send us the torrent. > How large it is? > > On Fri, Feb 27, 2015 at 2:42 PM, Evan Huus wrote: >> >> Although it seems it's not working for me to download on my laptop - I >> need to figure out how to properly create/host/seed a torrent I >> guess... >> >> Evan >> >> On Fri, Feb 27, 2015 at 8:26 AM, Evan Huus wrote: >> > I have a local copy that I grabbed by logging into the host server - >> > I've created a torrent of it (attached) which I am currently seeding, >> > so you should be able to grab it from me (and if you do, please seed >> > to others in return!). >> > >> > Gerald hopefully this is OK, as far as I know all of the relevant >> > captures are publicly available on Bugzilla or the wiki anyways. >> > >> > Evan >> > >> > P.S. This is a snapshot of the menagerie as of today, of course. >> > >> > On Fri, Feb 27, 2015 at 8:00 AM, Dario Lombardo >> > wrote: >> >> On Fri, Feb 27, 2015 at 1:55 PM, Evan Huus wrote: >> >>> >> >>> >> >>> I'm not sure if there is a more convenient way to download the entire >> >>> menagerie available to the general public. >> >> >> >> >> >> Who can know that? Gerald maybe? It would be very useful when >> >> conducting >> >> large scale tests to have access to a local copy of them, just like the >> >> buildbot. >> >> >> >> >> >> ___ >> >> Sent via:Wireshark-dev mailing list >> >> 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 >> 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 > 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 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] Menagerie
Should be supported by your torrent client (maybe create torrent or something). Once you succeded, send us the torrent. How large it is? On Fri, Feb 27, 2015 at 2:42 PM, Evan Huus wrote: > Although it seems it's not working for me to download on my laptop - I > need to figure out how to properly create/host/seed a torrent I > guess... > > Evan > > On Fri, Feb 27, 2015 at 8:26 AM, Evan Huus wrote: > > I have a local copy that I grabbed by logging into the host server - > > I've created a torrent of it (attached) which I am currently seeding, > > so you should be able to grab it from me (and if you do, please seed > > to others in return!). > > > > Gerald hopefully this is OK, as far as I know all of the relevant > > captures are publicly available on Bugzilla or the wiki anyways. > > > > Evan > > > > P.S. This is a snapshot of the menagerie as of today, of course. > > > > On Fri, Feb 27, 2015 at 8:00 AM, Dario Lombardo > > wrote: > >> On Fri, Feb 27, 2015 at 1:55 PM, Evan Huus wrote: > >>> > >>> > >>> I'm not sure if there is a more convenient way to download the entire > >>> menagerie available to the general public. > >> > >> > >> Who can know that? Gerald maybe? It would be very useful when conducting > >> large scale tests to have access to a local copy of them, just like the > >> buildbot. > >> > >> > ___ > >> Sent via:Wireshark-dev mailing list > >> 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 > 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 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] Menagerie
Although it seems it's not working for me to download on my laptop - I need to figure out how to properly create/host/seed a torrent I guess... Evan On Fri, Feb 27, 2015 at 8:26 AM, Evan Huus wrote: > I have a local copy that I grabbed by logging into the host server - > I've created a torrent of it (attached) which I am currently seeding, > so you should be able to grab it from me (and if you do, please seed > to others in return!). > > Gerald hopefully this is OK, as far as I know all of the relevant > captures are publicly available on Bugzilla or the wiki anyways. > > Evan > > P.S. This is a snapshot of the menagerie as of today, of course. > > On Fri, Feb 27, 2015 at 8:00 AM, Dario Lombardo > wrote: >> On Fri, Feb 27, 2015 at 1:55 PM, Evan Huus wrote: >>> >>> >>> I'm not sure if there is a more convenient way to download the entire >>> menagerie available to the general public. >> >> >> Who can know that? Gerald maybe? It would be very useful when conducting >> large scale tests to have access to a local copy of them, just like the >> buildbot. >> >> ___ >> Sent via:Wireshark-dev mailing list >> 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 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] Wireshark crash after removing if(tree)
Hi
I am developing custom dissector and i was having issues on reassembly
with help from PASCAL i have found my reassembly is not working because of
if(tree) and if i remove if(tree) i can able to open my pcap file only in
debug mode (Edit -> preference -> console window = always debugging). and i
can able to see my reassembly successful. but not in normal mode.
i ran MSVC debugger and found the error in trees
in dissect function under if(tree)
iam calling functions 8+ different functions. in debuggger i could see all
my sub trees and other trees returning error
ALL trees getting CXX0030 ERROR Mnt tree 0x null pointer. First
child Last child Next Parent Fino Data
All the trees have this same error.
my code is some thing like this
dissect function { if (tree){ call function1(passed tree); call
function2(passed tree); } } function1 (){ used tree created subtree
function3 (passed subtree) } function2(){ used tree created subtree
function4 (passed subtree) } function 4(){ reassembly code here.. }
I have used wireshark build 1.11.3 and also i hae tried 1.12.3 both are
getting same issue .
Some one please suggest what i can do with this ? any suggestions to
overcome from this.
I have posted the question here
https://ask.wireshark.org/questions/40125/wireshark-crash-after-removing-of-iftree
Please help.
Thanks
Best Regards
Raj
___
Sent via:Wireshark-dev mailing list
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] Menagerie
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Evan Huus Sent: den 27 februari 2015 13:56 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Menagerie >The menagerie consists mostly of files uploaded to bugzilla. Captures attached >to bug tickets are automatically added to the menagerie, and most files in the >menagerie can be downloaded from a bug >report somewhere. > >I'm not sure if there is a more convenient way to download the entire >menagerie available to the general public. Adding files is as easy as filing a >dummy bug and attaching files to that. I think you can also add them to the wiki sample captures. Regards Anders > On Feb 27, 2015, at 05:41, Dario Lombardo wrote: > > Browsing the buildbot site, I've read somewhere about menagerie. I suppose it > is a large set of file that is used as regression test. > Is it correct? Is it possible to download it? And to upload new samples to it? > Thanks. > Dario. > ___ > Sent via:Wireshark-dev mailing list > 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 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 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] Menagerie
On Fri, Feb 27, 2015 at 1:55 PM, Evan Huus wrote: > > I'm not sure if there is a more convenient way to download the entire > menagerie available to the general public. Who can know that? Gerald maybe? It would be very useful when conducting large scale tests to have access to a local copy of them, just like the buildbot. ___ Sent via:Wireshark-dev mailing list 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] Menagerie
The menagerie consists mostly of files uploaded to bugzilla. Captures attached to bug tickets are automatically added to the menagerie, and most files in the menagerie can be downloaded from a bug report somewhere. I'm not sure if there is a more convenient way to download the entire menagerie available to the general public. Adding files is as easy as filing a dummy bug and attaching files to that. > On Feb 27, 2015, at 05:41, Dario Lombardo wrote: > > Browsing the buildbot site, I've read somewhere about menagerie. I suppose it > is a large set of file that is used as regression test. > Is it correct? Is it possible to download it? And to upload new samples to it? > Thanks. > Dario. > ___ > Sent via:Wireshark-dev mailing list > 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 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] Menagerie
Browsing the buildbot site, I've read somewhere about menagerie. I suppose it is a large set of file that is used as regression test. Is it correct? Is it possible to download it? And to upload new samples to it? Thanks. Dario. ___ Sent via:Wireshark-dev mailing list 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] Building Own GUI for stats plugin
Hi I am creating a separate stats plugin, which will only be distributed to customers and in-house. Adding a statistics entry and displaying the general information is a no-brainer using the stats_tree functions. But I would need to add my own GUI elements, as well as graphical and statistics information. I've browsed quite a bit, but cannot find anything, that would suit my needs. I would either need some kind of handle provided by the stats_tree plugin (or a similair interface), so that I just get a reference to the gui window and add my own stuff there (for Qt and GTK), or the ability, to add a statistics menu entry, which calls my own menu callback, so that I can go from there, but then I would need to ensure, that my statistic is not hidden by the main wireshark instance. I know that some companies do extend Wireshark to achieve that (seems Riverbed being one of them), but is there a way without modifying the source? If not, should I create one and submit it to gerrit? Would this be accepted for future implementations as a general option? regards, Roland ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
