[Wireshark-dev] C++ program usig editcap

2009-03-20 Thread SOLTANI FATEN
Hello all,
I'll need to use the EDITCAP to convert files from ASCII format to pcap format, 
I need a help about writing a C++ program, where I call the editpcap function, 
and where the input file must be located(in the same folder as the function 
editpcap?).
Thanks for any help


-Message d'origine-
De : wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] De la part de 
wireshark-dev-requ...@wireshark.org
Envoyé : jeudi 19 mars 2009 20:00
À : wireshark-dev@wireshark.org
Objet : Wireshark-dev Digest, Vol 34, Issue 45

Send Wireshark-dev mailing list submissions to
wireshark-dev@wireshark.org

To subscribe or unsubscribe via the World Wide Web, visit
https://wireshark.org/mailman/listinfo/wireshark-dev
or, via email, send a message with subject or body 'help' to
wireshark-dev-requ...@wireshark.org

You can reach the person managing the list at
wireshark-dev-ow...@wireshark.org

When replying, please edit your Subject line so it is more specific
than Re: Contents of Wireshark-dev digest...


Today's Topics:

   1. Re: XML parsing (Jeff Morriss)
   2. ESP decoding capabilities (Vincent Helfre)
   3. g_snprintf() and sizeof (Guy Harris)


--

Message: 1
Date: Thu, 19 Mar 2009 10:52:23 -0400
From: Jeff Morriss jeff.morriss...@gmail.com
Subject: Re: [Wireshark-dev] XML parsing
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Message-ID: 49c25c27.9030...@gmail.com
Content-Type: text/plain; charset=UTF-8; format=flowed



Abhik Sarkar wrote:
 Hi Everyone,
 
 This is a question specifically to the core developers. Would it be OK 
 to use the GMarkupParser facility which is provided by the latest glib 
 that is part of the required libraries for the development version? I 
 want to use it to read XML configuration files for a generally available 
 dissector.

Define latest.  (I looked through the GLIB documentation and their 
list of symbols new to each release and at least some of the markup 
functions have been around for a while.)


--

Message: 2
Date: Thu, 19 Mar 2009 17:25:36 +0100
From: Vincent Helfre vincent.hel...@gmx.net
Subject: [Wireshark-dev] ESP decoding capabilities
To: wireshark-dev@wireshark.org
Message-ID: 20090319162536.102...@gmx.net
Content-Type: text/plain; charset=iso-8859-1

Hi all,
I used once in a while the ESP decoding capability on Wireshark, and it seems 
it does not work anymore. Could anyone familiar with IPSec help me have a look 
at that? I raised the bug report 2943 and attached a log with the keys, so it 
is possible to test it. It used to work on version 0.99.8 but does not on 
version 1.1.2 and later.

BRs,
Vincent 
-- 
Pt! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01


--

Message: 3
Date: Thu, 19 Mar 2009 11:12:03 -0700
From: Guy Harris g...@alum.mit.edu
Subject: [Wireshark-dev] g_snprintf() and sizeof
To: wireshark-dev@wireshark.org
Message-ID: 09de2876-f92f-43a4-8e16-df84e23af...@alum.mit.edu
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes


On Mar 19, 2009, at 10:44 AM, wme...@wireshark.org wrote:

 -As suggested by Jakub Zawadzki: use sizeof(...) rather than a  
 numeric constant in various places;

Warning: g_snprintf()'s function signature has an annoying botch in it  
- the size argument is a gulong, not a gsize.

Not a problem in the UN*X and Windows ILP32 environment and in the  
UN*X LP64 environment, but it causes the Microsoft compiler to  
(correctly) warn about a conversion from a 64-bit integer to a 32-bit  
integer in the Windows LLP64 environment.  Cast sizeof - or any other  
size_t value - to (gulong) before passing it as the length argument to  
g_snprintf().


--

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


End of Wireshark-dev Digest, Vol 34, Issue 45
*
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] C++ program usig editcap

2009-03-20 Thread Richard Sharpe
On Fri, Mar 20, 2009 at 1:51 AM, SOLTANI FATEN
faten.solt...@alcatel-lucent.com wrote:
 Hello all,
 I'll need to use the EDITCAP to convert files from ASCII format to pcap 
 format, I need a help about writing a
 C++ program, where I call the editpcap function, and where the input file 
 must be located(in the same folder as
 the function editpcap?).
 Thanks for any help

Hmmm, I can vaguely recall writing editcap a long time ago now, and I
just checked the man page again, but I don't think that it does what
you want.

Perhaps you are thinking of text2pcap.

In any event, these programs are not designed as libraries, although
perhaps they should have been. They are simple main programs on their
own.

Have you considered a batch file or one of the other scripting
languages available under Unix and Windows?

