Re: [Wireshark-dev] Failed pipeline for nvmeof_getlog_page | wireshark | 3a8e09ef

[ronnie sahlberg]

It seems like you already know what is wrong and how to solve this.
Why not just change your patch so it does not trigger this compiler
error/warning?


Maybe the compiler is overly sensitive here? Who knows.
Why is this a problem for wireshark developers?

Do this:
* fix your code so it does not trigger the warnings.  Wireshark developers
are not supposed to
keep track of what are false warnings that are bogus or what are real
problems.
* if you have a problem with the compiler, bring it up with them. we are
not compiler developers or maintainers.
* work on your people skills. You are rubbing people that could help you in
seriosly the wrong way.


On Wed, Mar 31, 2021 at 5:21 PM Constantine Gavrilov 
wrote:

> I have a question regarding for a special form of automatic builds that I
> do not understand.
>
> Occasionally, I get an email for additional pipeline build that is
> different from default pipeline linked to the ticket. It is a wider set of
> compilers and distributions.
>
> Several questions:
>
>1. What is the significance of this and when it is triggered?
>2. Why it is not linked to MR (meaning I cannot see this failure in
>MR)?
>3. Shall I fix these failures?
>4. How do I know that the issue is fixed, since such builds are not
>linked to MR?
>5.
>
> I have looked at this particular one, and it is a a bug in compiler:
>
> guint64 off =...; /* take from command context, now looking at reply */
> if (off < 40)
> proto_add_item(,  40-off,.);
>
> So, the error (in CLANG-11) is (40-off) is 64-bit and passing it as 32-bit
> parameter "looses high-order bits".
>
> First, the compiler shall see that no loss of value takes place because of
> the "IF" statement here. Second, since when passing 64-bit value as a
> 32-bit parameter shall be a compiler error in C language?
>
> I can easily fix this (check the value in saved context, and if it is
> above possible payload length return, then declare off as 32-bit), but I
> need to know if CLANG-11 (with draconian compile options) is a MUST to
> pass.
>
>
> -
> 
> Constantine Gavrilov
> Storage Architect
> Master Inventor
> Tel-Aviv Storage Lab IDT Lead
> Tel-Aviv IBM Storage Lab
> 1 Azrieli Center, Tel-Aviv
> 
> - Forwarded by Constantine Gavrilov/Israel/IBM on 03/31/2021 10:07 AM
> -
>
> From:GitLab 
> To:
> Date:03/30/2021 05:37 PM
> Subject:[EXTERNAL] Failed pipeline for nvmeof_getlog_page |
> wireshark | 3a8e09ef
> Sent by:git...@mg.gitlab.com
> --
>
>
> Pipeline #278885577 has failed!   Project Constantine Gavrilov / wireshark
> Branch nvmeof_getlog_page Commit
> ‍‍‍ZjQcmQRYFpfptBannerStart
> *This Message Is From an External Sender *
> This message came from outside your organization.
> ZjQcmQRYFpfptBannerEnd
>
> Pipeline #278885577 has failed!
>
>
> Project
> Constantine Gavrilov / wireshark
> 
> Branch
> nvmeof_getlog_page
> 
>
> Commit
> 3a8e09ef
> 
> NVMe: Get LogPage: Commands Supported and Effects
> Commit Author
> Constantine Gavrilov 
>
>
>
> Pipeline #278885577
> triggered
> by
> Constantine Gavrilov 
>
> had 1 failed build.
> Failed builds
> build
>
> clang-11 
>
>
>
>
> You're receiving this email because of your account on gitlab.com. Manage
> all notifications  · Help
> 
>
>
>
> ___
> 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

Re: [Wireshark-dev] Is there a way to easily go to the next packet that satisfies a filter string without filtering the packets

[ronnie sahlberg]

Doesn't wireshark already have this?

CTRL-F and then type in the filter string
then click "Find" and it will cycle through the packets that are matching.

On Sun, Mar 21, 2021 at 7:18 AM Richard Sharpe
 wrote:
>
> Hi folks,
>
> I use Wireshark a great deal in my job because I am always looking at
> captures when trying to figure out bugs in our code.
>
> I often have captures with a lot of different types of packets and
> need to find a particular set of packets of mixed type, eg SMB2
> followed by the NFS packets caused by the SMB2 request or SMB2
> followed by the Kerberos packets caused etc.
>
> What I would like to be abe to do is to set up a filter string for a
> specific type of SMB2 request, say, based on source and dest IP and
> maybe type (ie, a CREATE, or whatever) and then go to the first such
> packet in the capture and then examine the subsequent packets to see
> if they satisfy my criteria. If they don't then I would like to go the
> next packet that satisfies my filter string and examine them, and so
> on until I find what I am looking for.
>
> I will usually also have filtered already on two types of frames (or a
> few types) like SMB2 || NFS.
>
> Currently, the only way I can think to do this is to filter on SMB2,
> select the first one I am interested in, unfilter (or refilter),
> examine the packets, and if they are not what I am interested in,
> refilter on SMB2 and select the next packet, and so on. The workflow
> is quite painful.
>
> Is there a simpler way to do this?
>
> If not, could we add a button for Next packet satisfying filter?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> 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

Re: [Wireshark-dev] [Outreachy] Internship blog 2020

[ronnie sahlberg]

Just a followup to clarify,

Take [1] and [2] as good suggestions, then look at other dissectors
and mimic them.
We are pretty flexible and forgiving when it comes to style and as
long as you mostly match what
other dissectors look like no one will object.

On Fri, Dec 4, 2020 at 1:28 PM ronnie sahlberg  wrote:
>
> On Fri, Dec 4, 2020 at 12:47 PM Jonathan Nieder  wrote:
> >
> > Hi Joey,
> >
> > Joey Salazar wrote:
> >
> > > Very happy to be joining for this winter's internship! A short blog
> > > entry on the beginning of this journey here: https://jsal.home.blog/
> > >
> > > A new entry every 2 weeks, check it out!
> > >
> > > Thank you Outreachy, Git, and Wireshark for the opportunity, happy
> > > to be working together!
> >
> > Welcome!  I'm looking forward to working together (starting with an
> > initial wireshark patch to get the lay of the land, then fleshing out
> > the plan for the project, then executing on it in earnest).
> >
> > A question for wireshark developers: are there preferences for what a
> > high quality dissector looks like?  [1] talks about portability and
> > robustness but doesn't address other aspects of convention such as how
> > long functions should be (like [2] does).  Is there a rule of thumb
> > like "when in doubt, do things the way 
> > does?"
>
> Only speaking for myself. This one is tricky.
> Most dissectors I think follows [1] and [2] pretty closely, with the
> exception that I don;t think
> there is any concern about lengths of a function. For a lot of
> protocols you may end up with
> switch statements with hundreds of cases and then that is just how it
> is. Or similar.
>
> Now, this is not uniform across all dissectors. Wireshark has grown
> organically over more than two decades
> and styles and preferences, which at the end of the day are dictated
> by the developers, change.
>
> So do not be surprised to find some dissectors that are very different
> in style. In some cases it might
> just be that the dissector is very old and also for an obscure
> protocol that almost no one cares about.
> Sometimes it is that simple.
>
> I would see [1] and [2] as good guidelines but not absolute law. Then
> also when in doubt look at how are things done
> in popular protocols where there are many developers involved and
> where the dissector is well maintained.
> For example  packet-smb2.c  is pretty modern and has a fair amount of
> crunch to keep up with the evolving standard.
>
> Modern and popular(i.e. people care about them) dissectors also are
> much more likely to contain useful examples of more advanced features
> such as
> * ExpertInfo,
> * Preferences,
> * Reassembly,
> * lots of Generated items (things that are not part of the packet
> itself but still useful to show when wireshark deducts it),
> * state tracking such as keeping track on Request and Response
> matching and response times.
> etc etc etc.
>
> This makes the dissectors more daunting to look at since there are so
> many different concepts there ontop of just "show what the bits and
> bytes mean" but at the same time they show these extra things that we
> usually have in a good/popular/mature dissector.
>
>
> But at the end of the day, for every protocol, what makes a good
> dissector is what an experienced engineer would need to do his/her
> job.
> I think that means that it takes a lot of subject-matter-expert
> knowledge to know what is useful and what is not and here you probably
> have as good or probably better input on what the dissection features should 
> be.
>
> Hypothetical example: say if wireshark had a feature where it would
> reassemble objects and store them under their hash somewhere
> and it allowed you to right-click on a sha1 in the dissection pane and
> then "export object as file". Would that be useful?
> You would know if it would be useful for git developers and engineers.
> I have no idea.
>
> ronnie
>
> >
> > Excited,
> > Jonathan
> >
> > [1] https://gitlab.com/wireshark/wireshark/-/raw/master/doc/README.developer
> > [2] https://www.kernel.org/doc/html/v5.9/process/coding-style.html
> > ___
> > 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

Re: [Wireshark-dev] [Outreachy] Internship blog 2020

[ronnie sahlberg]

On Fri, Dec 4, 2020 at 12:47 PM Jonathan Nieder  wrote:
>
> Hi Joey,
>
> Joey Salazar wrote:
>
> > Very happy to be joining for this winter's internship! A short blog
> > entry on the beginning of this journey here: https://jsal.home.blog/
> >
> > A new entry every 2 weeks, check it out!
> >
> > Thank you Outreachy, Git, and Wireshark for the opportunity, happy
> > to be working together!
>
> Welcome!  I'm looking forward to working together (starting with an
> initial wireshark patch to get the lay of the land, then fleshing out
> the plan for the project, then executing on it in earnest).
>
> A question for wireshark developers: are there preferences for what a
> high quality dissector looks like?  [1] talks about portability and
> robustness but doesn't address other aspects of convention such as how
> long functions should be (like [2] does).  Is there a rule of thumb
> like "when in doubt, do things the way 
> does?"

Only speaking for myself. This one is tricky.
Most dissectors I think follows [1] and [2] pretty closely, with the
exception that I don;t think
there is any concern about lengths of a function. For a lot of
protocols you may end up with
switch statements with hundreds of cases and then that is just how it
is. Or similar.

Now, this is not uniform across all dissectors. Wireshark has grown
organically over more than two decades
and styles and preferences, which at the end of the day are dictated
by the developers, change.

So do not be surprised to find some dissectors that are very different
in style. In some cases it might
just be that the dissector is very old and also for an obscure
protocol that almost no one cares about.
Sometimes it is that simple.

I would see [1] and [2] as good guidelines but not absolute law. Then
also when in doubt look at how are things done
in popular protocols where there are many developers involved and
where the dissector is well maintained.
For example  packet-smb2.c  is pretty modern and has a fair amount of
crunch to keep up with the evolving standard.

Modern and popular(i.e. people care about them) dissectors also are
much more likely to contain useful examples of more advanced features
such as
* ExpertInfo,
* Preferences,
* Reassembly,
* lots of Generated items (things that are not part of the packet
itself but still useful to show when wireshark deducts it),
* state tracking such as keeping track on Request and Response
matching and response times.
etc etc etc.

This makes the dissectors more daunting to look at since there are so
many different concepts there ontop of just "show what the bits and
bytes mean" but at the same time they show these extra things that we
usually have in a good/popular/mature dissector.


But at the end of the day, for every protocol, what makes a good
dissector is what an experienced engineer would need to do his/her
job.
I think that means that it takes a lot of subject-matter-expert
knowledge to know what is useful and what is not and here you probably
have as good or probably better input on what the dissection features should be.

Hypothetical example: say if wireshark had a feature where it would
reassemble objects and store them under their hash somewhere
and it allowed you to right-click on a sha1 in the dissection pane and
then "export object as file". Would that be useful?
You would know if it would be useful for git developers and engineers.
I have no idea.

ronnie

>
> Excited,
> Jonathan
>
> [1] https://gitlab.com/wireshark/wireshark/-/raw/master/doc/README.developer
> [2] https://www.kernel.org/doc/html/v5.9/process/coding-style.html
> ___
> 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

Re: [Wireshark-dev] Packet Diagram shows only raw bytes of a subtree instead of individual fields

[ronnie sahlberg]

On Tue, Dec 1, 2020 at 7:51 AM Gerald Combs  wrote:
>
> On 11/26/20 11:03 AM, John Thacker wrote:
> >
> > On Thu, Nov 26, 2020 at 1:19 PM Maynard, Christopher via Wireshark-dev 
> > mailto:wireshark-dev@wireshark.org>> wrote:
> >
> > Many protocols contain subtrees, such as a header with various fields 
> > that are part of the header, and it’s convenient/logical to group those 
> > fields within the header subtree.  However, doing so results in a Packet 
> > Diagram that only shows the raw bytes of the subtree rather than the 
> > individual fields contained within the subtree.
> >
> > So either I’m doing something wrong, in which case I welcome any 
> > suggestions for improving the display, or there seems to be a current 
> > limitation to the way the Packet Diagram behaves with respect to subtrees.  
> > Has anyone else noticed this?
> > ...
> >
> > Is there a way to achieve this while still grouping the fields within a 
> > subtree?
> >
> >
> > Not in a subtree currently. If you look around line 600 of 
> > ui/qt/packet-diagram.cpp, you'll see that it only groups the top level 
> > fields in each protocol.
>
> That's correct. I wanted to keep the initial implementation as simple, naive, 
> and lazy as possible.
>
> > For the same reason, bitmask fields that are grouped together not in a 
> > subtree, using proto_tree_add_bitmask_list()
> > (like packet-rtp.c#L2072 with octet1_fields), then they are displayed 
> > separately (in master, post commit
> > https://gitlab.com/wireshark/wireshark/-/commit/7654bb260d08fdb7adeafce1877fa3c38f3465ae
> >  
> > 
> >  ), whereas
> > for bitmask fields that are added with a subtree with 
> > proto_tree_add_bitmask() only the top level header
> > item appears.
> >
> > You can see some images here: 
> > https://gitlab.com/wireshark/wireshark/-/merge_requests/959 
> > 
> > There you can see bitmask fields that are displayed properly because there 
> > is no subtree.
> >
> > I agree it would be a nice enhancement to travel down into the children of 
> > items that have children, though I imagine
> > you'd have to take care in some cases; e.g., dissect_e164_msisdn() from 
> > packet-e164.[ch] is used a lot in various dissectors,
> > and has a header that has the entire number, with child that only has the 
> > country code (but not a child for the non country code digits).
> > The simplest way to descend into the subtree for a E.164 number would thus 
> > only has an entry for the country code but leave the
> > other bits blank. Or you could have issues with dealing with overlaps.
>
> Would it make sense to add second-level items only if they collectively fit 
> the offset+size of the top-level item? In this case we'd skip the 
> second-level country code child, but we'd add it if dissect_e164_msisdn() 
> added a non-country code sibling field.

I think so, it is worth trying.
When it expands these subtrees I think it would be nice also if it
would put an extra thick border around the entire subtree.
So it is easy to visually see what the different subtrees are.
(See smb2 as an example, it has two subtrees in every pdu, header and
command, and nothing else)

(
I tested adding a new flag for items so you you could tell wireshark
to step down into these subtrees.
It was mainly driven by SMB2 which only has two top level items and I
wanted to at least show the content of "smb2/header" instead of it
just being a 64 byte blob
but threw it away because it would be unrealistic to go through all
dissectors manually and individually flag which trees to expand
)

>
> BTW, for 1- and possibly 2-bit fields we might want to take inspiration from 
> https://twitter.com/vivekrj/status/1269649718059118601 and rotate the label 
> 90 degrees.
> ___
> 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

Re: [Wireshark-dev] Joint project with Git for outreachy

[ronnie sahlberg]

Hi Emily

I got confused. I worked in Jonathans team about 5-6 years ago and
since I am old fart I couldn't realize that maybe they had other
people join since I left.
Hence I assumed you were the intern.

Just me being senile. No harm meant.

Regardless, a git dissectors will be totally awesome so whomever ends
up being the intern or whatever doing it, I will be happy to help
them get it going and have a successfull project that they can
remember with joy and be proud of.

regards
ronnie sahlberg

On Mon, Sep 21, 2020 at 2:17 AM Emily Shaffer  wrote:
>
> On Sat, Sep 19, 2020 at 03:36:23PM -0700, Junio C Hamano wrote:
> >
> > "brian m. carlson"  writes:
> >
> > > On 2020-09-19 at 09:12:53, ronnie sahlberg wrote:
> > >> Hi Jonathan,
> > >> Hi Emily
> > >>
> > >> Emily, you want to contribute to wireshark? That is awesome. I think I
> > >> speak for everyone to send a HUGE welcome
> > >> your way and hope your experience working on and with wireshark be 
> > >> excellent!
> > >
> > > I think there's been a misunderstanding.  I think the proposal was to
> > > have Emily and Jonathan, who are both significant contributors to Git,
> > > doing the mentoring from the Git side, along with someone from the
> > > Wireshark side.  I don't think we know yet if anyone will be interested
> > > in working on it, but it seems from the response to be a proposal that
> > > has interest in both projects.
> > >
> > > Feel free to correct me if I've misunderstood.
> >
> > That matches my understanding.
>
> Right - brian and Junio are correct, I'm hoping to co-mentor with
> Jonathan. Ronnie, I'm really pleased to see this warm welcome, which
> makes me optimistic about the kind of experience an intern would have on
> this project. It would be really great if we could get a volunteer to
> serve as point-of-contact if the mentee is not sure about something
> they want to send to the Wireshark list, and possibly to come to an
> introductory real-time chat (video/voice/IM) to provide a little
> overview and nudge in the right direction.
>
> It sounds to me like we have enough enthusiasm to put this project on
> the list, though - if I understood my conversation with Jonathan last
> week he's planning to add that. Feel free to correct me :)
>
> Thanks, Ronnie and Richard!
>
> > > > (
> > > > Jonathan, remember that smb2 client I was working on, libamb2?  I got
> > > > it to run on PlayStation2 now. It is totally awesome being able to use
> > > > SMB3.1.1 and full encryption to copy file between the PS2 memory card
> > > > and Azure cloud file server :-)
> > > > )
>
> (This actually sounds awesome. Got a repo or blog post up somewhere?)
>
>  - Emily
___
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] Joint project with Git for outreachy

[ronnie sahlberg]

Hi Jonathan,
Hi Emily

Emily, you want to contribute to wireshark? That is awesome. I think I
speak for everyone to send a HUGE welcome
your way and hope your experience working on and with wireshark be excellent!

I think a git dissector would be really awesome.
We do have a packet-git.c already in wireshark, but looking at it it
is very barebones (understatement of the year:-)
but getting a real full blown git protocol implementation would be
totally awesome.

I am more than happy to provide feedback and advice for Emily. We do
have pretty good development documentation so it should be pretty easy
to get started and get a development environment up and running.


(
Jonathan, remember that smb2 client I was working on, libamb2?  I got
it to run on PlayStation2 now. It is totally awesome being able to use
SMB3.1.1 and full encryption to copy file between the PS2 memory card
and Azure cloud file server :-)
)

best regards
Ronnie Sahlberg




On Sat, Sep 19, 2020 at 8:21 AM Jonathan Nieder  wrote:
>
> Hi wiresharkers,
>
> Outreachy <https://www.outreachy.org/> is a program similar to the
> Google Summer of Code, providing internships to work on open source
> projects.
>
> Emily (cc-ed) and I would be interested in mentoring an outreachy
> intern on adding support for the Git protocol to wireshark.  We think
> this would be helpful for documenting the spec better, for making
> debugging easier for future Git developers, and for helping people
> working on systems involving Git (e.g. CI systems) to understand the
> behavior of the systems they oversee.  We think that a co-mentor
> within wireshark would be helpful for making sure an intern is set up
> for success (helping them find pointers, making sure their approach is
> on the right track, etc).
>
> This would be a project under the Git umbrella
> <https://www.outreachy.org/communities/cfp/git/>.
>
> What do you think?  Does this sound interesting to you?
>
> Thanks,
> Jonathan
___
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] Code of Conduct for our community

[ronnie sahlberg]

I agree,

The samba one is much more comfortable.

On Thu, Aug 6, 2020 at 3:07 AM Richard Sharpe
 wrote:
