Re: [Wireshark-dev] Mac Build Error

[David Morsberger]

> On Jan 20, 2016, at 2:48 AM, Stig Bjørlykke  wrote:
> 
> On Wed, Jan 20, 2016 at 3:28 AM, David Morsberger  > wrote:
> I am trying to create support and possibly instructions for Xcode.
> 
> The only issue I have with using Xcode is 
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11816 
> 

I also see that behavior but figured it was just Xcode convention.

I am getting actual errors within Xcode after ‘cmake -G Xcode’. This can easily 
be resolved by not testing ‘—as-needed’ or ‘—pie’ when XCODE just like what is 
done for MSVC.

What do you see in your CMakeError.log and CMakeOutput.log for ‘—as-needed’?

What version of Xcode are you using?



___
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] Mac Build Error

[Stig Bjørlykke]

On Wed, Jan 20, 2016 at 1:47 PM, David Morsberger 
wrote:

> I am getting actual errors within Xcode after ‘cmake -G Xcode’. This can
> easily be resolved by not testing ‘—as-needed’ or ‘—pie’ when XCODE just
> like what is done for MSVC.
>

Ah, yes, I forgot about this.  I have tried to fix this earlier without
luck.
https://www.wireshark.org/lists/wireshark-dev/201009/msg00278.html


I have a local fix in my cmake build directory for this flags, I manually
changed this lines in CMakeCache.txt:

WS_LD_FLAG_VALID0:INTERNAL=0
WS_LD_FLAG_VALID1:INTERNAL=0


> A correct fix for this would be nice.


-- 
Stig Bjørlykke
___
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] Mac Build Error

[David Morsberger]

On Wed, Jan 20, 2016 at 8:43 AM, Stig Bjørlykke  wrote:

> On Wed, Jan 20, 2016 at 1:47 PM, David Morsberger 
> wrote:
>
>
I am getting actual errors within Xcode after ‘cmake -G Xcode’. This can
>> easily be resolved by not testing ‘—as-needed’ or ‘—pie’ when XCODE just
>> like what is done for MSVC.
>>
>
> Ah, yes, I forgot about this.  I have tried to fix this earlier without
> luck.
> https://www.wireshark.org/lists/wireshark-dev/201009/msg00278.html
>
>
> I have a local fix in my cmake build directory for this flags, I manually
> changed this lines in CMakeCache.txt:
>
> WS_LD_FLAG_VALID0:INTERNAL=0
> WS_LD_FLAG_VALID1:INTERNAL=0
>
> A correct fix for this would be nice.
>
>
>
>
My current workaround is the following change to CMakeLists.txt :

-if(NOT CMAKE_C_COMPILER_ID MATCHES "MSVC")
+if(NOT (CMAKE_C_COMPILER_ID MATCHES "MSVC" OR XCODE))
set(WIRESHARK_LD_FLAGS
-Wl,--as-needed

I still want to know what is going on because there has to be a way to
find out when the compile/link check fails.
___
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] Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Anders Broman]

Hi,
I just came across a problem where reassembly of IP fragments failed/messed up, 
see https://code.wireshark.org/review/#/c/13452/
The problem was fixed by changing line 2409 in packet-ip.c to
   iph->ip_p ^ iph->ip_id ^ src32 ^ dst32 ^ 
pinfo->vlan_id,
e.g throw vlan_id into the mix as well.

A better fix might be to change the addresses_reassembly_table_functions 
functions ( reassembly.c line 152) to include
VLAN Id as well, Opinions?

I think similar problems may exist in the TCP dissector too e.g TCP messages on 
different VLANS seen as duplicates possibly messing up
TCP analysis and reassembly. Perhaps conversations should take VLAN into 
account too.
Best regards
Anders
___
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] Mac Build Error

[Alexis La Goutte]

On Wed, Jan 20, 2016 at 3:48 PM, David Morsberger 
wrote:

>
>
> On Wed, Jan 20, 2016 at 8:43 AM, Stig Bjørlykke 
> wrote:
>
>> On Wed, Jan 20, 2016 at 1:47 PM, David Morsberger 
>> wrote:
>>
>>
> I am getting actual errors within Xcode after ‘cmake -G Xcode’. This can
>>> easily be resolved by not testing ‘—as-needed’ or ‘—pie’ when XCODE just
>>> like what is done for MSVC.
>>>
>>
>> Ah, yes, I forgot about this.  I have tried to fix this earlier without
>> luck.
>> https://www.wireshark.org/lists/wireshark-dev/201009/msg00278.html
>>
>>
>> I have a local fix in my cmake build directory for this flags, I manually
>> changed this lines in CMakeCache.txt:
>>
>> WS_LD_FLAG_VALID0:INTERNAL=0
>> WS_LD_FLAG_VALID1:INTERNAL=0
>>
>> A correct fix for this would be nice.
>>
>>
>>
>>
> My current workaround is the following change to CMakeLists.txt :
>
> -if(NOT CMAKE_C_COMPILER_ID MATCHES "MSVC")
> +if(NOT (CMAKE_C_COMPILER_ID MATCHES "MSVC" OR XCODE))
>   set(WIRESHARK_LD_FLAGS
>   -Wl,--as-needed
>
> I still want to know what is going on because there has to be a way to find 
> out when the compile/link check fails.
>
> The fix look good for me (and can be push on gerrit)

>
>
> ___
> 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
>
___
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] Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Michael Mann]