For general questions on programming (under Windows perhaps) I suggest
that you search the Web. There are many pages showing you how to run
one program from another.

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


Re: [Wireshark-dev] [Wireshark-commits] rev 27790: /trunk/ /trunk/epan/crc/: Makefile.am Makefile.common Makefile.nmake crc-16-plain.c crc-16-plain.h /trunk/epan/: Makefile.am Makefile.nmake crc16.c c

2009-03-20 Thread Ulf Lamping
ger...@wireshark.org schrieb:
 http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=27790
 
 User: gerald
 Date: 2009/03/18 02:59 PM
 
 Log:
  Create an epan/crc directory for CRC code. Add crc-16-plain.[ch],
  generated from pycrc. The command line used to generate the file is in
  epan/crc/Makefile.common. I used plain to distinguish it from CCITT,
  USB, and other 16-bit CRCs. Integrate the new CRC code into our
  infrastructure.
  
  Add crc16_plain_tvb_offset() to epan/crc16.[ch] and use it in
  plugins/profinet/packet-pn-rt.c. This _should_ work correctly, but
  hasn't been tested.

Hi!

I've just checked your CRC changes and it's looking good.

I've removed the CRC GPLv2 code from the PROFINET plugin.


Thanks a lot for your work on this task. My feeling is that this 
solution is now much better than having more or less generic CRC code in 
the PN dissector anyway :-)

Regards, ULFL
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Help on NBAP

2009-03-20 Thread tulip neo
Hi List,
I need help to understand how Transportlayeraddress is 
decoded.TransportLayerAddress is per bit string (20 ocetet) which is decoded as 
follows:
 
transportLayerAddress 350001 : 10.3.35.131
How ever the 20 octet for transportlayer address is
 
35 00 01 0a 03 23 83 00 00 00 00 00 00 00 00 00 00 00 00 00.
 
I guess its decoded as port number:ip address
 
Can any one give me pointer how ip address can be fetched from 
transportlayeraddress?
in this case ide decodes it decodes first 3 ocetet as port number or some thing 
else.?
next 4 ocetet is converted to dotted decimal ip address.
 
can any one give me some pointer where i can find info about composing 
transportlayeraddress to port number(as i guess) and ip address.
How if there are no octetes after 7 octets having 00 value. i mean if we have 
transportlayeraddress as 35 00 01 0a 03 23 83 11 22 33 44 55 66 77 88 99 11 22 
33 44.
link where u can see the decoding is as folows:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1951
here soem decoding logs are given where transpostlayeraddress is decoded as
transportLayerAddress 350001 : 10.3.35.131
 
Br
Tulip
 
 
 


  Check out the all-new Messenger 9.0! Go to http://in.messenger.yahoo.com/___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Changing the column setting API

2009-03-20 Thread Stig Bjørlykke
2009/1/21 Jaap Keuter jaap.keu...@xs4all.nl:
 In the course of fixing bug 2902
 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2902) a proposal was made
 to change the API of the column setting functions.

Hi,

I have committed this check in revision 27806.  Please have a check if
we should add this to more functions.  Cleaner code is always good.


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


Re: [Wireshark-dev] Help on NBAP

2009-03-20 Thread Anders Broman
Hi,
TS 25.433
-- Snip --
9.2.1.63 Transport Layer Address

In case of transport bearer establishment with ALCAP [2][31], this IE
contains the address to be used for Transport

Network Control Plane signalling to establish the transport bearer
according to [2][31].

In order to allow transport bearer establishment without ALCAP, this IE
contains the address of the transport bearer to

be used for the user plane transport.

For details on the Transport Address used see ref. [2][31].

--- End Snip ---

[2}  3GPP TS 25.426: UTRAN Iur and Iub Interface Data Transport 
Transport Signalling for DCH Data Streams.

[31]  3GPP TS 25.434: UTRAN Iub Interface Data Transport  Transport
Signalling for Common Transport Channel Data Streams .

BIT STRING (1..160, ...)

I have not checked the referenced dockuments. But I guess the content
depends on the context.

Regards

Anders




From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of tulip neo
Sent: den 20 mars 2009 13:21
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Help on NBAP


Hi List,
I need help to understand how Transportlayeraddress is
decoded.TransportLayerAddress is per bit string (20 ocetet) which is
decoded as follows:
 
transportLayerAddress 350001 : 10.3.35.131
How ever the 20 octet for transportlayer address is
 
35 00 01 0a 03 23 83 00 00 00 00 00 00 00 00 00 00 00 00 00.
 
I guess its decoded as port number:ip address
 
Can any one give me pointer how ip address can be fetched from
transportlayeraddress?
in this case ide decodes it decodes first 3 ocetet as port number or
some thing else.?
next 4 ocetet is converted to dotted decimal ip address.
 
can any one give me some pointer where i can find info about composing
transportlayeraddress to port number(as i guess) and ip address.
How if there are no octetes after 7 octets having 00 value. i mean if we
have transportlayeraddress as 35 00 01 0a 03 23 83 11 22 33 44 55 66 77
88 99 11 22 33 44.
link where u can see the decoding is as folows:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1951
here soem decoding logs are given where transpostlayeraddress is decoded
as
transportLayerAddress 350001 : 10.3.35.131
 
Br
Tulip
 
 
 



Connect with friends all over the world. Get Yahoo! India Messenger.
http://in.rd.yahoo.com/tagline_messenger_1/*http://in.messenger.yahoo.c
om/?wm=n/ 
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] Unresolved call_dissector_only issue

2009-03-20 Thread Sean

I have another suggestion regarding this issue,
Do you have any plan on exporting function req_resp_hdrs_do_reassembly?
It seems that sometimes the plugins want to call this interface.



--- On Mon, 3/16/09, Maynard, Chris christopher.mayn...@gtech.com wrote:

 From: Maynard, Chris christopher.mayn...@gtech.com
 Subject: Re: [Wireshark-dev] Unresolved call_dissector_only issue
 To: Developer support list for Wireshark wireshark-dev@wireshark.org
 Date: Monday, March 16, 2009, 1:20 AM
 
 
 
  
  
 
 
 
 
 
 
 
  
 
 
 
 epan/libwireshark.def did not include call_dissector_only in
 1.0.4. 
 
    
 
    
 
 
 
 
 
 
 
 From:
 wireshark-dev-boun...@wireshark.org
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf
 Of philippe
 alarcon
 
 Sent: Sunday, March 15, 2009 12:04 PM
 
 To: wireshark-dev
 
 Subject: Re: [Wireshark-dev] Unresolved
 call_dissector_only issue 
 
 
 
 
 
    
 
 Hi Sean,
 
 
 
 Have you include packet.h file ?
 
 
 
 #include epan/packet.h
 
 
 
 Regards
 
 Philippe
 
 
 
 
 
 
 
  Date: Sun, 15 Mar 2009 06:23:03 -0700
 
  From: yun...@yahoo.com
 
  To: wireshark-dev@wireshark.org
 
  Subject: [Wireshark-dev] Unresolved
 call_dissector_only issue
 
  
 
  
 
  Hi,
 
  
 
  I'm working on an external dissector, and I want
 to call another dissector
 from my dissector,
 
  but when I use the function call_dissector_only,
 
  the compiler complains:
 
    error LNK2019: unresolved external symbol
 _call_dissector_only referenced
 in function _dissect_mydissector
 
  
 
  BTW, I'm working on version 1.0.4 and want to
 compile the dissector as a
 DLL.
 
  Any clues on it?
 
  Thanks a lot,
 
  Sean
 
  
 
  
 
  
 
 
 ___
 
  Sent via: Wireshark-dev mailing list
 wireshark-dev@wireshark.org
 
  Archives:
 http://www.wireshark.org/lists/wireshark-dev
 
  Unsubscribe:
 https://wireshark.org/mailman/options/wireshark-dev
 
 
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
 
 
 
 
 
 
 
 
 Souhaitez
 vous  « être au bureau sans y
 être » ? Oui
 je le veux ! 
 
 
 
 
 
 CONFIDENTIALITY NOTICE: The contents of this email are
 confidential
 and for the exclusive use of the intended recipient. If you
 receive this
 email in error, please delete it from your system
 immediately and 
 notify us either by email, telephone or fax. You should not
 copy,
 forward, or otherwise disclose the content of the email.
  
 
 
 
 -Inline Attachment Follows-
 
 ___
 Sent via:    Wireshark-dev mailing list wireshark-dev@wireshark.org
 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] g_snprintf() and sizeof

2009-03-20 Thread Guy Harris

On Mar 19, 2009, at 5:27 PM, Guy Harris wrote:


 On Mar 19, 2009, at 1:54 PM, Stephen Fisher wrote:

 Stop using fixed length strings so much? :-)

 Even if we cast them now, I can see people adding sizeof in the  
 future
 and forgetting to cast it.  GLib doesn't appear to have any other
 solution.

 I suspect a lot of the g_snprintf() is to generate formatted strings
 and put them into places such as the Info column and the display form
 of protocol tree items, and I suspect a lot of those calls generate
 strings by producing an initial string and appending to them.  The
 idiom used for the latter is really ugly.

 GLib has the GString type, which, other than doing g_mallocs which
 could leak if the dissector throws an exception, are probably the
 right type for this.  Perhaps we should create an ep_string type or
 something such as that, which is a string similar to a GString to
 which you can append stuff, with the string expanding as necessary,
 and use that to replace those g_snprintf()s?

