Re: [Wireshark-dev] ISO 7816 vs GSM SIM dissector

[Martin Kaiser]

Hi Pascal and Stig,

Thus wrote Pascal Quantin (pas...@wireshark.org):

> Le mer. 18 août 2021 à 13:51, Stig Bjørlykke  a écrit :

> > Hi,

> > Does anyone know the difference between the ISO 7816 dissector and the GSM
> > SIM dissector?

amongst other things, the iso7816 dissector includes the ATR (answer to
reset). This seems to be used by a couple of other dissectors as well.

> > For me it looks like they are handling the same PDUs, but both are
> > incomplete in different ways.


> You are correct. Both were done by different developers for different
> purposes (Martin added the generic ISO 7816 dissector after Harald added
> the GSM SIM one). SIM or USIM application is just one of the many
> applications that can run on a smartcard. Note that the 3GPP specs override
> the ISO specs, so the decoding of the elementary files could differ as far
> as I can remember

I guess that specific applications of ISO 7816, such as GSM-SIM or
payment cards, redefine not only elementary files (payload) but also
some header fields and status codes. We'd have very few common items
across all iso 7816 use cases.

Nevertheless, I suppose that gsm_sim and iso7816 could be merged if we
wanted to.

Best regards,
Martin
___
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] Growing memory with tshark & Lua

[Martin Kaiser]

Hi Thomas,

Thus wrote Thomas Baudelet (thomas.baude...@gmail.com):

> Hi Devs,

> When Wireshark profiles are correctly tuned (few protocols, disabled TCP
> reassembly & analysis, bytes tracking, timestamps calculations, IP defrag),
> tshark memory doesn't grow at all.

> Simply adding a simple Lua script with 1 listener and 1 field, without doing
> nothing with them, then the memory grows along with pcap file.

> As tshark memory alone doesn't grow due to correct profile, I'd have
> expected Lua to forget about all values also on each Listener.packet() loop,
> but it doesn't seem to be coded like this.

> Lua script by itself doesn't consume that much memory according to
> collectgarbage("count").

> So it seems that Lua+Listener+Field is forcing { tshark / Lua } to collect
> all packets as if some reassembly was asked.

> Anybody has some hints about this, the section of code involved here ?

> And most important : is there a way to prevent the memory growing !

would you mind sharing the profile and the lua script?

Thanks,
Martin
___
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] lua decoder accessing info from layers above

[Martin Kaiser]

Thus wrote Maynard, Chris via Wireshark-dev (wireshark-dev@wireshark.org):

> > From: Wireshark-dev  On Behalf Of 
> > chuck c
> > Sent: Wednesday, October 14, 2020 10:33 AM
> > To: Developer support list for Wireshark 
> > Subject: Re: [Wireshark-dev] lua decoder accessing info from layers above

> > local p_foo = Proto.new("foo", "foo")
> > local f_frame_protocols = Field.new("frame.protocols")

> > function p_foo.dissector(buf, pinfo, tree)
> >print(pinfo.number, "Protocols: " .. (f_frame_protocols() and 
> > f_frame_protocols().value or "Unknown"))
> > --print(pinfo.number, f_frame_protocols().value)
> > end

> > register_postdissector(p_foo)

> > Script above prints to the Lua console.
> > What was the situation where it doesn't work?

> It works as a post-dissector, but not as a registered dissector.  For 
> example, replace:

> register_postdissector(p_foo)

> with something like so, replacing the port number with whatever you can 
> easily test with:

> local udp_table = DissectorTable.get("udp.port")
> udp_table:add(3, p_foo)

> Yet you can access and print other frame fields such as "frame.len" and 
> "frame.cap_len".

frame.protocols is added to the tree by the frame dissector after all
upper-layer protocols were running, i.e. after the big try-catch block
in packet-frame.c and before the try-catch block for postdissectors.
This makes sense to me. We have to dissect the packet completely before
we can compile the list of all protocols that got to see the packet.

Thus, by the time p_foo.dissector runs, there's no frame.protocols field in
the tree yet. f_frame_protocols() is nil. Field__call() calls
proto_get_finfo_ptr_array() which doesn't find a frame.protocols entry
in the tree.

This is different for frame.len and frame.cap_len. These fields are
added to the tree before packet-frame.c passes control to other
dissectors.

When postdissectors are called, frame.protocols is also present in the
tree and visible to postdissectors.

Best regards,
Martin
___
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] NEWS flle

[Martin Kaiser]

Dear all,

CMake has a target "news" that copies the release notes into a NEWS file
in the source directory. NEWS is under version control and hasn't been
updated in the repository for a while.

Should we remove NEWS from the repository? Should we modify the CMake
target to leave the source directory alone (which would mean deleting
the target itself, all it does it copy the release notes to NEWS)?

Best regards,

   Martin
___
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] MPEG2-TS, DVB-SI, and DVB-GSE Dissectors

[Martin Kaiser]

Hi Alexander,

good to see you again. We worked together in the DVC-CI+ group back in
2014. I hope that I told you about Wireshark's CI+ dissector then ;-)

Thus wrote Alexander Adolf (alexander.ad...@condition-alpha.com):

> For both topics, I would expect one likely guidance I'll be receiving
> to be "submit a patch". This is of course the most productive and
> easiest to manage way from the point of view of the regular
> contributors who are familiar with the code

... and the best way to _become_ familiar with the code.

There's no such thing as a "high-level introduction to the DVB-related
functionality" document.
There is, however, doc/README.dissector, which is worth a read.

> (1) A little bit of streamlining of how DVB PSI/SI is presented when
> analysing MPEG2-TS. I could e.g. imagine it to help readability if the
> PID were shown in the source and/or destination address field. Also,
> when interpreting DVB PSI/SI tables, some interpretations of
> identifiers doesn't seem to be quite accurate. 

That sounds like a good starting point: Find a field that we don't
interpret correctly. Try to find out where it's defined and modify it.
Try to come up with a small and simple modification for the first patch.
If you get stuck along the way, let me know which field you're looking
at and prepare a ts file that you can share with us.

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

Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on OSX 10.6 x64

[Martin Kaiser]

Hmm, generating the .qm files seems to cause problems on OSX.

Thus wrote buildbot-no-re...@wireshark.org (buildbot-no-re...@wireshark.org):

> The Buildbot has detected a new failure on builder OSX 10.6 x64 while 
> building wireshark. Full details are available at:
> 
> http://buildbot.wireshark.org/wireshark-master/builders/OSX%2010.6%20x64/builds/11360

> Buildbot URL: http://buildbot.wireshark.org/wireshark-master/

> Buildslave for this Build: osx-10.6-x64

> Build Reason: The SingleBranchScheduler scheduler named 'Gerrit' triggered 
> this build
> Build Source Stamp: [branch master] 5c03bda31af87bf08a404509cd0714df65471416
> Blamelist: Martin Kaiser <wiresh...@kaiser.cx>

> BUILD FAILED: failed compile_3

  RCC  qrc_i18n.cpp
RCC Parse Error: 'i18n.qrc' Line: 2 Column: 34 [unexpected text]
make[2]: *** [qrc_i18n.cpp] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

i18n.qrc is now generated from i18n.qrc.in. Is there a way to see what
the generated file looks like on OSX? Can anyone reproduce this locally?

Thanks,
Martin
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://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] cmake, linker flags, whitespace, cmp0004

[Martin Kaiser]

Hi Jörg,

Thus wrote Joerg Mayer (jma...@loplof.de):

> Hello Martin,

> is this problem still open?

yes, it's still open. Just tried it again on master.

Best regards,
Martin

> Thanks
>Jörg

> On Sun, Apr 17, 2016 at 03:14:32PM +0200, Martin Kaiser wrote:
> > I'm getting strange cmake errors on Debian Wheezy (cmake 2.8.9).

> > -- Performing Test WS_LD_FLAG_VALID0
> > CMake Error at CMakeLists.txt:11 (ADD_EXECUTABLE):
> >   Target "cmTryCompileExec701976172" links to item " -Wl,--as-needed" which
> >   has leading or trailing whitespace.  This is now an error according to
> >   policy CMP0004.


> > CMake Error: Internal CMake error, TryCompile generation of cmake failed
> > -- Performing Test WS_LD_FLAG_VALID0 - Failed
> > statuscheck linker flag - test linker flags: -pie
> > -- Performing Test WS_LD_FLAG_VALID1
> > CMake Error at CMakeLists.txt:11 (ADD_EXECUTABLE):
> >   Target "cmTryCompileExec2930916065" links to item " -pie" which has 
> > leading
> >   or trailing whitespace.  This is now an error according to policy
> > CMP0004.

> > CMake Error: Internal CMake error, TryCompile generation of cmake failed



> > Apparently, cmake doesn't like leading whitespace in linker options. I
> > tried setting the CMP0004 policy to the old behaviour which is not
> > ignore the whitespace.

> > cmake_policy(SET CMP0004 OLD)

> > This doesn't fix things. Google results show that this is in fact a bug
> > in cmake's parsing.

> > KDE discovered the bug in their build
> > http://comments.gmane.org/gmane.comp.kde.devel.buildsystem/7858

> > Cmake fixed it here
> > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e65ef08b


> > I tried to work around this by removing whitespace from the linker flags
> > or applying a regexp replace on the final list of linker flags.
> > None of this produced a clean and readable solution.

> > Does anyone more familiar with cmake have a recommendation how to fix
> > this properly?

> -- 
> Joerg Mayer   <jma...@loplof.de>
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
> ___
> Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
> Archives:https://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:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] warning if running with Qt4

[Martin Kaiser]

Hi Gerald, all,

the current master shows this warning on a Qt4 system.

martin@husavik:~/src/wireshark.git$ ./wireshark
Object::connect: No such slot QScrollBar::setRange(int,int) in 
overlay_scroll_bar.cpp:74

The offending line is
connect(this, SIGNAL(rangeChanged(int,int)), _sb_, 
SLOT(setRange(int,int)));

In Qt4, QScrollBar has no setRange() method.

I'm not sure how to implement such things portably without littering the
code with #if QT_VERSION >= QT_VERSION_CHECK(...) lines.

Best regards,
Martin

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

[Wireshark-dev] cmake, linker flags, whitespace, cmp0004

[Martin Kaiser]

Hi,

I'm getting strange cmake errors on Debian Wheezy (cmake 2.8.9).

-- Performing Test WS_LD_FLAG_VALID0
CMake Error at CMakeLists.txt:11 (ADD_EXECUTABLE):
  Target "cmTryCompileExec701976172" links to item " -Wl,--as-needed" which
  has leading or trailing whitespace.  This is now an error according to
  policy CMP0004.


CMake Error: Internal CMake error, TryCompile generation of cmake failed
-- Performing Test WS_LD_FLAG_VALID0 - Failed
statuscheck linker flag - test linker flags: -pie
-- Performing Test WS_LD_FLAG_VALID1
CMake Error at CMakeLists.txt:11 (ADD_EXECUTABLE):
  Target "cmTryCompileExec2930916065" links to item " -pie" which has leading
  or trailing whitespace.  This is now an error according to policy
CMP0004.

CMake Error: Internal CMake error, TryCompile generation of cmake failed



Apparently, cmake doesn't like leading whitespace in linker options. I
tried setting the CMP0004 policy to the old behaviour which is not
ignore the whitespace.

cmake_policy(SET CMP0004 OLD)

This doesn't fix things. Google results show that this is in fact a bug
in cmake's parsing.

KDE discovered the bug in their build
http://comments.gmane.org/gmane.comp.kde.devel.buildsystem/7858

Cmake fixed it here
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e65ef08b


I tried to work around this by removing whitespace from the linker flags
or applying a regexp replace on the final list of linker flags.
None of this produced a clean and readable solution.

Does anyone more familiar with cmake have a recommendation how to fix
this properly?

Thanks,
Martin
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] proto_tree_add_text stats

[Martin Kaiser]

Thus wrote mman...@netscape.net (mman...@netscape.net):

 2. There are 12 dissectors with 20-30 proto_tree_add_text calls
 packet-dvbci.c

I'll look into this one, shouldn't be much of a problem.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://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] master 9b5a09a: [Automatic update for 2015-04-26]

[Martin Kaiser]

Thus wrote Graham Bloice (graham.blo...@trihedral.com):

 We're really close to not worrying about that :-)

That's what I was hoping :-)

I couldn't get the QMakefile to rebuild the .qm files correctly. There's
a bunch of examples on the web, none of them would work for me.

The cmake version should be ok, I had to make modifications to create
and use the .qm files in the build dir rather than in the source. My
solution might be a bit clumsy but it should work.

