[Wireshark-dev] Struggling to setup Windows command-line build

[Martin Mathieson via Wireshark-dev]

Hi,

I am using Visual Studio 2019 (not community version).

My cmake step is succeeding, but when I try to build, it is pointing at an
invalid solution configuration.

[image: image.png]

My cmake command is:
[image: image.png]

I don't know why it is trying to build with RelWithDebInfo | *x86*.  The
configuration (given as the cmake -A param) that exists in the solution
file is RelWithDebInfo | x64.

[image: image.png]

I am able to build Wireshark from inside the VS IDE.

Apologies for not digging deeper into this myself, I use linux and only
create  occasional internal Windows releases for team members.

Best regards,
Martin
___
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] Struggling to setup Windows command-line build

[Graham Bloice]

On Tue, 22 Jun 2021 at 10:22, Martin Mathieson via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:

> Hi,
>
> I am using Visual Studio 2019 (not community version).
>
> My cmake step is succeeding, but when I try to build, it is pointing at an
> invalid solution configuration.
>
> [image: image.png]
>
> My cmake command is:
> [image: image.png]
>
> I don't know why it is trying to build with RelWithDebInfo | *x86*.  The
> configuration (given as the cmake -A param) that exists in the solution
> file is RelWithDebInfo | x64.
>
> [image: image.png]
>
>
Is the prompt set up for building x64?  What's the value of the platform
env var?


> I am able to build Wireshark from inside the VS IDE.
>
> Apologies for not digging deeper into this myself, I use linux and only
> create  occasional internal Windows releases for team members.
>
> Best regards,
> Martin
>
>
>
>
>

-- 
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] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[Anders Broman via Wireshark-dev]

Hi,

I think you should go for 2. Wouldn’t this type of construct from the goose 
protocol work?

 

GSEMngtRequests ::= CHOICE {

   getGoReference[1] IMPLICIT 
GetReferenceRequestPdu,

   getGOOSEElementNumber [2] IMPLICIT 
GetElementRequestPdu,

   getGsReference [3] IMPLICIT 
GetReferenceRequestPdu,

   getGSSEDataOffset   [4] IMPLICIT 
GetElementRequestPdu,

   ...

}

e.g.