>
> On Wed, Aug 5, 2020 at 8:49 AM Uli Heilmeier  wrote:
> >
> > All,
> >
> > As discussed in the last Remote Developer Den meeting I see a Code of 
> > Conduct (CoC) as helpful for our community.
>
> Why? Nothing is broken at the moment, so nothing needs fixing, AFAICT.
>
> I would suggest the following alternative approach that the Samba team
> seems to have adopted:
>
> https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely
>
> As far as I can recall, there have been no instances of the behavior
> the Contributor Covenant seems to protect against, so what is the
> point here?
>
> Is someone saying that Wireshark is bad because of harassment on the lists?
>
> > I propose that we adopt the "Contributor Covenant" version 2 [1] for our 
> > community.
> > This is a well established CoC with a good scope (including code review, 
> > mailing lists, ask.wireshark.org, Sharkfest).
> >
> > The instance to handel reports should be a team consisting of 3 or 5 well 
> > accepted community members (not only core
> > devs). The email address to reach them should be an alias or so 
> > (repo...@wireshark.org).
> > We should have a wiki page where the team members are listed (similar to 
> > node.js [2]).
> >
> > [3] gives a nice overview of CoC and is a good starting point to read. [4] 
> > is a scientific paper discussing some aspects
> > of different CoC.
> >
> > So, what's your opinion? Any concerns? Any suggestions?
> >
> > Cheers
> > Uli
> >
> > [1] https://www.contributor-covenant.org/version/2/0/code_of_conduct.html
> > [2] https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md
> > [3] https://opensource.guide/code-of-conduct/
> > [4] https://www.win.tue.nl/~aserebre/SANER2017.pdf
> >
> >
> > ___
> > 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
>
>
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> 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

Re: [Wireshark-dev] Bzip2 support

[ronnie sahlberg]

On Thu, Jun 27, 2019 at 7:17 AM Guy Harris  wrote:
>
> On Jun 26, 2019, at 2:03 PM, Jaap Keuter  wrote:
>
> > On 26 Jun 2019, at 19:41, Guy Harris  wrote:
> >
> >> It could probably be done (note that for decompressing capture files that 
> >> would require the ability to do random access I/O,
> >
> > It (http://sourceware.org/bzip2/manual/manual.html#limits) now says: 
> > "Further ahead, it would be nice to be able to do random access into files. 
> > This will require some careful design of compressed file formats."
>
> gzip format wasn't carefully designed for that, either, but it can be - and 
> has been - made to work.  It requires storing dictionary state.

Yepp. BGZIP and its library you can link with does this. I even built
a fuse filesystem to transparently "unzip" these kind of files.

What BGZIP does is that it will restart a new dictionary every ~64k
bytes and also stores an index in a separate file.
The bgzip file itself is compatible with gzip so you can uncompress it
using vanilla gzip
but in order to do random reads/seek in the file you need the index file.

It works, quite well.
The problem I found is that when you restart with a new dictionary
every ~64kb there is not much for the compression engine to work with
so compression ratio is usually (in my cases) quite poor compared to
normal gzip.
___
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] Something that would be useful in Wireshark when dealing with dropped packets

[ronnie sahlberg]

That is a really good idea, but instead of you having to manually
search for where the next pdu starts, it would be possible to teach
wireshark to do this automatically.

We already track the PDU boundaries for SMB as well as a bunch other
protocols so we know where a pdu starts/stops, most of the time.

Except in your situation where we have lost so many packets that we no
longer have any knowledge of pdu boundaries.
In that situation the only thing that can bring wireshark back on
track is to find a frame where the start of the SMB pdu is at the
start of the tcp segment.

We could do a lot better here especially for SMB since we can fairly
strong heusirsitics :
i.e. we can verify that the 4-byte length looks sane, we can verify
that the 'S' 'M' 'B' 0xff/0xfe/0xfd signature is there, we can check
that the command opcode is sane
and even check that the sessionid matches sessions from before the gap
in packets.


Hypothetically we could add a mechanism where a protocol could
register a callback to the tcp dissector and say
"if you have lost track of the pdu boundaries, and the attempt to call
the dissector at tcp segment offet 0 was also rejected then
call this special 'serach the whole segment to find a new PDU start' callback."

That should make it possible to automatically find those headers and
also dissect them.




On Mon, Dec 31, 2018 at 12:58 PM Richard Sharpe
 wrote:
>
> Hi folks,
>
> I recently had to perform some surgery on a packet capture that had
> dropped packets.
>
> I was capturing a GbE link that was operating at capacity and a few
> packets were dropped in the area I was interested in.
>
> I was chasing the reason that the current Mac OS X smbfs would
> disconnect from the server on some occasions.
>
> I was interested in the SMB headers and had no interest in the data
> carried in SMB writes or reads, and fortunately, none of the dropped
> packets in the area I was interested in covered SMB headers.
>
> Using wireedit, mergecap and Wireshark's ability to export packets
> from a point in the capture I was able to put together a new capture
> that showed me all the SMB info, by:
>
> 1. Exporting a singe frame where the NetBIOS/SMB header was in the
> middle of a TCP segment,
> 2. Remove the portion from before the NetBIOS header and adjust the
> sequence number (that is, essentially split the segment into two),
> 3. Merge the adjusted packet with the packets from after its position
> in the capture,
> 4. Make up the missing few packets/segments by saving the packet from
> before the missing segment, duplicating the data and adjusting the
> sequence numbers.
>
> This worked quite well and I was able to determine that the Mac OS X
> smbfs was sometimes not sending an SMB request and thus causing
> crediting issues.
>
> That lead me to think of the following changes that would be useful:
>
> 1. It would be useful to have a right-mouse-button menu item that
> allows you to split a frame into two TCP segments at the point where
> the mouse is pointing.
>
> This would possibly allow Wireshark to correctly dissect the data
> starting at that point, especially if you save the capture from the
> new frame forward.
>
> 2. It would also be useful if you could tell Wireshark: Please insert
> a TCP segment with random data to cover the missing segments that it
> so conveniently warns you about.
>
> Perhaps these could be handled by adding some sort of pcap-ng
> annotation to the frames specifying additional actions.
>
> Anyway, can anyone think of other ways to achieve what I want and
> other ideas like these?
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> 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

Re: [Wireshark-dev] [pcap-ng-format] Proposal for storing decryption secrets in a pcapng block

[ronnie sahlberg]

What Guy said.
On Fri, Oct 5, 2018 at 4:11 PM Guy Harris  wrote:
>
> On Sep 30, 2018, at 10:47 AM, Peter Wu  wrote:
>
> > Requirements for block placement:
> > - No requirement. Producers are allowed to write the block anywhere.
> >  Disadvantages for consumers: requires a two-pass scan to collect
> >  secrets before they are used.
> > - Place secrets before the packet blocks that require them. Consumers
> >  can read and decrypt in one pass. Disadvantage: producers cannot
> >  always guarantee availability of secrets while writing the capture.
> > - Place a single secret block before the first packet block. Consumers
> >  can read and decrypt in one pass. Disadvantage: requires producers to
> >  post-process (rewrite) the capture file to insert secrets.
>
> The third of those appears to be a special case of the second of those.  I 
> don't see any need to require the secrets to be before the *first* packet 
> block if the first packet block doesn't require the secret; presumably 
> "before the packet blocks that require them" just means "*somewhere* before 
> the packet blocks that require them", which is *allowed* to be "before all 
> packet blocks in the file" but not *required* to be "before all packet blocks 
> in the file".
>
> If the secret isn't available by the time the first packet requiring the 
> secret for decryption is ready to be written to the capture, *somebody* will 
> have to do some form of two-pass processing.
>
> The first option says the consumer must do so; that's inconvenient for a 
> consumer doing one-pass processing (tcpdump, TShark without the -2 option), 
> and isn't even really good for at least some consumers doing two-pass 
> processing (Wireshark, TShark with the -2 option), because dissection is done 
> on the first pass.
>
> The second and third option require either the producer, or some 
> post-processor, to write a new version of the file putting the secrets before 
> the packets that require them.  The producer isn't necessarily responsible 
> for doing so; one might have tcpdump, or dumpcap (or some program using 
> dumpcap, such as TShark or Wireshark) write out a capture with no secrets, 
> and then have another program (a utility, or Wireshark after having read in 
> the file and then given the secret in question) write out a new file with the 
> secrets early enough in the file ("before all the packet blocks" is probably 
> the simplest implementation).
>
> A producer that *does* happen to have the secret available before seeing any 
> packets that require the secret *could* write it directly.
> ___
> 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

Re: [Wireshark-dev] compilation problem

[ronnie sahlberg]

Add "-I.."  to your compiler flags.

On Tue, Sep 12, 2017 at 7:12 PM, Sadik Sikder  wrote:
> Hello all
> i am trying to compile a file like packet-ssl-utils.c. the compilation
> command is below
>
> ssikder@ssikder:~/Desktop/wireshark_source_code/epan/dissectors$  gcc -o foo
> packet-ssl-utils.c `libgcrypt-config --cflags --libs`
>
> In returns it gives --
> ssikder@ssikder:~/Desktop/wireshark_source_code/epan/dissectors$
> packet-ssl-utils.h:29:18: fatal error: epan/packet.h: No such file or
> directory compilation terminated.
>
> Since the epan/packet.h file is available in the certain folder, although it
> could not find. it gives error.
>
> my question is regarding this scenerio...
>
> is one such specific file compilation valid ?
> is there any false command in my compilation ?
>
>
> Thanks in advance...
>
>
>
>
> Kind Regards,
>
> Samsuddin Sikder
>
>
> ___
> 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

Re: [Wireshark-dev] Wireshark may get ISN wrong

[ronnie sahlberg]

You can just disable relative sequence numbers in the preferences for tcp.


On Mon, Nov 17, 2014 at 9:38 AM, Matt matta...@gmail.com wrote:
 Hi,

 I use wireshark to examinate some traces generated by a network
 simulator (ns3 www.nsnam.org) which set the ISN to 0 (no randomization
 yet).
 As wireshark assumes base_seq == 0 to be an unitialized value, it
 triggers some error as wireshark tries to set again and again the base
 seq. Here is the output of a single 3WHS (custom printf), in peculiar
 in the 4th line, which is the ACK of the 3WHS, wiresharks sets
 base_seq =seq-1, ie 0-1 and it wraps the seq number (ugly).

 Setting base seq to : 0
 Setting base seq to : 0
 Setting rev base seq to : 0
 Setting base seq to : 4294967295
 Setting rev base seq to : 0
 Setting rev base seq to : 0
 Setting base seq to : 0
 Setting base seq to : 0
 Setting rev base seq to : 0
 Setting base seq to : 0
 Setting rev base seq to : 0
 Setting base seq to : 1

 I understand it seems a corner case but I don't believe have an ISN
 equal to 0 is forbidden by the RFC ?!
 I was wondering if I could add some boolean such as base_seq_set in
 mptcp_info_t to prevent such a behavior.

 Regards
 Matt
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Conflicts: field in commit messages

[ronnie sahlberg]

My 5 cent :   I think they should be removed.



On Mon, Oct 6, 2014 at 12:03 PM, Bálint Réczey bal...@balintreczey.hu wrote:
 Hi All,

 I usually leave the Conflicts: ... in the commit message after
 resolving conflicts to document that the merge was not automatic.
 Should I continue doings so you prefer removing this from the commit message?
 Guy raised the issue in https://code.wireshark.org/review/#/c/4438 ,
 but I think the question deserves more attention than being just a
 valid code-review comment.

 Cheers,
 Balint
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Qt License Change

[ronnie sahlberg]

I think the biggest gotcha with LGPLv3 is that it is no longer
compatible with GPLv2 only code.
Wireshark does not have any GPLv2only code right? If not, we should be ok.

On Wed, Aug 20, 2014 at 9:31 AM, Evan Huus eapa...@gmail.com wrote:
 http://blog.qt.digia.com/blog/2014/08/20/adding-lgpl-v3-to-qt/

 I don't *think* this affects us, but I haven't thought about it too hard.
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] How can Wireshark improve

[ronnie sahlberg]

On Sat, Apr 19, 2014 at 12:48 PM, Guy Harris g...@alum.mit.edu wrote:

 On Apr 19, 2014, at 12:24 PM, Richard Sharpe realrichardsha...@gmail.com 
 wrote:

 One think I would like to be able to do is Show me all the SMB2
 requests where the smb2.flags.is_response == true  smb2.nt_status !=
 NT_STATUS_SUCCESS

 Presumably you mean show me all the SMB2 transactions (requests and matching 
 responses) where the response returned an error.

 There's now a mechanism to, when saving filtered packets, save related 
 packets.  I think this was introduced to allow the earlier fragments/segments 
 of a reassembled packet to be saved, along with the final packet that matched 
 the filter, but in at least some cases somebody might want to save the 
 requests corresponding to replies that match the filter.

 So perhaps there should be a way to have a display filter show related 
 packets in addition to packets that match the packet-matching expression.

+100

Way back I added special code to the nfs dissector so that certain
filter fields would match both the request and the response. A kludge.
But it would be really nice to have a way to flag control that a match
will also match all related packets. And have it work for all
request/response protocols.


 However, there are multiple flavors of related, and sometimes you might 
 want the corresponding requests but *not* other fragments/segments, and other 
 times you might want the other fragments/segments but *not* the corresponding 
 requests, and sometimes you might want both.

Yes.  I think in most cases you want to split packet relations up into
two buckets :
packets are related because they form a request/reply (and or cancel) pair
and
packets are related for some other reason.

We could fix this by changing all request/response fields to a new
FT_REQUEST_REPONSE type.



 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Heuristic check of T.125 dissector

[ronnie sahlberg]

Wireshark has lots of reverse engineered protocols. So that should not stop you.

For example, the whole CIFS/SMB family of protocols used to be reverse
engineered, eventhough now in later times the documentation to those
protocols are now available so errors in the decoding can be fixed.


If the dissector is useful to others, then if it is based on reverse
engineering instead of official documentation,   include it.
An incomplete, reverse engineered, dissector is better than no dissector at all.


ronnie sahlberg


On Tue, Feb 25, 2014 at 8:51 AM, Thomas Wiens th.wi...@gmx.de wrote:

 Without knowing the protocol, I'd say there's almost always room for
 improvement.  Open a bug with a sample capture and see if someone can
 figure out how to strengthen the check.

 Ok, thanks. I will open a bug request then.

 ps. you mentioned your dissector is hosted on sourceforge; would you
 consider submitting it to Wireshark?

 The dissector is of a proprietary protocol which is completely reverse
 engineered. There is no official documentation available.
 The protocol is used in programmable logic controlles by Siemens, I
 think the most common vendor in Europe for those controllers.

 I don't know if there are other reverse engineered protocols in
 wireshark, but for myself I would like when the delivered plugins with
 wireshark refer to official documents or rfcs, and not guessed as my
 dissector.
 Is there a official wireshark point of view?

 The website is:
 http://sourceforge.net/projects/s7commwireshark/

 There are some sample captures available.

 --
 Regards
 Thomas Wiens



 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Add a capability to disable/enable a dissector table ?

[ronnie sahlberg]

sgtm

On Fri, Feb 21, 2014 at 10:37 AM, Bill Meier wme...@newsguy.com wrote:
 It seems to me that it would be nice to be able to disable/enable specific
 dissector and heuristic tables.

 For example, this would be useful when investigating tcp level issues
 for which tcp payload dissection is not interesting.

 All the different protocols which run over tcp wouldn't need to be disabled
 to just show the payloads as 'data (and not show things like malformed
 because some dissector mistakenly tries to dissect data).


 Thoughts ? Am i missing something ?

 (This might be a nice little project fpr me to learn QT ...).


 Bill

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Last few license header questions

[ronnie sahlberg]

On Wed, Feb 5, 2014 at 12:54 PM, Evan Huus eapa...@gmail.com wrote:
 The buildbot is down to reporting only 13 files with license header
 problems. Let's get them cleaned up and finally have that step pass :)

 ---

 'diameter/dictionary.dtd'
 'wimaxasncp/dictionary.dtd'

 These two DTD files both appear to be extracted from C code at some
 point in the past. We already have an 'ignore' rule set up for the
 whole dtds/ directory, so I'm happy ignoring these as well unless
 there is some way we should be embedding license information in them?

 'epan/dissectors/pidl/mapi/request.cnf.c'
 'epan/dissectors/pidl/mapi/response.cnf.c'

 These two appear to be Ronnie's. They're not entirely C code so I'm
 not sure if embedding a license header is possible. Ronnie, I assume
 we're safe to add an exception for these as well?

Thank you for doing this work.
Yes, please add an exception.
Or, since the files do contain some code fragments, you can add a GPL header.



 'epan/reedsolomon.h'
 'epan/reedsolomon.c'

 These two simply say May be used under the terms of the GNU public
 license which presumably means GPLv1. I have not been able to find
 specific information on compatibility, but it appears that the GPLv1
 does not have an or later clause. This means we need to
 remove/replace/relicense it. I found another reed-solomon C library
 (http://sourceforge.net/projects/rscode/) but it's only available
 under the GPLv3+ which we also can't use. *sigh*. Anyone have any
 ideas?

 'epan/dtd_grammar.h'
 'epan/dfilter/grammar.h'

 These two are generated by lemon, so we can just add an ignore rule for them.

 'doc/make-authors-short.pl'
 'docbook/custom_layer_pdf.xsl'

 This two appear to have been written by Ulf Lamping. The latter is
 XML, not C, so (as with the DTD files above) I'm not sure what that
 means for its status.

 'doc/make-authors-format.pl'
 'doc/perlnoutf.pl'

 These two appear to have been written by Graeme Hewson.

 'autogen.sh'

 The very first version was written by Gilbert Ramirez according to
 git, but it's undergone so many changes since then I'm not sure how we
 should attribute it...

 ---

 So it looks like the only potentially problematic one is going to be
 the reedsolomon code. The rest involve either tracking down the
 original author, or agreeing (eg for autogen.sh) that we should just
 add a GPLv2+ header and be done with it.

 Thoughts?

 Evan
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] snow3g dissector in violation of GPLv2+

[ronnie sahlberg]

On Wed, Jan 15, 2014 at 3:10 PM, Joerg Mayer jma...@loplof.de wrote:
 commit b01a99c385bc80566cff9134f93b5d4680dd5a58
 Author: Martin Mathieson martin.r.mathie...@googlemail.com
 Date:   Tue Jan 14 11:09:47 2014 +

 Provide hook for calling EEA1 implementation (Snow3G).  Implementation 
 not supplied due to licensing conditions.  TODO: EIA1.

 svn path=/trunk/; revision=54782

 This violates the GPLv2 requirement of not linking against code that is
 neither GPLv2 compatible nor a system library.
 This is not what open source is about. As long as we'd have any implementation
 that's GPLv2+ compatible with an identical API it would be fine to use another
 implementation, but code linking against a lib that doesn't exist is not 
 acceptable.

That matches my understanding too.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Thoughts on disabling an old dissector

[ronnie sahlberg]

I think we should keep the dissector  but either rename it to *_legacy
or something like someone suggested or control it via a preference.

We have similar situations for other protocols already that can be
used to highlught some of the options :
In iSCSI we already have a preference (that defaults to the
current/RFC version) but where we can still switch back to obsolete
pre-rfc versions of the protocol.

in Kerberos5 we automatically support both a special pre-rfc1510
version of the protocol that is used by packetcable?  as well as the
rfc version of the protocol.
In that case there is no preference setting since it is trivial to
detect/handle the subtle differences at runtime.
(I think one field that is optional in pre-rfc1510 became a mandatory
field in rfc1510 and beyond.)




On Wed, Dec 18, 2013 at 10:33 AM, Evan Huus eapa...@gmail.com wrote:
 This was originally filed as bug 9569. The situation is sufficiently
 unusual that I really don't know what the best solution is, so I
 figured I'd ask for general comments from the list. The company who
 created and used the TPNCP protocol (and submitted the packet-tpncp.c
 dissector) wants to reuse that name for a new, different protocol and
 are asking us to disable the old dissector to avoid conflicts. The bug
 has more detail.

 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9569

 Thoughts?
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Idea for faster dissection on second pas

[ronnie sahlberg]

That would be a good additions, but I always tried to do something like :
as soon as the heuristic dissector found a match then it would
explicitely register itself as the dissector for the conversation.
Perhaps we can make something like that automatic?

Similarly to the current discussion some dissectors (hello smb) has
some really huge value_strings for the response value.
Since a search across a linear valuestring is linear it would be nice
if it could also bubble frequent entries towards the head if the
array.



On Thu, Oct 10, 2013 at 4:51 PM, Evan Huus eapa...@gmail.com wrote:
 On Thu, Oct 10, 2013 at 6:22 PM, Evan Huus eapa...@gmail.com wrote:
 It might be simpler and almost as efficient to have
 recently-successful heuristic dissectors bubble nearer to the top of
 the list so they are tried sooner. Port/conversation lookups are
 hash-tables for the most part and likely won't be made noticeably
 faster by caching.

 The attached trivial patch more-or-less implements the above idea. It
 isn't easy to bubble dissectors to the very head of the list because
 we don't have a modifiable pointer, but it was surprisingly easy to
 bubble them to *second* in the list, which should still be a
 substantial improvement if there are many expensive heuristics.

 I don't have any long heuristic captures that I can easily time, but
 I've run a few short ones and at least it doesn't seem to break
 anything.

 Let me know if it helps,
 Evan

 On Thu, Oct 10, 2013 at 4:22 PM, Anders Broman a.bro...@bredband.net wrote:
 Hi,
 If we in the UDP/TCP/(SCTP?) dissectors saved next dissector on the first
 pas in say per packet data we could avoid
 repeated calls to heuristic dissectors and port/conversation lookups making
 the second pas faster.
 Does any one see any pitfalls with this idea?

 I can think of two ways of implementing it:
 - A new entry in pinfo previous protocol or something like that.
 or
 - make dissector_try_uint(), dissector_try_heuristic(),
 try_conversation_dissector() return the protocol
 or NULL;

 The second is perhaps cleaner but requires more changes or we could make new
 functions
 dissector_try_heuristic_ret_proto() etc or something like that.

 Comments?

 Regards
 Anders


 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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 PIDL generated dissectors

[ronnie sahlberg]

The tool.
I think that wireshark has been used a de-facto fork for PIDL the tool
since many many years. But a fork that is occasionally synced back
with upstream.
That is the only way we can make sure that we will always be able to
even compile the IDL in wireshark to a working dissector.

On Mon, Oct 7, 2013 at 1:57 PM, Guy Harris g...@alum.mit.edu wrote:

 On Oct 3, 2013, at 8:04 PM, ronnie sahlberg ronniesahlb...@gmail.com wrote:

 There is very little overlap between samba needs and wireshark needs for 
 PIDL.
 It is probably better to continue running two separate forks of PIDL,
 one for samba and one for wireshark.

 Switching to samba PIDL seems to be a lot of work for miniscule gain.
 And who will do the work?

 Are you referring to forking PIDL, the language, or to forking PIDL, the tool 
 that translates PIDL-the-language descriptions into code for 
 {Samba,Wireshark,...}?

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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 PIDL generated dissectors

[ronnie sahlberg]

Cool.
And we contact you when samba-PIDL no longer can generate compileable
wireshark dissectors?


On Thu, Oct 3, 2013 at 7:13 PM, Andrew Bartlett abart...@samba.org wrote:
 On Tue, 2013-10-01 at 10:55 -0400, mman...@netscape.net wrote:
 The check_col function in the Wireshark source has been deprecated for 
 awhile, but never officially removed.  I've been modifying the source 
 (removing calls) so that it can be officially removed.  The last big hurdle 
 was the DCE/RPC generated dissector files.  I've had a difficult time trying 
 to regenerate the dissectors with the necessary modified source, so I just 
 manually updated dissectors to mimic what the source should generate.
 Attached is a patch that contains the modifications to PIDL source
 that generates the dissector files (and not the dissector files
 themselves).  I couldn't tell from the Wireshark wiki [1] if this was
 maintained by samba or Wireshark, so now both will now have a copy,
 with the source already committed to Wireshark repository [3].

 Patch is also available in Wireshark bugzilla [3].

 Michael Mann

 [1] http://wiki.wireshark.org/Pidl
 [2] http://anonsvn.wireshark.org/viewvc?view=revisionrevision=52313
 [3] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8804

 PIDL is maintained by the Samba team, the canonical repository is in our
 master branch of git://git.samba.org/samba.git

 From the Samba perspective:

 I would warn that patching the generated code only passes the pain of
 fixing this properly down to the next person who needs to work here.

 As improvements are made to the IDL files or the parser, the generated
 files need to be re-generated, and then someone has the un-enviable
 choice of throwing away manual changes, or reverse engineering these
 back into the compiler.

 Even if you think you have modified them correctly to match your PIDL
 changes, please persevere to get the files re-generated using PIDL.
 Only then will we really know the generator generates the code
 correctly, and only then will the solution be long-term maintainable.

 Thanks,

 Andrew Bartlett

 --
 Andrew Bartlett
 http://samba.org/~abartlet/
 Authentication Developer, Samba Team   http://samba.org
 Samba Developer, Catalyst IT   http://catalyst.net.nz


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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 PIDL generated dissectors

[ronnie sahlberg]

These are probably better maintained by wireshark than samba.
I may be able to try taking a look at your patch during the weekend.
Please ping me if I forget.

On Tue, Oct 1, 2013 at 7:55 AM,  mman...@netscape.net wrote:
 The check_col function in the Wireshark source has been deprecated for
 awhile, but never officially removed.  I've been modifying the source
 (removing calls) so that it can be officially removed.  The last big hurdle
 was the DCE/RPC generated dissector files.  I've had a difficult time trying
 to regenerate the dissectors with the necessary modified source, so I just
 manually updated dissectors to mimic what the source should generate.
 Attached is a patch that contains the modifications to PIDL source that
 generates the dissector files (and not the dissector files themselves).  I
 couldn't tell from the Wireshark wiki [1] if this was maintained by samba or
 Wireshark, so now both will now have a copy, with the source already
 committed to Wireshark repository [3].

 Patch is also available in Wireshark bugzilla [3].

 Michael Mann

 [1] http://wiki.wireshark.org/Pidl
 [2] http://anonsvn.wireshark.org/viewvc?view=revisionrevision=52313
 [3] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8804




 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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 PIDL generated dissectors

[ronnie sahlberg]

What do you propose?

There is very little overlap between samba needs and wireshark needs for PIDL.
It is probably better to continue running two separate forks of PIDL,
one for samba and one for wireshark.

Switching to samba PIDL seems to be a lot of work for miniscule gain.
And who will do the work?


On Thu, Oct 3, 2013 at 7:58 PM, Andrew Bartlett abart...@samba.org wrote:
 On Thu, 2013-10-03 at 19:44 -0700, ronnie sahlberg wrote:
 Cool.
 And we contact you when samba-PIDL no longer can generate compileable
 wireshark dissectors?

 Contacting the Samba Team would seem to be the correct approach.

 Given Matthieu was working on generated dissectors only last week, it
 does not seem totally unreasonable.

 What do you propose?

 Andrew Bartlett

 --
 Andrew Bartlett
 http://samba.org/~abartlet/
 Authentication Developer, Samba Team   http://samba.org
 Samba Developer, Catalyst IT   http://catalyst.net.nz


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] OID list usage

[ronnie sahlberg]

Which oid list are you referring to exactly ?


On Thu, Sep 12, 2013 at 12:18 AM, Bart J. Smit b...@smits.co.uk wrote:
 Hi,

 I am working on a FOSS project (http://github.com/bartsmit/bedtime) and I
 would like to incorporate information from your OID list. Currently the
 relevant script (re)populates a database table by parsing the list on demand
 by the end user.

 I had a look for subscription/publication information in ask.wireshark.org,
 but did not find an answer to these questions:

 - Do you have a policy for data transfers from the OID list?
 - Do you have a preferred minimum interval between downloads?
 - Is there a mechanism that could alert list subscribers when there are
 updates?
 - Are incremental updates available?

 Thanks for your great work and for any answers you can give me,

 Bart...

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Seaching in the data pane would be useful ...

[ronnie sahlberg]

On Fri, Aug 9, 2013 at 8:52 AM, Christopher Maynard
christopher.mayn...@gtech.com wrote:
 Richard Sharpe realrichardsharpe@... writes:

 I can across a capture yesterday where there were DNS queries for a
 KDC in a Windows AD environment. The query returned 230 KDCs!

 Searching for a particular one was hard.

 It would be nice to have a right click menu item in either the details
 pane or the data pane where you can search for a particular string (or
 chars or hex equivalent) and have the string highlighted in the data
 pane and the detail pane sync'd to that.


 Isn't there a filter you can use, such as: dns.qry.name == The KDC name?

 Alternatively, it seems you're referring to the Edit - Find Packet (Ctrl+F)
 functionality, combined with Edit - Find Next (Ctrl+N) and/or Edit - Find
 Previous (Ctrl+B).  Is there something that feature doesn't provide that
 you're looking for?


I think he means something like this:

If you take the dns.cap sample capture from the wiki and then
CTRL-F * Display filter  dns.resp.ns == ns-ext.sth1.isc.org
It will bring you to frame #29 but it will not auto-select the field
in that packet. It just brings you to the packet in question.

On the other hand, IF you CTRL-F * string/packet-bytes sth1  it will
bring you to packet #29 and also highlight the first field there for
these bytes.
(Now DNS is special so you can not string/packet-bytes search for the
full name since due to dns compression will mangle the strings. You
can search for individual components though. But it is still
unreliable, it will find something and highlight something but maybe
not what you want)

However, what does work and what probably is what Richard can use is:
CTRL-F String/Packet-Details  ns-ext.sth1.isc.orgi.e. the full dns
name. This will find the right packet and will also automatically
select/highlight the right row in the display tree.



Display filters are harder since they might not map to a single hf
field when they match  (a==1  b==2which of a or b should we
highlight?)
but we could special case CTRL-F Display-Filter so that IF the the
display filter consists of a single field then try to find and
highlight that specific field when jumping to the packet that matched.

thus CTRL-F Displayfilter  ip.addr==1.2.3.4 would find the first
ip.addr field and highlight it
but  CTDL-F DisplayFilter ip.addr==1.2.3.4  tcp   would not work and
would just jump to the matching packet, just like today

That should be possible and would improve usability. At least for the
case when searching for a single field which is likely the majority of
light-use searches.

ronnie sahlberg
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Seaching in the data pane would be useful ...

[ronnie sahlberg]

On Fri, Aug 9, 2013 at 9:02 AM, Richard Sharpe
realrichardsha...@gmail.com wrote:
 On Fri, Aug 9, 2013 at 8:52 AM, Christopher Maynard
 christopher.mayn...@gtech.com wrote:
 Richard Sharpe realrichardsharpe@... writes:

 I can across a capture yesterday where there were DNS queries for a
 KDC in a Windows AD environment. The query returned 230 KDCs!

 Searching for a particular one was hard.

 It would be nice to have a right click menu item in either the details
 pane or the data pane where you can search for a particular string (or
 chars or hex equivalent) and have the string highlighted in the data
 pane and the detail pane sync'd to that.


 Isn't there a filter you can use, such as: dns.qry.name == The KDC name?

 Alternatively, it seems you're referring to the Edit - Find Packet (Ctrl+F)
 functionality, combined with Edit - Find Next (Ctrl+N) and/or Edit - Find
 Previous (Ctrl+B).  Is there something that feature doesn't provide that
 you're looking for?

 Sure, I can do the search, and I did, but the actual info I am
 interested in, like the priority, etc, is buried among 230 entries and
 I have to patiently scroll until I find it.

 That is hard to do.

You can use
CTRL-F String/PacketDetails text-to-match
That should work for your use-casebut it would probably be even
better if the normal Displayfilter search would do it too, where
possible.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] using C++, was: Notes from Sharkfest '13

[ronnie sahlberg]

Technically you could use smart pointers, or other types too.

But beware the performance impact,  and do get numbers before changing.

Ethereal/Wireshark does an enormous amount of small allocations and frees.

One of my primary goals when we added the first emem allocators were
performance.
Make it very cheap, near zero cost for both allocations and free,
especially for a lot of small shortlived allocations.

This is important especially if you have really big captures  where
the original malloc()/free()  real allocators became impossibly slow.


On Thu, Jun 20, 2013 at 11:08 PM, Dirk Jagdmann d...@cubic.org wrote:
 C++. It snuck in with Qt. Should we allow C++ in the rest of the code or
 at least use C++ compilation everywhere?

 A tough call. If we go C++ we should have a plan to use the STL classes with 
 our
 concept of memory (allocator scope). I've started a short discussion last 
 year,
 but somebody found out, that using STL objects on the heap with the C++
 allocators doesn't have the same semantics (and really doesn't work) with our
 packet or file lifetime scopes.

 However a second approach with C++ objects managed by smart pointers and those
 smart pointers being aware of the packet/file/application lifetime might work.
 We should research this, write guidelines how to use C++ objects in Wireshark
 and then make a decision if we want to allow C++ features everywhere.

 Another advantage would be that we can use real C++ exceptions.

 --
 --- Dirk Jagdmann
  http://cubic.org/~doj
 - http://llg.cubic.org
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Jurassic packets

[ronnie sahlberg]

Can you try loading an NFS trace on it?

I recall that in the old days,  sniffers usually could not decode the
NFS replies since they did not keep enough state around between
request/response to identify what kind of response packet it was.



On Thu, Jun 13, 2013 at 11:09 AM, Gerald Combs ger...@wireshark.org wrote:
 For Monday's Sharkfest keynote I wanted to show everyone what things
 looked like back in the early days of the project. After doing
 unspeakable things to a Red Hat 6.2 VM I managed to get a copy of
 Ethereal 0.2.0 up and running. Screenshot attached.

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Extract bytes from a tvbuff_t

[ronnie sahlberg]

fwrite(extracted, sizeof(extracted), 1, file)

extracted is a pointer so sizeof(extracted) is the size of pointers on
your platform.   Often 4 on 32-bit platforms and 8 on 64-bit.

You need something like this :
fwrite(extracted, tvb_get_length(tvb, 0), 1, file)

On Sat, May 25, 2013 at 1:42 PM, Rion Carter r...@rubion.com wrote:
 Hi,

 I'm trying to extract raw bytes from a tvbuff_t and am not having much luck.
 As a simple test I have code which tries to extract the bytes and write it
 to a file. When I compile and run I get an output file with only 4 bytes in
 it when I know there is more (extracting certificates).

 Here is what I've got. Any help is appreciated:

 guint8* extracted = (guint8*)ep_tvb_memdup(tvb, 0, -1);
 fwrite(extracted, size of extracted), 1, file);

 It's been awhile since I used c file io, and I'm pretty new to Wireshark
 dev. I may be missing obvious or going about this in the wrong fashion.

 Rion

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]

[ronnie sahlberg]

I dont think composite tvbs actually work.   or at least they didnt
work when we originally wrote the reassembly code.



On Thu, Apr 18, 2013 at 12:14 PM, Evan Huus eapa...@gmail.com wrote:
 This is a tangential issue that has always confused me.

 Why do we malloc+memcpy data for reassembly when we already have
 'virtual' composite TVBs?

 Wouldn't it be more efficient (in time and memory) to create a
 composite TVB for each reassembly and then build the reassembled
 packet in it? You would never have to copy or allocate any actual
 packet data...

 Or am I misunderstanding how composite TVBs actually work?

 Thanks,
 Evan

 P.S. Clearly some protocols where the payload is XORed or hashed
 wouldn't be able to do this, but most protocols doing reassembly just
 carry the raw payload bytes.
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] SRP dissector for wireshark

[ronnie sahlberg]

SCSI dissection in wireshark is a bit different than most other protocols.
There is no real protocol handler, instead you call out directly to
the dissect CDB, dissect data-in dissect data-out  dissect
sense etc.

In order to do this you also need to collect some additional metadata
and track things like conversations etc.
But this should be fairly straightforward.

SCSI dissector is called today from at least :
iSCSI, FCP, NDMP, USB,  and a handful of other layers too.


Have a look at the iSCSI dissector. I think that should be a good
example on how / what to track and how to invoke the SCSI dissection.





On Tue, Mar 5, 2013 at 1:09 AM, Carmel Bregman carm...@mellanox.com wrote:
 Hello all,



 I’m working on a dissector for SRP (SCSI RDMA Protocol).

 I have the SRP header parsing complete and I have a short question:



 How do I parse CDB as SCSI cmd? I assume that this is done in FC but I
 couldn’t figure out how it’s done – can you help me here?



 Thanks,

 Carmel Bregman


 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Patches to properly handle extended responses for NTCreateX

[ronnie sahlberg]

hf_smb_volume_guid   shouldnt this be a FT_GUID ?

Can you try making it FT_GUID and see if it works?


On Thu, May 31, 2012 at 1:57 PM, Richard Sharpe
realrichardsha...@gmail.com wrote:
 Hi,

 Attached is a patch to handle extended responses for NTCreateX
 requests for CIFS.

 I have tested this patch with captures I have and it seems to decode
 the additional information correctly.

 Could someone with commit privileges either push it or let me know
 what changes are needed please?

 --
 Regards,
 Richard Sharpe
 (何以解憂？唯有杜康。--曹操)

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Conversation tracking

[ronnie sahlberg]

Tobias,
below

On Sat, May 12, 2012 at 2:25 AM, Tobias Weiss twe...@ra.rockwell.com wrote:


 Thanks for your quick replies (Jeff  Lars).

 I guess I have to explain my real problem in more detail. I want to implement 
 a dissector for a quite old protocol that has 2 stages. The packets of the 
 first stage have a fixed length (4 byte) and the packets of the second stage 
 can have an arbitrary length but with a fixed header (8 bytes).

Ok so the sequence for the protocol would then be something like

TCP session setup
1 or more stage 1 PDUs
1 or more stage 2 PDUs
TCP session closure

and this applies to both directions of the TCP session?


 Unfortunately the content of a 4 byte frame can be the beginning of the 8 
 byte header. So I have to figure out where stage 1 ends and stage 2 starts. 
 But as the payload of one TCP frame can contain the last stage 1 frame(s) and 
 the first stage 2 frame, this is not straightforward. So my idea was to do 
 this just once with the first packet and save the state in the conversation 
 data and subsequently reuse that information. Because detecting the end of 
 stage 1 is pretty easy if you know where you are in the stream.

 And now I'm not sure if something like this could happen within the same 
 conversation:

 TCP connect - stage 1 frames - stage 2 frames - TCP disconnect - TCP 
 connect - stage 1 frames - stage 2 frames

 In this case I cannot just save the packet number where stage 1 ends if my 
 dissector gets the same conversation for multiple connects/disconnects.


In this case this would be logged as two separate conversations, so
that should not be a problem.
But packet number alone might not be sufficient anyway since as you
say the transition from stage 1 to stage 2 is never guaranteed to be
on a tcp segment boundary.


What I would suggest here is that you create a conversation,
then attach a special state structure to this conversation that
contains something like

struct stage_transition {
 intframe ;   // packet number where stage 1 -  2 transition occured
 intoffset;// offset into the data of that frame where the
transition occured
}

Attach two of these structures to the conversation, one for each
direction of the tcp flow.
Create some mechanism to be able to determine direction to know
which one to pick.
Perhaps high portnumber - low portnumber == forward  and low port
number - high portnumber == reverse ?

When initially reading the capture file (pinfo-fd.flags.visited == 0)
  you build and track these structures.
When you re-filter or re-process the packet (pinfo-fd.flags.visited
!= 0) you just read from these structures.





 Tobi



 RUOFF, LARS (LARS) lars.ru...@alcatel-lucent.com
 Sent by: wireshark-dev-boun...@wireshark.org

 05/11/2012 11:33 AM

 Please respond to
 Developer support list for Wireshark wireshark-dev@wireshark.org

 To
 Developer support list for Wireshark wireshark-dev@wireshark.org
 cc
 Subject
 Re: [Wireshark-dev] Conversation tracking





 Hi Tobi,
 I don't understand your concern. (but that may be due to my weird 
 understanding of English)
 If those packets are part of the same stream, i.e. they are being identified 
 as belonging to the same conversation (by whatever means, eg adress-port 
 mapping etc.), then the whole point of conversation tracking is that you will 
 get the *same* conversation object for all those packets.
 So you can store things in there and retrieve them when dissecting another 
 packet of that same conversation.

 Regards,
 Lars



 

 From: wireshark-dev-boun...@wireshark.org 
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Tobias Weiss
 Sent: vendredi 11 mai 2012 16:30
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] Conversation tracking



 Right now I'm puzzled: I wanted to use conversation tracking in order to save 
 information about the state of the communication across packet dissection.

 The dissector is called completely out of order (which is reasonable) but I 
 get always the same conversation, even when dissecting an older packet than 
 the last one. So saving the state of the communication is completely 
 pointless if the same conversation is used for dissecting random packets. 
 Here is an example just in case you don't understand my possibly weird 
 English ;-)

 I have a stream of 10 packets and something interesting was send in packet 
 number 3. Now I want to save this information in the conversations data in 
 order to reuse it when dissecting future packets. But the dissector is called 
 randomly (which is ok) but always with the same conversation (which is 
 absolutely not ok in this case).

 I simply cannot rely on the saved information. So how am I supposed to use 
 conversation tracking in a sane way (as far as I can see I can't _track_ 
 anything)???

 Tobi




 Tobias Weiss twe...@ra.rockwell.com
 Sent by: wireshark-dev-boun...@wireshark.org

 05/10/2012 06:03 PM
 Please 

Re: [Wireshark-dev] Regarding wireshark design

[ronnie sahlberg]

There are READMEs in the doc subdirectory.

README.developer is a good starting point.


Otherwise, most of the code is pretty straightforward so it shouldnt
be too hard to just read it.



On Thu, May 10, 2012 at 8:52 PM, Singh, Anand anand.si...@landisgyr.com wrote:
 Hi,

   Can anyone give me thorough reference on how exactly
 wireshark work while displaying packet on linux. Where do I start to get
 insights of design of wireshark. What is the code flow, from which file I
 start browsing the code. I will greatly help me understand wirshark existing
 code  enhance the code for my usage.



 Regards

 Anand





 P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

 This e-mail (including any attachments) is confidential and may be legally
 privileged. If you are not an intended recipient or an authorized
 representative of an intended recipient, you are prohibited from using,
 copying or distributing the information in this e-mail or its attachments.
 If you have received this e-mail in error, please notify the sender
 immediately by return e-mail and delete all copies of this message and any
 attachments. Thank you.


 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Regarding wireshark design

[ronnie sahlberg]

Perhaps the answer can be found in the documentation ?


On Thu, May 10, 2012 at 9:28 PM, Singh, Anand anand.si...@landisgyr.com wrote:
 Hi,
                Can you please let me know how does it talk with raw packets. 
 Is it using existing TCP stack or is it directly communication with lower 
 level drivers like phy/Mac layer.  Where do I find that code section where 
 we accessing raw buffers.

 Regards
 Anand

 -Original Message-
 From: wireshark-dev-boun...@wireshark.org 
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of ronnie sahlberg
 Sent: Thursday, May 10, 2012 4:29 PM
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] Regarding wireshark design

 There are READMEs in the doc subdirectory.

 README.developer is a good starting point.


 Otherwise, most of the code is pretty straightforward so it shouldnt be too 
 hard to just read it.



 On Thu, May 10, 2012 at 8:52 PM, Singh, Anand anand.si...@landisgyr.com 
 wrote:
 Hi,

   Can anyone give me thorough reference on how exactly
 wireshark work while displaying packet on linux. Where do I start to
 get insights of design of wireshark. What is the code flow, from which
 file I start browsing the code. I will greatly help me understand
 wirshark existing code  enhance the code for my usage.



 Regards

 Anand





 P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

 This e-mail (including any attachments) is confidential and may be
 legally privileged. If you are not an intended recipient or an
 authorized representative of an intended recipient, you are prohibited
 from using, copying or distributing the information in this e-mail or its 
 attachments.
 If you have received this e-mail in error, please notify the sender
 immediately by return e-mail and delete all copies of this message and
 any attachments. Thank you.


 __
 _ Sent via:    Wireshark-dev mailing list
 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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 compile options

[ronnie sahlberg]

CFLAGS=-pg ./configure

should do the trick


On Sun, Mar 4, 2012 at 3:14 PM, James dsouza james.dso...@gmail.com wrote:
 Hello,

     I am new to Wireshark and want to use Wireshark with gprof which
 requires it to be compiled with -pg option. Where should this option be
 added so gcc
 would build it with this option? I am not sure in which Make file and where
 I should add this option. Thanks in advance.





 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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 SCSI dissectors for new transports

[ronnie sahlberg]

Hi Stefan.



Wireshark supports a lot more than just SCSI over iSCSI

It dissects SCSI over USB, FCOE, raw-FC, FCIP, iFCP (I never got
access to traces for mFCP :-( )   and also over NDMP.
I never got access to HyperSCSI traces either, so that is missing too.

Since I never got HyperSCSI or mFCP (very short-lived attempt from HBA
vendors)  those two are the only ones today I think where we miss
decode.
virt-scsi from QEMU sounds interesting!





SCSI has a very well defined API in wireshark  so assind a new
transport should be trivial.

I have done so several times.


First you need a DLT value from the tcpdump folks to wrap your packets in.
Once you have that  it should be semi-trivial to hook the
SCSI-dissector into your transport/DLT


Depending on what the framing looks like, you need at least a wrapper
around the SCSI payload that can contain
an I_T identifier, then  a LUN field, and then scoped per LUN you need
a task-tag or similar.
Wireshark would need I_T to be able to track initiators and targets
separately and form a conversation between an arbitrary pair.
A LUN identifier to track different luns on the same I_T separately.
Finally it also needs a task-tag so that on a specific ILT nexus it
will be able to match a SCSI CDB with DATA-IN/OUT blobs and a SCSI
response/sense

to make it map well  you might need to wrap thing inside a

struct scsi_wrapper {
initiator identifier
target identifier
lun
task-tag
opcode (cdb, datain, dataout, response/sense)

scsi *
}



if your transport also supports multiple datain/out blobs for a single
task,  in order to reassemble the data we would also need a
offset/length for each datain/out blob.


regards
ronnie sahlberg


On Tue, Feb 28, 2012 at 8:59 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
 Wireshark today supports SCSI dissectors for iSCSI.

 In the QEMU system emulator we have an emulated SCSI target which
 handles devices for SCSI Parallel Interface (SPI), USB Mass Storage
 Device, and now supports the new virtio-scsi transport (for efficient
 virtual machine SCSI I/O).

 Cong and I would like to add pcap support to the emulated SCSI target
 in QEMU, making it easy to use Wireshark for SCSI debugging and
 analysis.  I'm looking for advice on getting started because we are
 not familiar with Wireshark/dissector internals.

 I believe the SCSI dissector does not support raw CDB dissection - it
 requires a SCSI transport dissector (currently iSCSI).  A few options
 come to mind:

 1. Change the SCSI dissector to support top-level dissecting of raw
 SCSI CDBs without transport information (initiator, target, and other
 metadata).

 2. Add virtio-scsi and perhaps SPI SCSI transport dissectors.

 3. A simpler approach I'm missing? :)

 Suggestions appreciated.

 Stefan
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Ronnie's Wireshark presentation / attaching files to the Presentations page on the wiki

[ronnie sahlberg]

I am ok with putting the presentation on the wiki.


On Thu, Jan 19, 2012 at 1:37 AM, Jeff Morriss jeff.morriss...@gmail.com wrote:
 Hi Ronnie, Gerald, et al,

 This page on the wiki:

 http://wiki.wireshark.org/Presentations

 Points, among other things, to a presentation Ronnie made back in 2008
 showing some of the cool things you can do with Wireshark. Unfortunately the
 link has since gone bad.

 I happen to have a copy of the presentation locally (I had referred to it in
 some internal training I did).  Would it be acceptable to attach it to the
 wiki?

 The presentation says at the bottom:

 Storage Developer Conference 2008
 © 2008 Insert Copyright Information Here. All Rights Reserved.


 Or would it be a bad precedent to start attaching potentially large files
 there?

 Regards,
 -Jeff
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Is it still ok to create hidden items ?

[ronnie sahlberg]

Make each of them an expansion
and show the generic .node field inside the expansion with a help
blurb of matches either sender or receiver
?

Wireshark has a 5 digit number of filterable fields already   so for
users to find that a certain field exists and can be used is tricky.
Unless your protocol is IP, TCP or UDP,   unless the user can see
the filter variable in the decode pane it pretty much does not exist.


regards
ronnie sahlberg


On Mon, Oct 31, 2011 at 9:10 PM, Roland Knall rkn...@gmail.com wrote:
 Hi

 Ok, always ready to learn something new, but answer me this:

  You have two fields displayed, in my case:

 Sender: 0x0001
 Receiver: 0x0002

 How do you add a generated field, which will match either one of these
 entries, so that you can ask:

 opensafety.msg.node == 0x0002

 and only receive messages where either the Sender or the Receiver
 field has the value 0x0002 ?

 Using generated fields, just clobbers up the display in such a case,
 because you would have to have 2 entries for [Node] which confuses the
 user. Or am I overlooking some special usage of generated fields here?

 One definite negative side-effect of using hidden fields is of course,
 that you can not use the Apply as .. or Prepare as .. entries, and
 that the user has to know about them. But that was already mentioned
 earlier.

 regards,
 Roland


 On Mon, Oct 31, 2011 at 11:03 AM, Anders Broman
 anders.bro...@ericsson.com wrote:
 Hi,
 I'd say using a generated field is more elegant :-)
 /Anders

 -Original Message-
 From: wireshark-dev-boun...@wireshark.org 
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Roland Knall
 Sent: den 31 oktober 2011 10:51
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] Is it still ok to create hidden items ?

 Hi

 As I just came across something regarding this issue, there is a counter 
 argument to the whole if it is not there, the user may not find it idea. 
 Looking at the way the IP dissector is used, hidden fields have their 
 merits. ip.addr is a more generic way of avoiding ( ip.src == x || ip.dest 
 == x ). I plan to use it in the same way in the openSAFETY dissector, where 
 I have the fields opensafety.msg.sender and opensafety.msg.receiver, and I 
 am currently implementing a opensafety.msg.node matching either one.

 The most elegant solution for such a case is still using hidden fields.

 regards,
 Roland

 On Thu, Oct 27, 2011 at 4:04 PM, Teto matta...@gmail.com wrote:
 Thanks for both of your ideas. What bothers me with Michaels'idea is
 that I wonder how many wireshark users know of or use contains and
 matches compared to eq or == keywords. From that point of view,
 Jeff's idea looks as a good idea.

 On Thu, Oct 27, 2011 at 3:34 PM, Jeff Morriss jeff.morriss...@gmail.com 
 wrote:

 Teto wrote:

 Hi,

 Just had a question about what's the best practice. I have a packet
 with a field contianing several keywords. I intend to split those
 keywords so that one can filter display based upon a keyword.
 My problem is am compelled to display each keyword separately (one
 itemp per kewyord and group them in a subtree) or could I display
 all of them in one item in the main tree (my preference) and then
 create several hidden fields (one per keyword). I wonder if that
 last

 Why not combine the two?  Put one item (or maybe even just a text 
 entry--from proto_tree_add_text()) with all the keywords (possibly added 
 with proto_tree_append_text()) and then create a subtree below that with 
 each keyword individually?

 This is how we get, for example, nice summary lines for the TCP protocol 
 (including port numbers, etc.) while keeping the port numbers themselves 
 as separate filterable items in the TCP subtree.
 __
 _ Sent via:    Wireshark-dev mailing list
 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 Archives:    http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe

Re: [Wireshark-dev] Is it still ok to create hidden items ?

[ronnie sahlberg]

Hi,

I think one of the reasons why one should avoid hidden items is that
if they dont
show up in the dissect pane, users might not be aware that they exist at all.
And then they will not be able to use them.

Wireshark supports so very many different filter fields that it is not
practical to use a list of all filterable items.


So see it as if they show up in the dissect pane, this is how you
tell the users 'these fields exist, you can filter on them'
If they dont show up in the disset pane, no one will know about them
or use them, i.e. they dont exist :-)


regards
ronnie sahlberg


On Thu, Oct 27, 2011 at 8:54 PM, Teto matta...@gmail.com wrote:
 Hi,

 Just had a question about what's the best practice. I have a packet
 with a field contianing several keywords. I intend to split those
 keywords so that one can filter display based upon a keyword.
 My problem is am compelled to display each keyword separately (one
 itemp per kewyord and group them in a subtree) or could I display all
 of them in one item in the main tree (my preference) and then create
 several hidden fields (one per keyword). I wonder if that last
 solution is good since I read in proto.h :
 /* HIDING PROTOCOL FIELDS IS DEPRECATED, IT'S CONSIDERED TO BE BAD GUI
 DESIGN! */

 What would you advise me ?

 Matt
 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] [PATCH] Re: Freeing memory of se_alloc'ated object

[ronnie sahlberg]

I think registering a destructor for an allocated is very useful, but
it would be very uncommon.
Most allocations never need a destructur, so it shouldnt be made
mandatory in the allocation functions.

So instead of creating a new API for allocations with a destructor I
would suggest adding a new _add_destructor call instead.
That way you can add destructors to existing objects after they are
allocated, post allocation time.


something like :

object = se_alloc(...);
se_set_emem_destructor(object,  void (*your_callback)(void
*object), void *private_data);


Then this can just add the destructor to a linked list of
struct se_destructors {
struct se_destructors *next;
void *object;
void *private_data;
void (*callback)(void *object, void *private_data);
};


I threw a private_data pointer in there too.
Once you have callbacks you almost always enbd up wanting to pass data
like this to it too.


Then when before releasing all the se_ memory,   just have it walk the
list of callbacks and invoke them in turn first.

regards
ronnie sahlberg



On Tue, May 3, 2011 at 8:31 AM, Max dmitr...@gmail.com wrote:
 2011/5/2 Guy Harris g...@alum.mit.edu:

 A separate cleanup routine, called when the capture is closed, *before* 
 the se_allocated memory is freed, might be useful...

 Do you mean separate as global? I.e. with setup code like

  register_se_cleanup_callback(my_module_cb);

 ?

 --
  Max
 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Portable Linux Wireshark with custom dissectors - possible ?

[ronnie sahlberg]

You should be able to either build a statically linked version of wireshark,
or copy the normally built dynamically linked version as well as the
various shared libraries wireshark comes with and just wrap it inside
a small shell-script that sets the LD_LIBRARY_PATH so that ld.so can
find the wireshark libraries.

But you cant use plugins like that so your custom dissectors have to
be built in as normal dissectors.

regards
ronnie sahlberg



On Wed, Mar 9, 2011 at 12:20 PM, Dan White y...@comcast.net wrote:
 I have been tasked to come up with a Wireshark configuration that can sit on
 a USB thumb drive and get plugged into a Linux system and run.

 The building would, obviously, take place on a separate platform.  All I
 would need on the thumb is the actual executables.

 I looked through the official documentation, and it wants me to install
 Wireshark onto the system I want to run it on.

 There is a Portable Wireshark for the Microsoft operating systems.  Can the
 same thing happen for Linux ?
 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Query

[ronnie sahlberg]

rfc 791 and 792


On Fri, Dec 31, 2010 at 4:52 PM, prathiba meenu prathibame...@gmail.com wrote:
 Hi,
 Could you please tell what are all the things needed to calculate checkum of
 ICMP and ICMPv6?

 --
 Thanks  Regards,
 Prathiba.H

 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] UDP desegmentation - how to?

[ronnie sahlberg]

Fragmented UDP packets are reassembled in the IP layer.
See the preferences for IP and enable the reassembly.

This should reassemble fragmented Kerberos over UDP packets.


regards
ronnie sahlberg

On Wed, Dec 22, 2010 at 7:58 PM, Kaul myk...@gmail.com wrote:
 Can I use something like tcp_dissect_pdus() for UDP packets? Specifically,
 Kerberos over UDP - I think we can get the PDU length from the packet and
 get a complete PDU.

 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Thinking of some changes to packet-scsi.c ...

[ronnie sahlberg]

Yeah

The scsi dissector does need some tlc
to clean up and to harmonize the dissection according to the latest
versions of the standard.

For handling flags,
you may want to look at some examples such as

...
   static const int *aca_fields[] = {
hf_scsi_inq_aerc,  /* obsolete in spc3 and forward */
hf_scsi_inq_trmtsk,/* obsolete in spc2 and forward */
hf_scsi_inq_normaca,
hf_scsi_inq_hisup,
hf_scsi_inq_rdf,
NULL
};
...
/* aca flags */
proto_tree_add_bitmask(tree, tvb_v, offset_v,
hf_scsi_inq_acaflags, ett_scsi_inq_acaflags, aca_fields, FALSE);
offset_v+=1

which can simplify creating/dissecting bitfields.



this would be a reasonable summer of code project for a student,
go through all of spc/sbc/ssc/smc/mmc and update wireshark accordingly.
at the same time, and to have something to generate data to test with,
they could at the same time
enhance dbench.samba.org and its iscsi backend to be able to generate such i/o.



regards
ronnie sahlberg

On Sun, Dec 5, 2010 at 9:45 AM, Richard Sharpe
realrichardsha...@gmail.com wrote:
 On Sat, Dec 4, 2010 at 6:29 AM, Chris Maynard chris.mayn...@gtech.com wrote:
 Richard Sharpe realrichardsha...@... writes:

 If there are any suggestions for other changes, let me know.

 Hi Richard.  It looks like there are other bit-oriented fields besides
 hf_scsi_control that could benefit from this as well: hf_scsi_inquiry_flags,
 hf_scsi_modesel_flags, ...

 There also seem to be a lot of proto_tree_add_text() calls (I count 186 of
 them).  I haven't looked at them all, but I suspect most would be better 
 added
 using proto_tree_add_item() so those fields could be filterable as well.

 I saw that you posted a patch on Thursday.  Could you open up a bug report 
 and
 submit the patch(es) there instead?  I think it will make it easier to track 
 and
 the patches won't get lost.  Thanks.


 I created bug https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5466
 for this since it has nothing to do with iSCSI...

 The patch I first posted needs reworking so I will not attach it yet.

 I will attach patches as I get make changes.

 --
 Regards,
 Richard Sharpe
 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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-commits] rev 34269: /trunk/tools/ /trunk/tools/: make-sminmpec.pl

[ronnie sahlberg]

Yeah, there is a whole bunch of references to it.
Since it was static in the generated file and declared extern in the header
file this makes it not compile on some systems


On Tue, Sep 28, 2010 at 9:20 PM, Bill Meier wme...@newsguy.com wrote:

 sahlb...@wireshark.org wrote:
  http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=34269
 
  User: sahlberg
  Date: 2010/09/27 08:31 PM
 
  Log:
   The array sminmpec_values should not be declated static since it is
   referenced from several dissectors
 
  Directory: /trunk/tools/
ChangesPathAction
+1 -1  make-sminmpec.plModified
 

 I thought I fixed all the references (to use sminmpec_values_ext instead
  of sminmpec_values).

 Did I miss some ?? :)

 Bill
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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 decode as..??

[ronnie sahlberg]

change it to

   if (!initialized) {
   data_handle = find_dissector(data);
   helen_handle = create_dissector_handle(dissect_helen,
proto_helen);
   for (i = 0; i  25; i++) {

   dissector_add(udp.port, ports[i], helen_handle);
   }
   }

You also shouldnt hardcode the size of the array in the for loop like
that,   use something like  sizeof[ports] / sizeof(ports[0])
instead.



On Tue, Mar 23, 2010 at 9:30 AM, Brian Oleksa
olek...@darkcornersoftware.com wrote:
 Olivier

 Yes...looks like I do. Any thoughts on how I can fix this..??

 Thanks,
 Brian

 void proto_reg_handoff_helen(void) {
    static gboolean initialized = FALSE;

    int i;

    for (i = 0; i  25; i++) {

        if (!initialized) {
            data_handle = find_dissector(data);
            helen_handle = create_dissector_handle(dissect_helen,
 proto_helen);
            dissector_add(udp.port, ports[i], helen_handle);
        }
    }
    initialized = TRUE;
 }



 wsgd wrote:
 Perhaps you call create_dissector_handle for each port ?

 Olivier

 Brian Oleksa a écrit :

 Guy

 Actuallythis is what I am doing:

 dissector_add(udp.port, ports[i], helen_handle);

 Where ports has a list of port numbers in it.

 static int ports[25] = {5136, 5000, 5220, 42250, 5, 5221, 5222,
 49901, 49501, 49510, 42251, 42250, 5226, 47001, 5227, 7636, 59201,
     59202, 59203, 59204, 59205, 59206, 59207, 59209, 59210};

 Is this a problem..??  How do I get around this..??

 Thanks,
 Brian



 Guy Harris wrote:


 On Mar 22, 2010, at 1:04 PM, Brian Oleksa wrote:




 When I right click on a packet and select decode asunder the
 transport tab... there is like 14 of my protocols in the selection box.
 (so I see the word HELEN 14 times in a row)

 Does anybody know why this is..??



 You're only calling dissector_add() or dissector_add_handle() once, right? 
  You're not calling it, for example, every time a preference is set?
 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] INTERLINK dissector plugin added

[ronnie sahlberg]

On Tue, Mar 16, 2010 at 8:13 PM, Joerg Mayer jma...@loplof.de wrote:
 On Tue, Mar 16, 2010 at 08:16:44AM +0100, Dr. Uwe Girlich wrote:
 I just added (with revision 32202) a new dissector plugin: INTERLINK (yes, I
 know, a too general name but that's what it is called by BMW). This protocol 
 is
 used in BMW cars (real and simulated) for all kinds of gadget communication
 (for example to and from the combination display or the iDrive). I assume 
 only
 a few engineers at BMW will ever use this, so I added the dissector as a 
 plugin.

 I prepared a table for sub-dissectors for particular type/version 
 combinations
 but did not add any. Hopefully some BMW engineers will fill this part later 
 on.

 And of course: Where do I get the sniffer hw so I can actually do the
 sniffing :-)



At the same place where you give a guy 50$ so he can add 20k km to the
odo for your tax rebate enjoyment.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] preliminary code submission

[ronnie sahlberg]

Any particular reason this is not licensed under GPL?


I am not sure that this licence is compatible with GPLv2 which may
hinder its inclusion into wireshark.
It is not known to the gpl folks and thus not explicitely listed as
gpl compatible.
http://www.gnu.org/licenses/license-list.html


There are also some sections I think might be problematic and which
would require a more detailed analysis.


Possible to re-licence it under GPLv2 or maybe one of the other
licences that have been verified to be compatible and
has the blessing of the gpl folks?



regards
ronnie sahlberg




On Thu, Feb 11, 2010 at 9:33 AM, Brian Oleksa
olek...@darkcornersoftware.com wrote:
 Chris

 Thanks for all the great advice. Attached is the updated code based on some
 of your suggestions.

 Per your suggestions:
 I have registered the port that my dissector is using with IANA.
 I have added my companies license info at the top of my dissector.
 I put the handoff and register routines at the bottom.
 I have defined a value_string constant for the gpsStatus.

 You mentioned that the helen_sub_item assignment is not needed.
 I have not removed it yet. All this displays is that it is a helen packet as
 it does start with 0xbead.
 I guess your thoughts are that I do not need to display 0xbead..?? I can
 easily move this ...but I just wanted to get your thoughts on why you think
 I should not display this.

 I also tried to replace FT_ABSOLUTE_TIME with FT_UNIT64 and replace the
 proto_tree_add_time_format with the add_unit_format that you provided but I
 ended up with the following error.
 conversion from guint64 to guint32 possible loss of data.
 But I cannot seem to locate the different value declarations.

 Codes:
 You mention that there is a number of Helen Packet Codes that I am not
 supporting in my dissector yet. These extra codes are for add ons or
 what we call plugins to the Minotaur SA application.
 For now... We just want to support the core Minotaur SA extensions which are
 (GPS, Flow and Host). Once this code is submitted and a part of the core
 wireshark distribution we will submit patches to add these other codes.
 Right now... these extra codes are subject to change.

 I did however add the range_string helen_code[]...but I am not 100% sure how
 to rip out my switch/case to replace it with your suggestion.

 I have alot of your suggestions in my code...but I either commented it out
 or am not using it.

 You also mentioned the following (see CHRIS MAYNARD WROTE:)...but I was
 having a bit of a problem following exactly what you are saying here.

 Thanks for the help.,
 Brian

 CHRIS MAYNARD WROTE:

 So you're missing a lot of the codes, but even the codes that you currently
 do support seem to be lacking.  Take for example the GPS Extension:  First
 off, you don't populate the Fields Available field at all.  It should be
 added to the helen tree then sub-treed with the bits comprising it (i.e.,
 have its own ett so it can expand independently of other trees).  It's nice
 to have a 1-line summary of all bitfields so you don't necessarily have to
 expand the tree to decipher which bits are set.  The Boolean bits themselves
 are usually populated from msb to lsb, although the fields indicated must be
 populated according to the spec.  Unfortunately, the Helen spec is
 ambiguous in this regard.  Here's an example of what the tree could look
 like as I describe (I assume the fields are added according to lsb to msb
 based on your implementation, but I indicate which fields are present from
 msb to lsb, as this yields a left-to-right expansion of the tree, which is
 what you normally see.):

 Not expanded, you would see:

 + Fields Available: 0x61 (speed, bearing, status)

 And when expanded, you would see:

 - Fields Available: 0x61 (speed, bearing, status)
  0... = Number of Satellites: Not Present
  .1.. = Speed: Present
  ..1. = Bearing: Present
  ...0 = Altitude: Not Present
  0... = Latitude: Not Present
  .0.. = Longitude: Not Present
  ..0. = Time: Not Present
  ...1 = Status: Present








 Maynard, Chris wrote:

 Hi Brian,

 I found some (the?) documentation on Helen here:
 https://www.darkcornersoftware.com/confluence/display/open/Packet+Structure.
  I have no idea if this is the definitive Helen specification or not, but
 based on the documentation, here is some additional feedback:

 Header:
 This 1st assignment of helen_sub_item is not needed:
        helen_sub_item = proto_tree_add_item(helen_tree, hf_helen_magic,
 tvb, offset, 2, FALSE);

 The System Tx Time: is 8 bytes and indicates ms since the Epoch.  Your
 hf_helen_txTime field is declared as an FT_ABSOLUTE_TIME, but that implies
 that you have an 8 byte field whose 1st 4 bytes represent seconds and last 4
 represent nanoseconds, but that isn't the case.  This field is simply an
 FT_INT64 (or FT_UINT64 if you don't care to represent ms before the Epoch).
  The Helen spec is ambiguous as to whether it's signed

Re: [Wireshark-dev] Some random patches I use...

[ronnie sahlberg]

metze
great patches, as usual.


applied, thanks.



On Sat, Jan 30, 2010 at 1:10 AM, Stefan (metze) Metzmacher
me...@samba.org wrote:
 Hi,

 I'm using a few patches in my private git branch of wireshark.
 It would be nice if they could go upstream.

 metze

 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] packet-kerberos.c: hand-written or ASN.1?

[ronnie sahlberg]

packet-kerberos.c is handwritten.

packet-kerberos contains a whoole lot more than just rfc1510
(it even handles a pre rfc version of 1510 with a slightly different
asn, used by packetcable)


The vast majority of the code in apcket-kerberos.c is not really the
actual pdu definitions as of 1510
but things likes vast numbers of microsoft (and other) extensions to
various fields.

value strings   that are not defined in 1510

and of course, the whole decryption code   and microsoft PAC code.


Since the packetstructure in rfc1510 is such a very small part of
packet-kerberos.c  I dont think it is worth it to move it to
machinegenerated code.
(and if doing so, we would have to use a modified asn anyway, to not
break packetcable)



I think it is best if you just enhance the hf fields, one by one, as
you find them too terse.




regards
ronnie sahlberg




On Wed, Jan 27, 2010 at 6:25 PM, Stephen Fisher
st...@stephen-fisher.com wrote:
 I've started working with Kerberos at work, and I was analyzing packets
 with Wireshark when I noticed that a number of the packet detail field
 names are pretty terse.  Is packet-kerberos.c written by hand, generated
 with ASN.1 or both?  I'm guessing both.  Is there a move to change it to
 entirely one way or the other?  I was wanting to expand some field names
 for things such as cusec.  I realize that hf_krb_cusec has a description
 for the status line of micro second component of client time but I
 still think that cusec could be expanded in the details pane.  Maybe
 something like Client microseconds or Microseconds under a Client
 tree title.


 Steve

 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] packet-kerberos.c: hand-written or ASN.1?

[ronnie sahlberg]

ouch,   it is partially machinegenerated!

when did that happen ? :-)


On Wed, Jan 27, 2010 at 7:30 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
 packet-kerberos.c is handwritten.

 packet-kerberos contains a whoole lot more than just rfc1510
 (it even handles a pre rfc version of 1510 with a slightly different
 asn, used by packetcable)


 The vast majority of the code in apcket-kerberos.c is not really the
 actual pdu definitions as of 1510
 but things likes vast numbers of microsoft (and other) extensions to
 various fields.

 value strings   that are not defined in 1510

 and of course, the whole decryption code   and microsoft PAC code.


 Since the packetstructure in rfc1510 is such a very small part of
 packet-kerberos.c  I dont think it is worth it to move it to
 machinegenerated code.
 (and if doing so, we would have to use a modified asn anyway, to not
 break packetcable)



 I think it is best if you just enhance the hf fields, one by one, as
 you find them too terse.




 regards
 ronnie sahlberg




 On Wed, Jan 27, 2010 at 6:25 PM, Stephen Fisher
 st...@stephen-fisher.com wrote:
 I've started working with Kerberos at work, and I was analyzing packets
 with Wireshark when I noticed that a number of the packet detail field
 names are pretty terse.  Is packet-kerberos.c written by hand, generated
 with ASN.1 or both?  I'm guessing both.  Is there a move to change it to
 entirely one way or the other?  I was wanting to expand some field names
 for things such as cusec.  I realize that hf_krb_cusec has a description
 for the status line of micro second component of client time but I
 still think that cusec could be expanded in the details pane.  Maybe
 something like Client microseconds or Microseconds under a Client
 tree title.


 Steve

 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] [PATCH] LIBNDR_FLAG_NOALIGN support in wireshark and PIDL

[ronnie sahlberg]

Can you send me your new di-no_align patch and Ill check it in right now.

I started applying it yesterday but modified it (to ensure we always
initialize di-no_align in get_next_di(), but will reverse these local
changes
so they wont collide with your patch.)


This patch can be applied right now, in anticipation of adding the pidl
patches later.






On Wed, Jan 20, 2010 at 1:58 AM, Julien Kerihuel
j.kerih...@openchange.orgwrote:

  On Tue, 2010-01-19 at 13:44 +1300, Jelmer Vernooij wrote:

 On Tue, 2010-01-19 at 11:13 +1100, ronnie sahlberg wrote:
  The wireshark patch for this is fine.
 
  I can apply these two patches to wireshark if you want me to.

  Is the pidl patch ok with the upstream pidl maintainer (jelmer?) ?
 It's mostly ok, but it should be looking at the alignment information in
 the level table rather than looking at IDL properties directly.

  Looks OK for me, I'll rework the patch to fetch information there rather
 than within properties directly. It may however require some time (few
 days). I'm currently trying to implement other things within wireshark/pidl
 for string support.

 FYI, similarly to the nstring/astring patch, I have added a wireshark/pidl
 implementation for ascstr3 [size(16bit)][string] based on the same logic -
 in this case we look whether we have .*LIBNDR_FLAG_STR_SIZE2.* flag or not
 associated to the IDL element - type being obviously string.

 Finally I have found a couple more functions where I forgot to propagate
 the di-no_align fix in packet-dcerpc.c (including the dissect_nastring
 one).

 It tends to be a little difficult to maintain all the patches properly and
 I'm not very good at svn diff and diff editing ... Anyway will do the
 necessary changes and come with an updated version here.

 Cheers,
 Julien.


   On Tue, Jan 19, 2010 at 1:25 AM, Julien Kerihuel
  j.kerih...@openchange.org wrote:
   Hi Lists,
  
   Prior submitting the wireshark's part of this patch onto the wireshark
   bugzilla, I thought it might be worthwhile to have feedback from
   developers first.
  
   MAPI content is non-NDR compatible. It can be dissected using the
   existing NDR layer functions in epan/dissectors/packet-dcerpc-ndr.c but
   it requires offsets to be left intact prior effective dissection, which
   means there shouldn't be any offset adjustment when LIBNDR_FLAG_NOALIGN
   flag is used in PIDL.
  
   The following patches implement such behavior:
   1. It adds a no_align gboolean variable to dcerpc_info structure
   (default set to FALSE)
   2. when pidl generates the code and LIBNDR_FLAG_NOALIGN flag is used, it
   sets the no_align gboolean to TRUE which turns offste adjustment off in
   wireshark.
  
   I couldn't come up with a nicer solution so far, but these tiny patches
   truly improves the overall development effort for the MAPI dissector. It
   basically prevents from writing hand-written code for most of the MAPI
   calls. This also means this may help keeping the conformance files - in
   particular request.cnf.c and response.cnf.c - readable and prevent them
   from exponentially growing up.
  
   Another advantage is that it becomes conceivable to generate code for
   structures or others some non-dceprc dissectors using pidl. You would
   only have to describe the structures, specify LIBNDR_FLAG_NOALIGN flag
   and you would have automatic dissection code generated which you can
   refer to (or cut and paste).
  
   Cheers,
   Julien.
  
   ---
  
   Julien Kerihuel
   j.kerih...@openchange.org
   OpenChange Project Manager
  
   GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79
  
  
  




 Julien Kerihuel
 j.kerih...@openchange.org
 OpenChange Project Manager

 GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79



___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] [PATCH] LIBNDR_FLAG_NOALIGN support in wireshark and PIDL

[ronnie sahlberg]

I have checked in the wireshark patch in anticipation for the pidl patches.


One nice thing that this allows is that we may soon be able to use
pidl to describe a whole lot of additional, normal,
protocols, just like the samba project already does.


I would like to experiment creating such a dissector and document the
process later for the wireshark project for use.


One nice thing is that PIDL is an actively supported and maintained
tool to do exactly that. A single language to describe several types
of protocols.




On Wed, Jan 20, 2010 at 10:33 AM, Julien Kerihuel
j.kerih...@openchange.org wrote:
 On Wed, 2010-01-20 at 08:50 +1100, ronnie sahlberg wrote:
 Can you send me your new di-no_align patch and Ill check it in right
 now.

 I started applying it yesterday but modified it (to ensure we always
 initialize di-no_align in get_next_di(), but will reverse these local
 changes
 so they wont collide with your patch.)


 This patch can be applied right now, in anticipation of adding the
 pidl patches later.

 Ronnie,

 Thanks I was looking for a correct place to initialize the variable.
 The new version of the patch is attached to this e-mail.

 Cheers,
 Julien.





 On Wed, Jan 20, 2010 at 1:58 AM, Julien Kerihuel
 j.kerih...@openchange.org wrote:
         On Tue, 2010-01-19 at 13:44 +1300, Jelmer Vernooij wrote:
          On Tue, 2010-01-19 at 11:13 +1100, ronnie sahlberg wrote:
           The wireshark patch for this is fine.
          
           I can apply these two patches to wireshark if you want me to.
         
           Is the pidl patch ok with the upstream pidl maintainer (jelmer?) 
 ?
          It's mostly ok, but it should be looking at the alignment 
 information in
          the level table rather than looking at IDL properties directly.
         Looks OK for me, I'll rework the patch to fetch information
         there rather than within properties directly. It may however
         require some time (few days). I'm currently trying to
         implement other things within wireshark/pidl for string
         support.

         FYI, similarly to the nstring/astring patch, I have added a
         wireshark/pidl implementation for ascstr3
         [size(16bit)][string] based on the same logic - in this case
         we look whether we have .*LIBNDR_FLAG_STR_SIZE2.* flag or not
         associated to the IDL element - type being obviously string.

         Finally I have found a couple more functions where I forgot to
         propagate the di-no_align fix in packet-dcerpc.c (including
         the dissect_nastring one).

         It tends to be a little difficult to maintain all the patches
         properly and I'm not very good at svn diff and diff
         editing ... Anyway will do the necessary changes and come with
         an updated version here.

         Cheers,
         Julien.



           On Tue, Jan 19, 2010 at 1:25 AM, Julien Kerihuel
           j.kerih...@openchange.org wrote:
        Hi Lists,
           
        Prior submitting the wireshark's part of this patch onto the 
 wireshark
        bugzilla, I thought it might be worthwhile to have feedback 
 from
        developers first.
           
        MAPI content is non-NDR compatible. It can be dissected using 
 the
        existing NDR layer functions in 
 epan/dissectors/packet-dcerpc-ndr.c but
        it requires offsets to be left intact prior effective 
 dissection, which
        means there shouldn't be any offset adjustment when 
 LIBNDR_FLAG_NOALIGN
        flag is used in PIDL.
           
        The following patches implement such behavior:
        1. It adds a no_align gboolean variable to dcerpc_info 
 structure
        (default set to FALSE)
        2. when pidl generates the code and LIBNDR_FLAG_NOALIGN flag 
 is used, it
        sets the no_align gboolean to TRUE which turns offste 
 adjustment off in
        wireshark.
           
        I couldn't come up with a nicer solution so far, but these 
 tiny patches
        truly improves the overall development effort for the MAPI 
 dissector. It
        basically prevents from writing hand-written code for most of 
 the MAPI
        calls. This also means this may help keeping the conformance 
 files - in
        particular request.cnf.c and response.cnf.c - readable and 
 prevent them
        from exponentially growing up.
           
        Another advantage is that it becomes conceivable to generate 
 code for
        structures or others some non-dceprc dissectors using pidl. 
 You would
        only have to describe the structures, specify 
 LIBNDR_FLAG_NOALIGN flag
        and you would have automatic dissection code generated which 
 you can
        refer to (or cut and paste).
           
        Cheers,
        Julien.
           
        ---
           
        Julien Kerihuel
        j.kerih...@openchange.org

Re: [Wireshark-dev] How about moving from svn to git?

[ronnie sahlberg]

On Mon, Nov 9, 2009 at 10:31 AM, Guy Harris g...@alum.mit.edu wrote:

 On Nov 7, 2009, at 3:08 AM, Joerg Mayer wrote:

 this is just something that went through my mind yesterday while
 working
 on the third patch on the same files and without a chance to commit
 between the patches. If there is one thing that I don't like (although
 I do it sometimes) is to do a commit that does several things at once.
 With git, I could commit each patch (which is done locally) and
 eventually
 push all commits to the central repository while maintaing the
 indivitual
 character of the commits.

 The way I work is that I have multiple working trees for various
 projects, with modified versions of various source files.

 For Wireshark, I do svn update on occasion, resolve the conflicts
 myself, and check the code in when it's done.

 For libpcap and tcpdump, which now use Git, that's not so easy, as I
 don't check in my work until it's done, and then push it.  git
 pull gets upset when I've modified files; it doesn't work the way
 cvs update and svn update work.

 I presume git stash is one of the tools to be used in this case,
 with a git stash save before git pull and a git stash pop
 after.  When I tried that, it appeared to do a local commit of the
 work done so far; if I then do more work and another git commit,
 will both of those commits get pushed individually, or do they get
 pushed as one single commit to the remote repository?  I'd prefer the
 latter, as there's no point in exposing individual checkpoints for
 work I've done in the history on the remote repository.

 (Currently, I work around it by diffing my tree, backing out my
 changes, doing a git pull, and then reapplying my changes.  That's
 the Git tool I *really* want, but I don't have time to become a
 porcelain craftsman)

You shouldnt work in the main branch.
Only use the main branch for pulling and pushing to the main repo.

When you want to work on a patch you should first create temporary
local branch and then do all the changes you want in that branch.
git branch work-patch-abc
git checkout work-patch-abc -f

Once you are happy with the patches you either merge the changes back
into the master branch and push
git checkout master -f
git merge work-patch-abc
git push

or you cherry pick the patches you want
git checkout master -f
git log work-patch-abc   (and pick the hash for the patches you want)
git-cherry-pick hash
git push


git is different from other systems. To really benefit from it you
should use branches, lots of branches.
(Git is different from other systems also in that branches are fast
and easy to work with,   not like some systems where branches are
convoluted, slow and will make your life miserable)
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Help with ASN based dissector

[ronnie sahlberg]

It might be possible to create a ANS.1/BER description that is
compatible with both encodings.


FooBar ::= SEQUENCE OF
{
  kludge KludgeFooBar
}

KludgeFooBar ::= CHOICE
{
  item1 [0] IA5String
  item2 [1] INTEGER
}

I think this might work and should be able to decode both types of encoding.

It is less than optimal from a maintenance perspective since you would
now have a third encoding to maintain. :-(


ronnie s




On Wed, Sep 2, 2009 at 8:46 AM, Alex Lindbergalind...@yahoo.com wrote:
 I am working on an ASN1 based dissector where there where major changes
 between V1 and V2 of the protocol.  As such I must select in the proto.cnf
 file the correct branch of the ASN1 tree to use.  As an example:

 Both v1 and v2:
 FirstFoo ::= SEQUENCE
 {
   version       [0] INTEGER
   dataMessasge  [1] FooBar
 }

 v1:
 FooBar ::= SEQUENCE
 {
   item1 [0] IA5String
   item2 [1] INTEGER
 }

 v2:
 FooBar ::= CHOICE
 {
   item1 [0] IA5String
   item2 [1] INTEGER
 }

 I am using an IF statement based on version to call the dissector of either
 the v1 or v2 construction of FooBar.  I have added the v1 version of FooBar
 to the end of the ASN1 definition so v1 Foobar becomes:

 FooBarV1 ::= SEQUENCE
 {
   item1 [0] IA5String
   item2 [1] INTEGER
 }

 and the dissector is dissector_xxx_FooBarV1.   When the v1 dissector is
 called, wireshark complains that with a DISSECTOR_ASSERT_NOT_REACHED error
 which indicates that the type and value don't match correctly during
 decoding.

 I suppect that I should pass the correct ASN1 definitions to the v1
 dissector, but don't see how that is to be done.  asn2ws created the
 necessary data structures.

 Any help would, as always, be greatly appreciated.

 Alex Lindberg


 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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's ISN handling

[ronnie sahlberg]

It does happen from time to time.

Most commonly when you have a retransmitted packet early in the trace
that has a sequence number before the first packet seen.
In that case those retransmitted packets just get a negative sequence
number (~ -2 billion something).

You get used to it and it is not really much of a big deal.




On Mon, Aug 17, 2009 at 5:45 PM, Selçuk Cevhercevh...@gmail.com wrote:
 Hi,

 I made some tests with Wireshark using some sample PCAP files.

 I noticed that Wireshark stores the sequence number of the first segment
 belonging to a specific connection that it comes across in the PCAP file as
 the ISN (initial sequence number) of that connection.

 I always thought that there might be a possibility that the first segment of
 a TCP stream (with the sequence number of ISN+1) may appear after, for
 example, 2nd segment of a certain TCP connection.

 Was this thought totally wrong that we never come across such a case ? or
 Does Wireshark not handle such a case which may actually occur in practice ?

 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] Parsing array and its size in EcDoRpcExt2

[ronnie sahlberg]

There are a number of places where the length variable comes after the
array.
I think there are even places where there are other variables separating the
length and the array apart in some places.

This is all allowed in DCE/RPC and the reason for this is that length is
just a normal variable.
When used in this way
...
   [length_is(len)] foo_t entries[];
   ...
   int len;

This will actually encode len twice on the wire.
First it will encode the array like this :

uint32_t  length (*)
element 0
element 1
...
element len-1

I.e. the length of the array is encoded together with the array and it
contains the value of lenth as the length of the array.

A short while later you will then also have the variable length itself
being encoded with obviously the same value.


I.e. length is encoded twice, first it is encoded as part of the
(conformance data of the) array itself
and a second time as the variable length itself.
Therefore it does not matter where in the IDL you specify the array and its
length in relation to eachother.


(* this is a simplified example,   the array size length is actually not
encoded at the head of the array but much earlier in the byse-sequence. It
is actually encoded at the head of the encapsulating structure)


regards
ronnie sahlberg



On Tue, Apr 28, 2009 at 10:32 AM, Harsha inet.har...@gmail.com wrote:

 On Mon, Apr 27, 2009 at 3:38 PM, Harsha inet.har...@gmail.com wrote:
  I did a quick read of the relevant part of DCE RPC specs, but in all
  the cases I saw it always had the size and then the array. In those
  cases it is trivial to first extract the size and use the size to
  extract the array contents.
 Here is an example in Wireshark code where the length of the array and
 then the array are extracted-
 void ept_lookup(
 [in] handle_t hEpMapper,
 [in] unsigned long inquiry_type,
 [in, ptr] UUID* object,
 [in, ptr] RPC_IF_ID* Ifid,
 [in] unsigned long vers_option,
 [in, out] ept_lookup_handle_t* entry_handle,
 [in, range(0,500)] unsigned long max_ents,
 [out] unsigned long* num_ents,
 [out, length_is(*num_ents), size_is(max_ents)] ept_entry_t entries[],
 -
 [out] error_status* status );

 Related dissecting code that extracts the length of the array and then
 array is in epm_dissect_ept_map_resp() in packet-dcerpc-epm.c.

 Unfortunately I don't see any other case where the array comes ahead
 of its length.

 Thanks,
 Harsha
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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] one possible way to speed up filtering

[ronnie sahlberg]

Another way to greatly speed up filtering would be to pick up and clomplete
the work to make it possible to use ep_* memory
for all field types when dissecting a packet.


When wireshark dissects a packet it performs a massive amount of
malloc()/free().
This was partially addressed when I added the SLAB_ allocator in slab.h eons
ago.
This did improve performance very significantly at that time, but there are
still speedups to gain, though not as low hanging anymore.

One thing that could make dissection faster is if we can get rid of all
usage of SLAB for the field_info type and make it use cheap and fast
ep_ allocated memory instead.


This would mainly be stuff down in the epan/ftypes directory.
I remember I started preparing some of the functions there to allow a
migration to ep_ allocation but did not do all of them.
One I remember would be problematic was the pcre one.

The first step would be to analyze all codepaths where data is created by
calling into the epan/ftypes helpers and make sure the scope
of useage for these are valid if they are allocated with an ep_ scope.

Second would be to get rid of all the use of SLAB for field_info and just
rely on ep_ allocations.

This would be more problematic though since there are instances when a tree
of field_info is created but the tree is valid and referenced across several
packets/the entire capture. I never had time to analyze this properly but if
the cause is identified, maybe using se_ allocations for the second style of
field_info allocations, which scope to use identified by a parameter to the
functions?





2009/3/22 yami yami...@gmail.com

 Hi Didier,

 Thank you for trying the patch :) and all the good comments given.

 I've attached a new patch to the wiki. Please see my detailed reply below.


 On Fri, Mar 20, 2009 at 6:30 AM, didier dgauthe...@magic.fr wrote:

 Hi,

 Le mercredi 18 mars 2009 à 23:05 +0800, yami a écrit :
  Thanks, I've written a page in Wiki:
http://wiki.wireshark.org/Development/FastFiltering
 Nice work.

 - If compiled without NDEBUG defined I get a failed assert:
 epan/dfilter/wslimmat.c :1680 : fix_variables:  v-assignment == v

 It seems like a 'bug' of gcc optimization. We can simply remove this
 assertion, see explanations below.

 The assertion fails, but the 'real' value of v-assignment and v are equal.
 I came to this conclusion by following experiments (is there any better
 way?):

 experiment 1. without NDEBUG defined, but using '-O0' to compile, not
 assertion failure occurs.
 experiment 2. no change to Makefile, simply add printf(v-assignment, v) to
 fix_pointer(), no assertion failure
 experiment 3. no change to Makefile, add following to fix_variables() after
 the assert line:
   if (v-assignment != v)
   printf(not hold v-assignment=%p, v=%p\n, v-assignment, v);
   else
   printf(hold v-assignment=%p, v=%p\n, v-assignment, v);

 The assertion fails (simply print, no abort), however output is:
  hold v-assignment=0x8070508, v=0x8070508

 which just says the opposite.


 valgrind doesn't complain and it seems to work with NDEBUG but only for
 simple stuff ie udp  dns, something like !(tcp.stream eq 1)
  !(tcp.stream eq 2) doesn't return the right result.
 ie:
 follow TCP stream, filter out this stream, follow TCP this stream, and
 so on.
 Does it work for you?


 This is a bug, I've fixed '!' (TEST_OP_NOT) part at least. I'll test the
 patch more.



 - stupid but Limmat uses the original BSD license which is incompatible
 with the GPL.


 Really? I've thought BSD license is looser than GPL (can you give me more
 details?).
 On the other hand, I find Wireshark code has already contains similar
 licenses (am I right?), for example,
 Menu - Help - About Wireshark - License - Part III has metioned some.


 - On the other hand if expressions are made incrementally via popup
 menus is a full SAT solver need?


 Perhaps you are right, but I'm not sure.

 However using a SAT solver (even if it is a simple one) is the most
 generalized way, which requires no special handling. And it is also a good
 example of how math is applied in real life :)

 Cons are
 1. SAT solvers are complicated. (But we may use a simple algorithm)
 2. Public available SAT solvers are mainly wrote by researchers, which may
 not have time to maintain the software.


 eg:
 Something like
 tcp.stream eq 1 -- H1

 !(tcp.stream eq 1) -- !H1 -- H2

 tcp.stream eq 2 -- H3

 !(tcp.stream eq 1)  !(tcp.stream eq 2) -- H2  !H3

 may be good enough.

 Didier




 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 

Re: [Wireshark-dev] reasebling packets - dissector question

[ronnie sahlberg]

but i noticed that the TCP checksum test fails

That may be an issue. Try disabling TCP checksum validation in the
preferences for TCP.

By default, TCP reassembly will ignore all packets with a checksum failure
or short packets. (i.e. packets captures with a snaplen smaller than the
ethernet mtu)



On Mon, Feb 23, 2009 at 9:57 PM, יוני תובל yoni6...@gmail.com wrote:

 hi , thanks .
 it seems to be working , but only when i raise the flag 
 pinfo-can_desegment=1
   inside the get_len method .
 but i noticed that the TCP checksum test fails in all the reassembled
 packets .
 why is that ?
 actually it also fails when i send the whole message in one buffer ...
 so its probably a different issue . . .


 thanks
 2009/2/23 Guy Harris g...@alum.mit.edu


 On Feb 23, 2009, at 12:59 AM, יוני תובל wrote:

  i tried to return the entire message length . still fails .
  (it only succeeds when the tvb consists of the entire message )
  What about he offest value we pass to the get_len method .

 It's the offset into the tvbuff handed to the get_len routine of the
 first byte of the packet whose length should be returned.

 Presumably the PDUs consist of a 2-byte length field (in network byte
 order?) followed by that number of bytes of data, and, in the get_len
 routine, you fetch the length value from the packet, add 2 to it, and
 return that value.

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
 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 wireshark-dev@wireshark.org
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-commits] rev 25368: /trunk/ /trunk/epan/crypt/: Makefile.common Makefile.nmake /trunk/epan/: addr_resolv.c emem.c /trunk/gtk/: Makefile.common Makefile.nmake /trunk/: Ma

[ronnie sahlberg]

why did you remote wireshark-tap-register.c
from the makefile?
wireshark doesnt build under linux without this file.


On Fri, May 23, 2008 at 3:55 PM,  [EMAIL PROTECTED] wrote:
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=25368

 User: etxrab
 Date: 2008/05/22 10:55 PM

 Log:
  Fix some of the Errors/warnings detected by checkapi.

 Directory: /trunk/epan/crypt/
  ChangesPath   Action
  +1 -1  Makefile.commonModified
  +4 -0  Makefile.nmake Modified

 Directory: /trunk/epan/
  ChangesPath Action
  +1 -1  addr_resolv.cModified
  +1 -1  emem.c   Modified

 Directory: /trunk/gtk/
  ChangesPath   Action
  +1 -2  Makefile.commonModified
  +7 -2  Makefile.nmake Modified

 Directory: /trunk/
  ChangesPath  Action
  +2 -2  Makefile.nmakeModified
  +1 -1  dumpcap.c Modified

 ___
 Wireshark-commits mailing list
 [EMAIL PROTECTED]
 http://www.wireshark.org/mailman/listinfo/wireshark-commits

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] jumping tcp packets

[ronnie sahlberg]

You would only be able to see the packets that you are fast enough to
capture, process and write to disk.
In particular for high speed networks it is an unfortunate
fact-of-life that you wont be able to capture packets and write them
to disk at the same speed as the packets arrive at the nic  and thus
you get missed packets unless you have a high-end disk subsystem.

What is the line speed and throughput you are looking at?


On Thu, Apr 3, 2008 at 7:35 PM, Maria de Fatima Requena
[EMAIL PROTECTED] wrote:
 Hi

  I am implementing a skinny sniffer using winpcap and I am experimenting 
 problems while parsing packets. Some of them are just missed to my 
 application. I am using wireshark to see what is really happening, and I cant 
 understand it

  This is part of my code (callback function called by winpcap):


  void packet_handler(u_char *param, const struct pcap_pkthdr *header, const 
 u_char *pkt_data)
  {
 ip_header *ih=NULL;
 udp_header *uh=NULL;
 tcp_header *th=NULL;
 u_int ip_len;
 u_short tcp_len;
 char* sipP,*sipBody;
 char* skinnyP;
 std::string payload;
 int longSIP;
 mapstring,callId_st*::iterator it;

 Logger* mainLog=0;


 /* retireve the position of the ip header */
 ih = (ip_header *) (pkt_data +
 14); //length of ethernet header

 /* retrieve the position of the udp header */
 ip_len = (ih-ver_ihl  0xf) * 4;

 mainLog=Logger::GetLogger(main);

 if (ih-proto==0x06)//tcp == 0x06
 {
 th = (tcp_header *) ((u_char*)ih + ip_len);

 u_short sport=ntohs(th-sdPorts.sport);
 u_short dport=ntohs(th-sdPorts.dport);

 if (sport==2000||dport==2000)//0x7d0=2000
 {
  ...

  This function is run inside a thread as:

  pcap_loop((pcap_t *)handle,0, packet_handler, NULL);

  With this instruction: if (ih-proto==0x06)//tcp == 0x06 I would be able to 
 see every TCP incoming packet anyway, many packets wireshark is able to 
 capture, are left for me. Can anyone have an idea of what is happening?

  Thanks in advance




  María de Fátima Requena Cabot (2488)
  +34 91 787 23 00 alhambra-eidos.es


  ___
  Wireshark-dev mailing list
  Wireshark-dev@wireshark.org
  http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] ethernet over USB

[ronnie sahlberg]

Hi.

I think you are comparing apples to oranges here.

SnoopyPro is a USB capture tool and it captures the various layers of
the USB protocol.
When used for EthernetOverUSB several layers above the USB layer  is
where you will find Ethernet frames.

So   with SnoopyPro you are capturing USB frames.


With wireshark on Linux you were capturing not USB frames  but rather
the Ethernet frames running on the virtual link layer provided by USB.


Your stack looks like this :

IP
Ethernet
Upper USB layer
Lower USB layer

With snoopy you captures tiny frames in the Lower USB layer and with
Wireshark you captured packets all the way up in the Ethernet layer.
thats why there is no real relation between what Wireshark saw on
linux and what snoopy saw on windows.   Two different layers.


To get something similar to what snoopy captured from your linux box
you must make it capture traffic on a much lower layer.


To be able to capture the USB layer on linux you need a new version of
TCPdump (download and install the latest tcpdump/libpcap svc version)
and also recompile your linux kernel so that it provides a pcap-like
interface to the USB layer.

http://wiki.wireshark.org/CaptureSetup/USB?highlight=%28usb%29

describes what you need to do to capture the usb frames on linux.


Since libpcap now has an encapsulation type for USB frames   which
usbmon in linux uses to write wireshark compatible pcap files,  you
may want to ping the snoopypro people and ask them if they can make
usbsnoopy compatible with libpcap and write libpcap files.



2008/2/2 Bill Fassler [EMAIL PROTECTED]:
 Just in case someone is as interested as me, I meant to attach these files:



 Bill Fassler [EMAIL PROTECTED] wrote:

  Well I found a packet to packet correlation between the two sniffers and
 then I tried to hand dissect the snoopypro packet based on what I could
 learn from the Wireshark Capture.

 I have a couple questions, I understand this might be outside the normal
 scope of things here, so if nobody knows or doesn't want to spend the time
 looking at this I'll certainly understand.

 I am trying to understand as much through reverse engineering before I
 resort
 to the protocol standard.  I like to try to do this because on rare
 occasions you
 run into proprietary protocols and you can't get your hands on any
 standard.

 1) What is the traffic inbetween real ethernet packets.  Hearbeat packets as
 Tyson seems to suggest or something more perplexing?

 2) What is in the Ethernet header/wrapper where it seems there are only
 a few relevant bytes of data and many many empty (0x00 bytes)

 3) How did I screw up on the byte size of my hand dissection? (highlighted
 below)

 The development team and the helpful users here have helped and saved me
 much time in the past, so I thought I would toss this over the fence:

 Here is the raw USB capture for this packet (according to SnoopyPro)

 01008e0024006200ae936c17012456da9ca1b3f3080045542bdf400080014b75c0a80103c0a80101b2c476016d07177500ec560008000800caa65000c8eb5600c4eb56004051510003000300


 
 Raw Ethernet captured by snoopypro and hand dissected
 *
 I am trying to understand this USB wrapper/header which seems to be the same
 for every packet with just a few exceptions:

 01008e0024006200

 Destination:
 ae936c170124
 Source:
 56da9ca1b3f3
 Traffic ID (Ethernet):
 0800
 Version:
 4
 Header Length: |
 5 |
| == I lost continuity here.  Wireshark claims 20
 bytes, but I
| == couldn't see how that was obtained. (seems like
 more to
   |  == me when I count them manually)
    |
 Total Length:
 54 (84)
 Identification:
 2bdf
 Flags:
 4
 Fragment offset:
 000
 Time to live:
 80 (128)
 Protocol IMCP:
 01
 Header Checksum:
 4b75
 Source:
 c0a80103
 Destination:
 c0a80101
 Type:
 00 (Ping Reply)
 Code:
 00
 Internet Control Message protocol checksum:
 b2c4
 Identifier:
 7600
 Sequence Numer:
 0001

 Ethernet payload:
 6d07177500ec560008000800caa65000c8eb5600c4eb56004051510003000300


 **
 Dissected Wireshark capture of same packet
 *
   No. TimeSourceDestination   Protocol
 Info
   7 12.412641   192.168.1.3   192.168.1.1   ICMP
 Echo (ping) reply

 Frame 7 (98 bytes on wire, 98 bytes 

Re: [Wireshark-dev] Trouble adding an ASN.1 based dissector

[ronnie sahlberg]

If Im not mistaken   T124 is encoded with aligned PER while T125 is
BER   so oyu also need to change the flags to asn2wrs to generate
a PER dissector.
You then  also need to look at how other PER dissectors set whether it
is aligned or unaligned PER from the template file.


On Nov 24, 2007 8:26 PM, Stephen Fisher [EMAIL PROTECTED] wrote:
 I'm stumbling through (is there a README somewhere?) trying to add my
 first ASN.1 based dissector (T.124 / Generic Conference Control) to
 Wireshark and I'm running into the following error.  I mostly copied the
 asn1/t124 files from asn1/t125.  This is another layer in a Microsoft
 Remote Desktop Protocol (RDP) session above t.125.

 [EMAIL PROTECTED]:/usr/local/src/wireshark/asn1/t124make generate_dissector
 python ../../tools/asn2wrs.py \
 -b -X -T \
 -p t124 \
 -c ./t124.cnf \
 -s ./packet-t124-template \
 -D . \
  GCC-PROTOCOL.asn
 ASN.1 to Wireshark dissector compiler
 Traceback (most recent call last):
   File ../../tools/asn2wrs.py, line 7671, in ?
 eth_main()
   File ../../tools/asn2wrs.py, line 7602, in eth_main
 ast.extend(yacc.parse(f.read(), lexer=lexer, debug=pd))
   File /usr/local/src/wireshark/tools/yacc.py, line 346, in parse
 tok = self.errorfunc(errtoken)
   File ../../tools/asn2wrs.py, line 7455, in p_error
 raise ParseError(t, input_file)
 __main__.ParseError: GCC-PROTOCOL.asn:54: Unexpected token 
 UniversalString('UniversalString')
 make: *** [packet-t124.c] Error 1

 Am I doing something wrong, or does it not like part of the .asn file?

 Also, how do I go about creating the t.124.cnf file?  (My attempt above
 was using the t125.cnf file)


 Thanks,

 Steve
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] proto_filter_names hash collision

[ronnie sahlberg]

Instead of creating a hash and store it in a hashtable
wouldnt it be better/faster to just store the names as the strings as
is in a se-tree instead.
That should be much faster.


On Nov 21, 2007 8:13 AM, Guy Harris [EMAIL PROTECTED] wrote:

 Kukosa, Tomas wrote:
  It seems that we have reached critical number of protocols.
  I have met collision of built in p7 protoco with my private nu
  protocol. They both have the same g_str_hash() value.
 
  Does it make sence to create hash from the protocol filter name
  which has usually 2-4 characters?
 
  BTW the g_str_hash() for full protocol name takes quite much time during
  startup. Does it make sence to check full protocol name duplicity? Is
  not it enough to check short name and filter name duplicity?

 Does it make sense to do all those sanity checks only if a special
 command-line flag is supplied to TShark, so that the checks are done as
 part of the build process, rather than being done every time you run
 Wireshark or TShark?
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] proto_filter_names hash collision

[ronnie sahlberg]

or rather a pe-tree

On Nov 21, 2007 9:45 AM, ronnie sahlberg [EMAIL PROTECTED] wrote:
 Instead of creating a hash and store it in a hashtable
 wouldnt it be better/faster to just store the names as the strings as
 is in a se-tree instead.
 That should be much faster.



 On Nov 21, 2007 8:13 AM, Guy Harris [EMAIL PROTECTED] wrote:
 
  Kukosa, Tomas wrote:
   It seems that we have reached critical number of protocols.
   I have met collision of built in p7 protoco with my private nu
   protocol. They both have the same g_str_hash() value.
  
   Does it make sence to create hash from the protocol filter name
   which has usually 2-4 characters?
  
   BTW the g_str_hash() for full protocol name takes quite much time during
   startup. Does it make sence to check full protocol name duplicity? Is
   not it enough to check short name and filter name duplicity?
 
  Does it make sense to do all those sanity checks only if a special
  command-line flag is supplied to TShark, so that the checks are done as
  part of the build process, rather than being done every time you run
  Wireshark or TShark?
  ___
  Wireshark-dev mailing list
  Wireshark-dev@wireshark.org
  http://www.wireshark.org/mailman/listinfo/wireshark-dev
 

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Is there a good way of handling bitfields with different bitmask offsets ?

[ronnie sahlberg]

Not tested!
grab the hfinfo structure and modify the fields at runtime :

header_field_info *hfinfo;

hfinfo = proto_registrar_get_nth(hf_index);
hfinfo-bitmask = new bitmask
hfinfo-bitshift = new bit shift


very ugly.   it could work.


please do not contribute any code to wireshark that does anything like this  :-)



On Nov 13, 2007 5:01 AM, Neil Piercy [EMAIL PROTECTED] wrote:
 If the protocol has bitfields they can be defined in the hf structs, but
 what is the best way to cope if these fields can be at different bit
 offsets within the byte ? E.g. a 4 bit field which can occur as the
 lower 4 bits or the upper 4 bits of a byte.

 The more I think about it, the general way would be to add a bit offset
 to _every_ existing proto_tree_add_*() to go with the existing byte
 offset, but is there a simpler way which
 A) maintains the bitmask display in the main packet field view which the
 hf bitmasks provide.
 B) isnt just a text decode - is based on hf entries.

 Neil
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] New Dissector: LLRP

[ronnie sahlberg]

Please add a page to the wiki for this protocol with some screenshot
and samplecaptures.

See http://wiki.wireshark.org/WakeOnLAN
for an excellent example on what a wikipage should look like.


On Nov 7, 2007 1:42 AM, Matt Poduska [EMAIL PROTECTED] wrote:
 I've submitted a new dissector to be considered for inclusion in Wireshark,
 patch request SVN #1957.  It is for the EPCglobal Low-Level Reader Protocol
 (see http://llrp.org for more information). A sample capture file is
 included with the patch submission.

 Matt Poduska


 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] More ITU-T standards available

[ronnie sahlberg]

Dont thank me. Im just a messenger.

Send an email to ITU-T and thank them.


On Nov 5, 2007 6:30 PM, Abhik Sarkar [EMAIL PROTECTED] wrote:
 Brilliant news indeed! Thanks Ronnie!



 On Nov 5, 2007 11:09 AM, ronnie sahlberg [EMAIL PROTECTED] wrote:

 
 
 
  List, people with telco protocol interests
 
 
  Some really good news:
 
 http://www.itu.int/ITU-T/newslog/Free+Access+For+All+To+ITUT+Standards.aspx
 
  http://www.itu.int/ITU-T/publications/recs.html
  ___
  Wireshark-dev mailing list
  Wireshark-dev@wireshark.org
  http://www.wireshark.org/mailman/listinfo/wireshark-dev
 


 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] More ITU-T standards available

[ronnie sahlberg]

List, people with telco protocol interests


Some really good news:
http://www.itu.int/ITU-T/newslog/Free+Access+For+All+To+ITUT+Standards.aspx

http://www.itu.int/ITU-T/publications/recs.html
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

I have commited an initial and very limited X.224 dissector that
registers TPKT on port 3389 and makes TPKT spawn off this port into
X.224 instead.

The X.224 dissector is very incomplete and only really dissects
CR/CC/DT and only for class 0.
But it is good enough for now as a start to decode up to and including
the X.224 layer for remote desktop.

Please if you feel like it   give T.12x a try and put it ontop of this
dissector.


On 10/25/07, Stephen Fisher [EMAIL PROTECTED] wrote:
 On Wed, Oct 24, 2007 at 11:39:15AM -0500, DePriest, Jason R. wrote:

  Unfortunately, I can't seem to locate any good technical documentation
  on how RDP does what it does.
 
  I considered looking at the linux programs that use it (rdesktop) and
  trying to read their code, but I don't write code myself so it would
  be hit or miss.
 
  RDP is Microsoft's baby and I don't know where to look for in depth
  docs on it.
 
  Does anyone have a link or two to some helpful stuff that would help
  me break the code?  Or will I just need to figure it the hard way?

 There is little to no public documentation on Remote Desktop.  I wanted
 to implement RDP dissection in Wireshark a while back and gave up (I had
 just finished off the VNC dissector which was a pain even with
 documentation).  Your best bet is to read the source code to rdesktop
 (which is poorly documented if I remember correctly) and the articles
 under the Documentation section of www.rdesktop.org.  It is a shame
 they did not document the protocol(s) in a nice fashion while writing
 the code to rdesktop.  I do not mean to discourage you or anyone from
 trying to figure it out as it would be a great feature to have in
 Wireshark.  I would be willing to help if someone could figure out at
 least enough to get started :)


 Steve
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

Maybe legacy mode is not used anymore in modern implementations?

Looking at frame 6 in his capture RDP-002...
the user data transported ontop ox x.224 is definitely BER encoded.

It starts with 0x7fthen what follows is definitely BER.

Frame 6/7 starts with   BER APPLICATION 5/6
Could this be  MTrq/MTcf  from T.125 ?


On 10/26/07, Kukosa, Tomas [EMAIL PROTECTED] wrote:

 I can look if asn2wrs could generate at least some usefull code for
 T.128 Legacy mode.


  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On Behalf Of
  ronnie sahlberg
  Sent: Wednesday, October 24, 2007 10:09 PM
  To: Developer support list for Wireshark
  Subject: Re: [Wireshark-dev] decoding Remote Desktop Protocol
 
  I think RDP is just using T.126 with some extra extensions.
  As far as I recall it is using the old legacy encoding and
  not ASN PER.
 
  I did find some documentation about this a long time ago but never had
  any traces/nor real interest in implementing it.
 
  It should be possible to find the T.126 family as well as the old
  legacy encoding through google.
  (the old legacy encoding means the dissector has to be written by hand
  since asn2wrs can not be used)
 
 
  On 10/25/07, DePriest, Jason R. [EMAIL PROTECTED] wrote:
   After Tenable announced that they are going to have operating system
   detection based on Remote Desktop fingerprinting available to Direct
   Feed customers
  (http://blog.tenablesecurity.com/2007/10/windows-operati.html),
   I thought it would be great to figure out how they are doing that.
  
   Unfortunately, I can't seem to locate any good technical
  documentation
   on how RDP does what it does.
  
   I considered looking at the linux programs that use it
  (rdesktop) and
   trying to read their code, but I don't write code myself so it would
   be hit or miss.
  
   RDP is Microsoft's baby and I don't know where to look for
  in depth docs on it.
  
   Does anyone have a link or two to some helpful stuff that would help
   me break the code?  Or will I just need to figure it the hard way?
  
   Thanks!
  
   -Jason
  
   --
   NOTICE:  This email is being sent in clear-text across the public
   Internet.  Therefore, any attempts to include unenforceable legalese
   restrictions are ridiculous and pointless.  If you can read this,
   consider yourself authorized (whether I like it or not).
   ___
   Wireshark-dev mailing list
   Wireshark-dev@wireshark.org
   http://www.wireshark.org/mailman/listinfo/wireshark-dev
  
  ___
  Wireshark-dev mailing list
  Wireshark-dev@wireshark.org
  http://www.wireshark.org/mailman/listinfo/wireshark-dev
 
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

I think RDP is just using T.126 with some extra extensions.
As far as I recall it is using the old legacy encoding and not ASN PER.

I did find some documentation about this a long time ago but never had
any traces/nor real interest in implementing it.

It should be possible to find the T.126 family as well as the old
legacy encoding through google.
(the old legacy encoding means the dissector has to be written by hand
since asn2wrs can not be used)


On 10/25/07, DePriest, Jason R. [EMAIL PROTECTED] wrote:
 After Tenable announced that they are going to have operating system
 detection based on Remote Desktop fingerprinting available to Direct
 Feed customers (http://blog.tenablesecurity.com/2007/10/windows-operati.html),
 I thought it would be great to figure out how they are doing that.

 Unfortunately, I can't seem to locate any good technical documentation
 on how RDP does what it does.

 I considered looking at the linux programs that use it (rdesktop) and
 trying to read their code, but I don't write code myself so it would
 be hit or miss.

 RDP is Microsoft's baby and I don't know where to look for in depth docs on 
 it.

 Does anyone have a link or two to some helpful stuff that would help
 me break the code?  Or will I just need to figure it the hard way?

 Thanks!

 -Jason

 --
 NOTICE:  This email is being sent in clear-text across the public
 Internet.  Therefore, any attempts to include unenforceable legalese
 restrictions are ridiculous and pointless.  If you can read this,
 consider yourself authorized (whether I like it or not).
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

 The parser files are plain-text with no sort of licensing information
 in them.  How likely is it that I would get in trouble for posting
 them to this list?  I'll do some more reading before venturing into
 that.

Please DON'T !
The files are still copyrighted.

since the rdesktop tool can connect to RDP just fine,   the source
code for rdesktop should contain everything anyone would need to
implement a dissector.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] decoding Remote Desktop Protocol

[ronnie sahlberg]

Please start a wiki page and add as many example captures as possible
and interested people can start chipping in.

Maybe the rdesktop people can/want to help out as well?




On 10/25/07, DePriest, Jason R. [EMAIL PROTECTED] wrote:
 From the EULA
 2.  ADDITIONAL LICENSING REQUIREMENTS AND/OR USE RIGHTS.
 a.  Distributable Code.  The software contains code that you are
 permitted to modify and distribute internally within your organization
 if you comply with the terms below.
 i.  Right to Use and Distribute.  The code and text files listed below
 are Distributable Code.
 •   Files with an .npl file extension.  You may copy and distribute
 the object code form of code of only those files marked with an .npl
 file extension and copy and use such modified files solely for your
 internal use.

 So, no joy there.  I bow to your wisdom.

 -Jason

 On 10/24/07, ronnie sahlberg  wrote:
   The parser files are plain-text with no sort of licensing information
   in them.  How likely is it that I would get in trouble for posting
   them to this list?  I'll do some more reading before venturing into
   that.
 
  Please DON'T !
  The files are still copyrighted.
 
  since the rdesktop tool can connect to RDP just fine,   the source
  code for rdesktop should contain everything anyone would need to
  implement a dissector.
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Adding CFM plugin and requesting review.

[ronnie sahlberg]

some comments

1, the libfile should be a header file   packet-cmf.h with the usual
boilerplates included

2, all value strings must be terminated with a {0,NULL} entry or else
you risk reading beyond the end of the array.

3, get rid of theif (proto_cfm == -1) {
  this function should only be called once anyway



On 10/11/07, keith mercer [EMAIL PROTECTED] wrote:
 I have opened the following bugzilla:
 http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1905

 Hopefully I have done it correctly, and have provided the needed material as
 this is the first time I have ever done this. :)

 This plugin will enable the dissection of CFM EOM ethernet packets defined
 by IEEE 802.1ag/D8.1 and also recognizes the opcodes defined by the ITU
 recommendations in Y.1731 as well as dissect AIS PDUs.  I plan on adding
 everything defined in Y.1731 in a future once I am sure I am heading down
 the right road with the current version of the code.

 Thanks to Anders Broman for fixing up the etypes.h and packet-ethertype.c so
 the ethertype does not come up as 'unknown'. ;)

 --Keith Mercer

  
 Ask a question on any topic and get answers from real people. Go to Yahoo!
 Answers.


 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Steps to port wireshark to windows xp, vista and solaris

[ronnie sahlberg]

send your dissectors to the mailing list and someone will review it and give
suggestions on what is portable and what needs fixing.

once the dissector is in the mainline codebase it will be built and verified
on windows hosts that are part of the buildfarm


On 9/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

  Hi ,

 We have used Linux 64 bit machine to compile and test our dissectors. Now
 we want the same to be done in Windows XP, Vista and Solaris environment.

 Can somebody please explain the steps or tell me where can I find the
 information regarding the same.

 BR,
 Tarani

 The information contained in this electronic message and any attachments
 to this message are intended for the exclusive use of the addressee(s) and
 may contain proprietary, confidential or privileged information. If you are
 not the intended recipient, you should not disseminate, distribute or copy
 this e-mail. Please notify the sender immediately and destroy all copies of
 this message and any attachments.

 WARNING: Computer viruses can be transmitted via email. The recipient
 should check this email and any attachments for the presence of viruses. The
 company accepts no liability for any damage caused by any virus transmitted
 by this email.

 www.wipro.com

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Strip Ethernet broadcast / locally administered flags from address before doing manufacturer name resolvings?

[ronnie sahlberg]

On 8/17/07, Sake Blok [EMAIL PROTECTED] wrote:
 On Wed, Aug 15, 2007 at 04:26:23PM +0200, Joerg Mayer wrote:
  On Wed, Aug 15, 2007 at 03:31:08PM +0200, Sake Blok wrote:
   I can't imagine myself situations where you locally assign an
   address and still be interested in the manufacturor of the card
   from which the mac was used as seed. I usually use a BCD encoded
   vlan-tag-number as the LA-mac, this would result in something
   like Local_00:01:30 for vlan 130 :-)
 
  I don't think that's a good idea. Just leave the number in there,
  because otherwise addresses local_00:01:02 and local_00:01:02 would look
  the same, while the first local might have a value of 36:37:38 and
  the second local value might be 02:00:00

 True, but that risk is already there for a lot of Vendors:

 [EMAIL PROTECTED]:~/wireshark$ grep ^..: manuf | awk '{print $2}' | sort | 
 uniq -c | sort -rn | head
  321 Cisco
   52 Private
   28 NokiaDanma
   23 NortelNetw
   22 TexasInstr
   22 Intel
   21 Nortel
   19 3com
   18 SamsungEle
   18 HewlettPac
 [EMAIL PROTECTED]:~/wireshark$

 Of course the risk is bigger in this case, although I think in practice
 it would not occur very often :-)

 Maybe just adding a line:

 02:00:00Local   # LOCALLY ADMINISTRATED ADDRESS

 would be an option. That way, there are no duplicates. This is of course
 only beneficial other people besides me choose their locally administrated
 addresses within 02:00:00:XX:XX:XX .

 Are there any other people that choose their addresses like this?

 Cheers,

Microsoft Cluster creates a local mac address for the cluster by taking the
mac address of the primary node and just flipping the la bit.

If the primary node of the cluster has
04:05:06 - Xerox

then the virtual mac address for the cluster itself will be
06:05:06

in that situation it is useful to do the matching by masking out the la bit
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Strip Ethernet broadcast / locally administered flags from address before doing manufacturer name resolvings?

[ronnie sahlberg]

Sounds good.

In particular doing this for the LocallyAdministrated would make sense
since many active/passive cluster implementations pick a MAC address
to represent the active node by
taking the MAC address of the primary NIC of the primary node and then
setting the locally administrated bit, to make sure there is a single
mac address that follows the cluster ip address during failover.

MS cluster for example does this.


The multicast bit is tricker since there is for unknown reasons some 3
byte prefixes that already have this bit set !   But they are so few
and rare it hardly matters and they can probably be ignored.


I would suggest only doing this for when matching with the three byte prefixes
of the form AA:BB:CC


Additionally, maybe if you find a match for
AA:BB:CC Vendor
and if the LA bit was set then you could change the string it resolved into
to Vendor(Cluster) instead of just Vendor

I think it is very rare that this bit is set nowadays except for when
one is using some sort of clustering software with ip and mac
failover.




On 8/15/07, Ulf Lamping [EMAIL PROTECTED] wrote:
 Hi List!

 The current Ethernet manuf name resolving (resolve the manufacturer name - 
 the first three bytes of the Ethernet address, e.g. 04:05:06 - Xerox) 
 doesn't work if the address uses the Ethernet broadcast or locally 
 administered flags (see 
 http://wiki.wireshark.org/Ethernet?highlight=%28ethernet%29#head-93bbcf02a0070b56eaae6b5f3f4ba6112c64522a
  for details about these flags).

 Currently only the resolving of 04:05:06 - Xerox does work, 05:05:06, 
 06:05:06 and 07:05:06 are not resolved, although the manufaturer part is the 
 same.

 I've implemented an experimental change in epan/addr_resolv.c, which strips 
 down both flags before doing the actual manuf resolvings - which is working 
 well:

 04:05:06 - Xerox
 05:05:06 - Xerox
 06:05:06 - Xerox
 07:05:06 - Xerox

 Unfortunately, this hides both flags a little bit (although the display of 
 these flags wasn't very prominent already before), so I'm unsure if the 
 change should go into the Wireshark sources or not.

 I think only the manuf resolvings as described above should be changed, the 
 wka (well-known-addresses) aka full address resolution (00-E0-2B-00-00-00 - 
 Extreme-EDP) should not be changed.

 Comments?

 Regards, ULFL
 __
 Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!
 Mehr Infos unter http://produkte.web.de/club/?mc=021131

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Strip Ethernet broadcast / locally administered flags from address before doing manufacturer name resolvings?

[ronnie sahlberg]

On 8/15/07, ronnie sahlberg [EMAIL PROTECTED] wrote:
 Sounds good.

 In particular doing this for the LocallyAdministrated would make sense
 since many active/passive cluster implementations pick a MAC address
 to represent the active node by
 taking the MAC address of the primary NIC of the primary node and then
 setting the locally administrated bit, to make sure there is a single
 mac address that follows the cluster ip address during failover.

 MS cluster for example does this.


 The multicast bit is tricker since there is for unknown reasons some 3
 byte prefixes that already have this bit set !   But they are so few
 and rare it hardly matters and they can probably be ignored.


 I would suggest only doing this for when matching with the three byte prefixes
 of the form AA:BB:CC


 Additionally, maybe if you find a match for
 AA:BB:CC Vendor
 and if the LA bit was set then you could change the string it resolved into
 to Vendor(Cluster) instead of just Vendor


Ah crap, you need to do it in two passes since there are real MACs
that already come with the LA bit set.

So when matching the AA:BB:CC entries in manuf
1, First try to match it exactly
   if you find a match, then thats the match.
   i.e.  52:54:4C   Novell2000
   which would resolve into Novell2000

2, If that fails, then try to match it by stripping off the LA bit   with  0xfd
In that case 3E:00:00:xx:xx:xx would match
3C:00:003Com
But the original address would have the LA bit set so it should then be
resolved into 3Com(Cluster)


You have to be careful in which order you try to resolve them as well so that
you dont mixup
00:01:00EquipTrans
and
02-01-00-00-00-00/16MS-NLB-PhysServer-01



I think the optimal would be to resolve your examples as
04:05:06 - Xerox
06:05:06 - Xerox(Cluster)
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] TCP Reassembly issues

[ronnie sahlberg]

On 7/10/07, Graham Bloice [EMAIL PROTECTED] wrote:

 DNP application message fragments are carried in a transport layer which has
 a
 single byte header containing a 6 bit sequence number (tr_seq, 0-63) and two
 flags, first (tr_fir) and final (tr_fin).

 A single fragment message will have both flags set.

 The sequence number does not necessarily reset to 0 at the start of a
 sequence
 of fragments, it just runs sequentially from the fragment where the first
 bit
 is set.

 Because the protocol sequence number is repeated between hosts, I needed to
 invent a unique one to link related application message fragments together,
 hence the static seq_number.  The aim of this is to allow many conversations
 between hosts that are individually identifiable, but reuse the protocol
 sequence number.  If I understand correctly, you are saying that I should
 only
 increment this and add fragments when first finding a fragment, i.e. the
 flag.visited is false.

Maybe packet-nbd.c is useful.
NBD clients often reuse the transaction ID once a previous transaction
has completed making tracking more difficult.

NBD has a structure attached to each conversation,   this structure
contains two hashtables,
one for unacked packets which is populated on initial scan
and a second hashtable which is used later.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Run-time error (samr.hnd disappeared)

[ronnie sahlberg]

i temporarily disabled sidsnooping for now.


sidsnooping was an idea i had a long time ago  but i never finished properly.
it would be nice if it were enhanced in the future to actually look at
most of the dcerpc commands where sids are mapped and used it.
it would also be nice with a small gui where one can see which sids
are known and mapped.

it would take a lot of time to fix it correctly so it becomes useful.
maybe i will do it soon   i hope


On 7/9/07, Martin Mathieson [EMAIL PROTECTED] wrote:
 I'm seeing this error when starting wireshark (despite tshark below in
 the error output).

 Ronnie - will you be adding samr.hnd back again as a field, or should
 this filter expression (in packet-smb-sidsnooping.c) be changed now?


 tshark: Couldn't register
 proto_reg_handoff_smb_sidsnooping()/samr_query_dispinfo tap: Filter
 samr and samr.opnum==40 and ( samr.hnd or samr.rid or samr.acct_name
 or samr.level ) is invalid - samr.hnd is neither a field nor a
 protocol name.
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Beginner article for custom dissector now on Code Project

[ronnie sahlberg]

You need to terminate the value_string
with a
{0,NULL}
entry to tell wireshark where it ends.

Othervise you risk reading beyond the end which will cause a segfault.

On 7/1/07, Ken Thompson [EMAIL PROTECTED] wrote:
 I've recently published a beginner article on creating a custom
 dissector.  This article would not of been possible without the
 developers guide.

 Note: The article is designed for the Win32 environment.

 http://www.codeproject.com/useritems/custom_dissector.asp

 Regards
 Ken
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] WiMAX and M2M plugin code

[ronnie sahlberg]

Do you have any example captures we can use to fuzz test the dissector with?



On 5/18/07, Harvey, Michael [EMAIL PROTECTED] wrote:
 Here is the code for the WiMAX and M2M plugins. These are not supplied
 as patches but as plugin subdirectories.

 Since WiMAX is a wireless protocol, we created an M2M protocol to carry
 WiMAX burst packets over Ethernet. The M2M plugin is registered as an
 Ethernet protocol, and in turn calls the WiMAX plugin.

 Mike


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [Wireshark-commits] rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c packet-ber

[ronnie sahlberg]

Is it really worth it to asn2wsr'ify the kerberos dissector?

First, the dissector currently handles two different versions of
kerberos, both the standard 1510 ASN but also the slightly different
ASN used by packetcable.

Second, the dissector as it is today is almost complete and dissects
virtually the entire asn for both dialects of kerberos we support,
so asn2wrs'ifying it will not really increase the coverage of it.

Third, the dissector contains a lot of special stuff that vendors
(==ms) added to kerberos that is not ans1 defined,things such as
storing nt_status codes inside salt fields and also calling off to NDR
stuff like the PAC in w2k domains

Fourth, there is a lot of code to handle the decryption feature  which
also ties into the various places where krb is used un conjunction
with gss-api for decryption of packets (== dcerpc and secure ldap)


maybe it is easier and less work to just handmassage the existing
dissector to use the new signatures instead of asn2wrs'ifying it ?



On 5/7/07, Anders Broman (AL/EAB) [EMAIL PROTECTED] wrote:
 Hi,
 Could you do the asn2wrs changes and send me the file then I could do some 
 experiments and
 see how much work is involved? At least you have taken care of T38 then there 
 is Kerberos
 and some gsm stuff so it might not be to difficult.
 Regards
 Anders

 

 Från: [EMAIL PROTECTED] genom Kukosa, Tomas
 Skickat: må 2007-05-07 09:42
 Till: Developer support list for Wireshark
 Ämne: Re: [Wireshark-dev] [Wireshark-commits] 
 rev21705:/trunk//trunk/plugins/asn1/:asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacket-acp133.cpacket-acse.cpacket-ansi_map.c
  packet-ber.cpacket-ber.hpacket-camel.c ...



 Hi,

 BTW when you are making such large changes do not you think about
 changing of packet-ber from field oriented to type oriented?

 I.e. replacing

  field_function() {
type_function(hf_field);
  }
  sequence_structure[] = {
   {..., field_function},
  }

 with code

  sequence_structure[] = {
   {hf_field, ..., type_function},
  }

 I did the same for PER last year and generated code is much shorter.

 Unfortunately it will be probaly very hard for BER as there are much BER
 code written by hands which can not be regenerated but has to be
 changed.

 regards,
   Tomas


 Mailcode: NdD2sKHg
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
 (AL/EAB)
 Sent: Monday, May 07, 2007 8:57 AM
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
 21705:/trunk//trunk/plugins/asn1/:
 asn1.hpacket-asn1.c/trunk/epan/dissectors/:packet-MAP_DialoguePDU.cpacke
 t-acp133.c packet-acse.cpacket-ansi_map.c packet-ber.cpacket-ber.h
 packet-camel.c ...

 Hi,
 I thought as much but there is still a lot of work to get the actx into
 all the BER dissecors. I'm taking it a step
 At the time.
 Regards
 Anders

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Kukosa, Tomas
 Sent: den 7 maj 2007 07:58
 To: wireshark-dev@wireshark.org
 Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 21705:
 /trunk//trunk/plugins/asn1/: asn1.h
 packet-asn1.c/trunk/epan/dissectors/:
 packet-MAP_DialoguePDU.cpacket-acp133.c packet-acse.c packet-ansi_map.c
 packet-ber.cpacket-ber.h packet-camel.c ...

 Hello Anders,

 I had not checked X.690 (BER) specification before I defined PER
 external structures in asn1_ctx_t.
 I expected BER uses encoding based on X.680 definition.

 I think we could merge most of PER and BER items in external structure.

 I will move PER items one layer upper and you can reuse them later in
 BER too.

 Regards,
   Tomas


 Mailcode: NdD2sKHg
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 [EMAIL PROTECTED]
 Sent: Monday, May 07, 2007 12:34 AM
 To: [EMAIL PROTECTED]
 Subject: [Wireshark-commits] rev 21705: /trunk/ /trunk/plugins/asn1/:
 asn1.h packet-asn1.c /trunk/epan/dissectors/: packet-MAP_DialoguePDU.c
 packet-acp133.c packet-acse.c packet-ansi_map.c packet-ber.c
 packet-ber.h packet-camel.c ...

 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21705

 User: etxrab
 Date: 2007/05/06 10:34 PM

 Log:
  Start introducing actx to ber functions.

 Directory: /trunk/plugins/asn1/
   ChangesPath Action
   +45 -0 asn1.h   Modified
   +0 -1  packet-asn1.cModified

 Directory: /trunk/epan/dissectors/
   ChangesPath Action
   +20 -20packet-MAP_DialoguePDU.c Modified
   +56 -56packet-acp133.c  Modified
   +103 -103  packet-acse.cModified
   +501 -501  packet-ansi_map.cModified
   +13 -10packet-ber.c Modified
   +2 -1  packet-ber.h Modified
   +434 -434  packet-camel.c   Modified
   +8 -8  packet-cdt.c Modified
   +133 -133  packet-cmip.c

Re: [Wireshark-dev] [Wireshark-commits] rev 21644: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-per.c

[ronnie sahlberg]

it broke SUSE Linux :-)   not windows


On 5/2/07, Kukosa, Tomas [EMAIL PROTECTED] wrote:
 Hi,

 I would fix it but I have to wail till result from builbot is available
 as do not have non-Windows environment.

 T.


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 [EMAIL PROTECTED]
 Sent: Wednesday, May 02, 2007 2:35 PM
 To: [EMAIL PROTECTED]
 Subject: [Wireshark-commits] rev 21644: /trunk/epan/dissectors/
 /trunk/epan/dissectors/: packet-per.c

 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21644

 User: sahlberg
 Date: 2007/05/02 12:34 PM

 Log:
  comment out a unused function so that wireshark builds on suse again

 Directory: /trunk/epan/dissectors/
   ChangesPathAction
   +2 -1  packet-per.cModified

 ___
 Wireshark-commits mailing list
 [EMAIL PROTECTED]
 http://www.wireshark.org/mailman/listinfo/wireshark-commits
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] protocol question

[ronnie sahlberg]

since all your examples above are widely used and publicly available
standardized protocols

is there any particular reason why implementation of these protocols
would have to be private and not be contributed to wireshark?
(those parts that are missing from the existing dissectors that is)



On 4/26/07, f27jx652 [EMAIL PROTECTED] wrote:
   Do you provide guidelines for development of in-house (private)
 protocols/capture filters for use with Ethereal/Wireshark?  Where can I add
 SMS, Wap Push  SMS protocol capturing abilities?

   Thank you


 -
 Ahhh...imagining that irresistible new car smell?
  Check outnew cars at Yahoo! Autos.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [Wireshark-commits] rev 21262: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-atsvc.c packet-dcerpc-dfs.c packet-dcerpc-efs.c packet-dcerpc-eventlog.c packet-dcerpc

[ronnie sahlberg]

Note that I did not yet regenerate WKSSVC since this dissector would
really need the not yet finished TYPE conformance file directive in
order to handle the dependency for a type from SRVSVC properly.





On 3/29/07, Joerg Mayer [EMAIL PROTECTED] wrote:
 On Thu, Mar 29, 2007 at 02:22:24AM +, [EMAIL PROTECTED] wrote:
  Log:
   regenerate the dissectors with an even newer patched version of pidl to
 add two more pragmas
 
 
   you need this patch ontop of svn pidl to regenerate the files :
 ...

 I've updated the pidl repo to that of the samba team and applied your
 patch on top of it, so hopefully everyone should be able to use the ws
 pidl right now.

  Ciao
 Joerg
 --
 Joerg Mayer   [EMAIL PROTECTED]
 We are stuck with technology when what we really want is just stuff that
 works. Some say that should read Microsoft instead of technology.
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] State of pidl and idl/cnf files?

[ronnie sahlberg]

We kind of use the original idl files, or at least some of them.

There are two exceptions where we are out of sync with samba and that
is the EVENTLOG and the SRVSVC idl files where there are a additional
fields and functions that samba have not yet merged into their idl
files.

PIDL still needs an implementation of the TYPE conformance file
directive in order to manage prettification of strings.
This is required in order to make strings appear on the info column, etc.


I think we really need to get TYPE working properly in PIDL before we
can start PIDLifying the more critical interfaces such as LSA, SAMR,
NETLOGON.
PIDL is not yet mature enough to generate those interfaces (unless one
accepts a massive regression in useability and prettification)
Once I am happy with how PIDL can generate the less imporant
interfaces we already have PIDLified  I will cut those critical
interfaces over as well.
That will be quite a lot of work since our handwritten dissectors do
contain a lot of things that are not yet in the IDL files so they have
to be audited and all items not present in the idl files have to first
be merged to the idl files.


We are getting there, step by step.




On 3/29/07, Joerg Mayer [EMAIL PROTECTED] wrote:
 Hello (mostly) Ronnie,

 (ignoring the #pragma patch) we have been using the original pidl stuff
 from the samba team for quite a while now. What we are not using are the
 original .idl and .cnf files. Is this still necessary and if so, what
 needs to be done to change this?

 Thanks
 Joerg
 --
 Joerg Mayer   [EMAIL PROTECTED]
 We are stuck with technology when what we really want is just stuff that
 works. Some say that should read Microsoft instead of technology.
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] State of pidl and idl/cnf files?

[ronnie sahlberg]

Forgot:

I think this was discussed some 2 years ago or so.
I think the long term plans are that samba owns the idl files and we
only use copies of them.
We on the other hand should own the conformance files and any
conformance files in samba should be deleted   or linked to ours.



On 3/29/07, Joerg Mayer [EMAIL PROTECTED] wrote:
 Hello (mostly) Ronnie,

 (ignoring the #pragma patch) we have been using the original pidl stuff
 from the samba team for quite a while now. What we are not using are the
 original .idl and .cnf files. Is this still necessary and if so, what
 needs to be done to change this?

 Thanks
 Joerg
 --
 Joerg Mayer   [EMAIL PROTECTED]
 We are stuck with technology when what we really want is just stuff that
 works. Some say that should read Microsoft instead of technology.
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [Patch] pragma warning

[ronnie sahlberg]

I dont think it is really realistic to have all autogenerated files
always compile without any warnings.
Maybe we should instead split Makefile.common up into three parts :

First part : normal dissectors

Second part : ANS2WRS generated dissectors  which take extra compile
time flags and definitions to suppress artefacts from the compiler.

Third part : PIDL generated dissectors that once again take extra
compile parameters and definitions.




On 3/28/07, Graham Bloice [EMAIL PROTECTED] wrote:
 Gisle Vanem wrote:
  Graham Bloice [EMAIL PROTECTED] wrote:
 
  Gisle Vanem wrote:
  The #pragma warning() statements are MSVC specific. So
  embed them inside #ifdef _MSC_VER.
 
  I always thought unrecognised #pragma directives were ignored.  I take
  it that MinGw barfs on them in some way?
 
  MingW ignores them, but with a warning. I thought we should strive
  to reduce the number of warnings. Hence my patch.
 

 Ignore and issues a warning don't quite mesh in my dictionary, but
 now I understand what's up I support your solution.

 --
 Regards,

 Graham Bloice

 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [Patch] pragma warning

[ronnie sahlberg]

On 3/28/07, Ulf Lamping [EMAIL PROTECTED] wrote:
 ronnie sahlberg wrote:
  I dont think it is really realistic to have all autogenerated files
  always compile without any warnings.
  Maybe we should instead split Makefile.common up into three parts :
 
  First part : normal dissectors
 
  Second part : ANS2WRS generated dissectors  which take extra compile
  time flags and definitions to suppress artefacts from the compiler.
 
  Third part : PIDL generated dissectors that once again take extra
  compile parameters and definitions.
 
 Sounds like a reasonable solution. It would also have the advantage that
 we get a list of generated dissectors, which we currently don't have.

 But: Is there a makefile magic, so you can have different CFLAGS
 settings for the different lists? Remember that we are using implicit
 rules here.

 Having three lists shouldn't be difficult to add, but I don't know how
 to get the compile logic for it - however, I'm really not an expert on
 this.

 If there's a solution for this makefile problem, I think it's the way to
 go ...

When it comes to the ANS2WRS dissectors are concerned  I think that
ANS2WRS is so mature now that maybe what we should do for those
dissectors would instead be to
remove them completely from epan/dissectors and make asn part of the
build process.
All these dissectors have their own makefile down in asn/* where one
can set additional or different compiler flags compared to those used
by the normal epan/dissectors.
These asn dissectors could even be linked to a separate dll :
libwireshark-asn.dll


As far as i remember,  the manual process of make copy_files and not
having the asn compilation part of the build process was really just
to wait doing so until we were sure asn2wrs was mature enough.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Patch to AMQP dissector

[ronnie sahlberg]

checked in

On 3/27/07, Martin Sustrik [EMAIL PROTECTED] wrote:
 Hi Ronnie,

 here's a patch to AMQP dissector. The only change is that when there are
 seceral AMQP frames in single TCP packet, all of them are referred in
 the info column.

 Can you check it in?

 Thanks.
 Martin

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [Wireshark-commits] rev 21256: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dcerpc-winreg.c packet-dcerpc-winreg.h /trunk/epan/dissectors/pidl/: winreg.idl

[ronnie sahlberg]

:-)

Well   those files are not supposed to be manually edited/modified anyway.


I can change PIDL to always emit

#ifdef _MSC_VER
#pragma warning(disable:4005)
#pragma warning(disable:4013)
#endif

at the head of the file.

Are there any other pramgas you want it to emit as well?





On 3/29/07, Ulf Lamping [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] wrote:
  http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=21256
 
  User: sahlberg
  Date: 2007/03/29 12:26 AM
 
  Log:
   update winreg to the latest idl
 
  Directory: /trunk/epan/dissectors/
ChangesPath  Action
+221 -18   packet-dcerpc-winreg.cModified
+1 -0  packet-dcerpc-winreg.hModified
 
  Directory: /trunk/epan/dissectors/pidl/
ChangesPath  Action
+26 -11winreg.idlModified
 
  ___
  Wireshark-commits mailing list
  Wireshark-commits@wireshark.org
  http://www.wireshark.org/mailman/listinfo/wireshark-commits
 
 Hi Ronnie!

 You've repeatedly breaking the Win32 buildbot by removing the
 handcrafted #pragma warning(disable) I've added to fix warnings of the
 generated files.

 Unless we have implemented the real fix you've mentioned, namely
 splitting the sources into generated and normal sources with
 different CFLAGS, could you add the #pragma changes to the generated
 files before checking them in?

 We are currently working against each other ;-)

 Regards, ULFL
 ___
 Wireshark-dev mailing list
 Wireshark-dev@wireshark.org
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Patches for compilation warnings

[ronnie sahlberg]

On 3/27/07, Peter Johansson [EMAIL PROTECTED] wrote:

 Oh, my bad. So how can one fix these problems then? I am not really on top
 of IDL, what should one generally do to correct this?

I have sent patches to Jelmer that maintains PIDL that will address
most of the warnings from the pidl generated dissectors.
Once these patches are in mainline pidl I will regenerate the dissectors.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Segmentation fault in dissector

[ronnie sahlberg]

Is this a proprietary dissector  or a dissector you plan to contribute
to wirehsark?


On 3/27/07, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

 Hi,



 We are using a 32 bit machine and dissector is working fine. The same
 dissector when used in a 64 bit m/c is giving problems. I would like to
 know how is it going to get affected in the change of environment,
 because initially it did not even compile properly .While testing in a
 64 bit machine the wireshark is getting crashed giving the following
 error:



 Inside unpack digits , length = 29 and offset is = 18





 Program received signal SIGSEGV, Segmentation fault.

 [Switching to Thread 182924546464 (LWP 1776)]

 0x002a9b46afb7 in unpack_digits (tvb=0x10dfbd8, offset=18,
 dgt=0x2a9b588e78) at packet-xxx.c:4488

 4488digit_str[i] = dgt-out[octet  0x0f];

 (gdb)





 The code for unpack digits is as follows:



 static char*

 unpack_digits(tvbuff_t *tvb, int offset, dgt_set_t *dgt){



 int length, length_fake, offset_fake, counter=0;

 guint8 octet, num_of_digits_imsi;

 int i=0;

 char *digit_str;



 length = tvb_length(tvb);

 printf(\n\nInside unpack digits , length = %d and offset is =
 %d\n\n,length,offset);

 if (length  offset)

 return ;

 digit_str = ep_alloc((length - offset)*2+1);



 offset_fake = offset-1;

 num_of_digits_imsi = tvb_get_guint8(tvb,offset_fake);

 if( (num_of_digits_imsi % 2) == 0 )

 length_fake = num_of_digits_imsi / 2;

 else

 length_fake = (num_of_digits_imsi+1)/2;



 printf(\noffset_fake = %d\tnum_of_digits_imsi = %d\tlength_fake
 =  %d,offset_fake,num_of_digits_imsi,length_fake);

 while ( counter  length_fake ){



 octet = tvb_get_guint8(tvb,offset);



 digit_str[i] = dgt-out[octet  0x0f];

 i++;



 /* unpack second value in byte */

 octet = octet  4;



 if (octet == 0x0f)  /* odd number bytes - hit filler
 */

 break;



 digit_str[i] = dgt-out[octet  0x0f];

 i++;

 offset++;

 counter++;



 }

 digit_str[i]= '\0';

 return digit_str;

 }





 Can anybody please help???



 Regards,

 Bhavani.




 The information contained in this electronic message and any attachments to
 this message are intended for the exclusive use of the addressee(s) and may
 contain proprietary, confidential or privileged information. If you are not
 the intended recipient, you should not disseminate, distribute or copy this
 e-mail. Please notify the sender immediately and destroy all copies of this
 message and any attachments.

 WARNING: Computer viruses can be transmitted via email. The recipient should
 check this email and any attachments for the presence of viruses. The
 company accepts no liability for any damage caused by any virus transmitted
 by this email.

 www.wipro.com
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] [PATCH] bunch of warnings fixes

[ronnie sahlberg]

checked in


On 3/26/07, Sebastien Tandel [EMAIL PROTECTED] wrote:
 One big patch is provided to apply all the changes.
 It contains warnings fixes and removed some declarations after statement
 too.

 I also provide patch-per-file.tar.gz containing one patch for each file
 affected by big patch, in case some modifs have been committed on one
 of these files :
 packet-alcap
 packet-ansi_637
 packet-ansi_a
 packet-atalk
 packet-beep
 packet-ber
 packet-bootp
 packet-bpdu
 packet-bthci_acl
 packet-btsdp
 packet-cops
 packet-cups
 packet-ssh
 packet-synergy
 packet-t38
 packet-tacacs
 packet-tali
 packet-tcp
 packet-tds
 packet-telnet
 packet-ucp
 packet-uma
 packet-vtp
 packet-wbxml
 packet-who
 packet-x11
 packet-x25
 packet-xdmcp
 packet-xml
 packet-yhoo



 Regards,
 Sebastien Tandel

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev