Re: [Wireshark-dev] Dissector for a custom protocol which starts as HTTP
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
[Wireshark-dev] Dissector for a custom protocol which starts as HTTP
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] How to improve LUA dissector performance?
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
Re: [Wireshark-dev] Release lifetime and version number changes?
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