MyNewProtocolMessages ::= CHOICE{

   myMeasge1 [1] IMPLICIT MyMessage1,

   :

Repeated as many times as needed, MyMessage1 could have sub messages or 
whatever…

I assume the encoder will be using an ASN1 encoder to serialize the data.

Regards

Anders

 

From: Wireshark-dev  On Behalf Of Vincent 
Randal
Sent: den 22 juni 2021 08:55
To: Developer support list for Wireshark 
Subject: [Wireshark-dev] ASN.1-based dissector decoding by port number vs 
switch/case using 1st octet

 

Hello everyone in the Wireshare-dev community,

 

The primary question in this email (but I think it requires some explanation 
below): How does one write an ASN.1-based dissector such that the generated 
code (per "make asn1") does indeed decode the first octet as the message type 
using C-style switch/case construct? 

 

In May I sat in (online) at an online Wireshark Developer Den meeting. I asked 
about encoding schemes like that in IEEE 1451.0 where the first octet is used 
to decode the message. I got a response indicating it was natural to use a 
switch/case statement in C programming to decode the messages (all of them, 
with one switch/case statement). [I gather that one switch/case statement for 
decoding all messages of a protocol implies one enumeration table for encoding 
them in the first octet.]


But I did not understand that until today. Nor did I know how to modify the 
ASN.1-based dissector “foo” to make it work with a switch/case statement. It 
had build errors from the change to cmake; I renamed it “myfoo” in my 
repository and fixed the build errors (I have been slow to make a MR, merge 
request, for it). I made the decision to base decoding entirely on port number 
and make one dissector per message per port number. Yuck, but that’s what I 
did. The current approach would add over 100 new folders to asn1 folder in 
(./epan/dissectors/asn1).  Is that acceptable? To add over 100 new folders in 
asn1 for a new protocol? [I am helping design a new protocol]. 

 

I am consider two options:

 

1. Explore the possibility of using a port-range since tcpdump and tshark 
support portrange filtering. To me that implies the possibility that people 
could indeed be implementing protocols with one dissector per message per port 
(and conceivably are using a lot ports for a single protocol in some cases). 
This new protocol allows for hundreds of unique messages. It seems, however, a 
port range of several hundred ports for one protocol is impractical and 
wasteful of port numbers. But ignoring that objection for the moment I press 
on, and ask how I might I put several hundred dissectors into a single 
source-tree under the asn1 folder (in ./epan/dissectors/asn1)? Again, assuming 
it's okay to use up several hundred UDP ports for a single protocol: What 
success might have during build step "make asn1" that it will generate 
dissectors from a source-tree of dissectors in one folder in the asn1 folder? 
For example, I am thinking I will put a group of dissectors in ./asn1/netsvc/ 
and another group in ./asn1/xdrsvc, and so on. Is anyone doing this? Is this 
supported in the current build process?

 

2. Give up on #1 above, and do something sane like use the first octet to 
encode the message type rather than waste hundreds of ports on a 
single-port-per-message-per-dissector approach describe in #1 above. This 
brings me back to the response I got in the Wireshark Developer Den in May: Use 
a C switch/case statement to decode the messages. Okay, I want to that do that. 
But I don't know how to do that for ASN.1-based dissectors. If I can learn how 
to do that then I would revise the "foo" dissector (simple ASN.1-based 
dissector) to be exactly that, get it working, and make my MR (merge-request 
for that and final give something back to this community that has been so 
helpful to me).

 

I like option #2 above, because it uses a single UDP for the entire protocol 
(again, this is a new protocol being developed as an IEEE standard). We could 
still end up using a few ports perhaps (one port per group of messages). For 
example, IEEE 1451.0 Network Services would get one UDP port, IEEE 1451.0 
Transducer Services would get another port, and so on. Then the protocol would 
need only a handful of port numbers at the most. Either way the issue remains: 
How does one even begin to write an ASN.1-based dissector such that the 
generated code (per "make asn1") do

Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[herbfalkmi]

I have a GOOSE dissector already written, but it is not a compiled version.  
Due to using old wireshark ASN.1 decoder code, and other reasons, it has not 
been integrated into the main code. The install at 
http://www.otb-consultingservices.com/brainpower/shop/ even includes an SCL 
parser that allows the dissector to show the names of the DataSet members.

 

 

 

From: Wireshark-dev  On Behalf Of Anders 
Broman via Wireshark-dev
Sent: Tuesday, June 22, 2021 6:59 AM
To: Developer support list for Wireshark 
Cc: Anders Broman 
Subject: Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs 
switch/case using 1st octet

 

Hi,

I think you should go for 2. Wouldn’t this type of construct from the goose 
protocol work?

 

GSEMngtRequests ::= CHOICE {

   getGoReference[1] IMPLICIT 
GetReferenceRequestPdu,

   getGOOSEElementNumber [2] IMPLICIT 
GetElementRequestPdu,

   getGsReference [3] IMPLICIT 
GetReferenceRequestPdu,

   getGSSEDataOffset   [4] IMPLICIT 
GetElementRequestPdu,

   ...

}

e.g.

MyNewProtocolMessages ::= CHOICE{

   myMeasge1 [1] IMPLICIT MyMessage1,

   :

Repeated as many times as needed, MyMessage1 could have sub messages or 
whatever…

I assume the encoder will be using an ASN1 encoder to serialize the data.

Regards

Anders

 

From: Wireshark-dev mailto:wireshark-dev-boun...@wireshark.org> > On Behalf Of Vincent Randal
Sent: den 22 juni 2021 08:55
To: Developer support list for Wireshark mailto:wireshark-dev@wireshark.org> >
Subject: [Wireshark-dev] ASN.1-based dissector decoding by port number vs 
switch/case using 1st octet

 

Hello everyone in the Wireshare-dev community,

 

The primary question in this email (but I think it requires some explanation 
below): How does one write an ASN.1-based dissector such that the generated 
code (per "make asn1") does indeed decode the first octet as the message type 
using C-style switch/case construct? 

 

In May I sat in (online) at an online Wireshark Developer Den meeting. I asked 
about encoding schemes like that in IEEE 1451.0 where the first octet is used 
to decode the message. I got a response indicating it was natural to use a 
switch/case statement in C programming to decode the messages (all of them, 
with one switch/case statement). [I gather that one switch/case statement for 
decoding all messages of a protocol implies one enumeration table for encoding 
them in the first octet.]


But I did not understand that until today. Nor did I know how to modify the 
ASN.1-based dissector “foo” to make it work with a switch/case statement. It 
had build errors from the change to cmake; I renamed it “myfoo” in my 
repository and fixed the build errors (I have been slow to make a MR, merge 
request, for it). I made the decision to base decoding entirely on port number 
and make one dissector per message per port number. Yuck, but that’s what I 
did. The current approach would add over 100 new folders to asn1 folder in 
(./epan/dissectors/asn1).  Is that acceptable? To add over 100 new folders in 
asn1 for a new protocol? [I am helping design a new protocol]. 

 

I am consider two options:

 

1. Explore the possibility of using a port-range since tcpdump and tshark 
support portrange filtering. To me that implies the possibility that people 
could indeed be implementing protocols with one dissector per message per port 
(and conceivably are using a lot ports for a single protocol in some cases). 
This new protocol allows for hundreds of unique messages. It seems, however, a 
port range of several hundred ports for one protocol is impractical and 
wasteful of port numbers. But ignoring that objection for the moment I press 
on, and ask how I might I put several hundred dissectors into a single 
source-tree under the asn1 folder (in ./epan/dissectors/asn1)? Again, assuming 
it's okay to use up several hundred UDP ports for a single protocol: What 
success might have during build step "make asn1" that it will generate 
dissectors from a source-tree of dissectors in one folder in the asn1 folder? 
For example, I am thinking I will put a group of dissectors in ./asn1/netsvc/ 
and another group in ./asn1/xdrsvc, and so on. Is anyone doing this? Is this 
supported in the current build process?

 

2. Give up on #1 above, and do something sane like use the first octet to 
encode the message type rather than waste hundreds of ports on a 
single-port-per-message-per-dissector approach describe in #1 above. This 
brings me back to the response I got in the Wireshark Developer Den in May: Use 
a C switch/case statement to decode the messages. Okay, I want to that do that. 
But I don't know how to do that for ASN.1-based dissectors. If I can learn how 
to do that then I would revise the "foo" dissector (simple ASN.1-based 
dissector) to be exactly

[Wireshark-dev] Struggling to build NSIS installation

[Martin Mathieson via Wireshark-dev]

Does the Java warning sound important? Is there something I should do to
try to increase the java heap size?  This machine should have loads
(c20GB)  of memory available..

[image: image.png]

Best regards,
Martin
___
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] Struggling to build NSIS installation

[Graham Bloice]

On Tue, 22 Jun 2021 at 13:41, Martin Mathieson via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:

> Does the Java warning sound important? Is there something I should do to
> try to increase the java heap size?  This machine should have loads
> (c20GB)  of memory available..
>
> [image: image.png]
>
>
Odd, Java isn't called out as an installable by the Developers Guide but
obviously ascidoctorj requires it.  Looking at my VM I have an old version
of Oracle Java 8 installed and absolutely no idea where it came from:

> java -version
java version "1.8.0_221"
Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)

> (Get-Command java.exe).Source
C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe

The invocation of asciidoctorj (if installed via chocolatey it will be
\lib\asciidoctorj\tools\asciidoctorj-x.x.x\bin\asciidoctorj.bat)
sets JVM options for memory.

I've never come across this before, and can't remember it being reported
elsewhere.

Best regards,
> Martin
>


-- 
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] Struggling to setup Windows command-line build

[chuck c]

I assume the build is working since there is a further question on java and
docbook.

What was the solution?

On Tue, Jun 22, 2021 at 4:26 AM Graham Bloice 
wrote:

>
> On Tue, 22 Jun 2021 at 10:22, Martin Mathieson via Wireshark-dev <
> wireshark-dev@wireshark.org> wrote:
>
>> Hi,
>>
>> I am using Visual Studio 2019 (not community version).
>>
>> My cmake step is succeeding, but when I try to build, it is pointing at
>> an invalid solution configuration.
>>
>> [image: image.png]
>>
>> My cmake command is:
>> [image: image.png]
>>
>> I don't know why it is trying to build with RelWithDebInfo | *x86*.  The
>> configuration (given as the cmake -A param) that exists in the solution
>> file is RelWithDebInfo | x64.
>>
>> [image: image.png]
>>
>>
> Is the prompt set up for building x64?  What's the value of the platform
> env var?
>
>
>> I am able to build Wireshark from inside the VS IDE.
>>
>> Apologies for not digging deeper into this myself, I use linux and only
>> create  occasional internal Windows releases for team members.
>>
>> Best regards,
>> Martin
>>
>>
>>
>>
>>
>
> --
> 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
>
___
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] Struggling to setup Windows command-line build

[Martin Mathieson via Wireshark-dev]

Sorry, I accidentally replied only to Graham.  Pasted here.



Ah,

[image: image.png]

The problem was that I began with  'x64_x64 Cross Tools Command Prompt for
VS 2019', rather than 'x64 Native Tools Command Prompt for VS 2019'.

When I initially pressed the Windows key then typed 'c''m'   'd'
the former appeared, whereas for the correct (latter) one I had to go
digging in the 'Visual Studio 2019' program group.

Thanks Graham!
Martin

On Tue, Jun 22, 2021 at 4:01 PM chuck c  wrote:

> I assume the build is working since there is a further question on java
> and docbook.
>
> What was the solution?
>
> On Tue, Jun 22, 2021 at 4:26 AM Graham Bloice 
> wrote:
>
>>
>> On Tue, 22 Jun 2021 at 10:22, Martin Mathieson via Wireshark-dev <
>> wireshark-dev@wireshark.org> wrote:
>>
>>> Hi,
>>>
>>> I am using Visual Studio 2019 (not community version).
>>>
>>> My cmake step is succeeding, but when I try to build, it is pointing at
>>> an invalid solution configuration.
>>>
>>> [image: image.png]
>>>
>>> My cmake command is:
>>> [image: image.png]
>>>
>>> I don't know why it is trying to build with RelWithDebInfo | *x86*.
>>> The configuration (given as the cmake -A param) that exists in the solution
>>> file is RelWithDebInfo | x64.
>>>
>>> [image: image.png]
>>>
>>>
>> Is the prompt set up for building x64?  What's the value of the platform
>> env var?
>>
>>
>>> I am able to build Wireshark from inside the VS IDE.
>>>
>>> Apologies for not digging deeper into this myself, I use linux and only
>>> create  occasional internal Windows releases for team members.
>>>
>>> Best regards,
>>> Martin
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> 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
>>
> ___
> 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] Struggling to build NSIS installation

[Gerald Combs]

As far as I can tell, Chocolatey doesn't support alternative package 
dependencies, so you get too choose between depending on a specific JRE (which 
might install an unwanted extra copy of java.exe) or none (which requires an 
extra installation step). The AsciidoctorJ package went with the latter. I've 
added a note about installing a JRE separately to the Developer's Guide in MR 
3441.

On 6/22/21 8:17 AM, Martin Mathieson via Wireshark-dev wrote:

Will try this later.  Will be interesting to see if I get an automated 
corporate email telling me to uninstall the Oracle one :)

On Tue, Jun 22, 2021 at 3:59 PM Graham Bloice mailto:graham.blo...@trihedral.com>> wrote:



On Tue, 22 Jun 2021 at 15:56, Martin Mathieson via Wireshark-dev 
mailto:wireshark-dev@wireshark.org>> wrote:

I manually installed Java "Windows Offline (64-bit)" from java.com 
 (rather than trying*choco install javaruntime*) and am now able to 
build NSIS packages.


Note the licencing of Java for Oracle versions.  This may or may not be an issue for 
you.  Much simpler to use an "open" alternative, e.g. adoptopenjdk or others.


On Tue, Jun 22, 2021 at 3:45 PM chuck c mailto:bubbas...@gmail.com>> wrote:

Maybe here https://community.chocolatey.org/packages/asciidoctorj 
 and 
https://gitlab.com/wireshark/wireshark-containers/-/blob/master/dev/windows/Dockerfile 

 ?

On Tue, Jun 22, 2021 at 9:36 AM Graham Bloice mailto:graham.blo...@trihedral.com>> wrote:

The infamous "someone" should update the WSDG to call out Java 
(64 bit) as a prerequisite for the docs.

On Tue, 22 Jun 2021 at 15:27, chuck c mailto:bubbas...@gmail.com>> wrote:


https://ask.wireshark.org/question/22386/wireshark-35-nsis-build-error/ 

"First time around building my dev environment (win10 x64), 
the Java installer picked 32-bit packages.
Similar messages to what you are seeing. Fixed by reinstalling 
64-bit Java."

On Tue, Jun 22, 2021 at 8:39 AM Graham Bloice 
mailto:graham.blo...@trihedral.com>> wrote:



On Tue, 22 Jun 2021 at 13:41, Martin Mathieson via Wireshark-dev 
mailto:wireshark-dev@wireshark.org>> wrote:

Does the Java warning sound important? Is there 
something I should do to try to increase the java heap size?  This machine 
should have loads (c20GB)  of memory available..

image.png


Odd, Java isn't called out as an installable by the 
Developers Guide but obviously ascidoctorj requires it.  Looking at my VM I 
have an old version of Oracle Java 8 installed and absolutely no idea where it 
came from:

 > java -version
java version "1.8.0_221"
Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, 
mixed mode)

 > (Get-Command java.exe).Source
C:\Program Files (x86)\Common 
Files\Oracle\Java\javapath\java.exe

The invocation of asciidoctorj (if installed via chocolatey 
it will be 
\lib\asciidoctorj\tools\asciidoctorj-x.x.x\bin\asciidoctorj.bat)
 sets JVM options for memory.

I've never come across this before, and can't remember 
it being reported elsewhere.

Best regards,
Martin



-- 
Graham Bloice


___
Sent via:    Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
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 mailto:wireshark-dev@wireshark.org>>
Archives: https://www.wireshark.org/lists/wireshark-dev 

Unsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 

              mai

Re: [Wireshark-dev] Struggling to build NSIS installation

[Gerald Combs]

The Asciidoctor.js project ships self-contained Windows executables with each 
release:

https://github.com/asciidoctor/asciidoctor.js/releases/tag/v2.2.4

I tried setting ASCIIDOCTOR_EXECUTABLE and ASCIIDOCTOR_PDF_EXECUTABLE to 
/path/to/asciidoctor-win.exe in a Windows VM here, and it was able to build 
what appear to be a valid User's Guide, Developer's Guide, and release notes. 
It looks like we should be able to use it instead, and remove our dependency on 
Java on Windows.

On 6/22/21 10:50 AM, Gerald Combs wrote:

As far as I can tell, Chocolatey doesn't support alternative package 
dependencies, so you get too choose between depending on a specific JRE (which 
might install an unwanted extra copy of java.exe) or none (which requires an 
extra installation step). The AsciidoctorJ package went with the latter. I've 
added a note about installing a JRE separately to the Developer's Guide in MR 
3441.

On 6/22/21 8:17 AM, Martin Mathieson via Wireshark-dev wrote:

Will try this later.  Will be interesting to see if I get an automated 
corporate email telling me to uninstall the Oracle one :)

On Tue, Jun 22, 2021 at 3:59 PM Graham Bloice mailto:graham.blo...@trihedral.com>> wrote:



    On Tue, 22 Jun 2021 at 15:56, Martin Mathieson via Wireshark-dev 
mailto:wireshark-dev@wireshark.org>> wrote:

    I manually installed Java "Windows Offline (64-bit)" from java.com 
 (rather than trying*choco install javaruntime*) and am now able to 
build NSIS packages.


    Note the licencing of Java for Oracle versions.  This may or may not be an issue for 
you.  Much simpler to use an "open" alternative, e.g. adoptopenjdk or others.


    On Tue, Jun 22, 2021 at 3:45 PM chuck c mailto:bubbas...@gmail.com>> wrote:

    Maybe here https://community.chocolatey.org/packages/asciidoctorj 
 and 
https://gitlab.com/wireshark/wireshark-containers/-/blob/master/dev/windows/Dockerfile 

 ?

    On Tue, Jun 22, 2021 at 9:36 AM Graham Bloice mailto:graham.blo...@trihedral.com>> wrote:

    The infamous "someone" should update the WSDG to call out Java 
(64 bit) as a prerequisite for the docs.

    On Tue, 22 Jun 2021 at 15:27, chuck c mailto:bubbas...@gmail.com>> wrote:

    
https://ask.wireshark.org/question/22386/wireshark-35-nsis-build-error/ 

    "First time around building my dev environment (win10 x64), 
the Java installer picked 32-bit packages.
    Similar messages to what you are seeing. Fixed by reinstalling 
64-bit Java."

    On Tue, Jun 22, 2021 at 8:39 AM Graham Bloice 
mailto:graham.blo...@trihedral.com>> wrote:



    On Tue, 22 Jun 2021 at 13:41, Martin Mathieson via Wireshark-dev 