See bug 4561 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4561)
 
 
 
-Original Message-
From: Anders Broman 
To: wireshark-dev 
Sent: Wed, Jan 20, 2016 10:13 am
Subject: [Wireshark-dev] Reassembly of IP fragments gets confused by multiple 
packets on different VLANS



Hi,
I just came across a problem where reassembly of IP fragments failed/messed up, 
seehttps://code.wireshark.org/review/#/c/13452/
The problem was fixed by changing line 2409 in packet-ip.c to
   iph->ip_p ^ iph->ip_id ^ src32 ^ dst32 
^pinfo->vlan_id,
e.g throw vlan_id into the mix as well.
 
A better fix might be to change the addresses_reassembly_table_functions 
functions ( reassembly.c line 152) to include
VLAN Id as well, Opinions?
 
I think similar problems may exist in the TCP dissector too e.g TCP messages on 
different VLANS seen as duplicates possibly messing up
TCP analysis and reassembly. Perhaps conversations should take VLAN into 
account too.
Best regards
Anders

___
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
___
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] Mac Build Error

[David Morsberger]

> On Jan 20, 2016, at 10:14 AM, Alexis La Goutte  
> wrote:
> 
> 
> 
>> On Wed, Jan 20, 2016 at 3:48 PM, David Morsberger  
>> wrote:
>> 
>> 
>>> On Wed, Jan 20, 2016 at 8:43 AM, Stig Bjørlykke  wrote:
 On Wed, Jan 20, 2016 at 1:47 PM, David Morsberger  
 wrote:
  
 I am getting actual errors within Xcode after ‘cmake -G Xcode’. This can 
 easily be resolved by not testing ‘—as-needed’ or ‘—pie’ when XCODE just 
 like what is done for MSVC.
>>> 
>>> Ah, yes, I forgot about this.  I have tried to fix this earlier without 
>>> luck.
>>> https://www.wireshark.org/lists/wireshark-dev/201009/msg00278.html
>>> 
>>> 
>>> I have a local fix in my cmake build directory for this flags, I manually 
>>> changed this lines in CMakeCache.txt:
>>> 
>>> WS_LD_FLAG_VALID0:INTERNAL=0
>>> WS_LD_FLAG_VALID1:INTERNAL=0
>>>  
>>> A correct fix for this would be nice.
>> 
>> My current workaround is the following change to CMakeLists.txt :
>> -if(NOT CMAKE_C_COMPILER_ID MATCHES "MSVC")
>> +if(NOT (CMAKE_C_COMPILER_ID MATCHES "MSVC" OR XCODE))
>>  set(WIRESHARK_LD_FLAGS
>>  -Wl,--as-needed
>> 
>> I still want to know what is going on because there has to be a way to find 
>> out when the compile/link check fails.
> The fix look good for me (and can be push on gerrit) 

I plan on pushing to gerrit but I was trying to figure out Xcode, cmake, and 
clang first. 
>>  
>> 
>> ___
>> 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
> 
> ___
> 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
___
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] Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Anders Broman]

Hi,
Trying to summarize…

captured on the "all" interface of a Linux machine acting as a router, or 
merged two captures from networks on different sides of a router.

various sorts of tunneling (or "other sorts of tunneling", if you view VLANs as 
a form of tunneling)

The right generalization might be to have some sort of "network tag" which 
incorporates a network interface ID plus all VLAN tags for the packet ("all 
VLAN tags" to handle QinQ).


So if we go for network tag, or key should that be created by
Outer VLAN tag, Hash of Source MAC, protocol-level, interface index(Pcap-ng)?

Outer VLAN tag should take care of, VLAN and QinQ, right?
Source MAC should take care of, “duplicate caused by mirroring” and alike(?)
Pinfo- curr_layer_num Should take care of tunneling(?)
Interface index should take care of ANY interface traces(?)

What size should the key be, is 32bits enough?

Starting by using outer VLAN ID in the IP dissector should take care of part of 
the problem at least.

Best regards
Anders





From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Michael Mann
Sent: den 20 januari 2016 16:29
To: wireshark-dev@wireshark.org
Subject: Re: [Wireshark-dev] Reassembly of IP fragments gets confused by 
multiple packets on different VLANS

See bug 4561 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4561)



-Original Message-
From: Anders Broman 
mailto:anders.bro...@ericsson.com>>
To: wireshark-dev 
mailto:wireshark-dev@wireshark.org>>
Sent: Wed, Jan 20, 2016 10:13 am
Subject: [Wireshark-dev] Reassembly of IP fragments gets confused by multiple 
packets on different VLANS
Hi,
I just came across a problem where reassembly of IP fragments failed/messed up, 
see https://code.wireshark.org/review/#/c/13452/
The problem was fixed by changing line 2409 in packet-ip.c to
   iph->ip_p ^ iph->ip_id ^ src32 ^ dst32 ^ 
pinfo->vlan_id,
e.g throw vlan_id into the mix as well.

A better fix might be to change the addresses_reassembly_table_functions 
functions ( reassembly.c line 152) to include
VLAN Id as well, Opinions?

I think similar problems may exist in the TCP dissector too e.g TCP messages on 
different VLANS seen as duplicates possibly messing up
TCP analysis and reassembly. Perhaps conversations should take VLAN into 
account too.
Best regards
Anders
___
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=unsubscribemailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe%3c/a>
 href='mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe'>mailto:wireshark-dev@wireshark.org'>
___
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] Mac Build Error

[Stig Bjørlykke]

On Wed, Jan 20, 2016 at 3:48 PM, David Morsberger 
wrote:

> My current workaround is the following change to CMakeLists.txt :
>
> -if(NOT CMAKE_C_COMPILER_ID MATCHES "MSVC")
> +if(NOT (CMAKE_C_COMPILER_ID MATCHES "MSVC" OR XCODE))
>   set(WIRESHARK_LD_FLAGS
>   -Wl,--as-needed
>
>
This is more like fixing the symptom, right?
The real issue here is that CMake finds support for the flags while
building with Xcode does not.


-- 
Stig Bjørlykke
___
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] Mac Build Error

[David Morsberger]

On Wed, Jan 20, 2016 at 12:02 PM, Stig Bjørlykke  wrote:

> On Wed, Jan 20, 2016 at 3:48 PM, David Morsberger 
> wrote:
>
> My current workaround is the following change to CMakeLists.txt :
>>
>> -if(NOT CMAKE_C_COMPILER_ID MATCHES "MSVC")
>> +if(NOT (CMAKE_C_COMPILER_ID MATCHES "MSVC" OR XCODE))
>>  set(WIRESHARK_LD_FLAGS
>>  -Wl,--as-needed
>>
>>
> This is more like fixing the symptom, right?
> The real issue here is that CMake finds support for the flags while
> building with Xcode does not.
>


Exactly. That's why I have not submitted the change and have a support
request out to cmake.
___
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] Mac Build Error

[Guy Harris]

On Jan 20, 2016, at 4:47 AM, David Morsberger  wrote:

> I am getting actual errors within Xcode after ‘cmake -G Xcode’. This can 
> easily be resolved by not testing ‘—as-needed’ or ‘—pie’ when XCODE just like 
> what is done for MSVC.

Testing --as-needed should fail with the OS X linker whether we're using Xcode 
*or* Boring Old Makefiles, as it doesn't support --as-needed.

And we *do* test it.

I'll try to figure out why it's being included - either the test isn't failing 
and we need to trick the clang into not just whining about it but actually 
*failing*, or the test is failing with the Makefile generator but not with the 
Xcode generator.
___
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] Mac Build Error

[David Morsberger]

On Wed, Jan 20, 2016 at 1:26 PM, Guy Harris  wrote:

> On Jan 20, 2016, at 4:47 AM, David Morsberger  wrote:
>
> > I am getting actual errors within Xcode after ‘cmake -G Xcode’. This can
> easily be resolved by not testing ‘—as-needed’ or ‘—pie’ when XCODE just
> like what is done for MSVC.
>
> Testing --as-needed should fail with the OS X linker whether we're using
> Xcode *or* Boring Old Makefiles, as it doesn't support --as-needed.
>
> And we *do* test it.
>
> I'll try to figure out why it's being included - either the test isn't
> failing and we need to trick the clang into not just whining about it but
> actually *failing*, or the test is failing with the Makefile generator but
> not with the Xcode generator.
>
>
This is what I am also tracking down. It has to do with the way cmake is
instantiating the compiler. The --serialized-diagnostics option is what
appears to be hiding the error.

