[Wireshark-dev] Decoding a buffer using a particular protocol

Hi everyone, I'm looking at doing what 'decode as' does, but directly in code : User provides a buffer and a protocol to use, and the code would perform the parsing and end up with an epan_dissect_t that contains the parsed information. I understand there might be limitations as to which

[Wireshark-dev] Exposing the encoding of fields

Hi everyone, Sorry for going silent for a while, I had to step away from my Wireshark-based project for a while. Looking at the code of Wireshark, unless I misunderstood it, it seems that the encoding of fields (aside of big/little endian for integers) is not exposed in

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

> -Original Message- > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf > Of Pascal Quantin > Sent: Thursday, August 10, 2017 2:19 AM > To: Developer support list for Wireshark > Cc: Sake Blok > Subject: Re:

Re: [Wireshark-dev] "[UNVERIFIED SENDER]Re: Using C++ for a test tool linking to wireshark

..@amazon.com> > Subject: "[UNVERIFIED SENDER]Re: [Wireshark-dev] Using C++ for a test tool > linking to wireshark > > On Aug 9, 2017, at 11:48 AM, Sultan, Hassan via Wireshark-dev d...@wireshark.org> wrote: > > > I’ve noticed everything in Wireshark seems to be in C89

[Wireshark-dev] Using C++ for a test tool linking to wireshark

Hi, I've noticed everything in Wireshark seems to be in C89 , which I guess is understandable for portability reasons. I'm curious whether you guys would be okay with having an external test tool be in C++ 11 though (think of something like tshark or rawshark but much smaller/simpler and for

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

dev] Hierarchy of fields & offsets again, more > potential > offenders > > > > On Tue, Aug 8, 2017 at 12:29 AM, Sultan, Hassan via Wireshark-dev d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > wrote: > > Hi Hasan, > > > Can you share y

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more > potential offenders > > On Wed, Aug 2, 2017 at 10:03 PM, Sultan, Hassan via Wireshark-dev > wrote: > > Regarding tcp.payload, I don't think tcp.payload in itself has any > > problems. I > think t

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

> -Original Message- > From: Pascal Quantin [mailto:pascal.quan...@gmail.com] > Sent: Wednesday, August 02, 2017 12:41 PM > To: Developer support list for Wireshark > Cc: Sultan, Hassan > Subject: Re: [Wireshark-dev] Hierarchy of fields &

Re: [Wireshark-dev] Setting to disable all expert info

t;wireshark-dev@wireshark.org> > Cc: Sultan, Hassan <sul...@amazon.com> > Subject: Re: [Wireshark-dev] Setting to disable all expert info > > > > 2017-08-02 22:00 GMT+02:00 Sultan, Hassan via Wireshark-dev d...@wireshark.org <mailto:wireshark-dev@wireshark.org> >:

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

org> > Subject: Re: [Wireshark-dev] Hierarchy of fields & offsets again, more > potential > offenders > > On Wed, Aug 2, 2017 at 10:03 PM, Sultan, Hassan via Wireshark-dev d...@wireshark.org> wrote: > > Regarding tcp.payload, I don't think tcp.payload in itself has any >

Re: [Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

17-08-02 21:24 GMT+02:00 Pascal Quantin <pascal.quan...@gmail.com > <mailto:pascal.quan...@gmail.com> >: > > > Hi Hassan, > > > 2017-08-02 1:05 GMT+02:00 Sultan, Hassan via Wireshark-dev > <wireshark-dev@wireshark.org <mailto:wireshark-dev@wireshar

Re: [Wireshark-dev] Setting to disable all expert info

appear tomorrow that significantly alters that. Thanks, Hassan > -Original Message- > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf > Of Jaap Keuter > Sent: Wednesday, August 02, 2017 11:59 AM > To: Sultan, Hassan via Wireshark-dev <wireshark

[Wireshark-dev] Setting to disable all expert info

Hi, Am I right in my understanding that there is no global way of disabling insertion of expert information ? Assuming I'm correct, would anyone object to me adding that setting ? That would be another way of lowering memory footprint. Thx, Hassan

[Wireshark-dev] Hierarchy of fields & offsets again, more potential offenders

Hi all, So I've started adding checks to my wrapper and am finding some interesting cases (they all look like issues that need to be fixed to me, but again, I might be missing something), would someone please take a look and tell me which you think are ok / bugs so I can start sending patches

Re: [Wireshark-dev] "[UNVERIFIED SENDER]Re: "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets

> -Original Message- > From: Guy Harris [mailto:g...@alum.mit.edu] > Sent: Tuesday, July 25, 2017 7:06 PM > To: Sultan, Hassan > Cc: Developer support list for Wireshark > Subject: "[UNVERIFIED SENDER]Re: "[UNVERIFIED SENDER]Re:

Re: [Wireshark-dev] "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets

ENDER]Re: [Wireshark-dev] Hierarchy of fields & > offsets > > On Jul 25, 2017, at 3:26 PM, Sultan, Hassan via Wireshark-dev d...@wireshark.org> wrote: > > > FT_BYTES 198 smb2.security_blob(120) : > 60:76:06:06:2b:06:01:05:05:02:a0:6c:30:6a:a0:3c