mailto:wireshark-dev@wireshark.org>> wrote:

    Does the Java warning sound important? Is there 
something I should do to try to increase the java heap size?  This machine 
should have loads (c20GB)  of memory available..

    image.png


    Odd, Java isn't called out as an installable by the 
Developers Guide but obviously ascidoctorj requires it.  Looking at my VM I 
have an old version of Oracle Java 8 installed and absolutely no idea where it 
came from:

 > java -version
    java version "1.8.0_221"
    Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
    Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, 
mixed mode)

 > (Get-Command java.exe).Source
    C:\Program Files (x86)\Common 
Files\Oracle\Java\javapath\java.exe

    The invocation of asciidoctorj (if installed via chocolatey 
it will be 
\lib\asciidoctorj\tools\asciidoctorj-x.x.x\bin\asciidoctorj.bat)
 sets JVM options for memory.

    I've never come across this before, and can't remember 
it being reported elsewhere.

    Best regards,
    Martin



    --     Graham Bloice
    
___
    Sent via:    Wireshark-dev mailing list 
mailto:wireshark-dev@wireshark.org>>
    Archives: https://www.wireshark.org/lists/wireshark-dev 

    Unsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev 

              mailto:wireshark-dev-requ...@wireshark.org 
?s

[Wireshark-dev] Wiki editor permission request

[Dr. Matthias St. Pierre]

Hi,

would you be so kind and grant me permission to edit the WireShark Wiki?  I 
would like upload the IPsec examples
demonstrating the decryption of IKEv2 and ESP packets, which I mentioned in [MR 
3444], to the [SampleCaptures] page.

Regards,

Matthias  St. Pierre
GitLab:  @mspncp


[MR 3444]:  https://gitlab.com/wireshark/wireshark/-/merge_requests/3444
[SampleCaptures]: https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures



Dr. Matthias St. Pierre
Senior Software Engineer
matthias.st.pie...@ncp-e.com
Phone: +49 911 9968-0
 www.ncp-e.com

Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
Nuremberg
North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • 
Clearwater, FL 33755

Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich
Registry Court: Lower District Court of Nuremberg
Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 
133557619

This e-mail message including any attachments is for the sole use of the 
intended recipient(s) and may contain privileged
or confidential information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient,
please immediately contact the sender by reply e-mail and delete the original 
message and destroy all copies thereof.


smime.p7s
Description: S/MIME cryptographic signature
___
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] Wiki editor permission request

[Gerald Combs]

Done.

On 6/22/21 3:57 PM, Dr. Matthias St. Pierre wrote:

Hi,

would you be so kind and grant me permission to edit the WireShark Wiki?  I 
would like upload the IPsec examples
demonstrating the decryption of IKEv2 and ESP packets, which I mentioned in [MR 
3444], to the [SampleCaptures] page.

Regards,

Matthias  St. Pierre
GitLab:  @mspncp


[MR 3444]:  https://gitlab.com/wireshark/wireshark/-/merge_requests/3444
[SampleCaptures]: https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures



Dr. Matthias St. Pierre
Senior Software Engineer
matthias.st.pie...@ncp-e.com
Phone: +49 911 9968-0
  www.ncp-e.com

Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
Nuremberg
North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • 
Clearwater, FL 33755

Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich
Registry Court: Lower District Court of Nuremberg
Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 
133557619

This e-mail message including any attachments is for the sole use of the 
intended recipient(s) and may contain privileged
or confidential information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient,
please immediately contact the sender by reply e-mail and delete the original 
message and destroy all copies thereof.


___
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] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[Guy Harris]

On Jun 21, 2021, at 11:54 PM, Vincent Randal  wrote:

> The primary question in this email (but I think it requires some explanation 
> below): How does one write an ASN.1-based dissector such that the generated 
> code (per "make asn1") does indeed decode the first octet as the message type 
> using C-style switch/case construct?

"ASN.1-based" in what sense?

If the data to be dissected is *entirely* specified by an ASN.1 specification, 
using one of the representations for ASN.1, then the way it should decode the 
first octet depends on the representation - BER or one of its derived variants 
(DER, CER), PER or one of its derived variants (CPER), XER, OER, etc..

> In May I sat in (online) at an online Wireshark Developer Den meeting. I 
> asked about encoding schemes like that in IEEE 1451.0 where the first octet 
> is used to decode the message.

...and which does not appear to use any ASN.1 encoding, so it may not be 
relevant in your case.

So what is the encoding of this protocol/data format?
___
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] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[Vincent Randal]

We are using PER per the foo example (Simple ASN.1-based dissector). Wow, I
never about all these different encodings.

Maybe we should be using something other than PER? We think we like PER
because the dissected values agree with what we can see in the raw UDP data.

On Tue, Jun 22, 2021 at 7:13 PM Guy Harris  wrote:

> On Jun 21, 2021, at 11:54 PM, Vincent Randal  wrote:
>
> > The primary question in this email (but I think it requires some
> explanation below): How does one write an ASN.1-based dissector such that
> the generated code (per "make asn1") does indeed decode the first octet as
> the message type using C-style switch/case construct?
>
> "ASN.1-based" in what sense?
>
> If the data to be dissected is *entirely* specified by an ASN.1
> specification, using one of the representations for ASN.1, then the way it
> should decode the first octet depends on the representation - BER or one of
> its derived variants (DER, CER), PER or one of its derived variants (CPER),
> XER, OER, etc..
>
> > In May I sat in (online) at an online Wireshark Developer Den meeting. I
> asked about encoding schemes like that in IEEE 1451.0 where the first octet
> is used to decode the message.
>
> ...and which does not appear to use any ASN.1 encoding, so it may not be
> relevant in your case.
>
> So what is the encoding of this protocol/data format?
> ___
> 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] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[Guy Harris]

On Jun 22, 2021, at 6:33 PM, Vincent Randal  wrote:

> We are using PER per the foo example (Simple ASN.1-based dissector). Wow, I 
> never about all these different encodings.
> 
> Maybe we should be using something other than PER? We think we like PER 
> because the dissected values agree with what we can see in the raw UDP data.

You should be using whatever encoding the protocol is using.

Is this a protocol for which you have an ASN.1 specification plus an indication 
of the encoding being used, or is this something you're reverse-engineering?
___
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] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[Vincent Randal]

The protocol does not exist yet.

Neither. I am helping develop this protocol for IEEE 1451.0. I do not
represent the IEEE. I am simply volunteering (as others) in one of the
working groups (IEEE 1451.0).

Why on earth did I choose to use ASN.1? Because I was asked to provide some
form of IDL for the messages, and I found esnacc and omiidl in Linux as a
means for translating ASN.1 to IDL and syntax checking it. So then I
decided it was worth it to convert our message descriptions to ASN.1
because I could translate them to IDL (per esnacc) and generate a dissector
(ASN.1-based) with Wireshark build step "make asn1"

On Tue, Jun 22, 2021 at 7:44 PM Guy Harris  wrote:

> On Jun 22, 2021, at 6:33 PM, Vincent Randal  wrote:
>
> > We are using PER per the foo example (Simple ASN.1-based dissector).
> Wow, I never about all these different encodings.
> >
> > Maybe we should be using something other than PER? We think we like PER
> because the dissected values agree with what we can see in the raw UDP data.
>
> You should be using whatever encoding the protocol is using.
>
The protocol does not exist yet. I am helping develop this protocol.

Is this a protocol for which you have an ASN.1 specification plus an
> indication of the encoding being used, or is this something you're
> reverse-engineering?
>
Neither? I am helping develop this protocol for IEEE 1451.0. I do not
represent the IEEE. I am simply volunteering (as others) in one of the
working groups (IEEE 1451.0).

Why on earth did I choose to use ASN.1? Because I was asked to provide some
form of IDL for the messages. I found esnacc and omiidl in Linux as a means
for translating ASN.1 to IDL and syntax checking it.

So then I decided it was worth it to write our message descriptions in
ASN.1 because I could translate them to IDL (per esnacc) and generate
dissectors (ASN.1-based) with Wireshark [build step "make asn1"]. And it
seems to be working (insofar as we have tested the entire process on
several messages) except we currently have
one-port-per-message-per-dissector (over 100 new folders in
./epan/dissectors/asn1). We are wasting a lot of UDP ports on a single
protocol (again, still under development).

Anders' suggestion to use CHOICE in ASN.1 looks like a good suggestion for
decoding the first octet. Then we can have a single UDP port handle all
messages (or one port for Network Services and another port for Transducer
Services).


> ___
> 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