...although, in some of those cases, you might *want* fixed-length  
strings.  If what's being generated is a string that would appear in  
the Info column or in a protocol tree item with a bunch of subitems,  
and it has a list of subitems followed by other information, you might  
not want it to include all the subitems if there are so many that this  
would push the information following the subitems too far to the right  
(or past the maximum length of the column or protocol tree item's  
display field).

For those, you might want another type, with a similar append to  
this API, but with a maximum length, with the append to this API  
just adding a ... and returning an error if the maximum length would  
be exceeded (or if it wouldn't even leave enough room for a ...), so  
that the loop adding items could terminate (or, if parsing the items  
is useful for other purposes, at least stop trying to append).
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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] XML parsing

2009-03-20 Thread Abhik Sarkar
Hi Jeff,

I meant version of glib which is part of the current set of libraries used
to build the SVN version (in particular wireshark-win32-libs). There are a
few different ways of parsing XML used in various parts of WS, and I wanted
to use an existing API without having to introduce a new dependency (but
also without having to use any parser generators) and it seems to be
possible using the mentioned functionality.

Thanks,
Abhik.

On Thu, Mar 19, 2009 at 6:52 PM, Jeff Morriss jeff.morriss...@gmail.comwrote:



 Abhik Sarkar wrote:
  Hi Everyone,
 
  This is a question specifically to the core developers. Would it be OK
  to use the GMarkupParser facility which is provided by the latest glib
  that is part of the required libraries for the development version? I
  want to use it to read XML configuration files for a generally available
  dissector.

 Define latest.  (I looked through the GLIB documentation and their
 list of symbols new to each release and at least some of the markup
 functions have been around for a while.)
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 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] Unresolved call_dissector_only issue

2009-03-20 Thread Maynard, Chris
Generally speaking, I think these functions get exported as needed or
requested.
If the core developers are reading this, one of them may add it for you;
otherwise, you may need to submit a bug report requesting that it be
added, as sometimes these e-mails get lost, forgotten or otherwise
buried
in a sea of other e-mails, whereas the bug report won't be.

- Chris

 -Original Message-
 From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
 boun...@wireshark.org] On Behalf Of Sean
 Sent: Friday, March 20, 2009 1:23 PM
 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] Unresolved call_dissector_only issue
 
 
 I have another suggestion regarding this issue,
 Do you have any plan on exporting function
req_resp_hdrs_do_reassembly?
 It seems that sometimes the plugins want to call this interface.
 
 
 
snip
CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and 
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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 failure in Wireshark (development) on OSX-10.5-x86

2009-03-20 Thread buildbot-no-reply
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark 
(development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/1989

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

Buildslave for this Build: osx-10.5-x86

Build Reason: 
Build Source Stamp: HEAD
Blamelist: etxrab

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
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 failure in Wireshark (development) on OSX-10.5-ppc

2009-03-20 Thread buildbot-no-reply
The Buildbot has detected a new failure of OSX-10.5-ppc on Wireshark 
(development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/OSX-10.5-ppc/builds/749

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

Buildslave for this Build: osx-10.5-ppc

Build Reason: 
Build Source Stamp: HEAD
Blamelist: etxrab

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

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

2009-03-20 Thread Jeff Morriss

Hi Abhik,

Sorry, I guess I mean: what is the earliest version of glib that 
supports the APIs you're talking about?

For Windows we don't have a problem because we distribute glib with 
Wireshark, but all other OS's rely on the currently-installed glib. 
configure.in currently enforces glib  2.4 .  Increasing that may be 
OK but of course it means some number of people will have to go upgrade 
their glib (so doing it shouldn't be taken lightly).

Regards,
Jeff


Abhik Sarkar wrote:
 Hi Jeff,
 
 I meant version of glib which is part of the current set of libraries 
 used to build the SVN version (in particular wireshark-win32-libs). 
 There are a few different ways of parsing XML used in various parts of 
 WS, and I wanted to use an existing API without having to introduce a 
 new dependency (but also without having to use any parser generators) 
 and it seems to be possible using the mentioned functionality.
 
 Thanks,
 Abhik.
 
 On Thu, Mar 19, 2009 at 6:52 PM, Jeff Morriss jeff.morriss.ws 
 http://jeff.morriss.ws@gmail.com http://gmail.com wrote:
 
 
 
 Abhik Sarkar wrote:
   Hi Everyone,
  
   This is a question specifically to the core developers. Would it
 be OK
   to use the GMarkupParser facility which is provided by the latest
 glib
   that is part of the required libraries for the development version? I
   want to use it to read XML configuration files for a generally
 available
   dissector.
 
 Define latest.  (I looked through the GLIB documentation and their
 list of symbols new to each release and at least some of the markup
 functions have been around for a while.)
 
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 mailto:wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org
 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