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 dissec
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
field_info/header_field
> -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: [Wireshark-dev] Hierarchy of fields & offsets again,
rk-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
>
> ...except for the files in ui/qt and subdirectories t
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 t
p; 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 your tools ? i can be add to wireshar
tential 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 the issue lies in tcp showing a length of 32 only, even though
> it ha
> -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 & offsets again, more
> potential
> offenders
>
ireshark
> Cc: Sultan, Hassan
> 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> >:
>
>
> Here's my scenario :
ireshark-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
> > proble
ailto:pascal.quan...@gmail.com> >:
>
>
> Hi Hassan,
>
>
> 2017-08-02 1:05 GMT+02:00 Sultan, Hassan via Wireshark-dev
> mailto:wireshark-dev@wireshark.org> >:
>
>
> Hi all,
>
> So I've started adding checks to my
ctor, one could 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
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
_
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 t
> -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: [Wireshark-dev]
> Hierarchy of fields & offsets
>
> On Ju
t;
> 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:30:3a:06:0a:2b:06:01:04:01:8
> 2:37:02:02:1e:06:09:2a:
R]Re: [Wireshark-dev] Hierarchy of fields & offsets
On Jul 25, 2017, at 3:26 PM, Sultan, Hassan via Wireshark-dev
wrote:
> Any reason why this is done in this way?
I don't know, but, whatever it is, it's not a *good* reason.
Perhaps they didn't know how to handle a request
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
FT_UINT8 69 mysql.packet_number(1) : 0
> 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
>
>
> > On 13 Jul 2017, at 22:41, Sultan, Hass
uestions
>
>
>
> 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: Wireshark-dev [mailto:wireshark-dev-
uestions
>
>
>
> 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 offset is 0,
> relative to
> t
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
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] [abbrev](
;
> Le 13 juil. 2017 22:00, "Sultan, Hassan via Wireshark-dev" d...@wireshark.org <mailto:wireshark-dev@wireshark.org> > a écrit :
>
>
>
>
> > -Original Message-
> > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.or
>
>
>
> 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: Pascal Quantin [mailto:pascal.quan...
_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:d...@wireshark.org> <mailto:wireshark-
> d
Hassan,
>
>
> 2017-07-13 19:25 GMT+02:00 Sultan, Hassan via Wireshark-dev d...@wireshark.org <mailto:wireshark-dev@wireshark.org> >:
>
>
>
>
> > -Original Message-
> > From: Wireshark-dev [mailto:wireshark-dev-boun...@wiresh
tp.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 Wireshark code base, and one thing puzzles
>
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 th
29 matches
Mail list logo