Regards,
Martin

 On 26 April 2015 at 19:01, Alexis La Goutte alexis.lagou...@gmail.com
 wrote:

  Hi Evan,

  Martin have start to work for generate qm files but the problem is don't
  (yet) work for nmake...
  https://code.wireshark.org/review/#/c/7597/

  Regards,

  On Sun, Apr 26, 2015 at 7:29 PM, Evan Huus eapa...@gmail.com wrote:

  Now that the translation files are being updated every week, we really
  need to remove the binary files from the repo. I know it's been
  discussed before, but anybody with a working qt-dev installation
  should be able to generate the .qm files from the .ts files, yes?

  On Sun, Apr 26, 2015 at 11:07 AM, Wireshark code review
  code-review-do-not-re...@wireshark.org wrote:
   URL:
  https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=9b5a09aa3479b56b111439222397f239b477cda8
   Submitter: Gerald Combs (ger...@wireshark.org)
   Changed: branch: master
   Repository: wireshark

   Commits:

   9b5a09a by Gerald Combs (ger...@wireshark.org):

   [Automatic update for 2015-04-26]

   Update manuf, services enterprise-numbers, translations, and other
  items.

   Change-Id: I431063783434a6f7a9a4f4b8186316ed3f98005b
   Reviewed-on: https://code.wireshark.org/review/8199
   Reviewed-by: Gerald Combs ger...@wireshark.org


   Actions performed:

   from  0437280   C15ch: fix o previous prototype for function
  [-Wmissing-prototypes]
   adds  9b5a09a   [Automatic update for 2015-04-26]


   Summary of changes:
epan/dissectors/usb.c|   76 ++---
epan/enterprise-numbers  |  116 +++-
epan/sminmpec.c  |   30 -
manuf|   46 +++-
services |   18 +--
ui/qt/wireshark_it.qm|  Bin 239430 - 239746 bytes
ui/qt/wireshark_it.ts|4 +-
ui/qt/wireshark_zh_CN.qm |  Bin 173107 - 173233 bytes
ui/qt/wireshark_zh_CN.ts |  272
  +++---
9 files changed, 398 insertions(+), 164 deletions(-)

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

  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  Archives:https://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:https://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:https://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:https://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] Latest build modifies files?

[Martin Kaiser]

Thus wrote Guy Harris (g...@alum.mit.edu):

 On Mar 7, 2015, at 4:26 PM, Martin Kaiser li...@kaiser.cx wrote:

  Thus wrote Martin Kaiser (li...@kaiser.cx):

  I just pushed a change to create the .qm files for Qt's translated texts
  from the corresponding .ts files. My change handles the autotools build.
  I saw that the cmake build already support this.

  Does anyone know if the Windows nmake build creates the .qm files?

  Looking at the buildbot output from e.g.
  http://buildbot.wireshark.org/petri-dish/builders/Windows%20x86%20Petri%20Dish/builds/1660/steps/nmake%20all/logs/stdio

  it seems this is already working.

 Great!

 So let's remove the .qm files *now*, so that a build that regenerates
 them won't leave developers with a Git tree with a bunch of bogus
 Changes not staged for commit for the .qm files.

I reverted my change.

cmake stops working when the .qm files are gone. It can apparently
update .qm from .ts but the .qm files have to be present or there'll be
dependency errors.
___
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] Latest build modifies files?

[Martin Kaiser]

Thus wrote Richard Sharpe (realrichardsha...@gmail.com):

 Hi folks,

 After my most recent build I noticed this:

 # On branch master
 # Your branch is ahead of 'origin/master' by 1 commit.
 #   (use git push to publish your local commits)
 #
 # Changes not staged for commit:
 #   (use git add file... to update what will be committed)
 #   (use git checkout -- file... to discard changes in working directory)
 #
 # modified:   ui/qt/wireshark_de.qm
 # modified:   ui/qt/wireshark_it.qm
 # modified:   ui/qt/wireshark_ja_JP.qm
 # modified:   ui/qt/wireshark_pl.qm
 # modified:   ui/qt/wireshark_zh_CN.qm
 #

 I did not touch those files and it seems a bit rude of the build to modify 
 them.

My fault, I reverted the change that caused this. Sorry for the
inconvenience.
___
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] Latest build modifies files?

[Martin Kaiser]

Thus wrote Guy Harris (g...@alum.mit.edu):

 On Mar 7, 2015, at 12:59 PM, Richard Sharpe realrichardsha...@gmail.com 
 wrote:

  Hi folks,

  After my most recent build I noticed this:

  # On branch master
  # Your branch is ahead of 'origin/master' by 1 commit.
  #   (use git push to publish your local commits)
  #
  # Changes not staged for commit:
  #   (use git add file... to update what will be committed)
  #   (use git checkout -- file... to discard changes in working 
  directory)
  #
  # modified:   ui/qt/wireshark_de.qm
  # modified:   ui/qt/wireshark_it.qm
  # modified:   ui/qt/wireshark_ja_JP.qm
  # modified:   ui/qt/wireshark_pl.qm
  # modified:   ui/qt/wireshark_zh_CN.qm
  #

  I did not touch those files and it seems a bit rude of the build to modify 
  them.

 That was done in

   https://code.wireshark.org/review/7460/

 and I've already added a comment there noting that either we should
 *not* have the .qm files checked into Git and *require* that you have
 the tools necessary to build them if you're going to build from Git or
 have them checked into Git and *not* build them as part of the build
 process.

The goal is to build the .qm files during the compilation and eventually
remove them from the repository. This works now for autotools and cmake
builds, I do not know about the status for nmake and sent the following
mail to the list earlier today (which did not get relayed for some
reason).



Dear all,

I just pushed a change to create the .qm files for Qt's translated texts
from the corresponding .ts files. My change handles the autotools build.
I saw that the cmake build already support this.

Does anyone know if the Windows nmake build creates the .qm files? I
can't test this myself at the moment, it seems that nmake uses qmake in
the qt directory.

When the nmake build can create the .qt files, we can remove them from
the repository.

Another open item is what to do if the lrelease tool that creates the
.qm files is not available. Should we fail the build if the Qt version
is to be built? Or can we continue without the .qm files and without
multi-language support?

Thanks,
Martin


___
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] Latest build modifies files?

[Martin Kaiser]

Thus wrote Martin Kaiser (li...@kaiser.cx):

 I just pushed a change to create the .qm files for Qt's translated texts
 from the corresponding .ts files. My change handles the autotools build.
 I saw that the cmake build already support this.

 Does anyone know if the Windows nmake build creates the .qm files?

Looking at the buildbot output from e.g.
http://buildbot.wireshark.org/petri-dish/builders/Windows%20x86%20Petri%20Dish/builds/1660/steps/nmake%20all/logs/stdio

it seems this is already working.

...
Updating qwindows.dll.
Creating directory printsupport.
Updating windowsprintersupport.dll.
Creating qt_cs.qm...
Creating qt_de.qm...
Creating qt_fi.qm...
Creating qt_hu.qm...
Creating qt_it.qm...
Creating qt_ja.qm...
Creating qt_ru.qm...
Creating qt_sk.qm...
Creating qt_uk.qm...
   )
   cd ../..
   set copycmd=/y
...
___
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?

[Martin Kaiser]

Thus wrote Guy Harris (g...@alum.mit.edu):

 In the best of all possible worlds, the only people who would have a
 reason to use something other than the system language would be people
 testing translations or reproducing bugs and testing fixes

and that's definitely something that we'll have to do a lot before our
translations (and their framework) are working ok. Therefore, I'd be
happy to keep the preference for changing the language, especially now
that a change takes effect immediately without a restart.
___
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] reassembly, addresses, hash calculation

[Martin Kaiser]

Hi,

when I looked at bug 10505, I noticed the following code in
packet-mp2t.c

/* It's possible that a fragment in the same packet set an address already
 * This will change the hash value, we need to make sure it's NULL */

SET_ADDRESS_HF(pinfo-src, AT_NONE, 0, NULL, 0);
SET_ADDRESS_HF(pinfo-dst, AT_NONE, 0, NULL, 0);

[...]
frag_msg = fragment_add_check(mp2t_reassembly_table,
tvb, offset, pinfo, frag_id, NULL,
[...]


Is it really necessary to clear the addresses here in order to make
reassembly work correctly?

Without looking at the reassembly mechanism, I'd say that lower-layer
addresses should be taken into account and mpeg ts packets from
different src/dst addresses shouldn't be reassembled.

mp2t_reassembly_table is initialized with
addresses_reassembly_table_functions. One of these is
fragment_addresses_hash(), which doesn't use the addresses at all.
However, the comparison and key creation functions do use src and dst
addresses...

I'm still tempted to remove the lines where the addresses are cleared.

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

Re: [Wireshark-dev] [Wireshark-commits] master 64cd827: Have dissect_usb_setup_request handle non-standard requests

[Martin Kaiser]

Hi Sean,

Thus wrote Stalley, Sean (sean.stal...@intel.com):

 I think we should discuss how to clean up the usb dissector. It seems
 like we are running into the too many cooks in the kitchen scenario.

So far, our changes co-existed nicely. Now's the first time they were in
conflict ;-)

 My primary goal has been to reuse as much of the USB dissector as
 possible for the MA USB dissector.

 I've been trying to simplify/modularize dissect_usb_common() along the
 way, but if I'm just getting in the way let me know.

I appreciate your work, the USB dissector definitely needs more cleanup.

As I said in the previous mail, I'd like to reduce the number of state
variables and simplify the execution flow (there's too many conditions
and branches).

I'll upload some more changes tomorrow.

Best regards,
Martin
___
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] master 64cd827: Have dissect_usb_setup_request handle non-standard requests

[Martin Kaiser]

The new req_type is the same as the existing type. There's a
switch(type) {...} followed by in if (req_type==...).

My goal is to have only one call to try_dissect_next_protocol(). In
dissect_usb_common(), we dissect the standard fields in the main
switch-statement and call try_dissect_next_protocol() _once_ for the
remaining data.

At the moment, try_dissect_next_protocol() is called
twice for control requests that it can't handle. This adds two generated
items saying unknown class.

Unfortunately, the recent patches make it harder to fix this...

Why is the setup_tvb for the standard setup request generated in
dissect_nonstandard_usb_setup_request()?

if (header_info  (USB_HEADER_IS_LINUX | USB_HEADER_IS_64_BYTES)) {
...
}
else {
...
offset = try_dissect_linux_usb_pseudo_header_ext(tvb, offset, pinfo, 
tree, header_info);
}

Will try_dissect_linux_usb_pseudo_header_ext() ever do anything if it's
only called when there's no extended pseudo header?

Is there a way to subscribe to gerrit change requests so that I'm
notified when a new USB-related change is uploaded?

Thus wrote Wireshark code review (code-review-do-not-re...@wireshark.org):

 URL: 
 https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=64cd8270c669e35bc2911133a9a7da31c4bb1965
 Submitter: Anders Broman (a.broma...@gmail.com)
 Changed: branch: master
 Repository: wireshark

 Commits:

 64cd827 by Sean O. Stalley (sean.stal...@intel.com):

 Have dissect_usb_setup_request handle non-standard requests

 Moved code for parsing non-standard setup requests from
 dissect_usb_common() to dissect_usb_setup_request().

 Also added header_info flag USB_HEADER_IS_MAUSB  updated mausb
 dissector.

 Change-Id: Ifa8abccbd57bf4dd3965f582872952383e6f737d
 Reviewed-on: https://code.wireshark.org/review/3851
 Petri-Dish: Anders Broman a.broma...@gmail.com
 Reviewed-by: Anders Broman a.broma...@gmail.com


 Actions performed:

 from  3d4d021   Non-standard USB control requests now handled in own 
 function
 adds  64cd827   Have dissect_usb_setup_request handle non-standard 
 requests


 Summary of changes:
  epan/dissectors/packet-mausb.c |9 +++
  epan/dissectors/packet-usb.c   |   51 
 ++--
  epan/dissectors/packet-usb.h   |7 --
  3 files changed, 38 insertions(+), 29 deletions(-)
 ___
 Sent via:Wireshark-commits mailing list wireshark-comm...@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-commits
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
  
 mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 64cd827: Have dissect_usb_setup_request handle non-standard requests

[Martin Kaiser]

Hi Pascal,

Thus wrote Pascal Quantin (pascal.quan...@gmail.com):

 I spotted a regression myself (that seems similar to what you report) and
 proposed https://code.wireshark.org/review/#/c/3858/ to fix it. Could you
 give it a try on your sample?

looks good to me, I just merged it.

Best regards,
Martin
___
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] should extcap dir be a preference?

[Martin Kaiser]

Hi,

at the moment, the directory for the extcap binaries is defined at
compile time.

When I first tried extcap a year ago, I created a patch to make the
extcap directory a preference. This was much easier for me to handle
when I played with several extcaps that needed frequent recompiling.

I'd like to resurrect this patch. Thoughts?

Best regards,
Martin
___
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 OSX 10.6 x64

[Martin Kaiser]

sorry, my fault

I merge two things in the wrong order
master should build ok now

Thus wrote buildbot-no-re...@wireshark.org (buildbot-no-re...@wireshark.org):

 The Buildbot has detected a new failure on builder OSX 10.6 x64 while 
 building wireshark.
 Full details are available at:
  http://buildbot.wireshark.org/trunk/builders/OSX%2010.6%20x64/builds/5016

 Buildbot URL: http://buildbot.wireshark.org/trunk/

 Buildslave for this Build: osx-10.6-x64

 Build Reason: scheduler
 Build Source Stamp: [branch master] c284e1211296361d1548e8f98a7ccc51c621019f
 Blamelist: Martin Kaiser wiresh...@kaiser.cx

 BUILD FAILED: failed compile

 sincerely,
  -The Buildbot



 ___
 Sent via:Wireshark-commits mailing list wireshark-comm...@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-commits
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
  
 mailto:wireshark-commits-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] Adding a new dissector - beginners guide

[Martin Kaiser]

Thus wrote Thomas Wiens (th.wi...@gmx.de):

 I thought, with git add file I am saying: look only on this files
 and ignore all others.

No, that's what you say with svn add. svn tracks files, git tracks
changes. git add file means add the changes I made to this file into
the next commit.

 What is the best way to share samples for my dissector, in the wireshark
 wiki? Should I create a site for this protocol, although it's only in
 review?

Yes, I'd suggest you create a new page for your protocol. Eventually,
the dissector will be merged ;-)
___
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] master 1194061: clear the temporary components of usb_conv_info_t before we dissect a new packet

[Martin Kaiser]

 Frankly, conversation structures shouldn't have per-packet data in
 them at all; this was probably the easiest way to fix the fuzz
 failure, but it really seems odd to me that it even needs to be done.

 Thoughts?

True. Per-packet data shouldn't be part of the conversation struct. I'm
working step by step to refactor the USB dissectors, this will be
addressed at some point (as time permits).
___
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] switching to proto_tree_add_subtree()

[Martin Kaiser]

Thus wrote darkjames...@darkjames.pl (darkjames...@darkjames.pl):

 Hi,

 On Mon, Jul 28, 2014 at 10:47:43PM +0200, Martin Kaiser wrote:
  However, I don't quite understand why for tree!=NULL but not visible,
  proto_tree_add_text() returns tree. I can see this in the code, we call
  TRY_TO_FAKE_THIS_ITEM(), which returns the tree itself when it's not
  visible. But what sense does this make for the caller?

 Just to make filtering works.
 We're keeping array of interesting fields, stored in 
 tree-tree_data-interesting_hfids.

 In common case like this:
   foobar_tree = proto_tree_add_subtree_format(tree, ..., Foobar);

   proto_tree_add_item(foobar_tree, hf_foobar_xyz, ...);
   proto_tree_add_item(foobar_tree, hf_foobar_aaa, ...);

 when foobar_tree == NULL, proto_tree_add_item() will fast return in if 
 (!tree) check inside TRY_TO_FAKE_THIS_ITEM_OR_FREE

This case is ok, I understand that this makes things faster if we don't
have a tree.

I'm confused about this block in TRY_TO_FAKE_THIS_ITEM_OR_FREE

if (!(PTREE_DATA(tree)-visible)) { \
if (PTREE_FINFO(tree)) { \
if ((hfinfo-ref_type != HF_REF_TYPE_DIRECT) \
 (hfinfo-type != FT_PROTOCOL || \
PTREE_DATA(tree)-fake_protocols)) { \
free_block; \
/* just return tree back to the caller */\
return tree; \

If tree is not visible (and fake_protocols is set, which seems to be the
default), we return the tree itself.

proto_item *it = proto_tree_add_text(tree, tvb, 0, -1, foobar);

If tree!=NULL  !(PTREE_DATA(tree)-visible) the return value it==tree
Why does this make sense?

Regards,
Martin
___
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] buildbot troubles

[Martin Kaiser]

Hi,

I made a (seemingly simple) change to the DVB-CI dissector and ran it
through the buildbot. The Ubuntu x86_64 one failed

gcc: internal compiler error: Segmentation fault (program as)
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
make[5]: *** [libdissectors_la-packet-zbee-zcl-meas-sensing.lo] Error 1
make[5]: *** Waiting for unfinished jobs

The full log is at
http://buildbot.wireshark.org/petri-dish/builders/Ubuntu%20x86-64%20Petri%20Dish/builds/143/steps/compile/logs/stdio

I had no problem on my x86_64 debian wheezy box with gcc 4.7.2.

Any idea what's going wrong here?

Thanks,
Martin
___
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] switching to proto_tree_add_subtree()

[Martin Kaiser]

Hi all,

I'm sending out some unsorted thoughts, hoping that you can help me
understand the issue I'm seeing.

After the switch to proto_tree_add_subtree(), I found that some output
of the DVB-CI dissector was different than before.

Replacing
ti = proto_tree_add_text(tree, tvb, offset, tvb_data_len, Resource ID: 
0x%04x, res_id);
res_tree = proto_item_add_subtree(ti, ett_dvbci_res);

with
res_tree = proto_tree_add_subtree_format(tree, tvb, offset, tvb_data_len,
   ett_dvbci_res, ti, Resource ID: 0x%04x, res_id);


Does not give 100% identical behaviour. When tree!=NULL but not set to
visible, ti will be !=NULL in the fist case and ==NULL after the change
to proto_tree_add_subtree_format()

I came across this in a function that does something like

check if input is valid, return NULL on error
create proto_item from the input
create tree
populate tree
return proto_item

The caller would then check the returned proto_item for NULL to see if
the input could be processed. This started failing when
proto_tree_add_subtree_format() is used.

My gut feeling is that proto_tree_add_subtree_format() does the right
thing and I should fix my dissector...

However, I don't quite understand why for tree!=NULL but not visible,
proto_tree_add_text() returns tree. I can see this in the code, we call
TRY_TO_FAKE_THIS_ITEM(), which returns the tree itself when it's not
visible. But what sense does this make for the caller?

Best regards,
Martin
___
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] tvb_get_string_enc() doesn't always return valid UTF-8

[Martin Kaiser]

Hi,

if I have a tvbuff that starts with 0x86 and I call

a = tvb_get_string_enc(tvb, 0, ENC_ASCII)
proto_tree_add_string(..., a);

I can trigger the DISSECTOR_ASSERT since a is not a valid unicode string.

Comments in the code suggest that tvb_get_string() should replace
chars=0x80 with the unicode replacement char, which is two bytes long.
This would look like

guint8 *
tvb_get_string(wmem_allocator_t *scope, tvbuff_t *tvb, gint offset, gint length)
{
wmem_strbuf_t *str;

tvb_ensure_bytes_exist(tvb, offset, length);
str = wmem_strbuf_new(scope, );

while (length  0) {
guint8 ch = tvb_get_guint8(tvb, offset);

if (ch  0x80)
wmem_strbuf_append_c(str, ch);
else {
wmem_strbuf_append_unichar(str, UNREPL);
}
offset++;
length--;
}
wmem_strbuf_append_c(str, '\0');

return (guint8 *) wmem_strbuf_get_str(str);
}


The resulting string would still contain len+1 chars but not necessarily
len+1 bytes. Would that be a problem, i.e. is it ok to do sth like

b = tvb_get_string(NULL, tvb, offset, len_b);
copy_of_b = g_malloc(len_b+1);
memcpy(copy_of_b, b, len_b+1);

?

If that should work, we'd need a separate function for get string 
replace 8bit chars.

Thoughts?

   Martin
___
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] tvb_get_string_enc() doesn't always return valid UTF-8

[Martin Kaiser]

Thus wrote Evan Huus (eapa...@gmail.com):

 I think we'd agreed that the right thing to do is to convert most of
 our string functions to handle and return counted strings
 (wmem_strbuf_t or something) and then do the replacement as you
 suggest. There are several other outstanding encoding issues
 (especially around embedded NULLs) where string length cannot be
 reliably managed without explicitly counting it.

 Unfortunately it's a relatively large API change, but I think it's the
 right thing going forward, especially since we already use a
 wmem_strbuf_t in most of the _get_string functions already (we just
 don't return it).

Ok, that means my idea does not conflict with your long-term plans.

I committed the change to tvb_get_string() in r54864. I'll have a look
at tvb_get_stringz() tomorrow.

   Martin
___
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 54662: /trunk/ui/qt/ /trunk/ui/qt/: main_window.h main_window_slots.cpp

[Martin Kaiser]

Thanks.

I saw earlier today that the authors list would not appear when I ran
from the build directory. This was because the main window (and the
about window) were created before init_progfile_dir() was called.

Your checkin fixed that as well.

In GTK, we create the main window much later than in Qt. Are there any
other widgets that depend on init_progfile_dir() and other setup?

Thus wrote alagou...@wireshark.org (alagou...@wireshark.org):

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

 User: alagoutte
 Date: 2014/01/08 02:43 PM

 Log:
  Don't create About window when Wireshark Qt start

 Directory: /trunk/ui/qt/
   ChangesPath Action
   +0 -1  main_window.hModified
   +6 -6  main_window_slots.cppModified

 ___
 Sent via:Wireshark-commits mailing list wireshark-comm...@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-commits
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits
  
 mailto:wireshark-commits-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] FT_BYTES hf with len==0

[Martin Kaiser]

Thus wrote Martin Kaiser (li...@kaiser.cx):

 Thus wrote Jakub Zawadzki (darkjames...@darkjames.pl):

  proto_item_fill_label() allows empty bytes:

  5389 case FT_BYTES:
  5390 case FT_UINT_BYTES:
  5391 bytes = (guint8 *)fvalue_get(fi-value);
  5392 label_fill(label_str, 0, hfinfo,
  5393 (bytes) ? bytes_to_str(bytes, 
  fvalue_length(fi-value)) : MISSING);
  5394 break;

  It'd be good to make them consistent, allow empty bytes (+1 from me) or 
  assert in both place.

 ok, I'll change this.

done in r54290.
___
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] FT_BYTES hf with len==0

[Martin Kaiser]

Thus wrote Martin Kaiser (li...@kaiser.cx):

   5392 label_fill(label_str, 0, hfinfo,
   5393 (bytes) ? bytes_to_str(bytes, 
   fvalue_length(fi-value)) : MISSING);
   5394 break;

   It'd be good to make them consistent, allow empty bytes (+1 from me) or 
   assert in both place.

  ok, I'll change this.

 done in r54290.

I've just found one more issue with empty FT_BYTES:
When I click on an empty FT_BYTES element in the tree and select Apply
as Filter / Selected, wireshark creates a filter expression

filter name==

that results in a syntax error.

This is created by construct_match_selected_string(), which calls
fvalue_to_string_repr() and uses the fvalue's string representation by
default.

One way to resolve this would be to change an empty FT_BYTES' string
representation from nothing to  (as filter name== is a valid
filter expression). See the attached patch.

Is that ok or does it break someone else's code? Should I check for
FTREPR_DFILTER and modify the representation for empty FT_BYTES only in
this case?
commit f7aeaec74abab8e11165ea742778d4875100cfac
Author: Martin Kaiser mar...@reykholt.kaiser.cx
Date:   Fri Dec 20 17:31:21 2013 +0100

change the string representation of an empty FT_BYTES fvalue to 
this creates a correct filter expression for Apply as Filter / Selected, etc.

diff --git a/epan/ftypes/ftype-bytes.c b/epan/ftypes/ftype-bytes.c
index de7adac..5bcb20d 100644
--- a/epan/ftypes/ftype-bytes.c
+++ b/epan/ftypes/ftype-bytes.c
@@ -63,9 +63,8 @@ static int
 bytes_repr_len(fvalue_t *fv, ftrepr_t rtype _U_)
 {
 	if (fv-value.bytes-len == 0) {
-		/* Empty array of bytes, so the representation
-		 * is an empty string. */
-		return 0;
+		/* Empty array of bytes, the representation is two double quotes */
+		return 2;
 	} else {
 		/* 3 bytes for each byte of the byte NN: minus 1 byte
 		 * as there's no trailing :. */
@@ -143,6 +142,11 @@ bytes_to_repr(fvalue_t *fv, ftrepr_t rtype _U_, char *buf)
 	c = fv-value.bytes-data;
 	write_cursor = buf;
 
+	if (fv-value.bytes-len==0) {
+		sprintf(write_cursor, \\);
+		return;
+	}
+
 	for (i = 0; i  fv-value.bytes-len; i++) {
 		if (i == 0) {
 			sprintf(write_cursor, %02x, *c++);
___
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] FT_BYTES hf with len==0

[Martin Kaiser]

Thus wrote Guy Harris (g...@alum.mit.edu):

 Do you mean this is a byte array field that has a length that can
 range from 0 to {some maximum value}, so that the field might have
 some value in some packets

and a length of 0 in others (in which case the default value is used).

In r54145, I changed the code to add a text item to the tree for
length==0, but it would be handy if I could filter for both cases.
___
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] FT_BYTES hf with len==0

[Martin Kaiser]

Thus wrote Jakub Zawadzki (darkjames...@darkjames.pl):

 proto_item_fill_label() allows empty bytes:

 5389 case FT_BYTES:
 5390 case FT_UINT_BYTES:
 5391 bytes = (guint8 *)fvalue_get(fi-value);
 5392 label_fill(label_str, 0, hfinfo,
 5393 (bytes) ? bytes_to_str(bytes, 
 fvalue_length(fi-value)) : MISSING);
 5394 break;

 It'd be good to make them consistent, allow empty bytes (+1 from me) or 
 assert in both place.

ok, I'll change this.
___
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] FT_BYTES hf with len==0

[Martin Kaiser]

Dear all,

is it allowed to add an FT_BYTES hf entry with len==0 to the protocol
tree?

E.g. 

proto_tree_add_bytes_format_value(tree, hf_myproto_myval,
   tvb, offset, 0, NULL, format, ...)

The idea would be to allow filtering for this element although it has no
value (it's just there).

When I do this, I run into an assert in proto_custom_set(),

   case FT_BYTES:
bytes = (guint8 *)fvalue_get(finfo-value);
   ... bytes_to_string(bytes, ...) - DISSECTOR_ASSERT


Who's at fault here: proto_custom_set() or the caller?

Regards,
Martin
___
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] Move plugins/ to epan/dissectors/plugins/

[Martin Kaiser]

Thus wrote Joerg Mayer (jma...@loplof.de):

 I'd like to move the plugins/ directory into epan/dissectors/. They provide
 just more dissectors and depend on epan anyway.
 Are there good reasons not to do that move?

Couldn't we have plugins for fileformats (wiretap) or taps as well?
___
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] r53871, test.sh decryption failure

[Martin Kaiser]

Hi Jakub and all,

sorry for causing problems with the DVB-CI decryption test.

Does this fail for others as well?

If so, could you send me the output of 

tshark \
-o dvb-ci.sek:  \
-o dvb-ci.siv:  \
-Tfields -e dvb-ci.cc.sac.padding \
-r test/captures/dvb-ci_UV1_.pcap

Thanks,

   Martin
___
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 53619: /trunk/ /trunk/: NEWS

[Martin Kaiser]

Thus wrote Guy Harris (g...@alum.mit.edu):


 On Nov 27, 2013, at 3:09 PM, jma...@wireshark.org wrote:

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

  User: jmayer
  Date: 2013/11/27 11:09 PM

  Log:
  Having a generated file in the source tree is not fun.

 Should we add a top-level rule to make it, and remove it from SVN?

+1

Last time I added a protocol and modified release-notes.asciidoc, I
couldn't figure out if/how I should update NEWS.
___
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] wmem_strbuf_printf()

[Martin Kaiser]

Dear all,

I just looked at the radius dissector and saw the call to
ep_strbuf_printf(), which has no wmem equivalent.

I guess wmem_strbuf_printf() could be as simple as

void
wmem_strbuf_printf(wmem_strbuf_t *strbuf, const gchar *format, ...) 
{   
va_list ap; 

if (!strbuf)
return;

strbuf-len = 0;

va_start(ap, format);   
wmem_strbuf_append_vprintf(strbuf, format, ap); 
va_end(ap);
}   


Are you ok with me adding this or has this been left out on purpose?

I'm aware that ui/profile.c has some calls to ep_strbuf_printf(). For
those, conversion to wmem may not be straightforward.

Best regards,

   Martin
___
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] wmem_strbuf_printf()

[Martin Kaiser]

Thanks Pascal  Evan,

Thus wrote Pascal Quantin (pascal.quan...@gmail.com):

 on my side while converting some dissectors to wmem, I replaced the
 ep_strbuf_printf by:
 - either a call to wmem_strbuf_append_printf directly if it was the first
 time the buffer was filled

that's the case for packet-radius as well.

I'll finish this tomorrow.

Regards,

   Martin
___
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] reported_length -1

[Martin Kaiser]

Dear all,

I stumbled on

tvb_new_subset(tvb, 10, (tvb_get_guint8(tvb, 1) - 2), (tvb_get_guint8(tvb, 1) - 
2)); 

If tvb_get_guint8(tvb, 1)==0, we throw an exception because of
backing_length - that makes sense.

As for reported_length-1, it looks like that's ok when the tvb is
created. There'll be an exception when it's accessed, we'll always be
out of bounds.

Is there a valid use case for reported_length-1?

Thanks,
Martin
___
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] reported_length -1

[Martin Kaiser]

Hi Pascal,

Thus wrote Pascal Quantin (pascal.quan...@gmail.com):

 2013/9/7 Martin Kaiser li...@kaiser.cx

  tvb_new_subset(tvb, 10, (tvb_get_guint8(tvb, 1) - 2), (tvb_get_guint8(tvb,
  1) - 2));

  As for reported_length-1, it looks like that's ok when the tvb is
  created. There'll be an exception when it's accessed, we'll always be
  out of bounds.

  Is there a valid use case for reported_length-1?

 I Martin,

 I (wrongly?) assumed that it would automatically throw an exception (as I
 found at least one other code line like this in the source tree) so I did
 not add an explicit check on the size before creating the tvb.
 I do not see any valid use case either.

my mistake. The code of tvb_new_subset() does throw an exception also
for reported_length  -1.

Regards,
Martin
___
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] SET_ADDRESS, if-else

[Martin Kaiser]

Hi,

I just found that

if (...)
   SET_ADDRESS(...);
else
   SET_ADDRESS(...);

does not compile as this would expand to

if (...)
{
};
else
{
}

and the compiler complains about else without if.

Is there anything useful we could do about this other that putting
another pair of brackets around the first SET_ADDRESS?

Regards,
Martin
___
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] Enabling linux kernel jit compiler from dumpcap?

[Martin Kaiser]

before we change it, should we remember the previous setting and restore
it when dumpcap exits?

Thus wrote Anders Broman (a.bro...@bredband.net):

 Bálint Réczey skrev 2013-08-22 23:02:
 Hi,

 I would be happier if the applications I run did not change kernel
 configuration without my consent.
 I see your point...

 Regarding Wireshark I would prefer suggesting echo 1 
 /proc/sys/net/core/bpf_jit_enable in the documentation
 instead of adding code to enable JIT.
 There may be good reasons for not enabling it by default in the Linux kernel.
 The problematic thing is that people seldom reads the documentation, the  
 setting gets reset at a reboot
 and it's easy to forget to re-enable it. The ideal thing would be if dumpcap
 - Had a preference/command line flag whether to use JIT or not.
 - If told to use it check if it was enabled or not used JIT and put it  
 back to zero if not set when starting.
 Wireshark could then default to use JIT and some warnings could be  
 displayed in the welcome screen
 and in dumpcaps help output.

 netsniff-ng activates it by default it seems.
 Regards
 Anders

 Cheers,
 Balint

 2013/8/22 Anders Broman a.bro...@bredband.net:
 Guy Harris skrev 2013-08-22 18:16:

 On Aug 22, 2013, at 4:46 AM, Anders Broman anders.bro...@ericsson.com
 wrote:

 Should we add code to enable the JIT compiler from dumpcap?
 Should I add code to enable the JIT compiler to libpcap while I'm at it?

 Should the Linux kernel folks enable it by default?

 I'm inclined to answer yes to all three questions.  I think the FreeBSD
 JIT compiler is enabled by default.  I'm surprised that the Linux one 
 isn't.
 I checked in the dumpcap code. I agree that it might be useful in libpcap
 too, root privileges are required to
 change it I think. and Yes

 I'm surprised that the Linux one isn't
 Regards
 Anders

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

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


 ___
 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] dissect_sip_tcp_heur()

[Martin Kaiser]

 I'm not really familiar with SIP over TCP (in all my use cases, SIP is
 over UDP) but your proposal makes sense.

Thanks Pascal,

that explains why nobody spotted this so far.

I committed the change in r51313 and I'll schedule it for backporting to
1.10 and 1.8 if nobody complains.

Best regards,
Martin
___
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] dissect_sip_tcp_heur()

[Martin Kaiser]

I came across this while browsing through the coverity defects.

gboolean first = TRUE; is never changed

Does the following change make sense to those who are familiar with SIP?

diff --git a/epan/dissectors/packet-sip.c b/epan/dissectors/packet-sip.c
index fa317c8..c04a0c8 100644
--- a/epan/dissectors/packet-sip.c
+++ b/epan/dissectors/packet-sip.c
@@ -2104,6 +2104,7 @@ dissect_sip_tcp_heur(tvbuff_t *tvb, packet_info
*pinfo, proto_tree *tree, void *
if (len == -1)
break;  /* need more data */
offset += len;
+   first = FALSE;
}
return TRUE;
 }

___
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 51037: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dvbci.c

[Martin Kaiser]

Thus wrote Joerg Mayer (jma...@loplof.de):

 On Tue, Jul 30, 2013 at 08:05:49PM +, mart...@wireshark.org wrote:
   provide a mechnism to exclude some CI+ SAC messages from being
   exported in the clear by the export PDU mechanism

   use this mechanism to exclude SAC messages that contain CCK precursor data
   (Exporting this is not a security issue, but people should be aware of what
they're doing. It's safer to exlude those messages and prevent people from
exporting them accidentially.)

 How about making the remaining stuff a preferences option with default off?

The remaining items are ok. Exporting them will do no harm, the
resulting capture file can be shared with anyone without leaking
any information.
If I change my mind about that, I'll consider using preference for
disabling other items.

Generally, I'd be surprised if many people used the DVB-CI export
feature ;-)

Regards,

   Martin
___
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] long options again

[Martin Kaiser]

Thus wrote Gisle Vanem (gva...@broadpark.no):

 Brandon Carpenter hashs...@pnnl.gov wrote:

 I have to say that I dislike getopt() and getopt_long() for option  
 parsing because of the disconnect between the options and the help. It  
 creates multiple places that require updating when options change and  
 quite often, one of those places is forgotten.  

 Agreed. That's why tools like gengetopt has been developed.
 This tool will generate the getopt_long() C-source + the help-text from a 
 .ggo file specifying the program args. 

 Ref.:
  http://www.gnu.org/software/gengetopt/gengetopt.html

we'd still need to keep the manpage in sync...
___
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] long options again

[Martin Kaiser]

Hi,

this was discussed months ago, I also raised this briefly at Sharkfest -
but I changed my mind since then.

 Guy Harris skrev 2013-04-09 00:32:

 On Apr 8, 2013, at 3:02 PM, Anders Broman a.bro...@bredband.net wrote:

 I think we have getopt_long already 
 http://anonsvn.wireshark.org/viewvc?view=revisionrevision=41926

 We do, so we have it available on both platforms that have it (most
 UN*Xes, these days) and platforms that don't (Windows, which has neither
 getopt() nor getopt_long(), and perhaps some current UN*Xes and older
 versions of other UN*Xes).

We don't have getopt_long() on windows at the moment. But we're
99% there. All it takes is copying another 10 lines from glibc.

It looks like getopt() and getopt_long() share a lot of helper
functions. So we're not pulling in a lot of new code if we provide a
getopt_long() implementation on windows.

We're not using it, however; did you check that in for future use, and
did you have any future use in mind?

I think it was added in conjunction with looking at
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2473 at the time I
think there were discussion about using long options for various stuff.
I just added it so we would have all options open as I didn't quite like
the glib implementation for some reason I don't quite remember now.

Lately, I played a bit more with the goptions. Changing completely from
getopt() to goptions seems a lot of work for no real benefit (unless we
do this everywhere where getopt() is used at the moment).

I tried to use goptions only for the long opts and leave getopt() in
place for the existing options. They don't co-exist well, there's always
a way to produce strange errors.

In short: Contrary to what I said at sharkfest, I believe that
getopt_long() is the way to go. Unless anyone protests, I'll make the
required changes and start using it.

Best regards,

   Martin
___
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] something in -r 50382:50384 epan/dissectors/packet forces warning: 'ddsti' may be used uninitialized in this function

[Martin Kaiser]

Thus wrote Evan Huus (eapa...@gmail.com):

 Martin fixed this in r50386 by initializing that variable, though I
 think it was a typo in commit r50384 that changed ddti to ddsti?

you're right
I fixed the typo in r50435
___
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 Gerrit workflow (was: Re: Notes from Sharkfest '13)

[Martin Kaiser]

Thus wrote Bálint Réczey (bal...@balintreczey.hu):

 I have started describing a Gerrit based workflow which IMO would fit
 to the project at http://wiki.wireshark.org/Development/Workflow .
 Please check it and share your opinion.

would that mean that even the most basic change needs peer review and
approval based on the process defined by gerrit?

I'm a bit worried that this doubles the time for such simple changes.  I
often see this in corporate environments where people don't correct
typos, misleading variable names, formatting etc. because they can't be
bothered with the administrative overhead.

Regards,
Martin
___
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 Gerrit workflow (was: Re: Notes from Sharkfest '13)

[Martin Kaiser]

Hi Balint,

Thus wrote Bálint Réczey (bal...@balintreczey.hu):

 We can relax the rules for Core Developers to let them bypass the peer review,
 but I did not want to include this exception in the first proposal.
 Speaking of myself I would be OK with requiring peer review for all my 
 commits,
 but it is not a surprise since I wrote the first version of the proposal. ;-)

I'd be in favour of a solution where core developers can decide to
bypass the review for trivial changes. This encourages people to do
cleanups straight away.

Reviewing complex changes is certainly necessary and it looks like
gerrit makes this easier than bugzilla/mails.

 What I'm really looking forward to in the proposed Gerrit work-flow is
 the ability of having my changes
 tested on architectures I don't use _before_ applying them to the main branch.

That is definitely an improvement.

Regards,
Martin
___
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 50097: /trunk/epan/ /trunk/epan/dissectors/: Makefile.am Makefile.common /trunk/epan/: Makefile.am

[Martin Kaiser]

Thus wrote Guy Harris (g...@alum.mit.edu):


 On Jun 20, 2013, at 5:15 PM, Gerald Combs ger...@wireshark.org wrote:

  On 6/20/13 5:13 PM, Evan Huus wrote:
  Very cool. I'm starting to wonder now if the file dissectors should be 
  named file-foo.c instead of packet-foo.c?

  That makes sense to me.

 +1

done in r50105 for file-mp4.c, I'll move other dissectors step by step
___
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] read/write capture comments from the command line

[Martin Kaiser]

Thus wrote Guy Harris (g...@alum.mit.edu):

 Sounds like a job for capinfos.

You're right, that's where it should go. And for capinfos, the cmdline
options don't have to be aligned with wireshark/tshark/dumpcap ;-)

 (I assume by capture file comment you mean the comment in the first
 Section Header Block in a pcap-ng file, rather than the comments on
 packets.)

Yes.

I uploaded my patch to
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8574

Shouldn't be contentious. I'll check it in tomorrow or so unless someone
complains.

(I couldn't get capinfos to compile with USE_GOPTION defined but that's a
different story...)
___
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] read/write capture comments from the command line

[Martin Kaiser]

Dear all,

I was asked by some people about access to capture comments from the
command line tools. We identified two use cases

- You have a capture file and want to display its capture file comment.
  Nothing but the comment, no packets etc.
- You start a capture from the command line and want to insert a comment 
  into the newly created file.

The reading should be an option to tshark (display the capture file 
comment and exit). Tshark would need a copy of cf_read_shb_comment() or 
a way to share it with file.c.

For writing, I added a switch -j new comment to both tshark and 
dumpcap. It turned out that things are most simple if I add a new field 
initial_capture_comment to the capture_options structure. Tshark can 
pass the comment to dumpcap via sync_pipe_start() and dumpcap writes the
SHB.

I have something basic that's working. Probably, a lot of plausibility 
checks for the parameters are missing. E.g. supplying a comment only 
makes sense if we capture into one pcapng file.

What do you think: Do these use cases and the approach make sense to 
you? And what letters should be used for the option? I know you've been
cleaning up the parameters lately ;-)

Best regards,

   Martin
___
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] libgcrypt 1.5.0 compiler warnings

[Martin Kaiser]

Dear all,

this issue has been around for a long time. When we use libgcrypt 1.5.0,
including gcrypt.h spills out lots of warnings about deprecated
definitions, breaking compilation with -Werror.

Steven Fisher asked about this on the libgcrypt list

http://old.nabble.com/Re%3A-Problem-with-warning%3A-gcrypt.h-%27...%27-is-deprecated-messages-p32398900.html

It was said that it's a gcc specific problem.

I was wondering if we could use gcc pragmas to address this. How about
replacing

#include gcrypt.h

with

#pragma GCC diagnostic push
#pragma GCC diagnostic warning -Wdeprecated-declarations
#include gcrypt.h
#pragma GCC diagnostic pop


This should be enough as we don't seem to use any of the deprecated
functionality.

It's relatively few places where gcrypt.h is included.

If that's too error-prone as people may include gcrypt.h elsewhere in
the future and forget to add the pragmas, we could have a wrapper
include file (epan/crypt/ws-libgcrypt.h ?) with the 4 lines above and
include that instead of gcrypt.h.

Thoughts?

Best regards,

   Martin
___
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] libgcrypt 1.5.0 compiler warnings

[Martin Kaiser]

Hi,

Thus wrote Gerald Combs (ger...@wireshark.org):

 On 2/21/13 12:47 AM, Martin Kaiser wrote:
  If that's too error-prone as people may include gcrypt.h elsewhere in
  the future and forget to add the pragmas, we could have a wrapper
  include file (epan/crypt/ws-libgcrypt.h ?) with the 4 lines above and
  include that instead of gcrypt.h.

 Sounds good to me. I've been working around the issue with
 CFLAGS=-D_GCRYPT_IN_LIBGCRYPT=1 but it would be nice if we could
 compile out of the box.

I just comitted a slightly modified version of this in r47801-47803
It turned out that not all gcc versions support the pragmas we need.

Please let me know if I broke anything.

Best regards,

   Martin
___
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: logical with non-zero constant will always evaluate as true

[Martin Kaiser]

Dear all,

I get this warning (error) when I compile svn head

peektagged.c: In function ???wtap_file_read_till_separator???:
peektagged.c:150: error: logical ?? with non-zero constant
will always
evaluate as true
make[2]: *** [libwiretap_la-peektagged.lo] Error 1


The offending line is

   if (strchr (separators, c) != NULL)

which seems to evaluate on my system (debian squeeze) to something like

  (__extension__ (__builtin_constant_p (c)  !__builtin_constant_p (s) \
 (c) == '\0'\
? (char *) __rawmemchr (s, c) \
: __builtin_strchr (s, c)))


I still don't understand the problem. c is not constant, it's read from
a file.

Commenting out 

AC_WIRESHARK_GCC_CFLAGS_CHECK(-Wlogical-op)

in configure.ac will stop the warning.

Any ideas how to fix this properly?

Thanks,

   Martin


___
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: logical with non-zero constant will always evaluate as true

[Martin Kaiser]

Thus wrote Martin Kaiser (li...@kaiser.cx):

 which seems to evaluate on my system (debian squeeze)

more specifically

martin@skogar:~$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

The Ubuntu buildbot does not complain, the behaviour might depend on the
gcc version.
___
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 46111: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-bssgp.c

[Martin Kaiser]

Thus wrote Anders Broman (a.bro...@bredband.net):

 Guy Harris skrev 2012-11-21 22:10:

  if(len  0){
  next_tvb = tvb_new_subset(tvb, offset, len, len);
  dissect_s1ap_SONtransferApplicationIdentity_PDU(tvb, gpinfo, tree, 
 NULL);
  }

 Should it be passing next_tvb to 
 dissect_s1ap_SONtransferApplicationIdentity_PDU()?
 Yes, sorry.

fixed in r46125

Regards,

   Martin
___
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] Compiling Plugin error

[Martin Kaiser]

Hi Matteo, Jeff,

Thus wrote Jeff Morriss (jeff.morriss...@gmail.com):

 Matteo Di Cosmo wrote:

 Dear all,

 I'm new in Wireshark and I'm trying to sniff IPMI packets throught a
 i2c bus.

 To do this I need to compile a plugin which has been previously
 developed in the context of 
 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1970 ) .

 Actually, my first question is why do I need to add this plugin if
 wireshark already cames out with a ipmb dissector?

 Well, I wouldn't think that you need to.  The new (compared to that
 in bug 1970) IPMI dissector stuff is built-in (see
 epan/dissectors/packet-*ipmi*).

 Why do you think you need to add the plugin?

Matteo: If your data isn't decoded correctly, did you set

Edit / Preferences / Protocols / I2C / Bus/Data type

to IPMB? I guess it defaults to None (raw i2c).

Regards,

   Martin
___
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 45566: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-rdp.c

[Martin Kaiser]

Hi,

Thus wrote Maynard, Chris (christopher.mayn...@gtech.com):

 Recently, I found and fixed some of these problems, but obviously I
 didn't catch them all.  Are there any more thoughts about changing
 tvb_length_remaining() and tvb_reported_length_remaining() to return 0
 instead of -1?

it looks like there's quite a few places where people used an unsigned
return value (I just fixed a few obvious cases).
I guess we should do something about this in the tvb part rather than in
the dissectors. 

What's the difference between return value 0 and -1 now? Both are
essentially saying there's no data left, -1 is an error case and 0
isn't? Is that significant to the caller, what can he do other than stop
reading?

   Martin
___
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] initializing a variable with a non-constant value

[Martin Kaiser]

Hi,

doc/README.developer says

Don't initialize variables in their declaration with non-constant
values. Not all compilers support this. E.g. don't use
   guint32 i = somearray[2];
...

In file.c, read_packet(), we do

  const struct wtap_pkthdr *phdr  = wtap_phdr(cf-wth);
  union wtap_pseudo_header *pseudo_header = wtap_pseudoheader(cf-wth);
  const guchar *buf = wtap_buf_ptr(cf-wth);


The two things are in contradiction and I'm wondering how to fix this.
Apparently, there's been no complaints about compiler problems with
read_packet() so I was wondering if the limitation in README.developer
is still required.

Any views about this? Or any idea which compilers could potentially be
affected?

Thanks,

   Martin
___
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] parsing an IPv6 address from a text string

[Martin Kaiser]

Hi,

as part of #7729, we have to parse a text string that contains an IPv6
address and convert it into a sequence of bytes - and detect malformed
addresses.

The current proposal does the parsing manually. I was wondering if we
could simplify things by using getaddrinfo(). It seems that it's
available for =WinXP and *NIX. Calling it on windows needs some winsock
initializations but in general, there wouldn't be huge differences
between platforms.

I'd be thinking about something like

---
   struct addrinfo hints, *res = NULL;
   struct sockaddr_in6 *sin6;
   const char service[] = discard;  /* well-known, unique port */

   hints.ai_family = AF_INET6;
   hints.ai_socktype = SOCK_STREAM;
   hints.ai_flags = AI_NUMERICHOST; /* no DNS lookup */

   ret = getaddrinfo(addr, service, hints, res);
   if (ret!=0)
  goto end;
   if (res-ai_addr-sa_family!=AF_INET6)
  goto end;

   sin6 = (struct sockaddr_in6 *)(res-ai_addr);
   /* take bytes from sin6-sin6_addr */

   freeaddrinfo(res);
---


Any views about this?

Thanks,

   Martin
___
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] order of include files

[Martin Kaiser]

Hi,

should the order in which we include files make any difference?

#include epan/packet.h 
#include epan/expert.h 
- ok

#include epan/expert.h 
#include epan/packet.h 
- failure

expert.h needs packet_info.h, which is included by packet.h

Trivial fix is of course to include packet_info.h in experts.h.
Are such issues worth fixing?

Best regards,

   Martin
___
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 45227: /trunk/ui/gtk/ /trunk/ui/gtk/: main_statusbar.c

[Martin Kaiser]

Thus wrote Maynard, Chris (christopher.mayn...@gtech.com):

 Capture comments can be added/removed through the summary dialog as well.

and that obviously invokes a different callback function. Which does not
update the statusbar icon.

Thanks for spotting this. I'll commit a fix soon.
___
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] Passing data from Plugin dissector to a standard wireshark dissector (i.e. TCP)

[Martin Kaiser]

Hi Hammad,

Thus wrote hammad kabir (hammadsa...@gmail.com):

 I have recently implemented a wireshark dissector of a relatively
 simple protocol (lets call the protocol as COOL) for a project of
 mine. This dissector gets the data from IP layer and then parses it
 according to protocol definition of COOL protocol. (so far its good).
 But, next step involves passing the data from COOL protocol ( which is
 a plugin dissector in my case) to TCP protocol for further dissection
 of packet. However, I am having a difficult time in getting this
 (later) task done.

a while ago, I added dissection of DVB-CI messages that contain a tcp or
udp part. Have a look at epan/dissectors/packet-dvbci.c. When the
connection is opened, I call store_lsc_msg_dissector() and try to find
the matching dissector for the selected tcp (or udp) port.
Later in dissect_dvbci_payload_lsc(), case
T_COMMS_SEND_LAST..., I call the tcp dissector using call_dissector()
and pass the message tvb as a parameter.

Is this similar to your task?

Regards,

   Martin
___
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] why does dissector_try_uint_new() return gboolean?

[Martin Kaiser]

Dear all,

I have a tvbuff that contains one or more dvb sections. I don't know the
number of sections or their lengths (only the overall length but that
doesn't really matter).

Each table starts with a tag, I can get the dissector table for dvb/mpeg
sections and call dissector_try_uint_new(...) to dissect the first
section based on its leading tag byte.

Unfortunately, dissector_try_uint_new() returns true or false, not the
number of dissected bytes. Therefore, I can't find the start of the 2nd
and any following sections.

This is surprising since dissector_try_uint_new() knows the number of
dissected bytes. The few places where it's used now are converting the
gboolean return value back to an integer

  gboolean ret; 
  ret = dissector_try_uint_new(...);
  return ret ? tvb_length(tvb) : 0; 


Would it make sense to change dissector_try_uint_new() to return guint?
Should I leave dissector_try_uint_new() as it is and introduce a similar
function returning guint?

Or am I misunderstanding something? I suppose it is ok for a new-style
dissector to return something other than 0 or the complete tvb length.

Thanks,

   Martin
___
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] PCAP-NG metadata support

[Martin Kaiser]

Hi Brandon,

Thus wrote Carpenter, Brandon J (brandon.carpen...@pnnl.gov):

 If so, what is the best way to make the patch available?  I'll post
 more details with the patch.

open a bug at https://bugs.wireshark.org/bugzilla/ and attach your
patch.

Best regards,

   Martin

___
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] cmake build of r43639 fails

[Martin Kaiser]

Dear all,

I'm building r43639 using cmake, this fails at

[ 78%] Built target tshark
[ 78%] Built target codecs
[ 88%] Built target gtkui
Linking C executable wireshark
lib/libgtkui.a(main_menubar.c.o):(.rodata+0x27d4): undefined reference
to `rlc_lte_graph_cb'
collect2: ld returned 1 exit status
make[2]: *** [wireshark] Error 1
make[1]: *** [CMakeFiles/wireshark.dir/all] Error 2
make: *** [all] Error 2


I guess rlc_lte_graph.c should be added to CMakeLists.txt, not just to
Makefile.common.

Trivial patch attached, could someone check it in?

Thanks,

   Martin
Index: ui/gtk/CMakeLists.txt
===
--- ui/gtk/CMakeLists.txt   (revision 43639)
+++ ui/gtk/CMakeLists.txt   (working copy)
@@ -187,6 +187,7 @@
mtp3_summary.c
ncp_stat.c
radius_stat.c
+   rlc_lte_graph.c
rlc_lte_stat_dlg.c
rpc_progs.c
rpc_stat.c
___
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 with QT

[Martin Kaiser]

Hi,

Thus wrote Akos Vandra (axo...@gmail.com):

 I'm having problems building wireshark with Qt. I'm trying to build on
 Ubuntu 10.04LTS x64, with QT 4.7.0, qmake 2.01a, latest svn revision
 at the moment, r43597.

 I used the following commands to build:

 autoconf
 ./configure --prefix=/home/akos/projects/c/wireshark/bin --with-qt=yes
 make -j10

I haven't tried this for some months but I recall that there were some
issues with qt and autotools. The recommendation is to use cmake, see
doc/README.qt

Regards,

   Martin
___
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] compile error on linux, r43534

[Martin Kaiser]

Hi,

r43534 does not compile on linux.

gcc -DHAVE_CONFIG_H -I.  -I. -I./wiretap -DINET6 -DG_DISABLE_DEPRECATED 
-DG_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE -DGTK_DISABLE_DEPRECATED 
-DGTK_DISABLE_SINGLE_INCLUDES -D_FORTIFY_SOURCE=2 
-D_U_=__attribute__((unused)) -I/usr/local/include -I/usr/include 
'-DPLUGIN_DIR=/usr/local/lib/wireshark/plugins/1.9.0' -Werror -DPYTHON_DIR= 
-g -O2 -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels 
-Wpointer-arith -Wno-pointer-sign -Warray-bounds -Wcast-align -Wformat-security 
-Wold-style-definition -pthread -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng12   -MT wireshark-capture_ifinfo.o -MD -MP -MF 
.deps/wireshark-capture_ifinfo.Tpo -c -o wireshark-capture_ifinfo.o `test -f 
'capture_ifinfo.c' || echo './'`capture_ifinfo.c
capture_ifinfo.c: In function ???get_interface_type???:
capture_ifinfo.c:344: error: ???ws_statb64??? undeclared (first use
in this function)
capture_ifinfo.c:344: error: (Each undeclared identifier is reported
only once
capture_ifinfo.c:344: error: for each function it appears in.)
capture_ifinfo.c:344: error: expected ???;??? before ???statb???
cc1: warnings being treated as errors
capture_ifinfo.c:345: error: ISO C90 forbids mixed declarations and code
capture_ifinfo.c:421: error: implicit declaration of function
???ws_stat64???
capture_ifinfo.c:421: error: ???statb??? undeclared (first use in
this function)
make[2]: *** [wireshark-capture_ifinfo.o] Error 1
make[2]: Leaving directory `/home/martin/src/wireshark.svn'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/martin/src/wireshark.svn'
make: *** [all] Error 2

I assume that file_util.h should be included, trivial patch attached.

Best regards,

   Martin
Index: capture_ifinfo.c
===
--- capture_ifinfo.c (revision 43534)
+++ capture_ifinfo.c (working copy)
@@ -47,6 +47,8 @@
 # include wsutil/inet_v6defs.h
 #endif
 
+#include wsutil/file_util.h
+
 #include glib.h
 
 #include capture_opts.h

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

Re: [Wireshark-dev] compile error on linux, r43534

[Martin Kaiser]

Thus wrote Martin Kaiser (li...@kaiser.cx):

 r43534 does not compile on linux.

 I assume that file_util.h should be included, trivial patch attached.

ok, Jeff was faster than me ;-)
___
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] warning - error in r41911

[Martin Kaiser]

Hi Graham and all,

r41911 gives a warning on my system

packet-dcerpc-spoolss.c: In function âdissect_spoolss_string_parm_dataâ:
packet-dcerpc-spoolss.c:497: error: âitemâ may be used uninitialized in
this function
make[5]: *** [libdissectors_la-packet-dcerpc-spoolss.lo] Error 1
make[5]: *** Waiting for unfinished jobs


trivial patch is attached

Best regards,

   Martin
Index: epan/dissectors/packet-dcerpc-spoolss.c
===
--- epan/dissectors/packet-dcerpc-spoolss.c	(revision 41911)
+++ epan/dissectors/packet-dcerpc-spoolss.c	(working copy)
@@ -494,7 +494,7 @@
 	dcerpc_info *di = pinfo-private_data;
 	guint32 buffer_len, len;
 	gchar *s;
-	proto_item *item;
+	proto_item *item = NULL;
 
 	if (di-conformant_run)
 		return offset;
___
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] warning-error in r41867

[Martin Kaiser]

Dear all,

there's a warning in r41867

cc1: warnings being treated as errors
main_menubar.c:3874: error: set_menu_visible defined but not used
make[2]: *** [libgtkui_a-main_menubar.o] Error 1

Trivial fix is attached.

Best regards,

   Martin
Index: ui/gtk/main_menubar.c
===
--- ui/gtk/main_menubar.c	(revision 41867)
+++ ui/gtk/main_menubar.c	(working copy)
@@ -145,7 +145,9 @@
 static void merge_lua_menu_items(GList *node);
 static void ws_menubar_build_external_menus(void);
 static void set_menu_sensitivity (GtkUIManager *ui_manager, const gchar *, gint);
+#if !defined(WANT_PACKET_EDITOR) || !defined(HAVE_AIRPCAP) || !defined(HAVE_LIBPCAP)
 static void set_menu_visible(GtkUIManager *ui_manager, const gchar *path, gint val);
+#endif
 static void name_resolution_cb(GtkWidget *w, gpointer d, gint action);
 static void colorize_cb(GtkWidget *w, gpointer d);
 
@@ -3870,6 +3872,7 @@
 gtk_action_set_sensitive (action, val); /* TRUE to make the action sensitive */
 }
 
+#if !defined(WANT_PACKET_EDITOR) || !defined(HAVE_AIRPCAP) || !defined(HAVE_LIBPCAP)
 static void
 set_menu_visible(GtkUIManager *ui_manager, const gchar *path, gint val)
 {
@@ -3883,8 +3886,8 @@
 }
 gtk_action_set_visible (action, val); /* TRUE to make the action visible */
 }
+#endif
 
-
 static void
 set_menu_object_data_meat(GtkUIManager *ui_manager, const gchar *path, const gchar *key, gpointer data)
 {
___
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] packet-mpeg-descriptor.c, unsused variable

[Martin Kaiser]

Dear all,

@Guy M: thanks a lot for the mpeg descriptor dissector, this is great!

while compiling it, I've got a warning == error about an unused variable
in the parental rating descriptor. Trivial patch attached,

thanks,

   Martin
Index: epan/dissectors/packet-mpeg-descriptor.c
===
--- epan/dissectors/packet-mpeg-descriptor.c	(revision 41602)
+++ epan/dissectors/packet-mpeg-descriptor.c	(working copy)
@@ -1152,12 +1152,9 @@
 void
 proto_mpeg_descriptor_dissect_parental_rating(tvbuff_t *tvb, guint offset, proto_tree *tree)
 {
-	guint8 rating = 0;
-
 	proto_tree_add_item(tree, hf_mpeg_descr_parental_rating_country_code, tvb, offset, 3, ENC_NA);
 	offset += 3;
 
-	rating = tvb_get_guint8(tvb, offset);
 	proto_tree_add_item(tree, hf_mpeg_descr_parental_rating_rating, tvb, offset, 1, ENC_NA);
 }
 
___
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] Mentioning encapsulation type in Protocol column

[Martin Kaiser]

Hi Lori and all,

Thus wrote Lori Jakab (lja...@ac.upc.edu):

 AFAIK, currently the protocol displayed in the Protocol column of
 Wireshark is that of the last dissector called on the packet. This makes
 it difficult to distinguish among packets with or without some type of
 encapsulation, unless filtering is employed. That is, a regular ICMP
 packet and a GRE encapsulated ICMP packet are both simply listed as ICMP.

 It would be a great feature to be able to see at a glance, when
 monitoring all traffic (especially with tshark), which packets are GRE
 or LISP (or any other encapsulating header) encapsulated. So, with the
 example above, instead of showing just ICMP, the Protocol field would
 display ICMP/GRE or ICMP/LISP.

 Is this possible with the current API?

probably not in the protocol column. Most (if not all) dissectors call
col_set_str(pinfo-cinfo, COL_PROTOCOL, my protocol); and clear the
previous content.

I just tried defining a custom column as follows
- select any packet
- open Frame in the tree
- select Protocols in Frame
- right click, Apply as column

That'll give you a colon-separated list of protocols in the column.
Hopefully, that's what you need.

Best regards,

   Martin
___
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] Data not getting formatted for custom columns added

[Martin Kaiser]

Thus wrote ashish goel (ashish.kumar.go...@gmail.com):

 I have defined some custom columns through preferences - Columns. and I
 want the data of these columns to be formatted as strings not raw bytes.
 I have used VALS() function in my dissector code while registering fields
 and it is working fine in the packet details window but in the columns the
 data is not formatted.

have a look at packet-dvbci.c, search for val_to_str_const() and
col_add_str()

is this what you need?
___
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] Unable to build wireshark-1.6.5

[Martin Kaiser]

Thus wrote Munish Dayal (munish.da...@aricent.com):

 I am unable to compile wireshark-1.6.5 source code due to the following error.
 Build environment is Linux RHEL5. The compilation machine is not connected to 
 the internet.

 Is there a way to bypass this step ?

 /usr/bin/perl ./tools/make-services.pl
 starting to fetch 
 http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
  ...
 request for 
 http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
  failed with result code:500 at ./tools/make-services.pl line 98.
 gmake[2]: *** [services] Error 9

I can't test this now, but could we just ignore the error from the make
target and continue anyway? IIRC this can be done (at least for gnu
make) by prefixing the rule with -

diff --git a/Makefile.am b/Makefile.am
index f79f5c4..ea3fa97 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -571,7 +571,7 @@ ps.c: print.ps $(srcdir)/tools/rdps.py
$(PYTHON) $(srcdir)/tools/rdps.py $(srcdir)/print.ps ps.c
 
 services: tools/make-services.pl
-   $(PERL) $(srcdir)/tools/make-services.pl
+   -$(PERL) $(srcdir)/tools/make-services.pl
 
 CLEANFILES =   \
*~  \

We'd need something similar for CMake and nmake, I don't know how that
works.
___
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] basic questions about writing dissectors

[Martin Kaiser]

Dear all,

I'm playing with some enhancements to my dissectors, some basic
questions came up:

Is it possible to add an element in the packet tree that has an hf entry
and can be filtered but does not have a corresponding tvb? I'm looking
at getting info from a circuit and add this to the tree as a filterable
element. For now, I read from the circuit, create a tvb, add another
data source for the tvb and dissect it. I was wondering if there's a
cleaner solution without adding a data source. (It looks like a tvb
that's not part of the packet itself needs a new data source).

It seems that a lot of dissectors use pinfo-fd-num without a previous
check if (pinfo  pinfo-fd). Is it safe to do so?

For se_malloc(), do I have to check the return value for NULL? I recall
that for g_malloc(), there's no need for a NULL check, the programs is
terminated when there's no memory.

Thanks in advance for your help,

   Martin
___
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] basic questions about writing dissectors

[Martin Kaiser]

Hi Joerg,

thanks for your quick reply.

Thus wrote Joerg Mayer (jma...@loplof.de):

 Take a look at packet-extreme.c and search for hf_edp_checksum_good
 (similar code can be found in other dissectors). The core point is
 setting the item to PROTO_ITEM_SET_GENERATED. Does this do what you
 want?

The checksum ok? item is not directly taken from the tvb but it is
still linked to a part of the tvb, the checksum itself.

In my case, I don't have any tvb but a value in a guint32. I've had
another look and guess that

it = proto_tree_add_uint_format(tree, hf_myproto_myfilter,
  NULL, 0, 0, value from the guint32, ...);

does what I want. My understanding is that I can pass tvb==NULL if
length==0 as well. The value is assigned to the hf without any reference
to a tvb. I'd then set PROTO_ITEM_SET_GENERATED(it) on the result.

 I haven't verfied this, but as pinfo-fd-num ist the frame number it seems
 to be extremely likely to be safe :-)

ok, null checks removed

 I assume you mean se_alloc(). epan/emem.c internally uses g_malloc unless
 some special steps are taken (debugging).

ok, understood

Best regards,

   Martin
___
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] packet-mip, vendor_id, r41171

[Martin Kaiser]

Hi,

I get a warning(==eror) compiling the latest svn

[  5%] Building C object
epan/CMakeFiles/epan.dir/dissectors/packet-mip.c.o
/home/martin/wireshark.svn/epan/dissectors/packet-mip.c:
In function 'dissect_mip_extensions':
/home/martin/wireshark.svn/epan/dissectors/packet-mip.c:424:11:
error: variable 'nvse_vendor_id' set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

It looks like this was introduced in r41171.

nvse_vendor_id is really not used, but the actual id is stored in an hf
and and added to the tree. Could we just remove nvse_vendor_id? Patch attached.

Best regards,

   Martin
Index: epan/dissectors/packet-mip.c
===
--- epan/dissectors/packet-mip.c	(revision 41173)
+++ epan/dissectors/packet-mip.c	(working copy)
@@ -421,7 +421,6 @@
   gint  hdrLen;
   guint32   cvse_vendor_id;
   guint16   cvse_vendor_type;
-  guint32   nvse_vendor_id;
   guint16   nvse_vendor_type;
   int   cvse_local_offset= 0;
   int   nvse_local_offset= 0;
@@ -648,7 +647,6 @@
   /*Vendor ID  nvse type  nvse value are included in ext_len, so do not increment offset for them here.*/
   nvse_local_offset = offset + hdrLen;
   proto_tree_add_item(ext_tree, hf_mip_nvse_vendor_org_id, tvb, nvse_local_offset, 4, ENC_BIG_ENDIAN);
-  nvse_vendor_id = tvb_get_ntohl(tvb, nvse_local_offset);
   nvse_local_offset+=4;
 
   /*Vendor NVSE Type*/
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Decode MTP3 message

[Martin Kaiser]

Thus wrote Anya Verizi (anya_ver...@hotmail.com):

 Can anyone know how I can decode MTP3 message? For example I put code
 in txt file and then to pcap (text2pcap -l 141 file.txt file.pcap
 ), but when I open it in wireshark I got malformed packet:ISUP? Do I
 )must put some in txt file before?

in the input file for text2pcap, each line must start with an offset
e.g. if your packet contains 0x1 0x2, the input line for text2pcap should be

00  0x01 0x02

can you run tshark -r your pcap file -V -x and post the output for one
malformed packet?

___
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] Decode MTP3 message

[Martin Kaiser]

Thus wrote Anya Verizi (anya_ver...@hotmail.com):

 I have to decode this sequence 02 00 10 c0 00 19 81 0f 0f 00 2c 01 01 11 02 
 16 00 00 but when I put it in txt and run as pcap I got this

 Frame 1 (23 bytes on wire, 23 bytes captured)
 Arrival Time: Feb 24, 2012 13:38:09.0
 [Time delta from previous captured frame: 0.0 seconds]
 [Time delta from previous displayed frame: 0.0 seconds]
 [Time since reference or first frame: 0.0 seconds]
 Frame Number: 1
 Frame Length: 23 bytes
 Capture Length: 23 bytes
 [Frame is marked: False]
 [Protocols in frame: mtp3:isup]
 Message Transfer Part Level 3
 Service information octet
 00..  = Network indicator: International network (0x00)
 ..00  = Spare: 0x00
  0101 = Service indicator: ISUP (0x05)
 Routing label
     ..00    = DPC: 0
     00..    = OPC: 0
         = Signalling Link Selector: 0
 ISDN User Part
 CIC: 2
 Message type: Release complete (16)
 Pointer to start of optional part: 192
 [Malformed Packet: ISUP]
 [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
 [Message: Malformed Packet (Exception occurred)]
 [Severity level: Error]
 [Group: Malformed]

   05 00 00 00 00 02 00 10 c0 00 19 81 0f 0f 00 2c   ...,
 0010  01 01 11 02 16 00 00  ...

I tried your sequence

[martin@homePc]$ cat a.t2p 

00   02 00 10 c0 00 19 81 0f 0f 00 2c 01 01 11 02 16 00 00

[martin@homePc]$ ./text2pcap -l 141 !$ a.pcap

[martin@homePc ]$ ./tshark -r a.pcap -V -x

Frame 1: 18 bytes on wire (144 bits), 18 bytes captured (144 bits) on
interface 0
Interface id: 0
Arrival Time: Feb 24, 2012 14:57:52.0 CET
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1330091872.0 seconds
[Time delta from previous captured frame: 0.0 seconds]
[Time delta from previous displayed frame: 0.0 seconds]
[Time since reference or first frame: 0.0 seconds]
Frame Number: 1
Frame Length: 18 bytes (144 bits)
Capture Length: 18 bytes (144 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: mtp3:mtp3mg]
Message Transfer Part Level 3
Service information octet
00..  = Network indicator: International network (0x00)
..00  = Spare: 0x00
 0010 = Service indicator: Maintenance Special Message
(MTNS) (0x02)
Routing label
    ..01    = DPC: 4096
Signalling Area Network Code (SANC): Liechtenstein
(Principality of) (2-000)
Unique Signalling Point Name: LTN ISC Vaduz
Signalling Point Operator Name: LTN Liechtenstein TeleNet AG
  1100  00..    = OPC: 768
Signalling Area Network Code (SANC): Unknown (0-096)
Unique Signalling Point Name: Unknown
Signalling Point Operator Name: Unknown
        = Signalling Link
Selector: 0
Message Transfer Part Level 3 Management
 1001 = H0 (Message Group): Unknown (0x09)
Unknown message (13 bytes)

  02 00 10 c0 00 19 81 0f 0f 00 2c 01 01 11 02 16   ..,.
0010  00 00 ..


your problem is the leading 05 00 00 00 00 bytes
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] pcapng, must opt_commentstring?be?0-terminated?

[Martin Kaiser]

Hi Chris,

Thus wrote Chris Maynard (chris.mayn...@gtech.com):

 Martin Kaiser lists@... writes:

  I was wondering why we need a static buffer at all. It looks like the
  intention is to keep using the same buffer for each option that we
  parse. When reading an option, how about checking the length first and
  then allocating the buffer dynamically? We could then remove the
  g_strdup() as well and use the allocated buffer to pass the option on to
  wiretap etc.

 Your suggestion sounds good to me.

  My understandig is that g_strdup() allocates a copy that the caller must
  free. I don't think that at the moment, anybody is freeing the copy for
  the comment (or for any other option).

 If there's a leak, then that should be fixed.  Care to open a bug report and
 submit a patch?

sure, I'll look into this. I hope that at FOSDEM, we can discuss my proposed
approach for getting the comment from pcapng-wiretap-capture_file, see
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3096
Once we've agreed on a way forward, I'll see how the g_strdup()s can be
replaced.

Best regards,

   Martin
___
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] Conference room before FOSDEM

[Martin Kaiser]

Dear all,

Thus wrote Graham Bloice (graham.blo...@trihedral.com):

 As the FOSDEM Friday beer event, http://fosdem.org/2012/beerevent takes
 place at Delirium I'm not intending to miss it.

that's for sure, we have to be there and see how many of the 2000
different beers are actually in stock ;-)

To keep us busy until the beer event starts, I've made a list of
of things I'd like to discuss

- opt_comment read patch
   https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3096

   is the general idea behind this ok for you? what can I do to brush up
   the gtk-parts (tooltip etc)?

   I played with writing support as well, I'd appreciate a chat about
   the approach.

- file format plugin

   For my daily job, I worked on a plugin for a (company-internal) file
   format. After some trial and error, it works ok.

   My impression is that there's plenty of documentation and examples
   for dissector and tap plugins, but very little for file format
   plugins.

   Should we improve the documentation and provide a framework and
   sample code? Do we need something like tools/make-dissector-reg for
   file format plugins?

- is it possible to define ASN.1 objects that are used only inside a
  certain dissector and are invisible to the rest of wireshark?

- crash when packets are re-dissected after display filter or
  preference change

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5284  or
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6031
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6172

  this is the wireshark bug I've seen most often. I have the impression
  that it's easy to trigger from my DVB-CI dissector. I'd like to
  understand what I can do to help resolving it.


I look forward to meeting you,

   Martin
___
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] warning in packet-rohc, r40673

[Martin Kaiser]

Hi Anders and all,

I get a warning (treated as an error)

martin@greta:~/src/wireshark.svn$ svn info
...
Last Changed Author: etxrab
Last Changed Rev: 40673
Last Changed Date: 2012-01-23 22:13:10 +0100 (Mon, 23 Jan 2012)

martin@greta:~/src/wireshark.svn$ uname -a
Linux greta 2.6.32-5-amd64 #1 SMP Thu Nov 3 03:41:26 UTC 2011 x86_64 
GNU/Linux

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I./../.. -I./.. 
-I/usr/local/include -I/usr/include 
-DPLUGIN_DIR=\/usr/local/lib/wireshark/plugins/1.7.1\ -Werror -DINET6 
-DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE 
-DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES -D_FORTIFY_SOURCE=2 
-D_U_=__attribute__((unused)) -g -O2 -Wall -W -Wextra 
-Wdeclaration-after-statement -Wendif-labels -Wpointer-arith -Wno-pointer-sign 
-Warray-bounds -Wcast-align -Wformat-security -Wold-style-definition 
-I/usr/local/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
-I/usr/include -MT libdissectors_la-packet-rohc.lo -MD -MP -MF 
.deps/libdissectors_la-packet-rohc.Tpo -c packet-rohc.c  -fPIC -DPIC -o 
.libs/libdissectors_la-packet-r
 ohc.o
cc1: warnings being treated as errors
packet-rohc.c: In function dissect_rohc_ir_rtp_udp_profile_static:
packet-rohc.c:1019: error: protocol may be used uninitialized in this function
make[5]: *** [libdissectors_la-packet-rohc.lo] Error 1


Would sth simple like this be ok as a fix?

Best regards,

   Martin

Index: epan/dissectors/packet-rohc.c
===
--- epan/dissectors/packet-rohc.c   (revision 40673)
+++ epan/dissectors/packet-rohc.c   (working copy)
@@ -1016,7 +1016,7 @@
 
 proto_item *item, *ipv4_item, *udp_item, *rtp_item;
 proto_tree *sub_tree=NULL, *static_ipv4_tree, *static_udp_tree, 
*static_rtp_tree;
-guint8 version, protocol;
+guint8 version, protocol = IP_PROTO_IP;
 int start_offset, tree_start_offset;
 
 start_offset = offset;



___
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] Conference room before FOSDEM

[Martin Kaiser]

Hi Gerald,

Thus wrote Gerald Combs (ger...@wireshark.org):

 Can any developer who is attending FOSDEM *and* would like to meet at
 the hotel on Friday the 3rd send me an email? I'm working on booking a
 conference room for the day and need to size the room accordingly.

you can count me in, I'll be there on the 3rd.

Thanks  Best regards,

   Martin
___
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] Dates for FOSDEM 2012: 4 5 February

[Martin Kaiser]

Thus wrote Joerg Mayer (jma...@loplof.de):

 On Tue, Jan 17, 2012 at 03:17:48PM -0800, Gerald Combs wrote:
  I've stayed at the Novotel Brussels Centre Tour Noire, which was nice.
  It looks like it's within walking distance of the Friday event:

  http://www.accorhotels.com/gb/hotel-2122-novotel-brussels-centre-tour-noire/index.shtml

  I'm still working out my schedule but will probably arrive on Thursday
  and leave on Monday.

 OK, I'Ve booked the hotel from Thu 2nd - Sun 5th.

Same for me, Thu to Sun

   Martin
___
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] Fwd: [FOSDEM] Dates for FOSDEM 2012: 4 5 February

[Martin Kaiser]

Thus wrote Gerald Combs (ger...@wireshark.org):

 On 1/5/12 3:19 AM, Sake Blok wrote:
  Gerald,

  Are plans to meet around FOSDEM finalized? For me it would be possible to 
  meet up during the day on Friday 3rd (after which we could join the FOSDEM 
  Beer Event :-)). I could either drive up early on Friday or come Thursday 
  in the afternoon. If we plan something like that, I think it would be best 
  to stay in the same hotel with all who are coming. 

 I'm still finalizing my travel arrangements but I was planning on being
 in Brussels from the 2nd or 3rd to the 5th.

I've just booked my flights, I'll be in Brussels from the 2nd to the
5th. 3rd as proposed by Sake would be ideal for me.

Best regards,

   Martin
___
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] pcapng, must opt_comment string be?0-terminated?

[Martin Kaiser]

Thus wrote Chris Maynard (chris.mayn...@gtech.com):

 To avoid the possibility of reading past the end of option_content in
 the case when oh.option_length  sizeof(option_content), I think it
 would be safer to do this instead:

 wblock-data.packet.opt_comment = g_strndup(option_content,
 MIN(oh.option_length, sizeof(option_content)))

 Note that this can't happen today because if the option length is greater than
 sizeof(option_content), then we never get there,