Re: [Wireshark-dev] "[UNVERIFIED SENDER]Re: Hierarchy of fields & offsets

mazon.com> Subject: "[UNVERIFIED SENDER]Re: [Wireshark-dev] Hierarchy of fields & offsets On Jul 25, 2017, at 3:26 PM, Sultan, Hassan via Wireshark-dev <wireshark-dev@wireshark.org> wrote: > Any reason why this is done in this way? I don't know, but, whatever it is, it's

[Wireshark-dev] Hierarchy of fields & offsets

Hi, Looking at some of the parsed data in my trials, I am seeing odd things such as : format is : [ftenum] [offset] [name or abbrev] ([length]) : FT_PROTOCOL 66 mysql(9) : FT_UINT24 66 mysql.packet_length(3) : 5

Re: [Wireshark-dev] hf_http_response_code in packet-http.c

_code in packet-http.c > > Hi all, > > I remember a similar discussion around the Contents-Length header some years > ago. > Can’t we make a similar solution here? Then everyone will be happy and we > have a backwards compatible solution. > > Thanks, > Jaap

Re: [Wireshark-dev] Fields offsets & tree hierarchy questions

v] Fields offsets & tree hierarchy questions > > > > On Fri, Jul 14, 2017 at 2:01 PM, Sultan, Hassan via Wireshark-dev d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > wrote: > > > > > > -Original Message- > > From: Wire

Re: [Wireshark-dev] Fields offsets & tree hierarchy questions

v] Fields offsets & tree hierarchy questions > > > > On Fri, Jul 14, 2017 at 1:02 PM, Sultan, Hassan via Wireshark-dev d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > wrote: > > [...] > > 2) When looking at http.file_data(65), the field's

Re: [Wireshark-dev] Fields offsets & tree hierarchy questions

Nevermind the last question, that was me being dumb and fooled by the offset. They actually are under the http tree > -Original Message- > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf > Of Sultan, Hassan via Wireshark-dev > Sent: Friday, July 14

[Wireshark-dev] Fields offsets & tree hierarchy questions

Hi everyone, Sorry to bother you with might be beginner questions but... well... I'm a beginner :) In my quest to understand how Wireshark's parsing engine works I've written a small wrapper that iterates through all parsed fields and displays them in the following format : [offset]

Re: [Wireshark-dev] hf_http_response_code in packet-http.c

ark-dev] hf_http_response_code in packet-http.c > > > > Le 13 juil. 2017 22:00, "Sultan, Hassan via Wireshark-dev" d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > a écrit : > > > > > > -Original Message- > > Fr

Re: [Wireshark-dev] hf_http_response_code in packet-http.c

v] hf_http_response_code in packet-http.c > > > > On Thu, Jul 13, 2017 at 8:47 PM, Sultan, Hassan via Wireshark-dev d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > wrote: > > > > > > -Original Message- > > From:

Re: [Wireshark-dev] hf_http_response_code in packet-http.c

an <sul...@amazon.com > <mailto:sul...@amazon.com> > > > Subject: Re: [Wireshark-dev] hf_http_response_code in packet-http.c > > > > > Hi Hassan, > > > > > > 2017-07-13 19

Re: [Wireshark-dev] hf_http_response_code in packet-http.c

ark-dev] hf_http_response_code in packet-http.c > > Hi Hassan, > > > 2017-07-13 19:25 GMT+02:00 Sultan, Hassan via Wireshark-dev d...@wireshark.org <mailto:wireshark-dev@wireshark.org> >: > > > > > > -Original Message- &

Re: [Wireshark-dev] hf_http_response_code in packet-http.c

v] hf_http_response_code in packet-http.c > > > > On Thu, Jul 13, 2017 at 1:12 AM, Sultan, Hassan via Wireshark-dev d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > wrote: > > > Hi, > > > > I am starting to learn the Wir

[Wireshark-dev] hf_http_response_code in packet-http.c

Hi, I am starting to learn the Wireshark code base, and one thing puzzles me... Why is hf_http_response_code defined as a FT_UINT16 with BASE_DEC rather than an FT_STRING ? It's a text field... not an integer. Anyone can enlighten me ? For the beginner that I am this looks like a bug, even