Re: [Wireshark-dev] Release lifetime and version number changes?

2019-04-16 Thread Jeff Morriss
On Thu, Apr 11, 2019 at 6:55 PM Gerald Combs  wrote:

> We currently have three active release branches: 3.0, 2.6, and 2.4. This
> is because we support each release branch for a set amount of time
> (typically 24 months after the initial .0 release) and our last three .0
> releases were less than 12 months apart. However, having many active
> branches can sometimes cause confusion[1] and far fewer people download the
> "Old Old Stable" release than the "Old Stable" or "Stable" releases. Would
> it make sense to have only two release branches active at any given time,
> e.g. by adjusting our release branch lifetimes to "24 months or whenever we
> have two newer active branches, whichever comes first"?
>
> We've also been using odd minor numbers for development releases and even
> minor numbers for stable releases[2] for many years now. We don't make very
> many development releases and instead tend to have one or more release
> candidates after branch is created. Would it make sense to drop the
> even/odd scheme and make the next major release 3.1.0?
>

As others have said, that should be OK as long as the version in the
not-released-yet code is identifiable.  IIRC part of what got us into
odd/even was:

https://www.wireshark.org/lists/wireshark-bugs/200712/msg00068.html

(Basically: the master branch's version was 0.99.7 while that version was
in development.  sunfreeware.com couldn't get the prior release to build so
they built from SVN and released the software that called itself 0.99.7 -
before we released it.)
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How to improve LUA dissector performance?

2019-04-16 Thread Jeff Morriss
On Mon, Apr 15, 2019 at 9:04 AM David Aldrich 
wrote:

> I haven't seen any answers to my question below. Any thoughts please?
>
> Hi
>> I have written a LUA dissector that analyses large packets that consist
>> of control information and  IQ data (complex numbers).  Until recently I
>> displayed the IQ data as a string and performance was fine. However, I now
>> dissect and display each IQ value and the user has complained of very slow
>> performance when analysing a large capture set of packets.
>>
>> I imagined that dissection of the IQ data would only occur when the tree
>> was expanded to display that data.  The reported slowness suggests that the
>> data for all packets is always dissected regardless of whether or not the
>> data is viewed. Is that correct?
>>
>> Apart from re-coding as a C++ dissector (a lot of work) how could I
>> optimise the current LUA code?
>>
>> Could I add a switch to control whether or not IQ data is dissected?
>>
>
You could try avoiding doing dissection work if the tree is NULL; I'm
assuming that the tree is actually NULL in Lua (I don't know).

In C we've decided checking for tree==NULL isn't worth the code
complication; maybe it could help with a slower language like Lua?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Dissector for a custom protocol which starts as HTTP

2019-04-16 Thread David Ameiss
I've developed a dissector for a custom protocol used by my company. The 
protocol starts out as HTTP, as in an HTTP GET, but after that uses the 
"custom" part - not HTTP at all.


The problem I'm running into is that, once a conversation is identified 
by the HTTP dissector as being HTTP (due to the first message, which IS 
HTTP), it stays that way. My dissector isn't called. I've added my 
dissector as a heuristic dissector for HTTP, but that doesn't seem to 
help. And unfortunately (since subsequent packets are not HTTP) I don't 
have Content-Type to steer the packets my way.


Subsequent packets appear as HTTP Continuation, BTW.

Is there some way to tell HTTP not to treat following packets for that 
conversation as HTTP, and to pass them to my dissector? Or a way to call 
the HTTP dissector (from my dissector) for the first packet WITHOUT it 
being "marked" as HTTP forever and ever?


--
David Ameiss
netsh...@ameissnet.com
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Dissector for a custom protocol which starts as HTTP

2019-04-16 Thread Eugène Adell
Hello,

in the Wireshark GUI did you try the "Decode As" functionality ? You
get it in the right-clic on a packet (or in Analyze menu). You also
can have a look at Analyze -> Enabled protocols.

see : 
https://www.wireshark.org/docs/wsug_html_chunked/ChUseAnalyzeMenuSection.html

Eugene

Le mar. 16 avr. 2019 à 23:22, David Ameiss  a écrit :
>
> I've developed a dissector for a custom protocol used by my company. The
> protocol starts out as HTTP, as in an HTTP GET, but after that uses the
> "custom" part - not HTTP at all.
>
> The problem I'm running into is that, once a conversation is identified
> by the HTTP dissector as being HTTP (due to the first message, which IS
> HTTP), it stays that way. My dissector isn't called. I've added my
> dissector as a heuristic dissector for HTTP, but that doesn't seem to
> help. And unfortunately (since subsequent packets are not HTTP) I don't
> have Content-Type to steer the packets my way.
>
> Subsequent packets appear as HTTP Continuation, BTW.
>
> Is there some way to tell HTTP not to treat following packets for that
> conversation as HTTP, and to pass them to my dissector? Or a way to call
> the HTTP dissector (from my dissector) for the first packet WITHOUT it
> being "marked" as HTTP forever and ever?
>
> --
> David Ameiss
> netsh...@ameissnet.com
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe