Re: [Wireshark-dev] Pointers needed for building Wireshark 2.6.3 on a Raspberry Pi model 3B (armv7 processor?)

[Ed Beroset]

On 9/17/18 1:04 PM, Jaap Keuter wrote:

HI,

Just a few responses on some items here. It seems that you got into building a 
(rather complicated) program for the first time. Please excuse us for not being 
in the business of teaching ‘first timers’ how this is done on the multitude of 
platforms this software is supposed to run on. That is just out of our scope. 
However, we do try to make the process as smooth as possible by preparing the 
build system in great detail.


One thing that occurs to me is that it might be good to summarize "what 
you should already know" for various kinds of tasks one might want to 
do, e.g. just building versus actually getting in a fixing things.  If I 
make an attempt to write such a thing, I imagine it should go into 
chapter 1 of the Wireshark Developer's Guide.  Is there a better place 
for it?


Ed
___
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] Building RPM proprietarry plugin including math.h fails

[Ed Beroset]

On 08/28/2018 09:35 AM, Anders Broman wrote:

Hi,

tfo/packet-tfo.c:3754: undefined reference to `pow'

collect2: error: ld returned 1 exit status

when running make-rpm-package


That's the symptom of missing the math library on the linker command 
line.  You'd need to add '-lm' to the linker line, if that's what you're 
asking about.


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

[Wireshark-dev] donation to menagerie?

[Ed Beroset]

I submitted a tiny patch to address a particular need I saw recently. 
(https://code.wireshark.org/review/#/c/26280/)


The patch just adds a more specific expert warning ("Payload IE in 
header") already would have been flagged by a more general expert 
warning ("Unsupported IE ID").  The question I have is whether it's 
worthwhile to submit a corresponding capture file.  I have a single 
capture file that contains both the malformed and corrected frames, but 
since it's only a relatively small warning change, is it worth 
submitting?  And if so, where?


Ed
___
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] gerrit registration problems

[Ed Beroset]

On 02/20/2018 10:39 PM, Richard Sharpe wrote:

On Tue, Feb 20, 2018 at 7:07 PM, Ed Beroset <bero...@mindspring.com> wrote:

On 01/31/2018 09:44 AM, Ed Beroset wrote:


I've submitted code to Wireshark in the past, but not since Gerrit.  I
tried again yesterday to register and now I remember why it's been so long
-- I can't seem to register.  Is this the place to ask for help, or is there
a better way to do it?



I may or may not be registered and I may or may not have submitted a patch.
I followed the instructions here:
https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html

Git seems to have accepted the push, but I don't see any evidence that it
exists when I go to https://code.wireshark.org/review/#/dashboard/self

Any troubleshooting clues, or is it normal that a successful push has no
observable manifestation?


Is it this one?

https://code.wireshark.org/review/#/c/25956/


Yes!  It seems that I may have two registrations, but I only know one 
password.  Who has admin rights and can help me combine them?  Or is 
there some self-service thing I can do?


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

[Ed Beroset]

On 01/31/2018 09:44 AM, Ed Beroset wrote:
I've submitted code to Wireshark in the past, but not since Gerrit.  I 
tried again yesterday to register and now I remember why it's been so 
long -- I can't seem to register.  Is this the place to ask for help, or 
is there a better way to do it?


I may or may not be registered and I may or may not have submitted a 
patch.  I followed the instructions here: 
https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html


Git seems to have accepted the push, but I don't see any evidence that 
it exists when I go to https://code.wireshark.org/review/#/dashboard/self


Any troubleshooting clues, or is it normal that a successful push has no 
observable manifestation?


Ed
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] report from the bleeding edge (VS 2017)

[Ed Beroset]

On 04/24/2017 01:01 PM, Graham Bloice wrote:

Who knows what will be in the next Visual Studio.  I haven't seen any 
announcements, but as VS 2017 was only released just over a month ago I 
don't expect any public announcements yet.


It's possible that future C++ language changes may force them to change 
the ABI.


I have been working through building an installer package on and for 
Win64 on Windows 10 using VS 2017 and NSIS 3.03, so I thought I'd send 
this report from the bleeding edge.


Cylance vs. Cygwin
==
"BLODA" is the Cygwin acronym for "Big List Of Dodgy Apps" and 
unfortunately, I have discovered another one, which is Cylance which is 
anti-malware software (despite both starting with "cy" they have no 
relationship).  For background on that, see 
https://cygwin.com/faq/faq.html#faq.using.bloda and 
https://cygwin.com/ml/cygwin/2017-04/msg00319.html


I have been able to work around this by getting my IT folks to whitelist 
the following cygwin executables:

xterm.exe
git.exe
perl.exe
python2.7.exe

That seems to have been sufficient (so far) to get Wireshark to compile 
(for building Wireshark, it's probably not necessary to have xterm.exe 
but I use xterm often and it annoyed me!). Although it's more of a 
Cygwin than a Wireshark issue, I mention it here in case anyone 
encounters this problem and does a search.


Specifying platform
===
I used this command for CMake:

cmake -DENABLE_CHM_GUIDES=on -G "Visual Studio 15 2017 Win64" ..

I found that I had to explicitly specify the platform when using 
msbuild.  For example, to build a Release version on my machine:


msbuild /m /p:Configuration=Release /p:Platform=x64 Wireshark.sln

I don't yet know enough about msbuild or sln files to troubleshoot much 
further, but that worked for me.


Results
===
I haven't yet done thorough testing, but the installer, Wireshark and 
Tshark all seem to be to working correctly.


Hope that helps.

Ed
___
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] gerrit registration problems

[Ed Beroset]

On 01/31/2018 11:36 AM, Jeff Widman wrote:

What error message are you hitting when you try to register?


I had two problems, which may be related.

First, I appear to have been able to register, but when I tried to 
assign myself a user name, it rejected it saying that it needed to 
consist of only letters, numbers and a few punctuation characters.  That 
was strange because it was only letters.  It didn't allow "beroset" but 
it let me use "eberoset" which suggests there may be a duplicate account 
from a previous attempt.


Second, I tried to associate an email address.  I got the confirmation 
email clicked on the link and then it gave a cryptic error message at 
first, but after my second attempt it now says "Error: Identity in use 
by another account."


I imagine that it might be possible for an admin to delete one or both 
accounts and I could try again.


Ed

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

[Wireshark-dev] gerrit registration problems

[Ed Beroset]

I've submitted code to Wireshark in the past, but not since Gerrit.  I 
tried again yesterday to register and now I remember why it's been so 
long -- I can't seem to register.  Is this the place to ask for help, or 
is there a better way to do it?


Ed
___
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] Adding pcap-ng pipe support to dumpcap

[Ed Beroset]

On 08/30/2017 09:31 PM, Guy Harris wrote:

On Aug 30, 2017, at 6:00 PM, Ed Beroset <bero...@mindspring.com> wrote:


One problem is that as dumpcap is currently written, it treats files and pipes 
very differently.


*Files* and pipes, or *capture devices* and pipes?


Actually, I meant to say pipes and sockets.


but I can't help but think that the general approach you describe is the better 
long term strategy.


Probably.  It means that the interface between *shark and extcap programs would 
be different - but, while having extcap programs behave like dumpcap might 
complicate the extcap programs (although some of the code to do that could be 
in a library used by dumpcap and by extcap programs), it might simplify the 
Wireshark capture code path.


I'm not sure that the interface between dumpcap and Wireshark/tshark 
would need to change to accommodate a wider variety of inputs via pipes. 
 What I meant was that much of the parsing and interpretation of the 
file formats seems to be essentially the same whether the data arrives 
as a file or as data in a pipe, so it seems, perhaps naively, that some 
of the code could also be shared.



There are some limitations.  Specifically, pipes don't allow random access, so 
any file formats that currently require that would need to either be rewritten


Which, for at least one capture file format (Network Monitor format), would be 
impossible, as we don't define it, Microsoft does (and they're probably not 
very amenable to changing it, not least because they've deprecated NetMon in 
favor of Message Analyzer).  The only file formats *we* control to any degree 
are pcap and pcapng, neither of which require random access in order to read 
them sequentially.


Partly for that reason, I've been concentrating my efforts on only those 
two formats for pipe input.  My patch is still quite rough, but it's 
working for my purposes.


Ed
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
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] Adding pcap-ng pipe support to dumpcap

[Ed Beroset]

On 08/30/2017 07:58 PM, Stephen Donnelly wrote:


Why pcap-ng specifically? Although pcap-ng is higher featured than pcap, it is 
not Wireshark's internal representation. Pcap-ng is merely the default output 
format.


I don't know about other people's desire for this, but here's mine:  I 
am working on a Raspberry Pi based sniffer tool for IEEE 802.15.4 
traffic and want to be able to have the Pi serve up sniffed packets to 
an instance of Wireshark on another machine.  Rather than fiddle with 
pcap, it seemed to make sense to me to use pcapng as the output format 
for the Pi-based sniffer.  It was only after I had finished that, that I 
realized that pcapng was not supported via a pipe.



Since Wireshark has the ability to detect and read multiple formats already in 
wiretap, why not leverage that?

At the very least extcap tools should be able to supply data in any format 
understood by wiretap, but since the extcap data currently goes via dumpcap 
(maybe not sensible either?) they are restricted to pcap only and have to 
convert to that internally, potentially losing information.


Yes, exactly the situation.  So I've created a patch which works for my 
immediate needs, but is rather hack-ish and ugly for any other, at least 
in part due to some of the factors you mention.



Wouldn’t it be better for the capture tool to indicate which of the wiretap 
formats it intends to use, rather than switching from one fixed format to a 
different fixed format? This would then support both pcap and pcap-ng 
intrinsically, as well as all other formats.


One problem is that as dumpcap is currently written, it treats files and 
pipes very differently.  Part of that appears to be due to the fact that 
Windows treats them very differently, but I can't help but think that 
the general approach you describe is the better long term strategy. 
There are some limitations.  Specifically, pipes don't allow random 
access, so any file formats that currently require that would need to 
either be rewritten or omitted for the pipe-able formats.


Might be doable in that way, but it would require a lot of re-engineering.

Ed
___
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] Adding pcap-ng pipe support to dumpcap

[Ed Beroset]

On 08/29/2017 02:35 PM, Richard Sharpe wrote:

On Tue, Aug 29, 2017 at 10:50 AM, Ed Beroset <bero...@mindspring.com> wrote:

On 06/16/2017 01:27 PM, Richard Sharpe wrote:

I've just encountered a need for this as well.  Have you made progress,
Evan?  Do you want some help?


Evan seems to have dropped off the radar. I outlined to Evan an
approach for doing this, so I could send it to Ed instead ...


It would be helpful if you could.  I've looked at your old patch and 
I've been looking over the dumpcap.c code and have been making some 
notes, but it would nice to have additional input on this, especially 
since you've already looked at it.  Thanks!


Ed
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
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] Adding pcap-ng pipe support to dumpcap

[Ed Beroset]

On 06/16/2017 01:27 PM, Richard Sharpe wrote:

On Fri, Jun 16, 2017 at 9:36 AM, Kvidera, Evan D  wrote:

Hello Wireshark Devs,

My name is Evan Kvidera and I am a senior undergraduate student studying
Computer Science. I have a decent amount of programming experience, but only
a little in C. My employer has asked me to try to add support for piping
pcap-ng captures to Wireshark.
I have read over the bug report requesting the feature,
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11370.

After reading the mailing list archives here,
https://www.mail-archive.com/wireshark-dev@wireshark.org/msg6.html, it
looks like this addition will be nontrivial, but doable, and that the
changes necessary are all going to be in dumpcap.

I have at least a month or two of full-time work I can dedicate to this if
necessary, although I am hoping it will not take that long.

I have read through the Wireshark Developer's Guide and looked over the
style guide for Wireshark. Is there anything else I should know before
starting development? I will try to develop this as independently as
possible, but I may have a few questions along the way.


Hi Evan,

I looked at this back in 2012 and even proposed a patch that might be
useful to you:

   http://seclists.org/wireshark/2012/May/25

No doubt it was a little too simplistic but if I find some time next
week while I am in Seattle I might try to resurrect it and see if it
works.


I've just encountered a need for this as well.  Have you made progress, 
Evan?  Do you want some help?


Ed
___
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] Remove our bundled crypto library (in favor of Libgcrypt)?

[Ed Beroset]

Bálint Réczey wrote:


+1 for going without a new layer of indirections.
Making libgcrypt mandatory is easy and every level of indirection make
understanding the code harder which is a source of bugs.

If we ever feel dropping libgcrypt necessary we can add the new layer.


FWIW, I heartily agree with this.  While I have no objection to nettle, 
I think that adding support for multiple libraries is unlikely to be 
worth the effort.


I also seem to recall that the reason QEMU has both is that it relied on 
gnutls and it's *that* package that had support for both.  Rather than 
linking yet another library, QEMU used to default to whatever had been 
selected for gnutls.  The change to allow an explicit choice when 
building QEMU is only a year or two old.


Ed
___
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] Menagerie

[Ed Beroset]

Dario Lombardo wrote:
Should be supported by your torrent client (maybe create torrent or
something). Once you succeded, send us the torrent.
How large it is?

From the originally sent torrent, it seems to be 1.88G.  I'm interested in 
this too and could seed pretty much perpetually once we get it started.

Ed


___
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

[Wireshark-dev] error initializing git review

[Ed Beroset]

I've followed the steps here: 
https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcObtain.html

And I've successfully gotten to the step where it says to run git review -s 
but then it fails.  The full error dump is:

Traceback (most recent call last):
  File /usr/bin/git-review, line 10, in module
sys.exit(main())
  File /usr/lib/python2.7/site-packages/git_review/cmd.py, line 1202, in main
set_hooks_commit_msg(remote, hook_file)
  File /usr/lib/python2.7/site-packages/git_review/cmd.py, line 264, in 
set_hooks_commit_msg
res = run_http_exc(CannotInstallHook, hook_url, stream=True)
  File /usr/lib/python2.7/site-packages/git_review/cmd.py, line 175, in 
run_http_exc
raise klazz(255, str(err), ('GET', url), env)
git_review.cmd.CannotInstallHook: Problems encountered installing commit-msg 
hook
The following command failed with exit code 255
GET https://bero...@code.wireshark.org/tools/hooks/commit-msg;
---
Problems encountered installing commit-msg hook
The following command failed with exit code 104
GET https://bero...@code.wireshark.org/tools/hooks/commit-msg;
---
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title404 Not Found/title
/headbody
h1Not Found/h1
pThe requested URL /tools/hooks/commit-msg was not found on this server./p
/body/html

---
---

I don't really know how to go about troubleshooting this since I haven't ever 
used it and don't know what it's supposed to do.  If it's relevant, I'm behind 
a corporate firewall that forces me to use https: instead of ssh: Any clues?

Ed
___
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] error initializing git review

[Ed Beroset]

Graham Bloice wrote:
On 5 February 2015 at 17:48, Ed Beroset bero...@mindspring.com wrote:


 Problems encountered installing commit-msg hook
 The following command failed with exit code 104
 GET https://bero...@code.wireshark.org/tools/hooks/commit-msg;
 ---
[...]


 I don't really know how to go about troubleshooting this since I haven't
 ever used it and don't know what it's supposed to do.  If it's relevant,
 I'm behind a corporate firewall that forces me to use https: instead of
 ssh: Any clues?

Is the URL correct?  

I have no idea.

Shouldn't it be
https://bero...@code.wireshark.org/wireshark/tools/hooks/commit-msg

What does git remote -v show?

origin  https://bero...@code.wireshark.org/review/wireshark (fetch)
origin  https://bero...@code.wireshark.org/review/wireshark (push)

Ed
___
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] Update Windows Build Instructions

[Ed Beroset]

Stephen Fisher wrote:

 Yes, use CMake :-)
 
 There are other cross-platform build solutions such as SCons, but it's 
 just as bad as CMake (or maybe worse, I haven't tried anything other 
 than a toy project).

 Adding a dissector to CMake is as simple as it is for nmake with the 
 bonus that it works for both Windows and Linux (and wherever else 
 CMake is used).  Doing anything else with the CMake build system 
 requires a lot of head scratching as getting the required output from 
 the arcane language of CMake files can be a battle.

With such a glowing review as that.. I'm not sure I want to try CMake :)  
Perhaps it would be better to handle the different platform build 
methods ourselves.

Having been around this particular block a couple of times, yes, CMake at times 
is a battle, but it's also better than the alternative of producing (and 
maintaining) multiple mutually incompatible and inevitably arbitrarily 
different build systems in parallel.

 msbuild will also use multiple threads to build so is can be much 
 quicker.  The other big advantage of VS solution files is that it 
 should make it easier for folks to use the IDE debugger.

Indeed.  So what about making a script to read in Makefile.common and 
spitting out those XML files for msbuild?  Or update the msbuild so IDE 
things in those files (if any) aren't reset every time its rebuilt.

It sounds like reinventing a subset of CMake.  I've found that for most things 
(the straightforward part of a makefile that typically makes up 80% of a 
project's build instructions) CMake works pretty well without a lot of thought. 
 For the other parts, there's usually only pain in figuring it out the first 
time, but after that, the vagaries of changes to the target systems (e.g. 
changes to nmake or gnu make or default locations for libraries on BSD, or any 
of a hundred other details) are all handled by the CMake developers.

Sorry this sounds like a sales pitch -- I've just done this exercise enough 
times to appreciate that while it's not perfect by a long shot and is maddening 
when it doesn't work, but even with its flaws, it's better than the 
alternatives I've found.

Ed
___
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] On which platforms is there a need for Wireshark to have a Language preference?

[Ed Beroset]

Guy Harris wrote:
 but in home I want to
 use Italian Wireshark and sometimes Polish/English. Set language in
 GUI is really helpful.

Is the ability to set the language on a *per-application* basis, rather than 
on a system-wide basis, really helpful to very many users?

It doesn't seem so to me, although I sometimes use different locales. If I 
wanted to set language per-application in Windows, it can still easily be done 
with a batch file by setting the environment variable first.  I would note, 
too, that QtLinguist, whose authors may actually have considered this issue, 
does respect the system locale, but does not provide a separate means of 
setting the language.

Ed
___
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] ctype.h calls

[Ed Beroset]

Jeff Morriss wrote:
Is there any reason the remaining ctype.h calls in master shouldn't be 
removed [and the functions put on the prohibited list in checkAPIs.pl]?

One of the calls in ctype.h is tolower() which is used in 
wsutil/strncasecmp.c.  Could we simply remove that entire file and use 
g_ascii_strncasecmp() instead?

Ed
___
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 to support wireshark w/o having an OpenID

[Ed Beroset]

Evan Huus wrote:

 On Aug 10, 2014, at 21:43, Ed Beroset wrote:
 I'm not sure it matters sufficiently that it could or should cause course 
 alteration, but as one who has contributed modestly to Wireshark before the 
 move to gerrit, but not since then, I'd have to say that for me, the 
 setup/registration/configuration/etc. has definitely impeded further 
 contributions.  The new process is something that I haven't really gotten 
 around to trying to figure out.  I'm not saying it's the wrong choice, but 
 it's just that much more effort to even *submit* a patch, that I suspect 
 that a lot of would-be contributors might find the threshold too high.  
 Maybe updating documentation could help.  Right now, if you go to the main 
 develop page https://www.wireshark.org/develop.html and click on the link 
 under code review site you get to 
 https://code.wireshark.org/review/#/q/status:open,n,z which offers no clue 
 at all as to how one should actually register.  I'm sure I could figure it 
 out, and I'm sure many have.  It's just that I'd really just like to be able
  to contribute patches without having to do quite so much exploration.  Maybe 
I'm just lazy, but it might be nice if the barrier to useful contribution were 
lowered just a bit.

There is http://wiki.wireshark.org/Development/SubmittingPatches which we 
should definitely do a better job of advertising. That should walk you through 
the major setup steps.

Where would be a more useful/obvious place to include that information?

If there were a link to that page, perhaps under the words contribute change, 
on https://www.wireshark.org/develop.html I think it would be a little easier 
to find.  Also, the sign in step seems to have been the source of most of the 
questions I've seen on this list, so maybe a bit of expansion on the options 
there and how to effect them would be useful.  I keep thinking that I'll write 
it up myself once I figure it out, but hadn't gotten around to doing either 
yet.  :(

Ed
___
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 to support wireshark w/o having an OpenID

[Ed Beroset]

-Original Message-
From: Kevin Cox kevin...@kevincox.ca
Sent: Aug 9, 2014 4:05 PM
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] How to support wireshark w/o having an OpenID

On 09/08/14 12:51, Toralf Förster wrote:
 My question is rather, whether it is mandatory to register at one of
 the big IT players or if an email address would be sufficient. 
You don't need to register at one of the big IT players, I think that
Wireshark gerrit is set up to accept any OpenID provider.  However I
believe you are asking if you can sign up with just an email and I'm
pretty sure the answer is no because gerrit doesn't do its own
authentication.

Basically the story is—as currently set up—you need an OpenID but who
your provider is doesn't matter, you can use a public service or set
your own up but it has to be OpenID.

Sorry if that doesn't suit you, maybe you could start a discussion about
alternate authentication methods however gerrit doesn't support much.[0]

[0]
https://gerrit.googlecode.com/svn/documentation/2.1/config-gerrit.html#auth

I'm not sure it matters sufficiently that it could or should cause course 
alteration, but as one who has contributed modestly to Wireshark before the 
move to gerrit, but not since then, I'd have to say that for me, the 
setup/registration/configuration/etc. has definitely impeded further 
contributions.  The new process is something that I haven't really gotten 
around to trying to figure out.  I'm not saying it's the wrong choice, but it's 
just that much more effort to even *submit* a patch, that I suspect that a lot 
of would-be contributors might find the threshold too high.  Maybe updating 
documentation could help.  Right now, if you go to the main develop page 
https://www.wireshark.org/develop.html and click on the link under code review 
site you get to https://code.wireshark.org/review/#/q/status:open,n,z which 
offers no clue at all as to how one should actually register.  I'm sure I could 
figure it out, and I'm sure many have.  It's just that I'd really just like to 
be able to contribute patches without having to do quite so much exploration.  
Maybe I'm just lazy, but it might be nice if the barrier to useful contribution 
were lowered just a bit.

Ed
___
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] gtk.h not found when compiling Wireshark 1.10.2 on Fedora 19

[Ed Beroset]

John Powell wrote:

I am trying to compile wireshark-1.10.2 on Fedora 19.

Most of my machines are currently running Fedora 19, so I know this actually 
works.

I get the following error:

checking for GTK+ - version = 2.12.0 and  3.0... no
[...]
conftest.c:34:21: fatal error: gtk/gtk.h: No such file or directory
 #include gtk/gtk.h
 ^
compilation terminated.
[...]

Ideas??

Thanks in advance!

Looks like you need to install gtk.  On Fedora 19, try yum install gtk3-devel 
and that should install the missing headers and packages.

Ed
___
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

[Wireshark-dev] setcap for CMake install under Linux

[Ed Beroset]

I've recently been trying to get used to the new system (git, gerrit, 
CMake) and noticed that unlike the autotools installation, the CMake 
installation does not seem to have support for setcap.  Is that correct, 
or am I just overlooking something?


Ed
___
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] Expert item for TCP RST flag

[Ed Beroset]

Joerg Mayer wrote:

The reason for my question is that someone had network trouble and looked
at the error/warning items. Had RST been at that level, he would have found
the problem lots of work hours earlier - the RSTs were indications of a
real problem.

So the question is: Do we allow lazy application writers to hide indications
of real problems in the network?

For what it's worth, I emphatically agree that RST abuse is is a problem (see 
RFC-3360 for still more corroboration http://tools.ietf.org/search/rfc3360).  
By flagging these as warning indications rather than chat, misbehaving 
applications will be more apparent, but at the potential risk of flooding the 
poor network engineer with irrelevant data.  However, I think that it's 
probably data that can easily be filtered out.  For that reason, I'd strongly 
endorse changing them to warning level.

Ed
___
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] Git + Gerrit: next steps

[Ed Beroset]

Gerald Combs wrote:

I'm assuming everyone has had a chance to test the Gerrit installation
at test.code.wireshark.org If you haven't, now might be a good time.


Had the chance to, perhaps, but haven't yet.  I'm not sure I saved the 
old emails about it, and http://www.wireshark.org/develop.html just 
points to a svn and a git clone repository.


For those of us who were sleeping that day in class, what's the best way 
to get up to speed on this?


Ed
___
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/BER memory oddness

[Ed Beroset]

Evan Huus wrote:


In one sense the problem is easy to trace: the oid resolution code is
returning the resolved string in an ep-allocated buffer, which is then
getting freed and subsequently used. However, I'm having trouble
tracking down exactly where this resolved oid is being persisted
between packets, since the way I've followed the trace makes it look
like the oid resolution and subsequent use are happening in the same
packet, in which case it shouldn't be freed in the middle.

I'm hoping this will be obvious to somebody who actually knows the
BER/OID code. If not I'll file a bugzilla and attach the capture.


If you're asking what I think you're asking, as names get resolved, 
they're added to a static tree called oid_root in oids.c.  The children 
of that tree are supposed to be in wmem_epan_scope().  There are three 
oid_add functions that add items to that tree.  One thing that may help 
resolving this is to set the environment variable WIRESHARK_DEBUG_MIBS 
to an integer value in the range 1 to 10.  (Higher numbers mean more 
verbose output.)


I'd like to have eliminated the ep_alloc() calls within oids.c in favor 
of the newer wmem_ calls, but didn't have the time to do that properly 
and it seemed that it might break other things.  That's why I also added 
the oid unit tests a few months ago.


If that doesn't help, let me know where I went astray and I can try again.

Ed
___
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/BER memory oddness

[Ed Beroset]

Evan Huus wrote:


The part that's confusing me is that somehow
actx-external.direct_reference seems to be getting a pointer to this
stale ep-allocated buffer, but I can't find anywhere in the call stack
that value could be set to such a stale buffer.


That would probably be dissect_ber_OBJECT_IDENTIFIER which calls 
dissect_ber_object_identifier_str(), which calls 
dissect_ber_any_oid_str() which calls oid_encoded2string.


Tracing through the ASN1 code is not very easy in my experience.  I have 
also been thinking that it would be nice to modify asn2wrs.py so that it 
would use the new style encapsulated hf variables but I haven't yet had 
time to dig into that.  Such a change would require some careful testing 
of all of the ASN1 protocols.


Ed
___
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/BER memory oddness

[Ed Beroset]

Ed Beroset wrote:

Evan Huus wrote:


The part that's confusing me is that somehow
actx-external.direct_reference seems to be getting a pointer to this
stale ep-allocated buffer, but I can't find anywhere in the call stack
that value could be set to such a stale buffer.


That would probably be dissect_ber_OBJECT_IDENTIFIER which calls
dissect_ber_object_identifier_str(), which calls
dissect_ber_any_oid_str() which calls oid_encoded2string.


As a correction, I was looking a little more at your original message 
with the trace, and I think that in your case it's more likely to be the 
call to dissect_x509af_T_extnId().  It's the line that's created by the 
DEFAULT_BODY line in asn1/x509af/x509af.cnf line 90.  If you look at the 
generated code, you'll see that it creates a call to 
dissect_ber_object_identifier_str() the last parameter of which is 
actx-external.direct_reference.


Ed
___
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 52701: /trunk/epan/ /trunk/epan/: oids_test.c

[Ed Beroset]

Joerg Mayer wrote:
On Sun, Oct 20, 2013 at 02:18:19AM +, eapa...@wireshark.org wrote:
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=52701
 
 User: eapache
 Date: 2013/10/20 02:18 AM
 
 Log:
  Don't use g_assert_cmpint, it isn't happy on Windows. g_assert is nearly as 
 good
  except it doesn't produce as nice error messages.

How about adding it to check api?

That's a good idea, since it was certainly news to me. I also looked and 
couldn't find anything in the gnome bugzilla.  The closest I could find was 
this: https://bugzilla.gnome.org/show_bug.cgi?id=516916

So for those of us without handy access to Windows (at the moment) what's the 
issue, exactly?  Are there other parts of gnome testing environment that won't 
work under Windows?

Ed


___
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

[Wireshark-dev] asn1 plugin

[Ed Beroset]

Recently, while I was working on unit tests for oids.c (see 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9294 ), I noticed a 
few lines toward the bottom of the oids.h file which say:


/* macros for legacy oid functions */
#define oid_resolv_cleanup() ((void)0)
#define subid_t guint32

It seems that the only place left that oid_resolv_cleanup() was called 
from was epan.c so I submitted a patch to eliminate both.  ( see 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9295 )


The only place that subid_t is being used is in the asn1 plugin.  When I 
looked there to see about replacing them, it seems that there are many 
functions in that plugin which duplicate functionality implemented in 
oids.c.  I seem to recall that there is at least one other thing 
somewhere in the code that exists solely to support the asn1 plugin (but 
I couldn't remember what that was).


So there are two possible ways to proceed in cleaning up.  One would be 
to eliminate the asn1 plugin entirely.  The other would be to update the 
asn1 plugin code to eliminate such code anachronisms.  I'd be willing to 
do either, but don't know if there are any available test cases for 
using the asn1 plugin.  I tried to use it once but didn't figure it out.


So would anyone object to removing it from the codebase?  And if so, can 
you provide some sample for how it's used?


Ed
___
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

[Wireshark-dev] column format strings

[Ed Beroset]

While attempting to answer a question[1] on ask.wireshark.org, I looked for the 
documentation for column format codes that may be used to customize tshark's 
output.  After a few minutes of searching, it seemed to me that the only place 
they're documented was in the source code, which seems rather user-unfriendly.  
To fix this without adding a maintenance burden, I decided to add a -G 
column-formats option to tshark which prints all the format strings and 
descriptions using mostly existing code.  I also added a description of that 
glossary to the tshark.pod file.  Also, while I was in there, I noticed that 
several of the already existing glossary options (ftypes, heuristic-decodes and 
plugins) were missing from the documentation, so I've added those, too.  Bug is 
filed with patch.[2]


[1] 
http://ask.wireshark.org/questions/26001/show-untranslated-and-translated-mac-addresses-in-different-columns-at-the-time
[2] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9272
___
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] Handling of generated dissectors

[Ed Beroset]

mmann78 wrote:

I think the issue is that not all generated dissectors can be generated on all 
platforms Wireshark supports (for varying reasons).  There were separate 
steps (outside of the Wireshark build process) to generate the PIDL dissector 
source as well as idl2wrs (GIOP) ones and I thought there were reasons why 
those separate steps weren't in the current build process.

It may be worth noting that even for tools entirely within our control 
(asn2wrs.py) we have both the dissector template and the generated dissector 
under version control.  Since the only dependency there is on Python (which is 
required anyway, to my knowledge) perhaps it's time to revisit that as well for 
all of the ASN.1 dissectors.

Ed
___
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 crashing [SOLVED]

[Ed Beroset]

Following up to my own report, I figured out the problem.  Somehow, I had two 
older versions of the libwiretap libraries lying around in my /usr/local/lib 
directory:

lrwxrwxrwx. 1 root root19 Sep 12 09:54 libwiretap.so - 
libwiretap.so.0.0.0
lrwxrwxrwx. 1 root root19 Sep 12 09:54 libwiretap.so.0 - 
libwiretap.so.0.0.3
-rwxr-xr-x. 1 root root   1492111 Sep 12 09:54 libwiretap.so.0.0.0
-rwxr-xr-x. 1 root root482721 Mar 27 06:13 libwiretap.so.0.0.2
-rwxr-xr-x. 1 root root   1428963 Apr 19 04:43 libwiretap.so.0.0.3

I deleted the two older versions and redid the logical link to point to the 
so.0.0.0 file and now all is well.  What I don't know is how those other two 
got there, or why the logical link was not set to point to the correct file.  
I'm writing this up here so that if anyone else has this problem in the future, 
the problem might get solved a little faster.

Ed
___
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

[Wireshark-dev] wireshark crashing

[Ed Beroset]

In working through the tutorial for ns3 (see 
http://www.nsnam.org/docs/release/3.14/tutorial/singlehtml/index.html ) I've 
created two simple pcap files.  When I try to look at them using wireshark, I 
get a signal 11 (segmentation fault). I've done a backtrace and the last 
function call is tvb_get_guint8 from tvbuff.c. Apparently, 
fast_ensure_contiguous() returns NULL, which then gets dereferenced.  The 
particularly strage part is that if I use the installed wireshark (that is, the 
one I just built and installed at /usr/local/bin/wireshark) I get this fault, 
but if I run it from the build directory, it works just fine.  I've configured 
with --enable-setcap-install and Im running on Fedora 19 if that matters.

I'm using the very latest trunk build:

wireshark 1.11.0 (SVN Rev 51971 from /trunk)

Copyright 1998-2013 Gerald Combs ger...@wireshark.org and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 3.8.4, with Cairo 1.12.14, with Pango 1.34.1, with
GLib 2.36.3, with libpcap, with libz 1.2.7, with POSIX capabilities (Linux),
without libnl, without SMI, without c-ares, without ADNS, with Lua 5.1, without
Python, with GnuTLS 3.1.11, with Gcrypt 1.5.3, with MIT Kerberos, with GeoIP,
with PortAudio V19-devel (built May  4 2013 13:59:07), with AirPcap.

Running on Linux 3.10.10-200.fc19.x86_64, with locale en_US.utf8, with libpcap
version 1.4.0, with libz 1.2.7, GnuTLS 3.1.11, Gcrypt 1.5.3, without AirPcap.
   Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz

Built using gcc 4.8.1 20130603 (Red Hat 4.8.1-1).

Ed


___
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] rev 50749: /trunk/ /trunk/: CMakeLists.txt

[Ed Beroset]

Joerg Mayer wrote:
On Tue, Jul 23, 2013 at 11:38:00PM +0200, Jakub Zawadzki wrote:
 I've tried googling for this error message...
 Have you tried uninstallation of VC runtimes / compilers? It's suggested by:
   
 http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/6e6c8a17-1666-42fa-9b5b-dfc21845d2f9/error-installing-windows-7-sdk-71-with-vs2008-vs2010-premium-on-win-7-32bit
   
 http://wurstkoffer.wordpress.com/2012/05/14/windows-sdk-error-while-installing-microsoft-windows-sdk-for-windows-7-and-net-framework-4/
 
 Also there is some other fix here:
   http://ctrlf5.net/?p=184

OK, removing the runtime and redist packages got me further.
I then did the permissions thing from http://ctrlf5.net/?p=184
and then the sdk install succeeded.
Now installing VS10SP1.

I'm glad that worked.  If there is a way you can encapsulate what you've 
learned/done to improve the Wireshark instructions, it will perhaps make it 
that much easier for the next person.  I tried to improve it recently, but 
apparently it's missing some steps, depending on the existing configuration of 
the Windows machine.

Ed
___
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] manual address resolution is broken

[Ed Beroset]

Anders Broman wrote:


Ed Beroset wrote:

My inclination would be for option 2 be the default, but with option
1 being available as a configuration checkbox.

Yes this sounds like the thing to do for me to, regarding address resolution there has 
been discussions of a rewrite using normal hash tables
And options not to dump NRB:s
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7380
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8349


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

So with this bug report I already knew about, that's three different 
ones with different aspects, ideas, problems and goals.  As I understand 
it, there are potentially four different (potential) sources for name 
resolution.  They are 1) a named hosts file (not necessarily the system 
hosts file) 2) whatever is behind OS gethostbyaddr() call 3) NRB in 
capture file and 4) manually entered names.


For name resolution, I'm thinking that it might be useful to allow the 
user to select both the order for resolution and whether each is used or 
not.  Just to make it even more complex, it may be desirable for the 
user to dump some but not all of the names when a new capture file is 
loaded.  For example, one might reasonably wish to dump the previous NRB 
names, but keep the manually entered ones.


There should probably also be some kind of options for saving as well. 
Specifically, it might be useful to allow the user to save a combined 
hosts file (which could include names resolved via any of the methods 
listed above) and/or save to an NRB or strip all of it out of the NRB.


Also, I think Evan Huus's comment about changing to use glib hash tables 
is a good one, and would propose to incorporate that as well.


Too complex?  Did I miss anything?  I think it's better to decide the 
behavior first and then code it, so thanks very much for your comments.


Ed
___
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

[Wireshark-dev] manual address resolution is broken

[Ed Beroset]

Today I was analyzing some capture files and wanted to use manual name 
resolution to make things a little to interpret, but I found out that manual 
name resolution no longer works.  The bug has already been reported 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8462 and a patch submitted, 
but I'm not sure that patch is the right way to resolve things since it 
basically undoes (incompletely) a deliberate change that was done some months 
ago: http://anonsvn.wireshark.org/viewvc?view=revisionrevision=45511

In my particular case, I have multiple capture files of traffic between the 
same two points and so it would actually be convenient in my case for the 
manual address resolution to persist between capture files.  On this particular 
machine, I have root privileges, and so could edit the hosts file, but we can't 
count on that for most people.  

Before I change the code, I think it would be useful to agree on desired 
behavior first.  At the moment, it's clearly broken because right after a 
manual name is entered, it's erased again by the call to 
host_name_lookup_cleanup() in epan/packet.c before the resolution is invoked 
again.  Here are three possible options:

1. have manually entered host names persist for the duration that Wireshark is 
running
2. have them persist only until another capture is begun or capture file entered
3. have a name resolution table that's stored as a persistent setting per 
configuration profile

Variations might include: for option 2 dialog that asks, if there is a 
non-empty list, whether to keep or dump the names; or for option 1, have a 
manual means to dump all manually entered host names.

My inclination would be for option 2 be the default, but with option 1 being 
available as a configuration checkbox.  What say you all?

Ed

___
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] Start and stop capture toolbar buttons?

[Ed Beroset]

Evan Huus wrote:
The *proper* (for certain values of that word) way to decide this issue is
really to do a usability study, however that is expensive/time-consuming so
unless Riverbed wants to make that investment it isn't likely to happen
with any degree of rigour.

There was a study on that very thing many years ago when the object of study 
was icons for VCRs.  (Anybody remember them?)  
http://books.google.co.uk/books?id=515hD47OVB0Clpg=PA552pg=PA553#v=onepageqf=false

They found the same confusion about the Record icon and noted that the Play 
icon had 85% recognition, but Record only 42% and noted that the Record icon 
was Often though of as 'stop', particularly if coloured red.  Connotations of 
traffic lights, 'no entry' sign or full stop.  

For that reason, I suggest we either use a different color (green? blue?) or 
(ab)use the Play icon and that we make the stop icon red if it isn't already 
by now (I'm still using SVN Rev 48628 at the moment).

Ed
___
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] proposed graph_analysis.c change

[Ed Beroset]

Jaap Keuter wrote:

On 03/23/2013 12:58 AM, Ed Beroset wrote:

In working on fixing a bug today, I made a proposed change or two
to graph_analysis.c.  See
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7418 for the
context.  The first patch was a very conservative one that simply
added a bit of code to address a problem with not being able to
resize the panes.  The second, superseding patch is a bit more
extensive in that it completely eliminates the pane_callback
function.  I thought that I would point out that I have only tested
the change on GTK+ 3 and not earlier versions, but didn't know how
far back we're intending to support.  Comments, accolades,
brickbats welcome.  :)

Ed


Well, GTK2 would be nice ;)


Ha!  OK, that's a good start.  I have verified it on Windows and two 
different Linux machines all using GTK 2.24, but don't have a good way 
to try it on other configurations.


One thing still puzzling me is the comment in the (now elided) code for 
pane_callback which says repaint the comment area because when moving 
the pane position there are times that the expose_event_comments is not 
called.  I can't see why the pane_callback routine needs to exist at 
all and things seem to work just fine with it deleted as per my patch.


Ed
___
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

[Wireshark-dev] proposed graph_analysis.c change

[Ed Beroset]

In working on fixing a bug today, I made a proposed change or two to 
graph_analysis.c.  See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7418 
for the context.  The first patch was a very conservative one that simply added 
a bit of code to address a problem with not being able to resize the panes.  
The second, superseding patch is a bit more extensive in that it completely 
eliminates the pane_callback function.  I thought that I would point out that I 
have only tested the change on GTK+ 3 and not earlier versions, but didn't know 
how far back we're intending to support.  Comments, accolades, brickbats 
welcome.  :)

Ed
___
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] buildbot failure in Wireshark (development) on Windows-XP-x86

[Ed Beroset]

-Original Message-
From: Evan Huus eapa...@gmail.com
Sent: Mar 17, 2013 12:09 PM
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark 
(development) on Windows-XP-x86

I'm still not having any luck (and I've reread
https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html to
no avail). I have two shells available: cygwin's bash and windows'
cmd.exe.

If I run cmd.exe and then run the vcvars32 script, I can build
Wireshark correctly using nmake. This seems to be working fine.

I I run cygwin then I do not have nmake available. Running the
vcvars32 script from cygwin does not seem to change this (should it)?

I cannot run test.sh from cmd.exe since cmd.exe will not interpret
unix shell scripts. I cannot run test.sh from cygwin since it requires
nmake, which I cannot get cygwin to recognize.

Here's what I did (that worked).  First, from a cmd.exe prompt, I set up the 
build environment as per 
https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html#ChSetupPrepareCommandCom
 (using the script there).  Next, I ran \cygwin\bin\bash to get a bash shell.  
Then I fixed the path (under bash) using the command export PATH=$PATH:/bin 
and then I changed to the test directory cd test. Finally, I ran the test 
script from there ./test.sh -c and everything worked.  If that works for you 
(or if it doesn't) let us know.  Since I was the last person to edit that 
portion of the developer's guide, I'd like to know your thoughts on how it 
should be edited so that this will be easier to understand.  It's definitely 
not intuitive, but I'm not sure where this test-specific information should be 
placed.  Any ideas would be welcome.

Ed
___
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] wtap_dump_file_seek() and _tell()

[Ed Beroset]

Guy Harris wrote:


On Mar 3, 2013, at 11:10 AM, Ed Beroset bero...@mindspring.com
wrote:


According to svn, version 36318 (March 2011) added, among other
things, the following lines to the wiretap/wtap-int.h file:

extern gint64 wtap_dump_file_seek(wtap_dumper *wdh, gint64 offset,
int whence, int *err); extern gint64
wtap_dump_file_tell(wtap_dumper *wdh);

However, unlike most of the corresponding functions which are
implemented in wiretap/file_access.c these two have no
implementations.

[...]

but these places in the code are doing it anyway.  How should we
best resolve this? Should I implement the functions?


Might as well.  They'd belong with the others in file_access.c, and
should fail if wdh-compressed is set.  (We already have
wtap_dump_can_compress(), which checks whether writing the file
format requires a seek, so no Wireshark code should be trying to
write out a compressed file in any of those formats.)

We should probably define a new WTAP_ERR_CANT_SEEK_COMPRESSED value
and return it as the error value if a seek is attempted on a
compressed stream.

file_tell() should probably also have an int *err argument, as
ftell() can fail.


Done, and submitted as a patch to Bug 8416: 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8416.  I haven't 
compiled this under Windows yet, but will later today.


Ed
___
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] wtap_dump_file_seek() and _tell()

[Ed Beroset]

Ed Beroset wrote:


Done, and submitted as a patch to Bug 8416:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8416.  I haven't
compiled this under Windows yet, but will later today.


OK, now I've updated the patch to work correctly under Windows as well.

Ed
___
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

[Wireshark-dev] wtap_dump_file_seek() and _tell()

[Ed Beroset]

According to svn, version 36318 (March 2011) added, among other things, 
the following lines to the wiretap/wtap-int.h file:


extern gint64 wtap_dump_file_seek(wtap_dumper *wdh, gint64 offset, int 
whence, int *err);

extern gint64 wtap_dump_file_tell(wtap_dumper *wdh);

However, unlike most of the corresponding functions which are 
implemented in wiretap/file_access.c these two have no implementations. 
 In 18 places within the code involving seven files (5view.c, k12,c, 
lanalyzer.c, netmon.c, netscaler.c, netxray.c, visual.c) either an ftell 
or fseek is used which does an implicit conversion from WFILE_T to 
struct FILE * which is an incompatibility with C++.  I could have added 
casts to each location, but it seems that the neater way to do this 
would be to actually implement these function.  I understand that seek() 
and tell() won't work every time (e.g. pipes or stdin), but these places 
in the code are doing it anyway.  How should we best resolve this? 
Should I implement the functions?


Ed
___
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

[Wireshark-dev] Bug 8416 - remove C++ incompatibilities from packet-pw-atm.c

[Ed Beroset]

As mentioned in the subject line, I've added Bug 8416 - remove C++ 
incompatibilities from packet-pw-atm.c with the associated patch.  Doing a 
little forensic work on the C++ incompatibilities still present in the code 
base, here are the types of issues of the 4919 c++-incompat lines in a 
compilation of the latest source using gcc on a Linux box (Fedora 17) (before 
this patch):

typecount   percent
implicit_casts  401381.58%
keyword_use 634 12.89%
enum_conversion 197 4.00%
uninit_const7   0.14%
field_typedef   5   0.10%
special_operator3   0.06%
incompat_ptr2   0.04%
other   58  1.18%

It's clear that the vast majority of these (over 98%) are of only three 
different kinds which are mostly trivial fixes.  I do want to point out, 
however, that the way I chose to resolve the enum_conversion complaint was to 
change the type of one member of a struct from an enum type to an int.  The 
longer version of the rationale is in the bug report.  If we find this kind of 
patch acceptable, and desirable, I'll do more.  

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

Ed



___
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] Bug 8416 - remove C++ incompatibilities from packet-pw-atm.c

[Ed Beroset]

Jaap Keuter jaap.keu...@xs4all.nl


What I would like to see is the abolishment of the pwc_packet_properties_t type
altogether. This is _not_ an enum.

I agree, and have come across another such enum abuse instance that may be 
harder to address. Specifically, in the header file gmessages.h there is a 
similar typedef enum called GLogLevelFlags which is also intended to provide 
names for bitflags rather than actually enumerate.  This construct is used a 
number of places in the Wireshark code (such as line 3169 of 
plugins/asn1/packet-asn1.c).  Adding a cast quiets the compiler, but is there a 
better way that doesn't require rewriting glib-2.0?

mylogh = g_log_set_handler (NULL, GLogLevelFlags(G_LOG_LEVEL_MASK | 
G_LOG_FLAG_FATAL
| G_LOG_FLAG_RECURSION), 
my_log_handler, NULL);

Ed
___
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] Win7 - 64 bit build

[Ed Beroset]

Alex Lindberg wrote:

One additional item.  When building an NSIS install package on a Win7
64 bit system, the NSIS installs to C:\Program Files (x86)\NSIS.
In config.nmake, the makensis.exe files uses C:\Program Files, thus
failing.

I did the following: Added: PROGRAM_FILES_NSIS=%%ProgramFiles(x86)%%
Changed: MAKENSIS=$(PROGRAM_FILES)\NSIS\makensis.exe To:
MAKENSIS=$(PROGRAM_FILES_NSIS)\NSIS\makensis.exe

Worked like a charm.  I would guess that there are more elegant
solutions to the problem that would detect the path and make the
correct choice.  I will leave that to folks smarter than me.


I have made a patch for the Developer Guide to better describe how to 
build either 32-bit or 64-bit versions of the code and also made a note 
about this issue.  I think you must have installed the 64-bit version of 
NSIS rather than the 32-bit version 2.46 which is linked to in the 
instructions.  Can you please check that?


The patch is attached to bug 8386 (see 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8386 ) which also 
describes the changes made.


Ed
___
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] Idle Thought - Compiling with C++

[Ed Beroset]

Evan Huus wrote:


If we do plan to migrate we will definitely be using only C-style
constructs to start. It will be enough work transitioning compilers
without changing language constructs at the same time.


I've created a patch which implements one small part of this and have 
attached it to https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8342


So far, I only changed the code relating to a single dissector that I 
submitted, but the work is easy and almost mechanical, so I can do 
additional code changes if this patch seems acceptable.  We can nibble 
away at it over time and get it done.


Ed
___
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 the default layout

[Ed Beroset]

Evan Huus wrote:

I've been playing with various layouts for the main dissection
interface and I've found one that works better (for me) than the
default. It leaves the packet list on top, but puts the details and
bytes panes side by side on the bottom (details on the left, bytes on
the right). This is what you get by selecting the second layout choice
in the layout preferences.


I have my own computer set up to use the same preference, but I tend to 
use this on a big laptop screen or big monitor for specific kinds of 
traffic.



To me this has two main advantages over the existing default:

- It makes better use of horizontal and vertical space, especially
since short-and-wide monitors are becoming more and more common.

- It makes a better conceptual distinction between the multi-packet
summary and the single-packet details, which are now neatly grouped to
the top and bottom.

Thoughts?


I agree that it's a better default, primarily for the first reason.  I 
would also strongly support changing the default because those who are 
already experienced with Wireshark have probably already chosen their 
preference and those new to Wireshark would probably benefit from a 
default that more closely matches common equipment these days.


Ed
___
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] Google Summer of Code 2013

[Ed Beroset]

Guy Harris wrote:
What is the user to do when informed that a new version exists?  
[...]
(I.e., different OSes do this differently, and perhaps we should handle this 
differently on different OSes.)

VLC, which runs on Windows, Linux and OSX (I think) relies on separate package 
handlers under Linux, but offers the ability to download and install the new 
version under Windows and does that without running an annoying and wasteful 
background service that always runs and whose sole purpose is looking for 
updates.  

Ed
___
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] Idle Thought - Compiling with C++

[Ed Beroset]

Evan Huus wrote:

On Mon, Feb 11, 2013 at 1:47 PM, Guy Harris g...@alum.mit.edu
wrote:



Note all the lines flagged with [-Wc++-compat]; those are for
code that's valid C but not valid C++ and that would have to be
fixed in order to compile with a C++ compiler (unless there's a
let valid C code that *could* be handled as C++ code through
option to all C++ compilers we'd be likely to use).


As per Jakub, we have about 7k of those at the moment. The vast
majority appear to be missing casts from void pointers, which are at
least not difficult to fix (especially since I think many are in
generated code).


I looked at some of those from a dissector I wrote, and I'm pretty sure
I can rewrite to avoid most or all of those, and can use the C-style 
cast such as r = (guint *)ptr; which will also work with C compilers, 
or I could use the C++ style: r = static_castguint *(ptr);  For 
those not familiar with the new style casts in C++, here's a quick 
pointer: http://www.cplusplus.com/doc/tutorial/typecasting/


Given that we haven't made the transition yet, I'm inclined to use the 
C-style casts for now.  Anybody have a differing opinion?


Ed
___
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] Idle Thought - Compiling with C++

[Ed Beroset]

Donald White wrote:

That said, I have some experience with C to C++ transitions.  Twice in
my career, the team I was with was given the job of maintaining legacy
products written in C (several 100K lines of code) to maintain and
enhance.  In both cases, our first step was to recompile with a C++
compiler.  This was done as a quick and intense effort without
introducing any C++ language features.  We would just get the code to
compile, link and pass its regression tests.  Only later did we replace
#defines with consts, macros with inline functions and such.  I judged
these efforts as being very beneficial in improving code quality.


This is a reasonable approach for improving code quality.  In an open 
source project like Wireshark, I think the challenge would be in 
specifying which C++ features/constructs would NOT be used. Having 
extensive experience with both C++ and C, I'd say that some of the most 
useful features in C++ didn't even exist in 1991 when that Old dogs, 
new tricks article was written.  Specifically, I mean templates and the 
Standard Template Library (STL).  That said, however and at the risk of 
stating the obvious, code written in C++ looks a lot different than C 
written in C++.


For example, to me, the tvbuff.c and value_string.c files cry out for 
reimplementation as C++ classes, but to actually do such a 
reimplementation would very literally be a change to the core of 
Wireshark. If we were to use a C++ compiler as simply an enhanced C 
compiler, we'd have to figure out how to prevent submissions from 
including C++ constructs no approved by Wireshark coding guidelines.


Ed
___
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] Having issues with wireshark dissector installation

[Ed Beroset]

-Original Message-
From: Graham Bloice graham.blo...@trihedral.com
Sent: Jan 30, 2013 12:41 PM
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Having issues with wireshark dissector
installation

On 30 January 2013 17:10, Arshad heyars...@gmail.com wrote:

 Hello,

 I am a newbie to programming. I am having issues with compiling the a
 basic dissector that I created as per the developer guide. I have the code
 but I am not able to compile it. I tried the steps to build it, but having
 issues with compiling it. I tried from WIndows to compile it and followed
 the step by step guide:
 http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html But I
 am getting error installing the SDK and it shows installation failed.

 A problem occurred while installing selected Windows SDK components.

 Installation of the Microsoft Windows SDK for Windows 7 product has
 reported the following error: Please refer to
 Samples\Setup\HTML\ConfigDetails.htm document for further information.

 Can I get some help in fixing it.


I'm guessing you are using VS 2010 Express.  If so, you only need the SDK
for 64 bit versions of wireshark.  Unless you really need a 64 bit version,
don't install the SDK.

For what it's worth, I use VS 2010 Express and have it set up for either 64- or 
32-bit compilation.  To make it simple, I use the following batch file:

@echo off
if %1 ==  goto x86
if /i %1 == x86   goto x86
if /i %1 == x64  goto x64
goto usage

:usage
echo Error in script usage. The correct usage is:
echo %0 [option]
echo where [option] is: x86 ^| x64 
echo:
echo For example:
echo %0 x86
goto :eof

:x64
set WIRESHARK_TARGET_PLATFORM=win64
call c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd /Release /x64
goto :eof

:x86
set WIRESHARK_TARGET_PLATFORM=win32
call c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd /Release /x86
goto :eof

Ed
___
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] Win7 - 64 bit build

[Ed Beroset]

Alex Lindberg wrote:

I was having issues compiling a x64 build of Wireshark on a Win7x64 bit PC.  I 
followed the instructions to the letter as referenced in the Win build page:

 http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html

All to no avail.  After reinstalling several times and googling for most of the 
day, the answer was found.

The referenced sugested setup batch file to build x64 Wireshark is:

@echo off
echo Adding things to the path...
set PATH=%PATH%;.
set PATH=%PATH%;c:\cygwin\bin echo Setting up Visual Studio environment...
call c:\Program Files\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat amd64 
title Command Prompt (VC++ 2010)
The issue was that the vcvars32.bat amd64 branch is broken.  The script is 
looking for files that don't exist.

To fix this the line 'call c:\windows... line should now read:

call c:\Program Files\Microsoft SDKs\Windows\v7.1\BIn\SetEnv.cmd /x64

The /x64 can be changed to set any number of different compile options.


Thanks for reporting back.  I have been intending to redo the build 
instructions for a while and this gives me both the confirmation that 
the existing instructions really need revision and that the edits that I 
have in mind will work.  Now all I need is to actually get around to 
doing the work!  :) Thanks!


Ed
___
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] I need help with Capture Filter

[Ed Beroset]

Chuck H Wilson wrote:

As the subject line states: I need help getting WireShark's capture
filter to work.

I have put together details of the problem(s) I'm having, but in keeping
with the request of keeping the E-mail file size small, and not sending
more information that would be useful for now, I'm just providing the
WireShark version that I'm running, the platform I'm running on, and a
brief description of my problem.


To cover the simplest case first, you're aware that the capture filter 
and display filter syntaxes are different, right?  For capture filter 
syntax, see http://wiki.wireshark.org/CaptureFilters


Ed

___
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] should editcap support -H and -W?

[Ed Beroset]

Jeff Morriss wrote:

I noticed today (in fighting to get name resolution blocks into my
PCAPNG files) that editcap does not (contrary to the man page) support
the -H and -W options.  Should it?

I coded up a patch today but realized that it would require linking
editcap against libwireshark.  Do we care?

The other aspect is that adding name resolution blocks can already be
done with tshark (in which the -H and -W options do work).


I think it makes sense to support -H and -W in editcap, especially since 
the man page says it already does.


Ed
___
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

[Wireshark-dev] tshark summary lines

[Ed Beroset]

Someone has asked a question on the wiki
http://ask.wireshark.org/questions/14581/how-to-use-tshark-to-output-a-tcpdump-into-text-formatted-file

Which asks if tshark can emit both the summary lines AND the details 
from -V.  There is currently no way to do that, but it seemed to me like 
a reasonable question.  Should it be added?


If so, I was thinking the combination of -V -P might be a reasonable way 
to do that.  What say you all?


Ed
___
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] tshark summary lines

[Ed Beroset]

mman...@netscape.net wrote:



Isn't this bug 2892?  (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2892)


Yes, it appears to be the same.


Or 4314? (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4314)


That one is different and talks about the sizing of the Info field when 
printing from Wireshark.


Ed




-Original Message-
From: Ed Beroset bero...@mindspring.com
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Tue, Oct 2, 2012 11:25 am
Subject: [Wireshark-dev] tshark summary lines


Someone has asked a question on the wiki
http://ask.wireshark.org/questions/14581/how-to-use-tshark-to-output-a-tcpdump-into-text-formatted-file

Which asks if tshark can emit both the summary lines AND the details
from -V.  There is currently no way to do that, but it seemed to me like
a reasonable question.  Should it be added?

If so, I was thinking the combination of -V -P might be a reasonable way
to do that.  What say you all?

Ed
___
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] tshark summary lines

[Ed Beroset]

Christopher Maynard wrote:


They are all different:
For bug 2892, if you use -T fields, there's no way to have the info column
information also displayed.  Support would have to be added to be able to
specify something like e.g., -e col.info


I think you're right.  It would probably be relatively easy to address 
that one at the same time.



For bug 4314, I interpreted this as the user performing the following steps in
Wireshark: File - Print - Output to file: wireshark.out, but then
wireshark.out cut off the long Info column unless a custom column was added.
But now I just tried that and it seemed to work fine, but I don't know how long
the info line must be for this to occur.  So either this bug is already fixed
or more information is needed in order to be able to reproduce it.  (I thought
*maybe* this was the same as bug 7543, but adding a custom column matter for
bug 7543, so I don't think they're the same either.)


I think it's already fixed.  I just tried it with a line that had an 
info line that's 516 characters line and it seemed to have no problem, 
even when I put another column behind it.



So this new one from ask that Ed mentioned here is about printing both the
entire summary line, which you get with -P, as well as the packet details,
which you get with -V.  Currently if you specify both -P and -V, you get the
packets details only, but no summary line.  I'd say this is a reasonable
request and that this should probably also work with -O protocols as well
(any others?).  But best to file an enhancement bug report for it.


Done.  It's now input as Bug 7782.  I'll see if I can create a patch 
some time this week.


Ed

___
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] tshark summary lines

[Ed Beroset]

Christopher Maynard wrote:

Ed Beroset beroset@... writes:


They are all different:
For bug 2892, if you use -T fields, there's no way to have the info column
information also displayed.  Support would have to be added to be able to
specify something like e.g., -e col.info


I think you're right.  It would probably be relatively easy to address
that one at the same time.


Well, if you're game for adding -e col.info support (or whatever sensible
naming convention you choose), then how about adding support for all of the
other built-in columns too?  Can 'o worms, eh? :)


Ha!  Yes, indeed.  I'll take a look, anyway.

Ed
___
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] Transmission Latency Calculation

[Ed Beroset]

Christopher Maynard wrote:

Herb Falk herb@... Herb@... writes:


I am creating a dissector that needs to be able to calculate the transmission

latency of a packet.


The protocol being dissected has the timestamp of the “transmission”, I need

to be able to gain access to the time of capture of wireshark in order to
calculate the difference.  Anybody know an example/documentation pointer?


I haven't done that exactly, but have used the tcp ACK round trip time 
to get some indication of latency.  I then used the statistical package 
R to do further analysis.  To get that information into text format for 
the analysis, I used tshark:


tshark -r sample.pcap -Tfields -eframe.number -eip.src -etcp.srcport 
-eip.dst -etcp.dstport -etcp.analysis.ack_rtt  rtt.txt



I believe pinfo-fd-abs_ts has what you're looking for.  But you'll need the
clocks of the transmitting and capturing devices to be synchronized in order to
obtain any meaningful latency calculations.


That's true.  A possibly useful discussion on this issue (with relevance 
particularly to NTP) is here: http://www.eecis.udel.edu/~mills/stamp.html


Ed
___
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] RFD: Creating subdirectories in epan/dissectors/

[Ed Beroset]

Evan Huus wrote:

On Thu, Aug 30, 2012 at 1:46 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:



Unwieldy how?  Except for having to know not to do vi
epan/dissectors/tabtab (for fear of too many pages of output) I don't
find the directory unwieldy.


That's part of it - I still do that accidentally on occasion. The
other part of it is just that the number of files is overwhelming.
It's not necessarily inefficient for the computer, but it is certainly
inefficient for a mental model of the source structure, and it feels
daunting, which is something we want to avoid in order to encourage
new developers. I know when I checked out the source tree for the very
first time I looked at the size of it and had very much a where do I
start?! moment.


I'm relatively new to Wireshark development (only a few years), so I 
remember that moment too.  However, I'm not sure that organizing things 
into subdirectories would really help that much.  What you've identified 
though, is a real thing that might be addressed, which is that 
regardless of how the files are physically organized, it would be useful 
to structure things to aid human beings who look at and work with the 
source files.  Doxygen, which is already lightly supported, could help 
there without a lot of additional effort.  I think that might be a 
better way to approach this problem than rearranging the source code 
directory structure.  What do you think?


Ed
___
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] small query

[Ed Beroset]

Krishnamurthy Mayya wrote:

Hi all,
   If i am writing a new file, in order for it to be compiled do i have to
include the file-name in any existing directory/files??
   the location of the new file is epan/dissectors.


Generally, yes.  The easiest way to find out where in a well-established 
project like Wireshark is to identify some similar file, such as 
packet-spice.c and use grep to find out where that file is mentioned. 
When I do that, I find that packet-spice.c is mentioned in 
epan/CMakeLists.txt and epan/dissectors/Makefile.common which suggests 
where your file name might be added.


Ed
___
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

[Wireshark-dev] updating the developer's guide

[Ed Beroset]

I recently changed laptop computers (running Windows) and had to 
reconfigure everything to be able to once again rebuild Wireshark. 
Since it had been a while, I referred to the developer's guide, but that 
didn't quite fit what I wanted to do, which was to configure so that I 
could build with either 32- or 64-bit versions using VC++ 2010 Express 
Edition.


I thought I remembered that we had said that that version was going to 
become the new default, but the documentation only describes the 2008 EE 
version (and 32-bit only).  If my recollection is correct, I'd like to 
update the docbook source step-by-step instructions for Quick Start to 
accurately describe the new version.  Any thoughts on that?


Ed
___
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

[Wireshark-dev] privilege separation

[Ed Beroset]

On the Wireshark wish list is Add privilege separation for POSIX environments 
(in progress).  What's left to do on that one?  Apply the privilege during a 
make install?

Ed
___
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

[Ed Beroset]

krishna hegde wrote:

I am using the Visual studio 2010 for the building Wire shark Source . I
understand that Visual studio already has nmake utitiy.

I am getting the error as

Error 1 error U1065: invalid option '-' C:\Wireshark\NMAKE wireshark Error
2 error MSB3073: The command nmake -f Makefile.nmake distclean exited
with code 2. C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets 33 6 wire shark

I tried using the nmake -f Makefile.nmake verify_tools

Still I am getting the same error Error 1 error U1065: invalid option '-'

This has actually come up before.  The problem then was that the hyphen 
character had actually been cut-and-pasted from another document which didn't 
actually use the ASCII hyphen character (ASCII code 0x2d).  Perhaps that's the 
problem here as well.  

Ed
___
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] buildbot failure in Wireshark (development) on Windows-XP-x86

[Ed Beroset]

Graham Bloice wrote:
  Most likely it has a problem with the / instead of \ in uil/util.obj.
  Does someone have an idea how to resolve this?
 
 util.obj is being produced in the top level root directory, but the linker
is
 looking for it in ui\.  I'm looking at the makefile now.
 

Hmm.  I think this would need an explicit build rule.  As it stands, the
compiler is told to compile ui/util.c when in the top level directory, so
that's where the object file is placed.  The linker is told to look for
ui/util.obj and complains.

This problem is not unique to the Windows build.  I just attempted to build 
this version under Linux and got this:

Making all in .
make[2]: Entering directory `/home/ejb/tools/wireshark'
make[2]: *** No rule to make target `util.c', needed by `wireshark-util.o'.  
Stop.

I'm also looking into this (on the Linux end) so let's make sure we continue to 
communicate on this issue to assure good coordination.

Ed
___
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] buildbot failure in Wireshark (development) on Windows-XP-x86

[Ed Beroset]

Jeff Morriss wrote:
I've been a little uneasy with the fact that there's no makefile in ui/ 
.  It seems like putting source files in there but no makefile is asking 
for trouble.  But I haven't thought about it much.

We have the same issue in ui/cli.

Ed
___
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] buildbot failure in Wireshark (development) on Windows-XP-x86

[Ed Beroset]

Jeff Morriss wrote:

Joerg Mayer wrote:

On Fri, Feb 17, 2012 at 09:59:22AM -0500, Jeff Morriss wrote:

Ed Beroset wrote:

Graham Bloice wrote:

Most likely it has a problem with the / instead of \ in
uil/util.obj.
Does someone have an idea how to resolve this?

util.obj is being produced in the top level root directory, but
the linker

is

looking for it in ui\. I'm looking at the makefile now.


Hmm. I think this would need an explicit build rule. As it stands, the
compiler is told to compile ui/util.c when in the top level
directory, so
that's where the object file is placed. The linker is told to look for
ui/util.obj and complains.

This problem is not unique to the Windows build. I just attempted to
build this version under Linux and got this:

Making all in .
make[2]: Entering directory `/home/ejb/tools/wireshark'
make[2]: *** No rule to make target `util.c', needed by
`wireshark-util.o'. Stop.

Are you using cmake (it doesn't look like it)? It builds fine for me
using auto*; I even just did a make clean all and it worked out.


I tested using cmake, so I'd like to know more about the specific
failure.


Ed sent me an email off-list [not sure if that part was intentional or
not] and said he got it working now--there was probably something
residual messing up his build.


No, I had intended to send it to the list.  Thanks for clearing that up.

Ed
___
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] buildbot failure in Wireshark (development) on Visual-Studio-Code-Analysis

[Ed Beroset]

Jeorg, 

eax.c(32) : fatal error C1083: Cannot open include file: 'gcrypt.h': No such 
file or directory

Ideas anyone?

I see you already found and fixed the problem in version 40502.  I apologize 
for accidentally deleting that change from the patch I submitted, Joerg.  
Thanks for doing that.  

Also, there's a problem introduced by commenting out some of the code.  You 
noted that you made fixes for these:

[ 64%] Building C object epan/CMakeFiles/epan.dir/dissectors/packet-c1222.c.o   
 
../../asn1/c1222/packet-c1222-template.c: In function ‘dissect_epsem’:  
 
../../asn1/c1222/packet-c1222-template.c:860:15: error: variable ‘ft’ set but 
not used [-Werror=unused-but-set-variable]

[  5%] Building C object epan/CMakeFiles/epan.dir/dissectors/packet-c1222.c.o
../../asn1/c1222/packet-c1222-template.c:103:19: error: ‘c1222_flags’ defined 
but not used [-Werror=unused-variable]

and I see the code you've commented out.  However, that also eliminates some 
functionality.  Specifically that causes autogenerated code to parse the flags. 
 With the code intact, we get this (an extract from tshark):

user-information
C12.22 EPSEM Flags: 0x88, C12.22 Reserved Flag, C12.22 Security 
Mode Flags: Ciphertext with authentication, C12.22 Response Control Flags: 
Always respond
1...  = C12.22 Reserved Flag: True
.0..  = C12.22 Recovery Flag: False
..0.  = C12.22 Proxy Service Used Flag: False
...0  = C12.22 ED Class Flag: False
 10.. = C12.22 Security Mode Flags: Ciphertext with 
authentication (0x02)
 ..00 = C12.22 Response Control Flags: Always respond (0x00)
C12.22 EPSEM: OK
C12.22 Response: OK (0x00)

Without the code, we get this:

user-information
C12.22 EPSEM: OK
C12.22 Response: OK (0x00)

I don't seem to get the same warning using MSC2008EE here.  There must be some 
way to eliminate the warning without sacrificing the feature.  Can you tell me 
how you got those warnings?  I may be able to help.

Ed
___
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] Problem with tools/win-setup.sh

[Ed Beroset]

Ed Beroset wrote:

Weir, Alan wrote:

Hi Ed,

When running nmake -f makefile.nmake verify_tools the message:

ERROR: The contents of C:\wireshark-win32-libs\current_tag.txt is
(unknown).
It should be 2011-06-27.

Is emitted even though the file exists and contains the correct text.


Ah, good clue. I'm guessing you have some other cat program in the
path. To check this, from the Windows command prompt (not the bash
shell) do this:

echo which cat  foo.sh
bash foo.sh

This should return something like
/usr/bin/cat

for the first line and then your complete path. If instead it returns
something like
/cygdrive/c/Program Files/PackageIForgotIEverInstalled/cat

Then you've found your problem. Either rename the other cat or fiddle
with the path to point to the cygwin version of cat first. If that
doesn't do it, let us know and we'll dig a little deeper.


For anyone else who might encounter this, I just got an email reply from 
Alan Weir confirming that this was indeed the problem and the fix.


Ed
___
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] Problem with tools/win-setup.sh

[Ed Beroset]

Bill Meier wrote:
So:

We should add 'cat' to the list of tools checked.

I have been thinking about this.  We could either do that or, perhaps somewhat 
perversely, we could use an alternative based on an already required 
application such as Perl or Python.  Also, we don't necessarily care that it's 
only a cygwin cat, but that it's a functional cat that will work with long 
Windows names.  

What we do actually care about is that which is the cygwin version.  If it 
isn't, uses such as this will certainly fail:

APP_PATH=`cygpath --unix $APP`
if [ -x $APP_PATH -a ! -d $APP_PATH ] ; then
APP_LOC=$APP_PATH
else
APP_LOC=`which $APP_PATH 2 /dev/null`
fi


It also sounds like:
We should require certain tools (bash, bison,...,sed,,...)
(in addition to the already checked /usr/bin/find) should
be in /usr/bin.

Does this seem too restrictive ?

Yes, but I have an idea.  We could leave the verify_tools target as it is and 
add a troubleshoot_tools target which could report the locations of all of 
these and perhaps make some suggestions about what might be wrong, including, 
if found, that a version of bison being used was not the right one.  That way, 
we could continue to improve the Windows build experience without arbitrarily 
limiting options or unduly interfering with currently working systems.

Ideally, we'd have a usable autotools for Windows, but that does not exist.

ISTR previous cases where something other with the same
name as a cygwin exec (e.g. sed) was found because of the
way PATH was set up.

Yes, and I have personally had a problem in which an old version of unzip was 
interfering, which I reported here last year.  
http://www.wireshark.org/lists/wireshark-dev/201002/msg2.html

Ed
___
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] Problem with tools/win-setup.sh

[Ed Beroset]

Weir, Alan wrote:
The log indicates that the removal should be benign as it eliminated a warning 
but in my case (and others based on googling the error message) it prevents 
the cycwin path from being constructed correctly.

I'm not a cycwin expert - anyone have any insight?

Could be, but I'd need a bit more information.  For instance which version of 
cygwin are you using and what precisely is the error?

Ed
___
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] happy birthday, bug 5531!

[Ed Beroset]

Joerg Mayer wrote:


I have a few small questions that came up during looking at the patch
(not all of them relevant to this patch!):
- why is eax.[ch] in epan instead of epan/crypt/?
- why do we have files named crypt/crypt-aes.c instead of crypt/aes.c?
- is eax.c added to CMakeLists.txt as well?


For what it's worth, I've addressed these and a few other things in an 
updated patch.  Thanks for the feedback!


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

Comments:
This patch differs from the previous in a couple of mostly minor ways, 
mostly

inspired by comment #20.  Changes are:
1. Moved eax.c and eax.h to crypt
2. fixed minor bug involving padding.  In the cases where the code 
should have

added exactly one pad byte, it was instead adding seventeen pad bytes.  
3. added eax to CMakeLists.txt
4. slightly simplified header canonization code
5. retested and refuzzed

Ed
___
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] happy birthday, bug 5531!

[Ed Beroset]

Joerg Mayer wrote:

I looked at this patch a bit but as I don't know anything about BER I can't
comment on much.

I have a few small questions that came up during looking at the patch
(not all of them relevant to this patch!):
- why is eax.[ch] in epan instead of epan/crypt/?


It could be moved to epan/crypt, and that may well be appropriate.


- why do we have files named crypt/crypt-aes.c instead of crypt/aes.c?


Historic.  Back in 2007, there was no epan/crypt and crypt-aes.c was in 
in epan.  In 2007, epan/crypt was created and code moved but not renamed.



- is eax.c added to CMakeLists.txt as well?


No, it isn't.  A quick check shows a number of files in epan are not.

$for foo in *.c ; do grep -q $foo CMakeLists.txt ; if [ $? -eq 1 ]; 
then echo $foo; fi ; done

diam_dict.c
dtd_grammar.c
dtd_parse.c
dtd_preparse.c
eax.c
exntest.c
inet_aton.c
radius_dict.c
reassemble_test.c
tpg.c
tvbtest.c
uat_load.c

Keeping three different build systems (CMake, make, nmake) synchronized 
is perhaps in need of some additional automation.  Should we use 
Makefile.common in CMake to reduce this problem?  A little more checking:


$ for foo in *.c ; do grep -q $foo Makefile.common ; if [ $? -eq 1 ]; 
then echo $foo; fi ; done

asm_utils.c
exntest.c
inet_aton.c
reassemble_test.c
tpg.c
tvbtest.c

I can see that the various test programs shouldn't be there, and it 
appears that the configure script handles inet_aton.c, but it appears 
that tpg.c isn't in either.  Is it used at all?



- is this in any way related to RFC 6142?


Not directly, no.  That RFC describes one rather idiosyncratic way to 
implement the same C12.22 standard over TCP/IP and UDP/IP.  I know of no 
real implementation that follows it, but if one ever did, there would be 
no problem with this dissector on such a stream.  (If anybody reading 
this has implemented such a thing, please send me a sample capture or 
add it to the sample captures so I can verify this.)



- I don't know anything about BER encoding, but is the existence of the
   function get_ber_len_size owed to missing infrastructure in Wireshark?


Good question, but I think it's more attributable to the particular 
usage of BER and cryptography to secure this particular protocol.  I 
created three functions (get_ber_len_size, get_ber_len_raw and 
encode_ber_len) which might have been put into packet-ber.c but I 
decided that these functions are unlikely to be generally useful.  This 
is because these functions are to assist in constructing BER encodings 
in memory (for processing with cryptography) rather than the more usual 
direction of disassembling BER encodings, which is what packet-ber.c 
does.  Where the latter kinds of functions are needed, the existing 
functions in packet-ber.c were used without problems, so I don't think 
there's missing infrastructure in Wireshark.


Ed
___
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] happy birthday, bug 5531!

[Ed Beroset]

Chris Maynard wrote:

Ed Berosetberoset@...  writes:


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

It's been a year since it was originally submitted.  As always, if there's

anything I can do to help get this

into the main code, please let me know.  I know a number of people that are

waiting for it.  And thanks again for

a mighty handy tool!

Ed


I know it can be frustrating when waiting for something so thanks for your
continued patience.  If it makes you feel any better, some bugs are over 6 years
old.  :)


Yes, it's a bit frustrating, but I also certainly understand.  I wish I 
had more time to spend on this, too.  I have a half-finished 
documentation section on how to write ASN.1 based dissectors that I'm 
hoping to finish within the next few weeks and I've been looking over 
Bill's rewritten tvb_ stuff to see if I can help explain that, too. 
First I'd have to understand it...


Ed
___
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

[Wireshark-dev] happy birthday, bug 5531!

[Ed Beroset]

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

It's been a year since it was originally submitted.  As always, if there's 
anything I can do to help get this into the main code, please let me know.  I 
know a number of people that are waiting for it.  And thanks again for a mighty 
handy tool!

Ed
___
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

[Wireshark-dev] how to fix Wiki login problem

[Ed Beroset]

Sorry if this is the wrong place to ask, but the right place to ask is not 
obvious to me.  I've done a number of edits on the Wireshark wiki (most 
recently in October) and intended to do a few more today, but found that my 
account won't work any longer and the various password recovery options do not 
appear to be working for me either.  

Any ideas as to how to address this problem?

Ed
___
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] for error on verify tools installed for Wireshark development

[Ed Beroset]

Song, Yuyin wrote:

I am new to Whireshark development.  I have installed all tools and Wireshark 
development version. When I verify all tools installed using command nmake –f 
Makefile.nmake verify_tools.
I got the error message namke: fatal error U1073: don't konw hpw to make '-f' 
.  What is the problem? how to fix it? Please advise. 

I suspect that the problem could be that although they look the same, you're 
entering the unicode character for '-'  (hex value e28093) rather than the 
ASCII character '-' (hex value 2d).  I was able to test this hypothesis on my 
machine by entering a long dash in Word and then cutting and pasting that 
into the command you mention.  That's the only way I can think of to get the 
error you describe.  I hope that helps.

Ed
___
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 1.6.4 is now available

[Ed Beroset]

Gerald Combs wrote:

I'm proud to announce the release of Wireshark 1.6.4.

Good news!  Is there any chance that the next version can include the patch for 
C12.22?  It's coming up on a year since it was originally submitted.  If there 
are any remaining impediments, please let me know.  Thanks!

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

Ed
___
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

[Wireshark-dev] updated developer guide to show proper use of ENC_BIG_ENDIAN

[Ed Beroset]

I've entered a bug and attached a patch to both fix a minor build issue (typo 
in makefile) and to update the Developer Guide to show the correct use of 
ENC_BIG_ENDIAN rather than FALSE in the final argument of proto_tree_add_item() 
calls. It might be worth reviewing further to see if some of those calls in the 
documentation might be changed to proto_tree_add_uint() or similar.  It would 
be a shame if outdated documentation caused new dissector writers to undo some 
of the work that has been accomplished lately.

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

Ed
___
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] working with header data

[Ed Beroset]

Guy Harris wrote:


crypto.  If that can be done in a different fashion, as per my
earlier suggestion, that code shouldn't even exist.


I implemented your suggestion over the weekend and tested it today on 
multiple platforms.  It has less monkeying around with the packet memory 
at the expense of more monkeying around within the ASN.1 portion.


Thanks for the help!  I've resubmitted the patch and attached it to 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5531



The code that actually does the crypto is in dissect_epsem(), which
should only be called after all the header fields have been
dissected.


I'm still unclear as to when that is or how one can tell.  The function 
in question was sometimes called with a pointer to the whole unparsed 
packet, and sometimes with a pointer to the parsed User-information 
section.  I still don't know why.


I've also added doxygen-style documentation on most of the functions in 
the C12.22 dissector I created.  I'd like to continue adding to the 
doxygen support as well, since it could be a very valuable tool with the 
proper care and feeding.


Ed
___
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

[Wireshark-dev] working with header data

[Ed Beroset]

I've written a dissector for a protocol (ANSI C12.22) which employs 
cryptography for both assuring the integrity of the message (including 
the unencrypted header) and the confidentiality of the payload (by 
encrypting it).  It uses what's called an AEAD (Authenticated Encryption 
with Associated Data) mode.  The cryptography part is working just fine, 
but there have been questions about what the code is doing mucking about 
in the header, so I'll try to both answer that here and also try to ask 
if there is any better way to do it.  (To be very clear, I'm not asking 
for crypto help, but Wireshark help!)


There is a portion of the code called canonify_unencrypted_header().  In 
order to cryptographically process the ASN.1 components of the header, 
the data must be canonified.  To do this, the dissector must process the 
pieces of the header in a particular order no matter what order these 
were actually sent.  Additionally, the entire BER encoding must be 
processed, and not just the data with a [tag, length, value] triplet.


I can think of two ways to do this (and indeed, have done it both ways). 
 First, I can rely on the ASN.1 parser to break things into their 
respective fields and then process the components.  This approach has 
two problems.  The first problem is that because the entire encoding 
must be processed, the tag and length must be reconstructed which is a 
bit messy and complex.  The more serious problem is that to enable 
filtering based on crypto results (e.g. c1222.crypto_good == true), 
the code must also work on packets that haven't yet been parsed.  For 
those reasons, this approach was tried and rejected.


The second way to do this is to use the contents of the tvb of the whole 
packet and do this parsing in a memory copy.  This also has some 
drawbacks.  First, because the packet may or may not be parsed, the 
routine is either handed an unparsed entire packet, or the 
user_information element within a parsed packet.  To accomodate either, 
the code does a test to see if it's a user_information element, and if 
so, navigates to the grandmother node which is the entire packet.  The 
code to do that looks like this:


  if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information)
pkt_tree = proto_item_get_parent_nth(tree, 2);
  else
pkt_tree = tree;


Second, operating on a copy of the tvb in memory requires intruding deep 
into the structure of a pnode, which I have isolated to a single line of 
code, but it's not pretty:


  /* fetch a memory copy of the data for processing */
  hdr = tvb_memdup(PNODE_FINFO(pkt_tree)-ds_tvb, 
PNODE_FINFO(pkt_tree)-start, PNODE_FINFO(pkt_tree)-length);

  for (i=0; canonifyTable[i].hf_id != NULL; i++)
status |= find_and_copy_element_raw(hdr, 
PNODE_FINFO(pkt_tree)-length, canonbuff, offset, length, i, key_id);

  g_free(hdr);

This code works and has been fuzz tested as well on multiple platforms 
(Windows  Linux).  If there's a better way to do this, please let me 
know what that might be.


For reference the whole of the source code and sample data are here:

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

Ed


___
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] working with header data

[Ed Beroset]

Guy Harris wrote:


On Oct 14, 2011, at 6:03 AM, Ed Beroset wrote:


There is a portion of the code called
canonify_unencrypted_header().  In order to cryptographically
process the ASN.1 components of the header, the data must be
canonified.  To do this, the dissector must process the pieces of
the header in a particular order no matter what order these were
actually sent.  Additionally, the entire BER encoding must be
processed, and not just the data with a [tag, length, value]
triplet.


I.e., what gets run through the CMAC algorithm is a bunch of
BER-encoded data, in a different order than the order in which the
data appears in the header?


It could be, yes. The specification for the standard doesn't prescribe a 
particular data order for header information, but of course the CMAC 
algorithm is designed to be sensitive to data order.  That leads to the 
requirement for being able to rearrange the data.



I can think of two ways to do this (and indeed, have done it both
ways).  First, I can rely on the ASN.1 parser to break things into
their respective fields and then process the components.  This
approach has two problems.  The first problem is that because the
entire encoding must be processed, the tag and length must be
reconstructed which is a bit messy and complex.


Could you use #.FN_BODY for each of the fields in question?  It looks
as if, in the code in question, offset would be the offset of the
BER tag for the field; once you've called the appropriate code to
dissect the field - %(DEFAULT_BODY) might expand to the function body
that would have been there without #.FN_BODY, which might be
sufficient - offset will point past it, so you'd have the offset
and length of the entire BER-encoded field, and could, for example,
copy it with tvb_memcpy().


I did two earlier versions of the code that did something like that. 
One version used knowledge of what the tags are and recalculated the 
length based on the length of the tvb.  The other one looked attempted 
to verify that the expected tag really was the expected number of bytes 
ahead of the data.  Both versions seemed messy and complex to me.



If you need to wrap BER encodings for sequences, etc. around the
individual fields to make a canonicalized composite field, that
sounds as if you have to construct a tag in any case.


The BER encodings (with tag and length) are already part of the incoming 
data, so they wouldn't need to be constructed for any other purpose.



The more serious problem is that to enable filtering based on
crypto results (e.g. c1222.crypto_good == true), the code must
also work on packets that haven't yet been parsed.


Why is that the case?  c1222.crypto_good is part of the protocol
tree, and gets put there as part of the parsing process.  You can put
it into the protocol tree at any point in the parsing process,
including after all the other parsing has been done.


I don't know why that is, but it's what I observe.  When I replace this 
if statement which is in the working code:


  if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information)
pkt_tree = proto_item_get_parent_nth(tree, 2);
  else
pkt_tree = tree;

with this one:

  if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information)
pkt_tree = proto_item_get_parent_nth(tree, 2);
  else
return FALSE;

The *displayed* values for parsed packets are all correct, but the 
*filter* does not work.  That is, I get a blank screen (no packets 
selected) no matter what particular value I use in the filter.  Maybe 
you can tell me why this is?


Ed
___
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] working with header data

[Ed Beroset]

Guy Harris wrote:


On Oct 14, 2011, at 1:16 PM, Ed Beroset wrote:


I did two earlier versions of the code that did something like
that. One version used knowledge of what the tags are and
recalculated the length based on the length of the tvb.  The other
one looked attempted to verify that the expected tag really was the
expected number of bytes ahead of the data.  Both versions seemed
messy and complex to me.


So why does not a #.FN_BODY such as

int start_offset = offset; int length;

$(DEFAULT_BODY)

length = offset - start_offset;

copy length bytes of stuff starting at start_offset

work?  No need to know what the tags are, no need to verify anything,
from what I can see.


I understand what you mean, and will experiment.  If I can work through 
the filter issue, and it works, then this could be a viable replacement.



if (PNODE_FINFO(tree)-hfinfo-id == hf_c1222_user_information)
pkt_tree = proto_item_get_parent_nth(tree, 2); else return FALSE;


None of that has anything to do with adding hf_c1222_crypto_good to
the protocol tree, which is what is relevant for making a
c1222.crypto_good field work; where is the code that adds that to
the tree?


It does, but it's a bit indirect.  If the call to that function returns 
false, it's an indication that the encryption validation failed for some 
reason.



The *displayed* values for parsed packets are all correct,


Where is the c1222.crypto_good field displayed in the protocol
tree?


It's around line 889 of packet-c1222-template.c and is only populated if 
the packet has a Message Authentication Code (MAC) which is part of how 
the cryptography verifies the integrity of the message.


  if (hasmac) {
if (tvb_offset_exists(epsem_buffer, local_offset+4-1)) {
  yt = proto_tree_add_item(tree, hf_c1222_epsem_mac, epsem_buffer, 
local_offset, 4, ENC_NA);

  /* now we have enough information to fill in the crypto subtree */
  crypto_tree = proto_item_add_subtree(yt, ett_c1222_crypto);
  item = proto_tree_add_boolean(crypto_tree, 
hf_c1222_epsem_crypto_good, tvb, local_offset, 4, crypto_good);

  PROTO_ITEM_SET_GENERATED(item);
  item = proto_tree_add_boolean(crypto_tree, 
hf_c1222_epsem_crypto_bad, tvb, local_offset, 4, crypto_bad);

  PROTO_ITEM_SET_GENERATED(item);
} else {
  expert_add_info_format(pinfo, tree, PI_MALFORMED, PI_ERROR, 
C12.22 MAC missing);

  return offset+len;
}
  }

Ed
___
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 39328: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acn.c packet-ancp.c packet-ansi_a.c packet-aodv.c packet-aruba-papi.c pa

[Ed Beroset]

Bill Meier wrote:

On 10/10/2011 1:07 AM, Guy Harris wrote:
   FT_UINT_STRING

 For FT_UINT_STRING, what character encoding was used?  FT_UTF_8 or FT_ASCII?

Actually: for the FT_UINT_STRING cases I just changed TRUE/FALSE to 
ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN

None of them had ENC_UTF_8/

Perhaps it's a bit late, but if this only affects hf_ variables when used 
within proto_add_item() calls, might it make more sense to keep this 
information within the hf_register_info struct?

Ed
___
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

[Wireshark-dev] updated patch file for bug 5531

[Ed Beroset]

Based on the current discussion about the use of the format field for 
proto_tree_add_item(), I have once again revised the patch file for Bug 5531 ( 
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5531 ).  It has gotten a 
lot of votes and was originally submitted over nine months ago.  Is there 
something else I should do to help get this in the main build?

Ed
___
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] modelines

[Ed Beroset]

Stephen Fisher wrote:

Can modelines be at the top of a file?


Yes, for vim (and I assume others).  That's where I usually put them.


The boiler plate copyright notice from doc/README.developer might be a good 
place to put it.


I think that's a good approach.  It may also be useful to think about 
settings for indent since we're on the topic.  I don't have a strong 
view on what the settings should be, but something generally in line 
with the majority of existing Wireshark code would be useful IMHO.


Ed
___
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] Can't compile latest trunk

[Ed Beroset]

Yosi Saggi wrote:
Can't find:  bison flex unzip wget


ERROR: These application(s) are either not installed or simply can't be
found in the current PATH: /cygdrive/c/Python26:/cygdrive/c/Program
[...]
For additional help, please visit:

http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html

 

NMAKE : fatal error U1077: 'C:\cygwin\bin\bash.EXE' : return code '0x1'

Stop.

 

What can I do to fix that.

If you go visit the URL that the build process mentioned, make sure you follow 
all of the steps of section 2.2.2.

Ed
___
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] Problem compiling Wireshark 1.6.1

[Ed Beroset]

Guy Harris wrote:
I think at least once I've had my path set incorrectly when building Wireshark 
on Windows, and getting the wrong command run - a Cygwin port of some UN*X 
command being run instead of some other Windows tool that had the same name 
but was a different tool.  I think that's happened for me at least once with 
mt - and, if not me, with somebody else asking wireshark-dev about it.

That's why I wanted you to run where mt.exe, to see whether it was picking 
up Cygwin's mt.  From the output you got, it appears that it wasn't picking 
up Cygwin's mt, so that's apparently not the cause of the problem.

For what it's worth, I've definitely had path trouble building Wireshark on 
Windows (with Cygwin installed and in the path) and have found that the 
Cygwin-supplied which command is very helpful to sort this out.  On my 
system, I use a batch file that explicitly sets the path (rather than the often 
recommended method of appending to the path) to avoid exactly this kind of 
problem.  It looks like this:

set PATH=...(long explicit path with Visual Studio stuff first)
set WIRESHARK_TARGET_PLATFORM=win32
call c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat
title Command Prompt (VC++ 2008)

Ed
___
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

[Wireshark-dev] how to check a field

[Ed Beroset]

I am working on refining a dissector and need to make sure the tree I'm 
passed actually points to the field I intend.  This code may be called 
either before or after the packet is dissected.  To do this I'm using 
code like this:


if (PNODE_FINFO(tree)-hfinfo-id == hf_myproto_specialfield)
{  /* do stuff... */ }

I don't like to reach that deep into the hfinfo data structure, but it 
seems that the only alternative that would work would be to call 
proto_find_finfo(tree, hf_myproto_specialfield) but that's not really 
what I want and incurs a much larger runtime penalty than is really 
needed.  Is there a better way to do this?


Ed
___
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] Traffic generation for ASN.1 PER

[Ed Beroset]

ANISH M wrote:

I want to generate some ASN.1 PER traffic, is there any tools available for
that? Please let me know.

It's not clear exactly what you're asking.  ASN.1 is a notation to express a 
protocol and PER is a means of encoding it.  What's missing from your question 
is some particular ASN.1 specification to describe the encoded data.  Maybe an 
example like this is what you are seeking?   
http://portal.etsi.org/mbs/languages/asn.1/asn1per.htm

Ed
___
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] CaveBear's Ethernet link is dead

[Ed Beroset]

Chris Maynard wrote:

The tools/make-manuf script attempts to gather Ethernet codes from IEEE, but
also from CaveBear at http://www.cavebear.com/CaveBear/Ethernet/Ethernet.txt,
but unfortunately this link is dead.

I could not find any meaningful contact information to Karl Auerbach on the site
other than Santa Cruz, CA, which isn't all that helpful.

CaveBear's, Ethernet Codes Master Page contains Ethernet code links to other
sites and mirrors, but the only one that seems to work is the MIT one, namely
http://www.mit.edu/~map/Ethernet/Ethernet.txt.  From what I can tell though,
that page hasn't been updated since 1999/03/09, so that's also not very helpful.


That seems actually to be the last revision.  The current CaveBear 
link is:


http://www.cavebear.com/archive/cavebear/Ethernet/Ethernet.txt


So ... should we use the MIT link instead, try to contact Karl somehow, or just
eliminate the CaveBear URL altogether and stick with IEEE?


He talks about the movement of the page here (in 2007!): 
http://cavebear.com/index.php?option=com_contentview=articleid=13:the-new-cavebear-websitecatid=1:latestItemid=28


I say leave it in place with the corrected link.

Ed
___
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] CaveBear's Ethernet link is dead

[Ed Beroset]

Joerg Mayer wrote:

http://www.cavebear.com/archive/cavebear/Ethernet/Ethernet.txt


If this file has been static for so long, how about integrating its content
into our template file?


That's probably the best idea, and then just have the link as 
documentation.  In fact, if anybody's interested, I'll do a delta of the 
IEEE and CaveBear list and only extract the unique bits for exactly that 
kind of inclusion.


Ed
___
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] Makefile for wireshark dissector

[Ed Beroset]

sagar sg wrote:
 I am trying to compile my dissector independently by writing a
single make file and Included some wireshark libraries. Can i do this or i
need to compile it with wireshark s source code only??

If it's a plugin, and you've done things the way the other plugins are done, 
you can compile just the plugin's .so file by simply going to, say, 
plugins/myproto and running make.  If it's successful, it will create the 
myproto.so file in a plugins/myproto/.libs directory.  

For rapid development, I've also been known to temporarily add a target to the 
makefile which then copies it to the installed location (default is 
/usr/local/lib/wireshark/plugins/1.7.0/ ) and runs tshark with a sample file, 
redirecting the output to an output file.

Note that the .so file that you put there must also match the wireshark build, 
so you'll need to get have the whole wireshark source tree even if all you 
desire is the plugin.  (OK, technically, you could just get a subset, but it 
would take longer to figure out exactly what subset you need than to just get 
the whole thing.)

Ed
___
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] Problem with recommended Makefile.nmake

[Ed Beroset]

eymanm wrote:
While building a plugin on Windows with Wireshark 1.6.0, I'm trying to
follow directions provided in README.plugins. With the recommended content
of \plugins\myudp\Makefile.nmake (attachment Recommended_Makefile.nmake) I'm
getting compilation errors as shown in attachment CompilationErrors.txt.
However, if use a different Makefile.nmake
(attachment Modified_Makefile.nmake), the compilation is successful.

Can somebody help to figure out what's wrong with using the recommended
Makefile.nmake?

The error messages say:
packet-myudp.c(90) : error C2220: warning treated as error - no 'object' file 
generated

packet-myudp.c(90) : warning C4554: '' : check operator precedence for 
possible error; use parentheses to clarify pre

cedence

packet-myudp.c(782) : warning C4113: 'void (__cdecl *)()' differs in parameter 
lists from 'void (__cdecl *)(void)'

packet-myudp.c(1119) : warning C4244: '=' : conversion from 'double' to 
'gfloat', possible loss of data

packet-myudp.c(1219) : warning C4244: '=' : conversion from 'double' to 
'gfloat', possible loss of data

packet-myudp.c(1860) : warning C4244: '=' : conversion from 'double' to 
'gfloat', possible loss of data

packet-myudp.c(2134) : warning C4244: '=' : conversion from 'guint16' to 
'guint8', possible loss of data

The difference in the makefiles is that you don't have the warnings treated as 
error turned on in the modified file, but that's not the correct modification 
to make.  The correct way to address this is to fix the warnings in 
packet-myudp.c as pointed out by the compiler.  They look like mostly minor 
things that would only need a few minutes to address and your code will be 
better quality as a result even though it may work as intended already.

Ed
___
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] Procedure to compile wireshark dissector on linux

[Ed Beroset]

sagar sg wrote:

Hi,
  What is the procedure for compiling the wireshark dissector in linux.


http://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBuildFirstTime.html#id521996

Ed
___
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] plugins to builtins

[Ed Beroset]

mman...@netscape.net wrote:
 
While I see grouped protocols in the current epan\dissector directory, I 
thought maybe Profinet could have its own directory off of it if otherwise 
'pollutes' the main dissector directory.  I just see the plugins directory as 
Windows only, and I don't think any protocol should be limited if there 
isn't anything Windows specific about it.  My goal is to just increase 
platform independent code.  

I may have misunderstood what you're saying, but plugins are certainly not 
generally Windows-only.  There is a page on the developer's wiki which 
describes the choice between building as a plugin vs. building as builtin.  
It's specifically talking about ASN.1 protocols, but most of the points are 
generic:

The usual way to build an ASN.1-based dissector is to put it into the asn1 
subtree. This works well and is somewhat simpler than building as a plugin, but 
there are two reasons one might want to build as a plugin:

* to speed development, since only the plugin needs to be recompiled
* to allow flexibility in deploying an updated plugin, since only the 
plugin needs to be distributed 

Reasons one might not want to build as a plugin:

* the code is somewhat more complex
* the makefile is quite a bit more complex
* building under the asn1 subtree keeps all such dissectors together 

(See http://wiki.wireshark.org/ASN1_plugin for the full text.)

Ed
___
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] Finding duplicate (conflicting) value_string entries

[Ed Beroset]

Jeff Morriss wrote:
Jakub Zawadzki wrote:
 On Wed, May 18, 2011 at 05:10:09PM +0100, Martin Mathieson wrote:
 On Wed, May 18, 2011 at 4:49 PM, Jakub Zawadzki nospam wrote:
 This patch is OK for me.
 I didn't measure, but it didn't noticibly add to the startup time
 
 This O(n^2) loop sucks a little, you can optimized it with some hashing 
 or bit-setting/checking. 
 But really please don't care about startup-time. It's not so important.

Well, I'd disagree with startup time not being important... :-)  I 
sometimes start Wireshark many times a day, sometimes on not-very-fast 
SPARCs.

Speaking of more limited platforms, I wonder about about a way of reducing both 
startup time and memory usage by having the dissectors dynamically loaded (as 
with the current plug-in mechanism) rather than statically linked.  The current 
model of adding all dissectors to the main code means that Wireshark will keep 
getting bigger and bigger.  I wonder if it might not be time to ponder if 
that's the best possible option.

Ed
___
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

[Wireshark-dev] climbing trees

[Ed Beroset]

(I posted this email twelve hours ago, but it hasn't shown up, so I'm 
resending.  Sorry if it's a duplicate.)

I've updated the patch for bug 5531 per comments from Jeff Morriss (thanks, 
Jeff!) but he brought up a comment I don't know how to address, so I thought 
I'd ask here.  The comment is on a bit of code that looks 
like this:

   /* at this point there are two possibilities:  either the packet
* has been dissected already or it has not.  If it has not, then
* we already have a tvb full of C12.22 data.  If it has, then we
* are actually two levels deep and the data we seek is actually in
* the grandparent of the current node.
*/
   if ((tree-parent-finfo != NULL)  (tree-parent-parent != NULL))
 pkt_tree = tree-parent-parent;

This code, which is within asn1/c1222/packet-c1222-template.c, is called when 
we're just displaying the list of packets and also when the packet is being 
displayed in tree form.  In order to allow the use of a display filter such as 
c1222.crypto_good == true the packet has to be parsed and rearranged in 
canonical form for cryptographic processing, per the protocol.  In some cases, 
what gets passed here is the whole packet in which case the if clause above is 
false.  However, if the tree has already been constructed, what this code is 
handed is actually deeper inside and we need to climb the tree to get access to 
the packet data.

Is there a better way to do this?

Ed
___
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