Re: [Wireshark-dev] Clearly, someone thought no one should be using CommView after 2038

2021-04-18 Thread Guy Harris
On Apr 18, 2021, at 10:18 PM, Eugène Adell  wrote:

> probably the guy writing this considered the "Epochalypse" problem.

Or wanted *some* test to help rule out files that are probably not ConnView NCF 
files (there is no file header, so there's no file magic number, and there's no 
packet magic number, either, so you can't just test that to check whether the 
file is an NCF file or not), and went with "make sure year is < 2038 because 
the 32-bit signed time epoch issue makes it an "obvious" choice.

It'd might still be useful to have *some* value there, to keep the heuristic 
reasonably strong, but maybe we should pick a bigger number.  (If, as per 
Richard's comment on my merge request:


https://gitlab.com/wireshark/wireshark/-/merge_requests/2762#note_554424206

Tamosoft may be considering switching to pcapng, if they do, perhaps we could 
use the year in which they do so plus 100, or something such as that.)

___
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] Clearly, someone thought no one should be using CommView after 2038

2021-04-18 Thread Eugène Adell
Hello,

probably the guy writing this considered the "Epochalypse" problem.
See https://en.wikipedia.org/wiki/Year_2038_problem if necessary.

best regards
E.A.

Le lun. 19 avr. 2021 à 04:18, Richard Sharpe
 a écrit :
>
> Hi folks,
>
> I just came across this validation check in the commview wiretap code:
>
> if (... cv_hdr.year < 1970 || cv_hdr.year >= 2038 || ...)
>
> --
> Regards,
> Richard Sharpe
> (何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者)
> ___
> 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] Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files

2021-04-18 Thread Guy Harris
On Apr 18, 2021, at 2:33 PM, Richard Sharpe  wrote:

> I am thinking of writing a wtap module to read ComView WLAN Analyzer
> and Decoder NCFS format files.
> 
> They are a little like PCAP files with a radiotap header,

...and a bit more like CommView NCF files, which we already support.

> One way to handle it would be to convert their info to a standard
> radiotap header but it looks kind of complicated to handle that.
> 
> Another approach might be to use a new or different WTAP type and
> write a separate dissector for those headers.

The way to do it, currently, is the same way it's done for NCF - fill in the 
pseudo-header in the wiretap module, and use WTAP_ENCAP_IEEE_802_11_WITH_RADIO 
for Wi-Fi packets.  (There's no per-file encapsulation type for NCF or NCFX, so 
we use WTAP_ENCAP_PER_PACKET.)

> Any thoughts?

Somebody from Tamosoft mentioned NCFX files to me a while ago, suggesting 
adding Wireshark support, and I worked on it; I've done a merge request for 
what I have now:

https://gitlab.com/wireshark/wireshark/-/merge_requests/2762

Currently, there may be some bits of information that the pseudo-header can't 
handle; if so, it should be extended to handle them.

The "number of streams" is NSS (N sub SS) minus 1 for HT, VHT, and HE PHYs - 0 
means 1 stream.

We may want to change the 802.11 pseudo-header to have data rates in units of 
100 Kb/s rather than 500 Kb/s, to handle NCFX and possibly other files.  (We 
might also want to add support for "scaled integer" fields, which display not 
as the raw value but as the value multiplied by/divided by a scaling factor, if 
avoiding inaccuracies due to scaling values not being representable exactly as 
floating-point binary numbers (.5 can, .1 can't).
___
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] still unclear how to build a new ASN.1-based dissector

2021-04-18 Thread Vincent Randal
CORRECTION:  I omitted the troublesome steps (underlined) when describing
the problem:
git clone https:// wireshark
cd wireshark
git checkout wireshark-3.4.4
cd wireshark/epan/dissectors

*cp ~/myfoo.tgz . #copy dissector code into wireshark clone*
*tar xvf myfoo.tgz #extract the dissector code (details in previous email)*
cd ../../..
mkdir build
cd build
cmake ../wireshark #this step worked previously but not on a fresh
wireshark clone now
make asn1 #with relevant entries in two CMakeListsCustom files
make

On Sun, Apr 18, 2021 at 8:15 PM Vincent Randal  wrote:

> Hello Wireshark-dev community,
>
> Apparently, I still don't have the correct sequence of steps necessary for
> first time generation of "packet-myfoo.c" and "packet-myfoo.h" for a new
> ASN.1-based dissector called myfoo. Details follow.
>
> I would like to understand (much better than I do) how to add an
> ASN.1-based dissector to epan/dissectors/asn1 in a fresh clone of
> wireshark. I got a lot of help from a lot of people last week (for which I
> am grateful) but I must still be missing a step here:
> git clone https:// wireshark
> cd wireshark
> git checkout wireshark-3.4.4
> cd ..
> mkdir build
> cd build
> cmake ../wireshark #this step worked previously but not on a fresh
> wireshark clone now
> make asn1 #with relevant entries in two CMakeListsCustom files
> make
>
> When I add my dissector folder "myfoo" to epan/dissectors/asn1 here's the
> relevant error messages from cmake (with some highlighting by me):
>
>
>
>
>
>
>
>
>
>
> *-- Configuring doneCMake Error at epan/dissectors/CMakeLists.txt:2004
> (add_library):  Cannot find source file:
> /home/vtrandal/ws1/wireshark/epan/dissectors/packet-myfoo.c  Tried
> extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm  .hpp
> .hxx .in .txxCMake Error at epan/dissectors/CMakeLists.txt:2004
> (add_library):  No SOURCES given to target: dissectors*
> [end of cmake error messages]
>
> The point of the above cmake error messages is that the "packet-myfoo.c"
> and "packet-myfoo.h" files have not yet been generated (and I don't know
> how to generate them). I do not know how I got past the cmake step before,
> but I was lucky (and unlucky now). The ASN.1-based dissector code is in the
> attached .tgz file which I extract in epan/dissectors as follows:
> tar xvf myfoo.tgz
> ./CMakeListsCustom.txt <== contains entry for myfoo
> ./asn1/CMakeListsCustom.txt <== contains entry for myfoo
> ./asn1/myfoo/
> ./asn1/myfoo/myfoo.asn
> ./asn1/myfoo/myfoo.cnf
> ./asn1/myfoo/CMakeLists.txt
> ./asn1/myfoo/packet-myfoo-template.h
> ./asn1/myfoo/packet-myfoo-template.c
>
> I apologize in advance for being thick-headed about the process of adding
> a new ASN.1-based dissector to epan/dissectors/asn1 in Wireshark. With help
> from a lot of people I got it to compile previously (again for which I am
> grateful). But I cannot repeat that success starting with a fresh clone of
> wireshark regardless of the branch. Somehow I still don't have the correct
> sequence of steps necessary to generate "packet-myfoo.c" and
> "packet-myfoo.h" the first time. With my dissector code in epan/dissectors
> the cmake step fails and I cannot make  anything.
>
> Vincent
>
> NOTE: The attached dissector code is based on the simple ASN.1-based
> dissector example online.
> https://www.wireshark.org/docs/wsdg_html_chunked/SimpleASN1BasedDissector.html
>
>
___
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] Clearly, someone thought no one should be using CommView after 2038

2021-04-18 Thread Richard Sharpe
Hi folks,

I just came across this validation check in the commview wiretap code:

if (... cv_hdr.year < 1970 || cv_hdr.year >= 2038 || ...)

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者)
___
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] still unclear how to build a new ASN.1-based dissector

2021-04-18 Thread Vincent Randal
Hello Wireshark-dev community,

Apparently, I still don't have the correct sequence of steps necessary for
first time generation of "packet-myfoo.c" and "packet-myfoo.h" for a new
ASN.1-based dissector called myfoo. Details follow.

I would like to understand (much better than I do) how to add an
ASN.1-based dissector to epan/dissectors/asn1 in a fresh clone of
wireshark. I got a lot of help from a lot of people last week (for which I
am grateful) but I must still be missing a step here:
git clone https:// wireshark
cd wireshark
git checkout wireshark-3.4.4
cd ..
mkdir build
cd build
cmake ../wireshark #this step worked previously but not on a fresh
wireshark clone now
make asn1 #with relevant entries in two CMakeListsCustom files
make

When I add my dissector folder "myfoo" to epan/dissectors/asn1 here's the
relevant error messages from cmake (with some highlighting by me):










*-- Configuring doneCMake Error at epan/dissectors/CMakeLists.txt:2004
(add_library):  Cannot find source file:
/home/vtrandal/ws1/wireshark/epan/dissectors/packet-myfoo.c  Tried
extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm  .hpp
.hxx .in .txxCMake Error at epan/dissectors/CMakeLists.txt:2004
(add_library):  No SOURCES given to target: dissectors*
[end of cmake error messages]

The point of the above cmake error messages is that the "packet-myfoo.c"
and "packet-myfoo.h" files have not yet been generated (and I don't know
how to generate them). I do not know how I got past the cmake step before,
but I was lucky (and unlucky now). The ASN.1-based dissector code is in the
attached .tgz file which I extract in epan/dissectors as follows:
tar xvf myfoo.tgz
./CMakeListsCustom.txt <== contains entry for myfoo
./asn1/CMakeListsCustom.txt <== contains entry for myfoo
./asn1/myfoo/
./asn1/myfoo/myfoo.asn
./asn1/myfoo/myfoo.cnf
./asn1/myfoo/CMakeLists.txt
./asn1/myfoo/packet-myfoo-template.h
./asn1/myfoo/packet-myfoo-template.c

I apologize in advance for being thick-headed about the process of adding a
new ASN.1-based dissector to epan/dissectors/asn1 in Wireshark. With help
from a lot of people I got it to compile previously (again for which I am
grateful). But I cannot repeat that success starting with a fresh clone of
wireshark regardless of the branch. Somehow I still don't have the correct
sequence of steps necessary to generate "packet-myfoo.c" and
"packet-myfoo.h" the first time. With my dissector code in epan/dissectors
the cmake step fails and I cannot make  anything.

Vincent

NOTE: The attached dissector code is based on the simple ASN.1-based
dissector example online.
https://www.wireshark.org/docs/wsdg_html_chunked/SimpleASN1BasedDissector.html


myfoo.tgz
Description: application/compressed-tar
___
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] Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files

2021-04-18 Thread Richard Sharpe
Hi folks,

I am thinking of writing a wtap module to read ComView WLAN Analyzer
and Decoder NCFS format files.

They are a little like PCAP files with a radiotap header, but their
format is quite different from the radiotap format. It contains much
of the same info but it is in a different format. The spec is here:

https://www.tamos.com/htmlhelp/commwifi/logformat.htm

The main things of interest are the 802.11ax info.

One way to handle it would be to convert their info to a standard
radiotap header but it looks kind of complicated to handle that.

Another approach might be to use a new or different WTAP type and
write a separate dissector for those headers.

Any thoughts?


-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者)
___
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