https://cmake.org/pipermail/cmake/2016-January/062543.html
___
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] Mac Build Error

[Guy Harris]

On Jan 20, 2016, at 11:09 AM, David Morsberger  wrote:

> This is what I am also tracking down. It has to do with the way cmake is 
> instantiating the compiler. The --serialized-diagnostics option is what 
> appears to be hiding the error.

--serialize-diagnostics takes an argument, which is the name of a file to which 
the diagnostics are written, in a binary format.

Clang documentation sucks.  Srsly.  The man page doesn't enumerate the -W 
options; the website:


http://clang.llvm.org/docs/UsersManual.html#options-to-control-error-and-warning-messages

does, but I'm not sure how to get the manual for an *arbitrary* version of 
Clang (the GCC folks are kind enough to provide online manuals, complete with 
listings of compiler flags, for multiple versions), and the word "serialize" 
appears nowhere on that page.

It might be that, when the tests are done, ld is being run directly, rather 
than by the gcc/clang driver, and that -as-needed isn't getting passed to it.  
It obviously is getting passed when the actual *build* is done.

Perhaps when CMake was being designed, its designers should have looked at the 
documentation for another configuration system - I think it's called "autoconf" 
or something such as that - and noticed that it offered not only macros to try 
compiling a file ("compiling" as in "turning a source file into an object file, 
without trying to link anything"), but macros to try *linking* things, which 
can come in handy if, say, to pick a purely *hypothetical* example, you're 
trying to see whether a given linker flag works.

Or perhaps they mistakenly had the attitude that "we take care of all the 
platform details, so you don't have to".
___
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] Mac Build Error

[David Morsberger]

On Wed, Jan 20, 2016 at 3:22 PM, Guy Harris  wrote:

> On Jan 20, 2016, at 11:09 AM, David Morsberger 
> wrote:
>
> > This is what I am also tracking down. It has to do with the way cmake is
> instantiating the compiler. The --serialized-diagnostics option is what
> appears to be hiding the error.
>
> --serialize-diagnostics takes an argument, which is the name of a file to
> which the diagnostics are written, in a binary format.
>

Yes, there is a binary .dia file generated and I cannot find any
information on the format or tools to read it.


> Clang documentation sucks.  Srsly.  The man page doesn't enumerate the -W
> options; the website:
>
>
> http://clang.llvm.org/docs/UsersManual.html#options-to-control-error-and-warning-messages
>
> does, but I'm not sure how to get the manual for an *arbitrary* version of
> Clang (the GCC folks are kind enough to provide online manuals, complete
> with listings of compiler flags, for multiple versions), and the word
> "serialize" appears nowhere on that page.
>

Welcome to my world :) I've searched all over for information and searched
my filesystem for any reference to it.


>
> It might be that, when the tests are done, ld is being run directly,
> rather than by the gcc/clang driver, and that -as-needed isn't getting
> passed to it.  It obviously is getting passed when the actual *build* is
> done.
>

I may ask the gcc/clang team why the different behavior when --serialized
argument is and is not used.


>
> Perhaps when CMake was being designed, its designers should have looked at
> the documentation for another configuration system - I think it's called
> "autoconf" or something such as that - and noticed that it offered not only
> macros to try compiling a file ("compiling" as in "turning a source file
> into an object file, without trying to link anything"), but macros to try
> *linking* things, which can come in handy if, say, to pick a purely
> *hypothetical* example, you're trying to see whether a given linker flag
> works.
>

Think of how "boring" life would be if there was only one way of doing
things.


>
> Or perhaps they mistakenly had the attitude that "we take care of all the
> platform details, so you don't have to".
>

I WILL find out how they take care of the platform details.
___
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 queastion - How to change Install Dirs, LIB and Executable names?

[Alex Lindberg]

This is a re-posting of an email that did not get sent out on the list:
I am using CMaketo build a customized version of Wireshark that needs to be 
installed beside the default Wireshark libraries and run-time files.
Todo this with previous version of Wireshark (<2) I created a SEDscript to do 
global search and replace functions to change file names,etc. The result of 
this script, that after a build, custom namedlibraries, directories and 
executable files where created. This approachworked (With a lot of hand 
'fixes') but did not allow for easy migration to newer code bases.
Sonow I am trying to do it the 'smart way' (if there is one) by migratingto 
CMake (using Jetbrains' Clion) for the build environment.  Thedefault build 
works just fine (Based on Debian's testing version of WS).
Any ideas on how to proceed?  I can imagine that my request will meet some 
resistance.
As always, thank you for your help.
Alex Lindberg
 
___
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