Re: [Wireshark-dev] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Guy Harris 
On Mar 19, 2020, at 11:38 AM, Guy Harris  wrote:

> In addition, we tend to use src_, rather than s_, as a prefix for "source", 
> and "dst_" or "dest" as a prefix for "destination", so I posted a change to 
> rename s_addr and d_addr to src_addr and dst_addr:
> 
>   https://code.wireshark.org/review/36504
> 
> which should fix this.

Committed.

This does raise the question of why winsock2.h is getting dragged in; dissector 
have no need for that, any more than they have any need for UN*X networking API 
headers, unless they're making networking calls (in which case they should 
probably be using wsutil/socket.h to hide platform differences).
___
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] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Guy Harris 
On Mar 19, 2020, at 7:40 AM, Gisle Vanem  wrote:

> I'm surprised no one has come across this compile
> error yet:
> epan/dissectors/packet-f5ethtrailer.c(482): error C2143: syntax error: 
> missing ';' before '.'
> epan/dissectors/packet-f5ethtrailer.c(485): error C2224: left of '.S_addr' 
> must have struct/union type
> epan/dissectors/packet-f5ethtrailer.c(487): error C2224: left of '.S_addr' 
> must have struct/union type
> 
> (using MSVC-2019).
> 
> Reason seems simple;  has snuck in somehow and
> added the wellknown "#define s_addr S_un.S_addr"

This isn't unique to Windows.  It dates back to old BSD, in which struct 
in_addr contained a union of multiple different types for an IP address, with 
some types being structures breaking up the address into host and network bits, 
and even included bits for IMP numbers.  s_addr was defined to be the member of 
the union that just defined an address as a 32-bit integer, so if you referred 
to the s_addr "field" of the structure it gave you the 32-bit integer value.

Some OSes, including later versions of 4.xBSD, dropped that, with struct 
in_addr having just a 32-bit-integer s_addr field; macOS was based on 4.4-Lite, 
so it worked like that, and the current *BSDs are also based on that.  Linux 
probably picked that up, too.

However, Illumos still has that old stuff, so Solaris probably does so as well; 
any code including , directly or indirectly, could get bitten by 
that.

In addition, we tend to use src_, rather than s_, as a prefix for "source", and 
"dst_" or "dest" as a prefix for "destination", so I posted a change to rename 
s_addr and d_addr to src_addr and dst_addr:

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

which should fix this.

(Why it's not happening with some Windows build environments is anybody's 
guess.  Different SDK versions?  Different #defines?)
___
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] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Jason Cohen 
Gisle,

Do you have the steps you used to setup your build environment, and then
the steps to build Wireshark? Unless we're able to reproduce it, there may
be little we can do.  It certainly hasn't been something I've seen either.

Jason

On Thu, Mar 19, 2020 at 12:34 PM Gisle Vanem  wrote:

> Maynard, Chris wrote:
>
> > Which specific release of VS2019 are you running?  This is a bit of a
> stretch, but *possibly* your version could use an update?
>
> I have the latest AFAIK I ran vs_installer last week.
>
>  From 'cl /?':   Version 19.24.28319 for x86
>  From 'vswhere': VisualStudio.16.Release/16.4.6+29905.134
>
> But IMHO, you're dodging the problem; a "#define s_addr S_un.S_addr"
> has been in the *Win-SDK* for ages. Nothing to do with 'cl' or
> it's headers.
>
> --
> --gv
> ___
> 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
___
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] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Maynard, Chris via Wireshark-dev 
> -Original Message-
> From: Wireshark-dev  On Behalf
> Of Gisle Vanem
> Sent: Thursday, March 19, 2020 1:33 PM
> To: wireshark-dev@wireshark.org
> Subject: Re: [Wireshark-dev] Problem in 'packet-f5ethtrailer.c'
>
> Maynard, Chris wrote:
>
> > Which specific release of VS2019 are you running?  This is a bit of a 
> > stretch,
> but *possibly* your version could use an update?
>
> I have the latest AFAIK I ran vs_installer last week.
>
>  From 'cl /?':   Version 19.24.28319 for x86
>  From 'vswhere': VisualStudio.16.Release/16.4.6+29905.134
>
> But IMHO, you're dodging the problem; a "#define s_addr S_un.S_addr"
> has been in the *Win-SDK* for ages. Nothing to do with 'cl' or it's headers.

Well, it wasn't my intention at dodging anything.  My apologies if this is a 
dead-end.  I can only say that it still appears that there's something unique 
or different with your build environment vs. everyone else's, including the 
buildbots; otherwise this problem would likely have been encountered.  With 
very little information to go by, I'm not sure how else to try to help except 
to say that maybe you could compare your environment with the buildbot and look 
for differences.  Maybe others have better suggestions.

Good luck.
- Chris
https://buildbot.wireshark.org/wireshark-master/waterfall

CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information. This message is intended solely for 
the use of the addressee. If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.
___
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] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Graham Bloice 
On Thu, 19 Mar 2020 at 17:34, Gisle Vanem  wrote:

> Maynard, Chris wrote:
>
> > Which specific release of VS2019 are you running?  This is a bit of a
> stretch, but *possibly* your version could use an update?
>
> I have the latest AFAIK I ran vs_installer last week.
>
>  From 'cl /?':   Version 19.24.28319 for x86
>  From 'vswhere': VisualStudio.16.Release/16.4.6+29905.134
>
> But IMHO, you're dodging the problem; a "#define s_addr S_un.S_addr"
> has been in the *Win-SDK* for ages. Nothing to do with 'cl' or
> it's headers.
>
>
As a counterpoint, I compiled today with the latest VS2019, no issue at
all.  From vswhere, the version is VisualStudio.16.Release/16.5.0+29911.84,
so slightly newer than your version.  I do only build x64 though, not x86.

-- 
Graham Bloice
___
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] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Gisle Vanem 

Maynard, Chris wrote:


Which specific release of VS2019 are you running?  This is a bit of a stretch, 
but *possibly* your version could use an update?


I have the latest AFAIK I ran vs_installer last week.

From 'cl /?':   Version 19.24.28319 for x86
From 'vswhere': VisualStudio.16.Release/16.4.6+29905.134

But IMHO, you're dodging the problem; a "#define s_addr S_un.S_addr"
has been in the *Win-SDK* for ages. Nothing to do with 'cl' or
it's headers.

--
--gv
___
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] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Graham Bloice 
On Thu, 19 Mar 2020 at 14:41, Gisle Vanem  wrote:

> BTW.
> note the time-stamp on the 'a' file. How come it
> gets updated as soon as I do a 'git pull'?
>  From a 'git log packet-f5ethtrailer.c', the last
> change was 19 days ago.
>
>
See
https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F



-- 
Graham Bloice
___
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] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Maynard, Chris via Wireshark-dev 
> -Original Message-
> From: Wireshark-dev  On Behalf
> Of Gisle Vanem
> Sent: Thursday, March 19, 2020 10:41 AM
> To: wireshark-dev 
> Subject: [Wireshark-dev] Problem in 'packet-f5ethtrailer.c'
>
> I'm surprised no one has come across this compile error yet:
>epan/dissectors/packet-f5ethtrailer.c(482): error C2143: syntax error:
> missing ';' before '.'
>epan/dissectors/packet-f5ethtrailer.c(485): error C2224: left of '.S_addr'
> must have struct/union type
>epan/dissectors/packet-f5ethtrailer.c(487): error C2224: left of '.S_addr'
> must have struct/union type
>
> (using MSVC-2019).
>
> Reason seems simple;  has snuck in somehow and added the
> wellknown "#define s_addr S_un.S_addr"
>
> A simple fix is:
>
> --- a/epan/dissectors/packet-f5ethtrailer.c 2020-03-19 13:31:36
> +++ b/epan/dissectors/packet-f5ethtrailer.c 2020-03-19 14:26:51
> @@ -204,6 +204,7 @@
>   #include 
>   #define F5FILEINFOTAP_SRC
>   #include "packet-f5ethtrailer.h"
> +#undef s_addr
>   #undef F5FILEINFOTAP_SRC

Which specific release of VS2019 are you running?  This is a bit of a stretch, 
but *possibly* your version could use an update?

As an added data point, I updated to 16.5 this week and I just recompiled 
Wireshark sources without any problem.
It seems the buildbots are running 16.0, so if you're running a version in 
between the two and one of those versions introduced this change, then *maybe* 
that could explain it?

Well, if that's not the problem, then there would appear to be something else 
different/unique to your build environment causing this.  I suppose we'd need 
more info ...
- Chris
https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes












CONFIDENTIALITY NOTICE: This message is the property of International Game 
Technology PLC and/or its subsidiaries and may contain proprietary, 
confidential or trade secret information. This message is intended solely for 
the use of the addressee. If you are not the intended recipient and have 
received this message in error, please delete this message from your system. 
Any unauthorized reading, distribution, copying, or other use of this message 
or its attachments is strictly prohibited.
___
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] Problem in 'packet-f5ethtrailer.c'

2020-03-19 Thread Gisle Vanem 

I'm surprised no one has come across this compile
error yet:
  epan/dissectors/packet-f5ethtrailer.c(482): error C2143: syntax error: 
missing ';' before '.'
  epan/dissectors/packet-f5ethtrailer.c(485): error C2224: left of '.S_addr' 
must have struct/union type
  epan/dissectors/packet-f5ethtrailer.c(487): error C2224: left of '.S_addr' 
must have struct/union type

(using MSVC-2019).

Reason seems simple;  has snuck in somehow and
added the wellknown "#define s_addr S_un.S_addr"

A simple fix is:

--- a/epan/dissectors/packet-f5ethtrailer.c 2020-03-19 13:31:36
+++ b/epan/dissectors/packet-f5ethtrailer.c 2020-03-19 14:26:51
@@ -204,6 +204,7 @@
 #include 
 #define F5FILEINFOTAP_SRC
 #include "packet-f5ethtrailer.h"
+#undef s_addr
 #undef F5FILEINFOTAP_SRC



BTW.
note the time-stamp on the 'a' file. How come it
gets updated as soon as I do a 'git pull'?
From a 'git log packet-f5ethtrailer.c', the last
change was 19 days ago.

--
--gv
___
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] Build without LUA fails

2020-03-19 Thread Pascal Quantin 
Le jeu. 19 mars 2020 à 08:54, Anders Broman  a
écrit :

>
>
>
>
> *From:* Pascal Quantin 
> *Sent:* den 17 mars 2020 10:13
> *To:* Developer support list for Wireshark 
> *Cc:* Anders Broman 
> *Subject:* Re: [Wireshark-dev] Build without LUA fails
>
>
>
> Hi Anders,
>
>
>
> Le mar. 17 mars 2020 à 10:02, Anders Broman via Wireshark-dev <
> wireshark-dev@wireshark.org> a écrit :
>
> Hi,
>
> Someone at work is trying to build without LUA and getting, from cmake:
>
>
>
> :
>
> - The following OPTIONAL packages have not been found:
>
>
>
> * LIBSSH (required version >= 0.6), Library for implementing SSH clients, <
> https://www.libssh.org/
> 
> >
>
>extcap remote SSH interfaces (sshdump, ciscodump)
>
> * Systemd, System and Service Manager (libraries), <
> https://freedesktop.org/wiki/Software/systemd/
> 
> >
>
>   Support for systemd journal extcap interface (sdjournal)
>
> * MaxMindDB, C library for the MaxMind DB file format, <
> https://github.com/maxmind/libmaxminddb
> 
> >
>
>Support for GeoIP lookup
>
> * SMI
>
> * Minizip, C library for supporting zip/unzip functionality, <
> https://www.winimage.com/zLibDll/minizip.html
> 
> >
>
>Support for profiles import/export
>
> * BROTLI
>
> * LZ4, LZ4 is lossless compression algorithm used in some protocol
> (CQL...),  
> >
>
>LZ4 decompression in CQL and Kafka dissectors
>
> * SNAPPY, A fast compressor/decompressor from Google, <
> https://google.github.io/snappy/
> 
> >
>
>Snappy decompression in CQL and Kafka dissectors
>
> * ZSTD (required version >= 1.0.0), A compressor/decompressor from
> Facebook providing better compression than Snappy at a cost of speed, <
> https://facebook.github.io/zstd/
> 
> >
>
>Zstd decompression in Kafka dissector
>
> * LUA (required version >= 5.1)
>
> * SBC, Bluetooth low-complexity, subband codec (SBC) decoder, <
> https://git.kernel.org/pub/scm/bluetooth/sbc.git>
>
>Support for playing SBC codec in RTP player
>
> * SPANDSP, a library of many DSP functions for telephony, <
> https://www.soft-switch.org
> 
> >
>
>Support for G.722 and G.726 codecs in RTP player
>
> * BCG729, G.729 decoder, <
> https://www.linphone.org/technical-corner/bcg729/overview
> 
> >
>
>Support for G.729 codec in RTP player
>
> * ILBC, iLBC decoder,  
> >
>
>Support for iLBC codec in RTP player
>
> * SpeexDSP, SpeexDSP is a patent-free, Open Source/Free Software DSP
> library,  
> >
>
>RTP audio resampling
>
> * Asciidoctor (required version >= 1.5):
>
> CMake Error: The following variables are used in this project, but they
> are set to NOTFOUND.
>
> Please set them or make sure they are set and tested correctly in the
> CMake files:
>
> LUA_INCLUDE_DIR
>
>used as include directory in directory ..Wireshark /epan
>
> :
>
>
>
> Any ideas?
>
>
>
> Just a blind attmpt. Would th epatch below change something?
>
>
>
> diff --git a/cmake/modules/FindLUA.cmake

Re: [Wireshark-dev] Build without LUA fails

2020-03-19 Thread Anders Broman via Wireshark-dev 
 

 

From: Pascal Quantin  
Sent: den 17 mars 2020 10:13
To: Developer support list for Wireshark 
Cc: Anders Broman 
Subject: Re: [Wireshark-dev] Build without LUA fails

 

Hi Anders,

 

Le mar. 17 mars 2020 à 10:02, Anders Broman via Wireshark-dev 
mailto:wireshark-dev@wireshark.org> > a écrit :

Hi,

Someone at work is trying to build without LUA and getting, from cmake:

 

:

- The following OPTIONAL packages have not been found:

 

* LIBSSH (required version >= 0.6), Library for implementing SSH clients, 

 >

   extcap remote SSH interfaces (sshdump, ciscodump)

* Systemd, System and Service Manager (libraries), 

 >

  Support for systemd journal extcap interface (sdjournal)

* MaxMindDB, C library for the MaxMind DB file format, 

 >

   Support for GeoIP lookup

* SMI

* Minizip, C library for supporting zip/unzip functionality, 

 >

   Support for profiles import/export

* BROTLI

* LZ4, LZ4 is lossless compression algorithm used in some protocol (CQL...), 

 >

   LZ4 decompression in CQL and Kafka dissectors

* SNAPPY, A fast compressor/decompressor from Google, 

 >

   Snappy decompression in CQL and Kafka dissectors

* ZSTD (required version >= 1.0.0), A compressor/decompressor from Facebook 
providing better compression than Snappy at a cost of speed, 

 >

   Zstd decompression in Kafka dissector

* LUA (required version >= 5.1)

* SBC, Bluetooth low-complexity, subband codec (SBC) decoder, 


   Support for playing SBC codec in RTP player

* SPANDSP, a library of many DSP functions for telephony, 

 >

   Support for G.722 and G.726 codecs in RTP player

* BCG729, G.729 decoder, 

 >

   Support for G.729 codec in RTP player

* ILBC, iLBC decoder, 
 >

   Support for iLBC codec in RTP player

* SpeexDSP, SpeexDSP is a patent-free, Open Source/Free Software DSP library, 

 >

   RTP audio resampling

* Asciidoctor (required version >= 1.5):

CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.

Please set them or make sure they are set and tested correctly in the CMake 
files:

LUA_INCLUDE_DIR

   used as include directory in directory ..Wireshark /epan

:

 

Any ideas?

 

Just a blind attmpt. Would th epatch below change something?

 

diff --git a/cmake/modules/FindLUA.cmake b/cmake/modules/FindLUA.cmake
index 2e5e8d476b..ea65b0f89e 100644
--- a/cmake/modules/FindLUA.cmake
+++ b/cmake/modules/FindLUA.cmake
@@ -84,7 +84,7 @@ find_package_handle_standard_args(LUA
   REQUIRED_VARS LUA_LIBRARY LUA_INCLUDE_DIR LUA_VERSION_NUM
   VERSION_VAR