Wireshark · Wireshark-dev: Re: [Wireshark-dev] Adding libxml2 as optional Wireshark dependency

[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

Hi Ahmad and Graham,

2017-04-05 15:38 GMT+02:00 Graham Bloice <graham.bloice@xxxxxxxxxxxxx>:

On 5 April 2017 at 14:11, Ahmad Fatoum <ahmad@xxxxxx> wrote:

Hello everyone,

I was advised on Gerrit to post this issue here as to garner wider input.

This concerns proposed Change-Id I13c0a2f408fb5c21bad7ab3d7971e0fa8ed7d783 [1] intending to add libxml2 as optional dependency to Wireshark.

I am currently preparing to submit upstream, changes I did to the EPL v2 dissector (packet-epl.c).

A significant change is the ability to optionally read in user-supplied XML device descriptions and to extract type/description/mapping information for aiding the dissection. See this previous submission of mine to the mailing list: https://www.wireshark.org/lists/wireshark-dev/201701/msg00154.html

Seeing as there also has been interest for libxml2 support in dissectors in the past:

https://www.wireshark.org/lists/wireshark-dev/201005/msg00108.html

https://ask.wireshark.org/questions/36063/using-libxml2-in-my-own-dissector

I think, it would be a good idea to have this as optional dependency as Glib's GMarkup may be inadequate or inconvenient for parsing actual XML.

Looking forward to your feedback.

Best regards,
Ahmad Fatoum

[1] https://code.wireshark.org/review/#/c/20912/

Thanks for the post,

1.  Where will the Windows binaries come from and are these supported long term?  The  libXml2 downloads page indicates another site provides Windows binaries [1].  The binaries at that site in the 64 bit directory seem to be the most recent and are labelled as libXml2-2.9.3 [2].  The current release of libXml2 is 2.9.4 which has a number of security fixes among other bug fixes and enhancements [3] so it would appear that the Windows binaries are not being maintained.

I suggest to use the binaries provided by openSUSE: they provide win32 and win64 variants for libxml2 2.9.0 and we are already using their packages for several third party libraries. If it is really required to take the latest version, I can probbly give it a try (I already did this in the past to package a newer version than the one from openSUSE).

2.  According to the diagram at [1], libXml2 depends on iconv and zlib.  We currently build our own zlib, will that be suitable for the libXml2 dependency?  What will be the source of the iconv binary (iconv-1.14 is available in the same download area as libXml2 [2])?

Same thing: we can use the ones provided by openSUSE (we already have those dependencies for other packages).
 

3. The readme.txt in the download area ([2]) has some "interesting" text:

These are experimental 64bit binaries. For completeness, 32bit binaries 
built using the same method are also included.

The libraries in these packages are made using GCC (MinGW) toolchain. It is 
presently not possible to use these libraries with any recent version of the 
Microsoft Visual C compiler because of conflicting C-runtimes. To help you 
resist the temptation, the import libraries (.LIB) are not provided at all. 
If you need these libraries in an environment which mandates the use of the 
Microsoft toolchain, you will have to build them from source yourself.

and inspection of the download shows this is true, so it appears that we'll need to rebuild to obtain the import .lib file.

As part of the process of integrating openSUSE libraries, we are generating the .lib file and adding it in the package we upload on our server, so it should be OK.

4. Microsoft have a Visual Studio porting effort underway called vcpkg [4], that does include libXml2, but unfortunately is only for VS2015 or later.  If we move to VS2015 for main releases (post 2.4 release) then this may be a viable source for libXml2 and other packages we use.  It might be possible to use this to build VS2013 libXml2.

5.  Are there any manufacturers or tools that produce XML device description files for the EPL dissector such that choosing XML as the input format is the most sensible choice, or would another format be just as applicable?

I agree XML can be painful, so this is a good question ;)
 

[1]: https://www.zlatkovic.com/libxml.en.html
[2]: ftp://ftp.zlatkovic.com/libxml/64bit/

[3]: http://xmlsoft.org/news.html

[4]: https://github.com/Microsoft/vcpkg

--

Graham Bloice

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