yes, I saw the check before the g_strndup()

 but I think the implementation would work better to read as much as
 will fit into the buffer as possible, in this case the 1st 99
 characters of the string (plus the NULL-terminator), rather than
 skipping it altogether.  The comment next to option_content indicates,
 XXX - size might need to be increased, if we see longer options, so
 it's apparently a somewhat arbitrary limit.  I think as pcapng sees
 more and more use, it's only a matter of time before longer and longer
 strings are added (or desired to be added).  Even the examples shown
 at the end of section 2.5 of the pcapng spec illustrate some strings
 approaching that limit, and those strings do not seem overly long to
 me:

 This packet is the beginning of all of our problems / Packets 17-23 
 showing a
 bogus TCP retransmission, as reported in bugzilla entry 1486! / Captured at
 the southern plant / I've checked again, now it's working ok / ...

You're right, 100 characters seems arbitrary and probably too small for
many cases.

I was wondering why we need a static buffer at all. It looks like the
intention is to keep using the same buffer for each option that we
parse. When reading an option, how about checking the length first and
then allocating the buffer dynamically? We could then remove the
g_strdup() as well and use the allocated buffer to pass the option on to
wiretap etc.

My understandig is that g_strdup() allocates a copy that the caller must
free. I don't think that at the moment, anybody is freeing the copy for
the comment (or for any other option).

Best regards,

   Martin
___
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] Fwd: [FOSDEM] Dates for FOSDEM 2012: 4 5 February

[Martin Kaiser]

Hello Gerald and all,

Thus wrote Gerald Combs (ger...@wireshark.org):

 Sorry for taking so long to get back to you on this. We don't have a
 devroom, but we might be able to find a spot in one of the existing
 rooms. Alternatively I might be able to reserve a conference room at a
 nearby hotel.

 I realize it's now short notice, but can anyone interested in meeting
 at FOSDEM send an email to -dev or to me directly with the dates you can
 attend? The main event is February 4 and 5 in Brussels, but we could
 also meet on the 3rd or 6th if that's more convenient.
 http://fosdem.org/2012/

I'm still interested in meeting at or around Fosdem. Any of 3rd-6th
would be ok. When we fix a date, I can organize my trip.

I'll try to prepare some questions and ideas before the meeting.

Best regards,

   Martin
___
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] non-official X.509 certificate extensions

[Martin Kaiser]

Dear all,

I would like to add ASN.1 definitions for some non-official certificate
extensions. They should be visible and usable by one certain dissector
but not disturb everyone else.

It seems that some extensions have their own asn1/... subdirectory but
they're globally visible. Could I create a similar subdirectory for my
extensions and define an on/off preference in the ...-template.c
file or is there a better way to really link the extensions to a
dissector?

Thanks,

   Martin
___
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] RSASSA-PSS (bug #6541)

[Martin Kaiser]

Dear all,

I'm trying to add support for RSASSA-PSS signatures in X.509
certificates. It's in a state where things are working for me, but I'm
not sure that I understood the ASN.1 handling in wireshark well enough.

Could anybody who's familiar with ANS.1 dissection spare some minutes
and look at #6541 in the bugtracker? I'd appreciate feedback about
what's required to make this contribution ready for checkin.

The reason I'd like to have this included is that the certificates used
by CI+ (about 100 mio are in use now) have PSS signatures. The DVB-CI
dissector could then make use of the x509 dissection...

Thanks for your help,

   Martin
___
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] compile warning/error on current svn (make_menu_actions)

[Martin Kaiser]

Dear all,

compiling r39420 fails for me on redhat fc 15.

main_menubar.c:3698:1: error: 'make_menu_actions' defined but not used
[-Werror=unused-function]

In main_menubar.c, the only place where make_menu_actions() is called
is inside an #ifdef HAVE_LUA_5_1.

Should we have #ifdef HAVE_LUA_5_1 around the function definition as
well?

Best regards,

   Martin
___
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] Send info to plugin

[Martin Kaiser]

Thus wrote Guy Harris (g...@alum.mit.edu):

 We should probably also add a notion of conversations available to
 dissectors at multiple layers (a notion more general than the current
 address-and-port-endpoint-pair notion, that can include multiple
 address layers, circuits for protocols that have a virtual circuit
 ID of some sort, and conversations at layers above the transport
 layer)

that would definitely be helpful.

As far as I can see, DVB-CI is an example that does not fit into the
current mechanism very well. CI is not based on tcp/ip, a ci session
looks like

open_session_request(resource_id)
session_opened(newly assigned session number)

payload transfer(session_number, payload data)
...

close session(session_number)


For now, how would you create a conversation from this? I've been
playing with a new port_type PT_DVBCI_SESSION_NUMBER and set both source
and destination port to the session number. Does that make sense or is
there a better approach?

Thanks,

   Martin
___
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 39143: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dvbci.c

[Martin Kaiser]

Hi^2,

Thus wrote Maynard, Chris (christopher.mayn...@gtech.com):

 So that would be option (c) then?
 c) Define ENC_NA differently from both ENC_LITTLE_ENDIAN and ENC_BIG_ENDIAN.

ah, ENC_NA == ENC_BIG_ENDIAN == 0x0 at the moment. That's the problem
you mentioned in your 1st mail?

 The impact of this would imply these other changes:

 For every proto_tree_add_*() function:
 - Change the const gboolean little_endian argument to something like gint 
 endian
 - Verify endian is valid for the given FT_ and choke on invalid ones.

You would then check explicitly that for FT_BYTES, ENC_NA is set and for
FT_(U)INT16/32/.. encoding != ENC_NA?

That sounds good. People will realize more quickly when they got it
wrong.

Best regards,

   Martin
___
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 39143: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-dvbci.c

[Martin Kaiser]

Dear all,

I wanted to discuss this as well to make sure that my next submissions
are in line with your policy, but you were faster ;-)

Thus wrote Maynard, Chris (christopher.mayn...@gtech.com):

  -Original Message-

   From me:
   Change ENC_NA to ENC_BIG_ENDIAN as i suppose this is a big endian
  protocol and ENC_NA was erroneously used for irems bigger than i
  byte
  in some cases.

 This is a good example of the problem that can occur with using
 ENC_NA.

What problem can occur with ENC_NA here?

My assumption was that ENC_BIG_ENDIAN/_LITTLE_ENDIAN is only applicable
to multi-byte numeric values, i.e. FT_(U)INT16/32/64. For FT_(U)INT8 and
FT_BYTES, FT_STRING etc., I used ENC_NA.

Anders' assumption is correct: all multi-byte values in DVB-CI are big
endian.

Best regards,

   Martin
___
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] Fwd: [FOSDEM] Dates for FOSDEM 2012: 4 5 February

[Martin Kaiser]

Hi Gerald and all,

Thus wrote Gerald Combs (ger...@wireshark.org):

 Would anyone be interested in meeting at FOSDEM in February for a
 Wireshark Bug Day? As I recall, someone suggested this at Sharkfest.

I'd be happy to join this and get to know the wireshark people in
person.

Best regards,

   Martin
___
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] strange crash when a display filter is cleared on a reassembled packet

[Martin Kaiser]

Hmm, no response...

I wasn't expecting people to spend time on reproducing this but I was
hoping that the backtrace would ring a bell for someone.

Yesterday, I played with DLNA traces and various wireshark versions
(down to 1.4.8). There's also been regular crashes when I cleared
display filters :-(

So I'm tempted to say it's unrelated to my DVB-CI code but it's
something particular for the FC15 box I'm running

BTW another backtrace for the DVB-CI scenario described below is 

#0  0x41427f4a in IA__gtk_label_new (str=
0x2e2e202e Address 0x2e2e202e out of bounds) at gtklabel.c:1398
#1  0x0809e68e in add_byte_tab (byte_nb=0x8cc2048 [GtkNotebook], name=
0x2e2e202e Address 0x2e2e202e out of bounds, tvb=0x2e2e3030, tree=
0xb7af1000, tree_view=0x8cb8208 [GtkTreeView]) at
main_proto_draw.c:708
#2  0x080a04a1 in add_byte_views (edt=0x8d66548, tree_view=
0x8cb8208 [GtkTreeView], byte_nb_ptr=0x8cc2048 [GtkNotebook])
at main_proto_draw.c:801
#3  0x080a04f1 in add_main_byte_views (edt=0x8d66548) at
main_proto_draw.c:779

in add_byte_views():

(gdb) print edt-pi.data_src
$7 = 0x8d3e720 = {0xb70f3000, 0xb70f301c, 0xb70f3038}
- that's the Frame, reassembled TPDU and reassembled SPDU data sources

(gdb) print *(data_source *)0xb70f3000
$8 = {tvb = 0x8dcec90, name_initialized = 0, name = 0x14d40c7 Frame}
(gdb) print *(data_source *)0xb70f301c
$9 = {tvb = 0x2e2e3030, name_initialized = 774778400, name = 
0x2e2e202e Address 0x2e2e202e out of bounds}
- this one's content is invalid and still passed on to other routines,
   leading to a crash

Any idea how to shed some light on this?

Best regards,

   Martin

Thus wrote Martin Kaiser (li...@kaiser.cx):

 Dear all,

 I'm struggling with a strange crash, I'd really appreciate your help.

 It may be that my DVB-CI dissector, other parts of wireshark or my
 system configuration is at fault...

 current svn on a Fedora Core 15 linux
 TShark 1.7.0 (SVN Rev Unknown from unknown)

 Copyright 1998-2011 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 (32-bit) with GLib 2.28.8, with libpcap 1.1.1, with libz 1.2.5,
 with POSIX capabilities (Linux), with threads support, without libpcre,
 without SMI, without c-ares, without ADNS, without Lua, with Python
 2.7.1, with GnuTLS 2.10.5, with Gcrypt 1.4.6, with MIT Kerberos, without
 GeoIP.
 Running on Linux 2.6.40-4.fc15.i686.PAE, with locale en_US.UTF-8, with
 libpcap version 1.1.1, with libz 1.2.5.
 Built using gcc 4.6.0 20110603 (Red Hat 4.6.0-10).


 The problem can be reproduced by setting a display filter to
 dvb-ci.apdu_tag
 so that only APDUs are displayed

 Next, load http://www.kaiser.cx/misc/crash5.pcap, select packet 53
 (Profile Information) and click on Clear to clear the display filter

 This causes a segfault, backtrace is

 #0  ensure_contiguous_no_exception (tvb=0xcb5af808, offset=0, length=-1, 
 exception=0xbfffd4dc) at tvbuff.c:852
 #1  0x0072e2c3 in ensure_contiguous (tvb=optimized out, 
 offset=optimized out, length=-1) at tvbuff.c:887
 #2  0x080a01f9 in get_byte_view_data_and_length (byte_view=
 0x8cc62f8 [GtkTextView], data_len=0xbfffd53c) at


 Packet 53 is reassembled on both session and transport layer
 There are 3 data sources: Frame (13 Bytes), reassembled tpdu (35 bytes),
 reassembled spdu (128 bytes).

 Setting a breakpoint in ensure_contiguous_no_exception() before pressing
 the clear button shows the following


 - the Frame (13 bytes)
 (gdb) print *tvb
 $12 = {type = TVBUFF_REAL_DATA, initialized = 1, usage_count = 2, ds_tvb = 
 0x8dd6cc8, used_in = 0x8dc5708 = {0x8dd6c20}, tvbuffs = {subset = {tvb = 
 0x, offset = 1710618, length = 437918234}, composite = {tvbs = 0x = 
 {error reading variable}, real_data = 0x822581c , length = 13, 
 reported_length = 13, raw_offset = 0, free_cb = 0}
 (gdb) cont 
 Continuing.

 - Reassembled TPDU (35 Bytes)
 Breakpoint 2, ensure_contiguous_no_exception (tvb=0x8dd6c58, offset=0,
 length= -1, exception=0xbfffd4dc) at tvbuff.c:849 849 {
 (gdb) print *tvb
 $13 = {type = TVBUFF_REAL_DATA, initialized = 1, usage_count = 2, ds_tvb = 
 0x8dd6c58, used_in = 0x8dbc018 = {0x8ddde78}, tvbuffs = {subset = {tvb = 
 0x, offset = 1710618, length = 437918234}, composite = {tvbs = 0x = 
 {error reading variable}, real_data = 0x8cd0aa8  !\001, 'ÿ' repeats 32 
 times, length = 35, reported_length = 35, raw_offset = 0, free_cb = 0}

 - next, ensure_contiguous_no_exception() is called with an illegal
 address as tvb *

 Breakpoint 2, ensure_contiguous_no_exception (tvb=0xb7e82720, offset=0,
 length= -1, exception=0xbfffd4dc) at tvbuff.c:849 849 {
 (gdb) print *tvb
 $14 = {type = 16927523, initialized = 16927530, usage_count = 16927537, 
 ds_tvb = 0x1024b38, used_in = 0x1024b3f = {0x14244489, error reading 
 variable

 (on some occassions, the tvb address