Re: [Wireshark-dev] malformed packet
Wireshark's SIP dissector is throwing an error on the RAck header field method
name.
It shouldn't, because the message's header is correctly formed, but there's a
bug in packet-sip.c:
for case POS_RACK, when it goes to add the method name, it's using
'(int)linelen-sub_value_offset' for the length argument to
proto_tree_add_item(),
but should be using '(int)value_len-sub_value_offset'.
patch:
Index: epan/dissectors/packet-sip.c
===
--- epan/dissectors/packet-sip.c(revision 47899)
+++ epan/dissectors/packet-sip.c(working copy)
@@ -2734,7 +2734,7 @@
{
proto_tree_add_item(rack_tree, hf_sip_rack_cseq_method, tvb,
value_offset + sub_value_offset,
-
(int)linelen-sub_value_offset, ENC_ASCII|ENC_NA);
+
(int)value_len-sub_value_offset, ENC_ASCII|ENC_NA);
}
break;
-hadriel
On Feb 28, 2013, at 1:21 AM, Lohith HS wrote:
> Hi ,
>
>I am getting malformed packet in SIP message(PRACK) in wireshark 1.6.7
> version.
>But if i see the same capture in 0.9 version , there is no malformed
> packet issue.
>Pls can anyone tell me what is the issue.i have attached the capture file.
>
>
> Thanks,
> Lohith
> >___
> Sent via:Wireshark-dev mailing list
> 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
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] malformed packet
Hi, This one, and CSeq, can't be at the end of the packet, since Wireshark will throw a ReportedBoundsError. That's not right, these should be possible at the end of a packet so, it's a bug. You should report this through bugs.wireshark.org, attaching this capture, so it can properly be investigated and fixed. Thanks, Jaap On 02/28/2013 07:21 AM, Lohith HS wrote: > Hi , > > I am getting malformed packet in SIP message(PRACK) in wireshark 1.6.7 > version. > But if i see the same capture in 0.9 version , there is no malformed > packet > issue. > Pls can anyone tell me what is the issue.i have attached the capture file. > > > Thanks, > Lohith > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Google Summer of Code
Thanks, I will add my stuff today kind regards, Roland On Thu, Feb 28, 2013 at 7:39 AM, Gerald Combs wrote: > On 2/27/13 6:06 PM, Roland Knall wrote: >> Hi >> >> As the last discussion towards the GSoC application resulted in a >> rather long off-topic discussion, I want to restart it. >> >> Is there a way / method / wiki-page where we could collect all ideas, >> and have a vote on them? Therefore we could at least collect some >> ideas, and if we reach a certain number (e.g. 10) chances would rise, >> that students will actually apply for them. > > Done. http://wiki.wireshark.org/GSoC2013 > ___ > Sent via:Wireshark-dev mailing list > 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 Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Google Summer of Code
On 2/27/13 6:06 PM, Roland Knall wrote: > Hi > > As the last discussion towards the GSoC application resulted in a > rather long off-topic discussion, I want to restart it. > > Is there a way / method / wiki-page where we could collect all ideas, > and have a vote on them? Therefore we could at least collect some > ideas, and if we reach a certain number (e.g. 10) chances would rise, > that students will actually apply for them. Done. http://wiki.wireshark.org/GSoC2013 ___ Sent via:Wireshark-dev mailing list 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] malformed packet
Hi , I am getting malformed packet in SIP message(PRACK) in wireshark 1.6.7 version. But if i see the same capture in 0.9 version , there is no malformed packet issue. Pls can anyone tell me what is the issue.i have attached the capture file. Thanks, Lohith sip_prack_malformed.pcap Description: application/vnd.tcpdump.pcap ___ Sent via:Wireshark-dev mailing list 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] dumpcap -B options default.
On Feb 27, 2013, at 9:01 AM, Anders Broman wrote: > Looking in libpcap sources it seems like our default of 1 MB actually > decreases the buffer if mmap is used, should the default be increased to 2MB > to reflect libpcaps default That's probably the best answer - on the platforms where libpcap can set the buffer size, if libpcap tries to set it to a larger size than is allowed, no error occurs, it's just silently clamped. ___ Sent via:Wireshark-dev mailing list 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] finishing Cmake (Was: Simpifying exporting DLL symbols)
On 2/27/2013 11:51 AM, Bálint Réczey wrote: Hi, - Add asn1 autogen target (assigned: krj) Since the asn1 seems to be assigned already I did not want to intervene with it. ;-) The last commit from krj was in r35324 | krj | 2011-01-02 03:29:33 -0500 (Sun, 02 Jan 2011) so, I expect, someone else will probably need to do this. Bill ___ Sent via:Wireshark-dev mailing list 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] finishing Cmake (Was: Simpifying exporting DLL symbols)
> Since the asn1 seems to be assigned already I did not want to intervene with > it. ;-) I don't think "krj" is actively participating any more... Regards Anders -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Bálint Réczey Sent: den 27 februari 2013 17:51 To: Jeff Morriss Cc: Developer support list for Wireshark Subject: Re: [Wireshark-dev] finishing Cmake (Was: Simpifying exporting DLL symbols) Hi, 2013/2/27 Jeff Morriss : > Bálint Réczey wrote: >> >> 2013/2/26 Bill Meier : >>> >>> On 2/26/2013 5:11 PM, Bálint Réczey wrote: 2013/2/26 Pascal Quantin : ... > > Thank you! If no one opposes I'll commit the patch on Thursday and then start converting the remaining libs. >>> It sounds like the change is significant. >>> >>> if so, I suggest we consider if we should wait until after 1.10 is >>> released to make the change. >> >> It is significant in a way, but I think it would be better to have it >> in 1.10. >> It is the last change needed for CMake build system to make it good >> enough to generate official Debian packages. >> I got several requests to ship the Qt GUI in Debian and with CMake I >> can generate both GTK and Qt GUIs nicely not to mention that CMake >> builds are faster. >> >> 1.10.0 would be a perfect candidate to release a fully operational >> CMake build system for Linux and after 1.10 we could make CMake work >> on every platform. > > > Another thing that is missing in CMake is the ability to (re)generate > the > ASN.1 dissectors. Currently you need to use autofoo or Windows to do that. > > (I tried looking at it once a long time ago but didn't spend the time > to learn CMake sufficiently...) The current TODO list in README.cmake is the following: What needs to be done? == - Add asn1 autogen target (assigned: krj) - Add back platform specific objects. - Fix places in the cmake files marked as todo. - Guides are not installed. - Build source package (using CPack). This is obsolete if we decide to release VCS snapshots instead - Build rpm package (using CPack). - Build dpkg package (using CPack). This is obsolete, we should call CMake from debian/rules instead, using dh (rbalint) - Add back checkAPI target. - Test and add support for other platforms (BSDs, OSX, Solaris, Win32, Win64, ...) ... Since the asn1 seems to be assigned already I did not want to intervene with it. ;-) I think we are pretty close to completion and we could have the Linux part finished for 1.10. I have added the dumpabi targets and with the symbol visibility patch I'll be able to ship Debian packages using CMake. I'm not sure which "platform specific targets" are missing, so if anyone has some idea please detail the TODO item, or - the better - fix it. ;-) Cheers, Balint ___ Sent via:Wireshark-dev mailing list 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 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] dumpcap -B options default.
Hi, Looking in libpcap sources it seems like our default of 1 MB actually decreases the buffer if mmap is used, should the default be increased to 2MB to reflect libpcaps default or some check be made if mmap is available or not. I also think that it should be made clearer that the size is specified In units of 1MB. Regards Anders ___ Sent via:Wireshark-dev mailing list 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] finishing Cmake (Was: Simpifying exporting DLL symbols)
Hi, 2013/2/27 Jeff Morriss : > Bálint Réczey wrote: >> >> 2013/2/26 Bill Meier : >>> >>> On 2/26/2013 5:11 PM, Bálint Réczey wrote: 2013/2/26 Pascal Quantin : ... > > Thank you! If no one opposes I'll commit the patch on Thursday and then start converting the remaining libs. >>> It sounds like the change is significant. >>> >>> if so, I suggest we consider if we should wait until after 1.10 is >>> released >>> to make the change. >> >> It is significant in a way, but I think it would be better to have it in >> 1.10. >> It is the last change needed for CMake build system to make it good enough >> to >> generate official Debian packages. >> I got several requests to ship the Qt GUI in Debian and with CMake I >> can generate both >> GTK and Qt GUIs nicely not to mention that CMake builds are faster. >> >> 1.10.0 would be a perfect candidate to release a fully operational >> CMake build system >> for Linux and after 1.10 we could make CMake work on every platform. > > > Another thing that is missing in CMake is the ability to (re)generate the > ASN.1 dissectors. Currently you need to use autofoo or Windows to do that. > > (I tried looking at it once a long time ago but didn't spend the time to > learn CMake sufficiently...) The current TODO list in README.cmake is the following: What needs to be done? == - Add asn1 autogen target (assigned: krj) - Add back platform specific objects. - Fix places in the cmake files marked as todo. - Guides are not installed. - Build source package (using CPack). This is obsolete if we decide to release VCS snapshots instead - Build rpm package (using CPack). - Build dpkg package (using CPack). This is obsolete, we should call CMake from debian/rules instead, using dh (rbalint) - Add back checkAPI target. - Test and add support for other platforms (BSDs, OSX, Solaris, Win32, Win64, ...) ... Since the asn1 seems to be assigned already I did not want to intervene with it. ;-) I think we are pretty close to completion and we could have the Linux part finished for 1.10. I have added the dumpabi targets and with the symbol visibility patch I'll be able to ship Debian packages using CMake. I'm not sure which "platform specific targets" are missing, so if anyone has some idea please detail the TODO item, or - the better - fix it. ;-) Cheers, Balint ___ Sent via:Wireshark-dev mailing list 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] new dissector - dynamic value string table?
On 02/27/2013 02:07 AM, Gisle Vanem wrote: > "Max Baker" wrote: > >> I've created a new dissector for USB PTP >> (http://en.wikipedia.org/wiki/Picture_Transfer_Protocol) . This is the >> protocol most digital cameras speak over USB. I've gotten far enough >> to do the basic dissection, and I'm pretty stoked on the results! > > Just a side-question. Anybody have any experience on USB-snooping > on Windows? Is it possible at all? The page > http://wiki.wireshark.org/CaptureSetup/USB > > describes how it's done under Linux. This page > http://benoit.papillault.free.fr/usbsnoop/ > > describes it for Win, but the project seems abandoned. It would > be cool it add usb-sniffing to libpcap or Wireshark itself. Ref. airpcap. I have been successful in an all-windows environment by : 1. Running Windows inside of Windows using VMWare 2. Enabling vmvware's usb logging capabilities 3. Converting their log into PCAP format and then running wireshark. I found a script that did this for me, that needed a little bit of tweaking. My notes are here : http://nikonhacker.com/wiki/USB_/_PTP Natively using wireshark is of course much simpler, but requires walking up stairs and plugging the camera in the linux box :) h2h, -m ___ Sent via:Wireshark-dev mailing list 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] new dissector - dynamic value string table?
On 02/26/2013 08:32 PM, Hadriel Kaplan wrote: > Can't you use a macro to populate/copy the "common" chunks into > separate lists? -hadriel Hi Hadriel, Good suggestion. I was trying to steer away from this because the cross product is too big. There are about 10 lists and about 10 variants. On the first question of detecting the camera type, it looks like the information I need is captured by packet-usb.c (emem_tree_t *device_to_product_table) -- however it's not exported. I will need to add a way of getting access to this tree from the new dissector. Thanks, -m ___ Sent via:Wireshark-dev mailing list 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] finishing Cmake (Was: Simpifying exporting DLL symbols)
Bálint Réczey wrote: 2013/2/26 Bill Meier : On 2/26/2013 5:11 PM, Bálint Réczey wrote: 2013/2/26 Pascal Quantin : ... Thank you! If no one opposes I'll commit the patch on Thursday and then start converting the remaining libs. It sounds like the change is significant. if so, I suggest we consider if we should wait until after 1.10 is released to make the change. It is significant in a way, but I think it would be better to have it in 1.10. It is the last change needed for CMake build system to make it good enough to generate official Debian packages. I got several requests to ship the Qt GUI in Debian and with CMake I can generate both GTK and Qt GUIs nicely not to mention that CMake builds are faster. 1.10.0 would be a perfect candidate to release a fully operational CMake build system for Linux and after 1.10 we could make CMake work on every platform. Another thing that is missing in CMake is the ability to (re)generate the ASN.1 dissectors. Currently you need to use autofoo or Windows to do that. (I tried looking at it once a long time ago but didn't spend the time to learn CMake sufficiently...) ___ Sent via:Wireshark-dev mailing list 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] Simpifying exporting DLL symbols
Hi Guy,
2013/2/27 Guy Harris :
>
> On Feb 26, 2013, at 2:08 PM, Bálint Réczey wrote:
>
>> Exporting all symbols when using more exotic compilers should not be and
>> issue,
>> because plugins used on such exotic systems are probably compiled with
>> GCC >= 4.0, LLVM
>> or Visual Studio too, and this ensures using exported APIs.
>
> Does it ensure that plugins use only exported APIs on, for example:
>
> HP-UX, if Wireshark itself is compiled with aCC (as would be the case
> if the user got Wireshark from the HP-UX Porting and Archive Centre);
>
> AIX, if Wireshark itself is compiled with XLC?
I think plugin writers should care about proper API usage.
We offer them a broad range of systems where only the supported API
symbols are exported
thus they can test their plugins if they care about API changes.
With the Solaris Studio related changes we will hide obsolete symbols
on every platform we run
buildbot on.
>
> Sun Studio 8 through Sun^WOracle Solaris Studio 12 appear to support __hidden
> as a way of saying "not visible outside the library", __global as a way of
> saying "visible outside the library and references from within the library
> could bind to code in the application if the application defines it", and
> "-xldscope=hidden" to make __hidden the default, so that __global overrides
> it. That sounds as if it'd be what we'd want. It requires us to tweak
> compiler options when building libraries, but, well, any
> build-and-configuration tools that can't handle that are toys
I have just sent an updated patch which allows easy customization of
such compiler parameters.
I haven't added the one you mentioned because I don't build on
Solaris, but adding it should now be really straightforward for anyone
having access to {Sun|Oracle} Solaris Studio.
Cheers,
Balint
___
Sent via:Wireshark-dev mailing list
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] Simpifying exporting DLL symbols
2013/2/27 Dirk Jagdmann : >> I have tested it using autotools and CMake, but I could not give it a try >> on >> Windows or OS X. If you have some time and access to those platform >> please test the patch. > > > I tested on OsX and it seems to work. I could compile Wireshark and run it. Thanks! > I think it's useful to have such a change if it works for all platform we > care about. However we should also add a section to the developer README to > explain the new macros. Sure, I planned updating the README while converting the rest of the libs. Cheers, Balint ___ Sent via:Wireshark-dev mailing list 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] Simpifying exporting DLL symbols
Hi Gisle, 2013/2/27 Gisle Vanem : > "Bálint Réczey" wrote: > >> I have created the attached patch to control symbol visibility using >> C defines instead of .def and .sym files. It is expected to work on every >> platform and every build system we support, but I did not want to >> commit it without discussing the direction. > > > Nice, but why not use nicer indenting to make it more readable? I think more indentation would look better, but starting #define-s at the beginning of the lines also has some value. If you don't mind I will leave indentation as it is now, but if we define coding guidelines covering this I won't stick to this style. :-) > > And what about foreign programs that would like to use e.g. libwireshark > code as a static lib? ws_symbol_export.h should IMHO account for this. > Something like: > > #if (defined (_WIN32) || defined (__CYGWIN__)) & !defined(WS_STATIC_LIB) > #ifdef WS_BUILD_DLL >#ifdef __GNUC__ > #define WS_DLL_PUBLIC __attribute__ ((dllexport)) >#else > #define WS_DLL_PUBLIC __declspec(dllexport) // Note: actually gcc seems > to also support this syntax. >#endif > .. Good point, I have updated the patch. AFAIK only MSVC compilers could have problems with the original #defines thus I fixed only that case. > > There is some interest out there to use libwireshark outside *shark > programs: > > http://stackoverflow.com/questions/10308127/using-libwireshark-to-get-wireshark-functionality-programatically > > The old Packetyzer 5.0 also uses ethereal libs. See: > http://sourceforge.net/projects/packetyzer/ There is also netexpect (http://netexpect.org) which is packaged in Debian. I usually collaborate with its author, Eloy, when I update packaged libraries in Debian. The new patch also covers Jakub's very valid concern about old (or other) compilers not supporting -fvisibility=hidden. Cheers, Balint 0001-Export-libwsutil-symbols-using-WS_DLL_PUBLIC-define.patch Description: Binary data ___ Sent via:Wireshark-dev mailing list 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] new dissector - dynamic value string table?
"Max Baker" wrote: I've created a new dissector for USB PTP (http://en.wikipedia.org/wiki/Picture_Transfer_Protocol) . This is the protocol most digital cameras speak over USB. I've gotten far enough to do the basic dissection, and I'm pretty stoked on the results! Just a side-question. Anybody have any experience on USB-snooping on Windows? Is it possible at all? The page http://wiki.wireshark.org/CaptureSetup/USB describes how it's done under Linux. This page http://benoit.papillault.free.fr/usbsnoop/ describes it for Win, but the project seems abandoned. It would be cool it add usb-sniffing to libpcap or Wireshark itself. Ref. airpcap. --gv ___ Sent via:Wireshark-dev mailing list 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] Google Summer of Code
Hi As the last discussion towards the GSoC application resulted in a rather long off-topic discussion, I want to restart it. Is there a way / method / wiki-page where we could collect all ideas, and have a vote on them? Therefore we could at least collect some ideas, and if we reach a certain number (e.g. 10) chances would rise, that students will actually apply for them. I think an application idea, to be valid, should consist of the following: * Subject * Developer who could mentor * Programming languages needed * Level of expertise in these languages (beg./adv./exp.) * Area of Wireshark it applies * Level of wireshark expertise needed * Summary of the topic, what should be done * Summary of the expected result * Amount of time estimated for a developer already familiar with the code I was an applicant for a previous GSoC run before, and it is a great experience and opportunity for each student involved. So I am greatly in favor for wireshark to offer some projects in this program. If need arises, I can lend my support in organizing this. kind regards, Roland ___ Sent via:Wireshark-dev mailing list 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] Simpifying exporting DLL symbols
"Bálint Réczey" wrote: I have created the attached patch to control symbol visibility using C defines instead of .def and .sym files. It is expected to work on every platform and every build system we support, but I did not want to commit it without discussing the direction. Nice, but why not use nicer indenting to make it more readable? And what about foreign programs that would like to use e.g. libwireshark code as a static lib? ws_symbol_export.h should IMHO account for this. Something like: #if (defined (_WIN32) || defined (__CYGWIN__)) & !defined(WS_STATIC_LIB) #ifdef WS_BUILD_DLL #ifdef __GNUC__ #define WS_DLL_PUBLIC __attribute__ ((dllexport)) #else #define WS_DLL_PUBLIC __declspec(dllexport) // Note: actually gcc seems to also support this syntax. #endif .. There is some interest out there to use libwireshark outside *shark programs: http://stackoverflow.com/questions/10308127/using-libwireshark-to-get-wireshark-functionality-programatically The old Packetyzer 5.0 also uses ethereal libs. See: http://sourceforge.net/projects/packetyzer/ --gv ___ Sent via:Wireshark-dev mailing list 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] Simpifying exporting DLL symbols
I have tested it using autotools and CMake, but I could not give it a try on Windows or OS X. If you have some time and access to those platform please test the patch. I tested on OsX and it seems to work. I could compile Wireshark and run it. I think it's useful to have such a change if it works for all platform we care about. However we should also add a section to the developer README to explain the new macros. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
