Re: [Wireshark-dev] Finding zlib-ng on MacOS?

[Guy Harris]

On Jun 6, 2024, at 8:36 AM, Anders Broman  wrote:

> The only reason for not going for zlib-ng only if it's available was starting 
> out with a partial implementation and being able to build during development. 
> Now it builds with zlib-ng only
> but there is some problem with the updated dependency libraries on Windows 
> still.

C:\Development\wireshark-x64-libs\vcpkg-export-20240524-1-x64-windows-ws\installed\x64-windows\include\libxml2\libxml\encoding.h(28,1):
 error C1083: Cannot open include file: 'iconv.h': No such file or directory 
[C:\builds\wireshark\wireshark\build\epan\dissectors\dissectors.vcxproj]
#include 
^ (compiling source file '../../epan/dissectors/packet-epl-profile-parser.c')

Doesn't look related to zlib-ng.
___
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] Finding zlib-ng on MacOS?

[Guy Harris]

On Jun 5, 2024, at 11:07 AM, Anders Broman  wrote:

> Th MR https://gitlab.com/wireshark/wireshark/-/merge_requests/15869
> is failing to build. I'm guessing the FindZLIBNG.cmake is not finding the 
> library(?)

Nope:

-- Checking for one of the modules 'zlib'
-- Found ZLIB: 
/Applications/Xcode-14.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/lib/libz.tbd
 
-- Looking for inflate
-- Looking for inflate - found
-- Looking for inflatePrime
-- Looking for inflatePrime - found
-- Checking for one of the modules 'zlib-ng'
-- Found ZLIBNG: /opt/homebrew/Cellar/zlib-ng/2.1.6/lib/libz-ng.dylib 
-- Looking for zng_gzopen
-- Looking for zng_gzopen - found

It's finding both zlib (as shipped with the system) *and* zlib-ng (as installed 
by Homebrew).

What appears to be happening is that it's including both the zlib and zlib-ng 
headers, and getting a collision because they're defining the same typedef and 
redefining the same structure:

In file included from 
/Users/gitlab/builds/wireshark/wireshark/wsutil/version_info.c:36:
/opt/homebrew/include/zlib-ng.h:1079:20: error: typedef redefinition with 
different types ('uint32_t (*)(void *, const uint8_t **)' (aka 'unsigned int 
(*)(void *, const unsigned char **)') vs 'unsigned int (*)(void *, unsigned 
char **)')
typedef uint32_t (*in_func) (void *, const uint8_t * *);
^
/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include/zlib.h:1102:20:
 note: previous definition is here
typedef unsigned (*in_func) OF((void FAR *,
^
In file included from 
/Users/gitlab/builds/wireshark/wireshark/wsutil/version_info.c:36:
/opt/homebrew/include/zlib-ng.h:1792:8: error: redefinition of 'gzFile_s'
struct gzFile_s {
^
/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/usr/include/zlib.h:1839:8:
 note: previous definition is here
struct gzFile_s {
^
2 errors generated.

Is there some particular reason why we search for zlib *and* zlib-ng, rather 
than, for example, searching for zlib-ng and, if we don't find it, searching 
for zlib, with some -D option to tell it not to look for zlib-ng?
___
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] Wireshark Developer's Guide feedback

[Guy Harris]

On Mar 29, 2024, at 11:23 AM, Krefta, Oliver O. - US via Wireshark-dev 
 wrote:

> Section 11.6.2.5
> My understanding is that tvb:reported_length_remaining() takes an optional 
> parameter specifying an offset. My own testing seems to confirm this. However 
> the function is documented as taking no parameters.

Yes.  That documentation is generated automatically from the Wireshark source 
code that implements the Tvb class, but the C source code for that particular 
function wasn't using the proper convention to cause the documentation 
generator to recognize the argument.  That's been fixed in the main branch and 
in the 4.2, 4.0, and 3.6 branches.

> Section 11.7 
> This section seems to have some formatting issues. Several of the documented 
> API functions are children of the "Example" subsection 11.7.2 when they 
> should be contained in the "TreeItem" subsection 11.7.1.

The "Example" subsection should be subsection 11.7.1.2.1, i.e. it should be a 
subsection of 11.7.1.2.

> Additionally, the documentation for treeitem:add() and similar functions have 
> mismatched brackets in the sentence:
> This function has a complicated form: 'treeitem:add([protofield,] [tvbrange,] 
> value], label)', such that ...
> (In fact that whole paragraph is a bit confusing to understand).

This *function* is a bit confusing to understand.  I'm not sure anything other 
than examples of every single possible way in which it can be called would be 
understandable.
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 15, 2024, at 12:01 AM, Oliver Hartkopp  wrote:

> Marc created a pull-request for Linux mainline upstream (net-next) and the 
> CAN XL VCID support will now show up in Linux 6.9:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c83c22ec1493c0b7cc77327bedbd387e295872b6

How does one request that the VCID information be provided on a PF_PACKET 
socket (whether SOCK_RAW or SOCK_DGRAM)?

___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

Wireshark 4.2.3, which includes the SocketCAN changes, has just been released.  
Presumably, various packagers of Wireshark 4.2.x will pick it up at some point.
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 1:15 PM, Oliver Hartkopp  wrote:

> Excellent! That seems to be the right approach.

OK, so:

fix libpcap to put the priority/VCID field in big-endian order in CAN 
XL frames:


https://github.com/the-tcpdump-group/libpcap/commit/eb6cfd8feae85b67529bb3c82f6a97bfd98c73f3
 in the main branch


https://github.com/the-tcpdump-group/libpcap/commit/23904ebe85c4556b77578fd8d61ef82d9bab62b4
 in the 1.10 branch

change Wireshark to treat that field as big-endian:


https://gitlab.com/wireshark/wireshark/-/commit/38a29e82cc96f727aeab7f10e751fa6e8d5e45b6
 in the main branch


https://gitlab.com/wireshark/wireshark/-/commit/b763663904b6101764c414056b9248803569d6d2
 in the 4.2 branch

update the LINKTYPE_CAN_SOCKETCAN spec to reflect all that:


https://github.com/the-tcpdump-group/tcpdump-htdocs/commit/9c357d9ed6d214bd2fc44850138c2f8861782d88

and it'll show up on the site within 24 hours.

___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 11:09 AM, Oliver Hartkopp  wrote:

> On 2024-02-12 18:54, Guy Harris wrote:
> 
>> Thus, I specified that all multi-byte fields in the CAN XL header, in 
>> LINKTYPE_CAN_SOCKETCAN packets, are little-endian (unlike the header for CAN 
>> classic and CAN FD, in which the CAN ID/flags field is big-endian):
>> https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html
>> So the question is whether the first 4 bytes of the CAN XL header are:
>> a single little-endian field in the form
>> 
>> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
>> 1 0 9 8 6 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
>> +---+---+-+-+
>> |Reserved   |  VCID |Reserved |   Priority  |
>> +---+---+-+-+
> 
> Yes! This is the correct plan.
> 
> But in fact this is a 32 bit value.

Yes, that's exactly what the figure I drew showed it as, and that's what a 
single field containing 4 bytes is on any machine likely to run 
{Linux,libpcap,Wireshark} would be.

> Currently the first 4 bytes in the Wireshark data window (in the bottom 
> right) for CAN CC & CAN look like this for CAN ID 0123:
> 
> 00 00 01 23 (which looks like big endian)

That's because, in LINKTYPE_CAN_SOCKETCAN captures, that field, *in CAN classic 
and CAN FD captures* is *defined* to be big-endian, and libpcap *explicitly 
puts it into big-endian order before handing the packet to the caller*.

> And CAN XL with VCID 0xCD and Prio 0x242 looks like this
> 
> 00 CD 02 42 (which also looks like big endian, right?)

That's because libpcap doesn't currently distinguish between CAN XL and the 
other packet types, and thus puts the first 4 bytes of the SocketCAN header 
into big-endian byte order.

It doesn't *have* to do that and, in fact, the libpcap code on the tip of the 
main and 1.10 branches puts that field into *little-endian* order for CAN XL.

However, if the goal is to allow programs that read LINKtYPE_CAN_SOCKETCAN 
captures to be able to handle both captures made with the existing libpcap 
*and* with the upcoming libpcap, the right way to handle this would be to have 
libpcap put those 4 bytes into *big-endian* byte order and put the *other two* 
multi-byte integral-valued fields - the payload length and the acceptance field 
- into *little-endian* byte order, as that's the order they'd be in with the 
libpcap 1.10.4 code if capturing on a little-endian machine.

I will update the libpcap code to put the first 4-byte field in the CAN XL 
header into big-endian order, and update the LINKTYPE_CAN_SOCKETCAN spec to 
indicate that it's big-endian (but not that the *other* multi-byte fields are).
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 4:04 AM, Oliver Hartkopp  wrote:

> I assume only ARM(64), X64 and Risc-V architectures will get in contact with 
> CAN XL. And all these archs are little-endian.

And the version of your Lua dissector at

https://github.com/hartkopp/canxl-utils/blob/main/wireshark/can_xl.lua

dissects multi-byte fields as little-endian.

Thus, I specified that all multi-byte fields in the CAN XL header, in 
LINKTYPE_CAN_SOCKETCAN packets, are little-endian (unlike the header for CAN 
classic and CAN FD, in which the CAN ID/flags field is big-endian):

https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html

So the question is whether the first 4 bytes of the CAN XL header are:

a single little-endian field in the form
 
 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
 1 0 9 8 6 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

+---+---+-+-+
|Reserved   |  VCID |Reserved |   Priority  
|

+---+---+-+-+

or, equivalently, two little-endian fields in the form

 1 1 1 1 1 1
 5 4 3 2 1 0 9 8 6 6 5 4 3 2 1 0
+-+-+
|Reserved |   Priority  |
+-+-+

 1 1 1 1 1 1
 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+---+---+
|Reserved   | VCID  |
+---+---+

with the first of those two being in bytes 0 and 1 and the second of 
those in bytes 2 and 3, in which case a VCID value of 0x12 and a priority value 
of 0x345 would be, as a sequence of octets, 0x45 0x03 0x12 0x00

or

a single little-median field in the form

 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

+-+-+---+---+
|Reserved |   Priority  |   Reserved| VCID  
|

+-+-+---+---+

or, equivalently, two little-endian fields in the form

 1 1 1 1 1 1
 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+---+---+
|Reserved   | VCID  |
+---+---+

 1 1 1 1 1 1
 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+
|Reserved |   Priority  |
+-+-+

with the first of those two being in bytes 0 and 1 and the second of 
those in bytes 2 and 3, in which case a VCID value of 0x12 and a priority value 
of 0x345 would be, as a sequence of octets, 0x12 0x00 0x45 0x03

(these being little-endian, the low-order, thus lower-numbered, bits are in the 
low-order, thus lower-address, bytes).

> The currently discussed struct canxl_frame is here:
> 
> https://lore.kernel.org/linux-can/20240128183758.68401-1-socket...@hartkopp.net/
> 
> struct canxl_frame {
> #if defined(__LITTLE_ENDIAN)
>__u16 prio;   /* 11 bit priority for arbitration */
>__u8  vcid;   /* virtual CAN network identifier */
>__u8  __res0; /* reserved / padding must be set to zero */
> #elif defined(__BIG_ENDIAN)
>__u8  __res0; /* reserved / padding must be set to zero */
>__u8  vcid;   /* virtual CAN network identifier */
>__u16 prio;   /* 11 bit priority for arbitration */
> #else
> #error "Unknown endianness"
> #endif

That appears to be the first of those two examples.
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 1:21 AM, Guy Harris  wrote:

> How many processors - as in "number of CPUs", not "number of instruction set 
> architectures" - capturing CANbus traffic and producing SocketCAN headers are 
> big-endian, and how many are little-endian?

To be more specific, how many processors - as in "number of CPUs", not "number 
of instruction set architectures" - capturing *CAN XL* traffic and producing 
SocketCAN headers are big-endian, and how many are little-endian?
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 12:07 AM, Oliver Hartkopp  wrote:

> I'm sorry but the fix went into the wrong direction and removed the formerly 
> correct values in the grey'ed line.
> 
> In the attached screenshot you can see from the plain data
> 
>    00 cd 02 42 81 00 0a 00 af af af af 00 00 00 00
> 0010   00 00 00 00 00 00
> 
> VCID = 0xCD
> PRIO = 0x0242 (here in correct in big endian)

...

> But now there are separate elements inside the first 32 bits (also in big 
> endian expression):

How many processors - as in "number of CPUs", not "number of instruction set 
architectures" - capturing CANbus traffic and producing SocketCAN headers are 
big-endian, and how many are little-endian?
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 11, 2024, at 1:19 PM, Oliver Hartkopp  wrote:

> Although the Priority 0x242 and the VCID 0xCD are correctly displayed in the 
> grey line the values below that line seem to be wrong (Priority 52480, VCID 
> 2).

Fixed in Wireshark change fdf4ecdb4aea61f6e557d75172d27ca0ffea79d7.

(All fixes mentioned have been backported to the 1.10 branch for libpcap and 
the 4.2 branch for Wireshark.)
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 11, 2024, at 1:19 PM, Oliver Hartkopp  wrote:

> Shouldn't LINUX_SLL_P_CANXL be set to 0x000E like in 
> include/uapi/linux/if_ether.h for ETH_P_CANXL instead of 0x000F here?

Fixed in libpcap commit 6735956299c5fbc803255a14fa493886e3cf81c6.
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 11, 2024, at 1:53 PM, Oliver Hartkopp  wrote:

> This issue seems to be fixed in libpcap in commit e50355893cd073c0 
> ("socketcan: *really* fix CAN FD support.")
> 
> 
> -   canhdr->fd_flags &= 
> ~(CANFD_FDF|CANFD_ESI|CANFD_BRS);
> +   canhdr->fd_flags &= 
> (CANFD_FDF|CANFD_ESI|CANFD_BRS);

Yes, *that* was the underlying reason why FD frames weren't being recognized as 
such; my trained-by-C-for-about-45-years brain sometimes automatically sticks a 
~ after an &=, given that A &= ~B is the "clear the B bits" C idiom, so that ~ 
was there where it didn't belong. e50355893cd073c0 fixed 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] Input plugin for PEAK Systems CAN interfaces

[Guy Harris]

On Jan 4, 2024, at 7:53 AM, Miklós Márton  wrote:

> The PEAK-CAN to Wireshark question came up again, and I started to work on it 
> based on this wonderful piece of code:
> https://github.com/theXappy/ExtcapNet
> 
> I also reached the point to figure out how to handle over the CAN messages 
> via extcap question.
> Would it be possible to share the code with me? I would only need the extcap 
> packet format for CAN 2.0B packets.

The packet formats for extcap are pcap format:


https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcap.html

and pcapng format:


https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcapng.html

and the link-layer types in those file formats are as described in

https://www.tcpdump.org/linktypes.html

That page lists both:

LINKTYPE_CAN20B, for which the format is *not* defined (I asked the 
people who requested it, and they don't have any documentation available);

LINKTYPE_CAN_SOCKETCAN, which is described at 
https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html.

That page will soon be updated to describe how CAN XL frames are handled.
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

So the libpcap main and 1.10 branches include changes to

not clear the CANFD_FDF flag for FD frames;

put the multi-byte fields in the CAN XL header into little-endian byte 
order;

and the Wireshark main and 4.2 branches include changes to

treat CAN frames without the CANXL_XLF flag or the CANFD_FDF flag as FD 
frames if they're exactly 72 bytes long, to work around the (fixed in the main 
and 1.10 branches) libpcap bug where CANFD_FDF is unintentionally cleared;

dissect CAN XL frames;

hand LINKTYPE_LINUX_SLL frames with a protocol type of CAN XL to the 
SocketCAN dissector;

so I think this issue will be resolved by the next Wireshark and libpcap 
releases.
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 6, 2024, at 1:24 PM, Guy Harris  wrote:

> 1) Provide a capture file that contains CAN FD frames but that isn't 
> correctly dissected, so we can see *why* the FD frames aren't being detected

OK, I managed to create the virtual CAN device on Ubuntu 22.04, recently 
updated, with a 6.5.0-17-generic kernel, with

sudo modprobe vcan
sudo ip link add dev xlsrc type vcan
sudo ip link set xlsrc mtu 2048
sudo ip link set up xlsrc

However, doing

cansend xlsrc 123##511223344

as per your mail gets a

CAN interface is not CAN FD capable - sorry.
 
error.

However, if I do

sudo ip link set xlsrc mtu 72

rather than

sudo ip link set xlsrc mtu 2048

I *can* send a CAN FD frame.  I'm not sure it will support CAN XL frames, 
however - I tried your command to generate a CAN XL frame, and it didn't appear 
to work.

How do I construct a virtual CAN device that supports CAN classic, CAN FD, 
*and* CAN XL?  Do I need a newer kernel version - or one with additional CAN XL 
support, built from modified source?

> (is the CANFD_FDF flag not set?).

It turns out it was getting cleared...

...by *libpcap*, due to a screwup on my part, so current libpcap is broken.

I've checked in code to:

look at the protocol field and force the right flag bits to be set or 
clear, based on the protocol field, even for CAN XL;

arrange to put the CAN XL fields into little-endian byte order on 
big-endian machines (if the kernel I have on my QEMU simulated IBM 
z/Architecture desktop workstation :-) running Ubuntu can be made to support a 
virtual CAN device with CAN XL support, I can test that to make sure it works), 
so that there's no "this is in host byte order" nonsense;

in


https://github.com/the-tcpdump-group/libpcap/commit/fe47b89f2ca93bbea2e9bf7b307460e6c741d6e0

and a fix to the bug where CANFD_FDF was getting cleared in


https://github.com/the-tcpdump-group/libpcap/commit/e50355893cd073c050786aad09db5aa9fdeb83cb

and backported both of those to the 1.10 branch, so we (the libpcap and tcpdump 
developers) can put out a new libpcap 1.10.5 release.

> 2) Add support to CAN XL, using the "is the 0x80 bit set in the fifth octet 
> of the header?" test, to epan/dissectors/packet-socketcan.c.

*IF* I can set up a virtual CAN device so that I can generate a capture with 
CAN classic, CAN FD, *AND* CAN XL traffic, I'll make that change.

> 3) Perhaps have libpcap forcibly set that flag based on the protocol field.

That was done as part of the aforementioned changes, just to make *extra* sure 
the right flags are set, even if the kernel doesn't happen to set them.
___
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] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 6, 2024, at 10:42 AM, Oliver Hartkopp  wrote:

> I'm currently working on CAN XL support which is the latest CAN protocol 
> after Classical CAN and CAN FD.
> 
> With Wireshark 3.6 I was able to add this dissector for CAN XL
> https://github.com/hartkopp/canxl-utils/blob/main/wireshark/can_xl.lua
> where Wireshark displayed Classical CAN, CAN FD and CAN XL correctly.
> 
> As I could see from Guys commit 39604740898f ("socketcan: support the 
> CANFD_FDF flag for identifying CAN FD frames.") there has been a change from 
> LINKTYPE_LINUX_SLL (worked and had different ETH_P_* types) to 
> LINKTYPE_CAN_SOCKETCAN.

Presumably meaning that, as per the commit comment for

https://gitlab.com/wireshark/wireshark/-/commit/39604740898f

"This will be needed when the current main-branch libpcap is released, as it 
uses LINKTYPE_CAN_SOCKETCAN rather than LINKTYPE_LINUX_SLL for ARPHRD_CAN 
devices".

Yes, libpcap 1.10.2 includes the change in question:


https://github.com/the-tcpdump-group/libpcap/commit/4357b2d0edbb6371906af2179cf3497e6e1db78a

according to

https://github.com/the-tcpdump-group/libpcap/blob/master/CHANGES#L247

(which is in the section that begins at

https://github.com/the-tcpdump-group/libpcap/blob/master/CHANGES#L189

showing that it was introduced in 1.10.2).

This means that *any* capture done with a program using 1.10.2 or later - 
tcpdump, Wireshark, etc. - on a Linux CANbus interface will use 
LINKTYPE_CAN_SOCKETCAN.

It *also* means that a capture with those version of libpcap will have the 
CANFD_FDF flag set on all frames that have LINUX_SLL_P_CANFD as the protocol 
value provided by the PF_PACKET socket (that value is also what is copied into 
the LINKTYPE_LINUX_SLL header).

This required that commit 39604740898f be made to Wireshark, to allow it to 
read those captures.

was backported to the 1.10 branch - so capturing on 

> I assume with the LINKTYPE_CAN_SOCKETCAN the correct display of the different 
> CAN traffic types broke.

As long as the frames in question are either CAN classic or CAN FD frames, and 
as long as the low-level capture code path (none of which is in Wireshark or 
tcpdump, it's in the Linux kernel and libpcap) sets the CANFD_FDF flag on CAN 
FD frames and doesn't set it on CAN classic frames, the display of those CAN 
traffic types works.

Note, however, that there is no mention of CAN XL there.

Wireshark includes absolutely *no* code to handle CAN XL.

libpcap also includes no such code.

This means that CAN XL frames will either look as if they're CAN classic or CAN 
FD frames; given the way libpcap works, they'll look as if they're CAN classic 
frames, as they don't have ETH_P_CANFD as the protocol type.

The LINKTYPE_CAN_SOCKETCAN header looks like

https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html

The headers from Linux for various CAN frame types are, as taken from Linux's 
can.h header:

/**
 * struct can_frame - Classical CAN frame structure (aka CAN 2.0B)
 * @can_id:   CAN ID of the frame and CAN_*_FLAG flags, see canid_t definition
 * @len:  CAN frame payload length in byte (0 .. 8)
 * @can_dlc:  deprecated name for CAN frame payload length in byte (0 .. 8)
 * @__pad:padding
 * @__res0:   reserved / padding
 * @len8_dlc: optional DLC value (9 .. 15) at 8 byte payload length
 *len8_dlc contains values from 9 .. 15 when the payload length is
 *8 bytes but the DLC value (see ISO 11898-1) is greater then 8.
 *CAN_CTRLMODE_CC_LEN8_DLC flag has to be enabled in CAN driver.
 * @data: CAN frame payload (up to 8 byte)
 */
struct can_frame {
canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
union {
/* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
 * was previously named can_dlc so we need to carry that
 * name for legacy support
 */
__u8 len;
__u8 can_dlc; /* deprecated */
} __attribute__((packed)); /* disable padding added in some ABIs */
__u8 __pad; /* padding */
__u8 __res0; /* reserved / padding */
__u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 15) */
__u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
};

/*
 * defined bits for canfd_frame.flags
 *
 * The use of struct canfd_frame implies the FD Frame (FDF) bit to
 * be set in the CAN frame bitstream on the wire. The FDF bit switch turns
 * the CAN controllers bitstream processor into the CAN FD mode which creates
 * two new options within the CAN FD frame specification:
 *
 * Bit Rate Switch - to indicate a second bitrate is/was used for the payload
 * Error State Indicator - represents the error state of the transmitting node
 *
 * As the CANFD_ESI bit is internally generated by the transmitting CAN
 * controller only the CANFD_BRS bit is relevant for real CAN controllers when
 * building a CAN FD frame for transmission. 

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

[Guy Harris]

On Dec 21, 2023, at 6:51 AM, Bálint Réczey  wrote:

> I'm not sure why libvirt dissector users should be "their users". In my eyes 
> they are very much our users as well since they use Wireshark extended with 
> the plugin and I'm happy that they get the best service.

It appears that the protocol that the libvirt dissector handles is an ONC 
RPC-based protocol, and that the dissector, for some unknown reason, has its 
own XDR routines, rather than using the ones that come with Wireshark and are 
used by the built-in dissectors for various ONC RPC-based protocols.

Is there some compelling reason why we don't just implement a built-in 
dissector for the libvirt protocol, using our built-in support for ONC 
RPC-based protocols, and render the libvirt plugin unnecessary?

(Speaking of ONC RPC-based protocols, it might also be nice if somebody either 
1) took the libvirt project's genxdrstub.pl Perl script and turned it into a 
script that converts rpcgen specifications for ONC RPC-based protocols into 
dissectors using our built-in ONC RPC support or 2) took Sun's rpcgen itself 
and did the same?  If somebody went with 2), they should probably grab a 
reasonably recent version of rpcgen, such as one from OpenSolaris - probably 
the one in Illumos - rather than one from the 1980's-vintage open-source ONC 
RPC release Sun put out, as the latter doesn't have support for 64-bit 
integers.)
___
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] Tracking branches, GitHub and Launchpad

[Guy Harris]

On Dec 17, 2023, at 10:08 AM, Jaap Keuter  wrote:

> 1. The GitHub mirror is picking up all our cherry-pick branches, which now 
> run in the hundreds.

1.5. Are cherry-pick branches deleted once the changes on those branches are 
merged into the version branch and, if not, why not?  Do they serve some 
purpose such as recording history that is, in some fashion, of interest?  The 
changes themselves are in the version branch and, by default, the commit 
message includes the signature of the commit from which it was cherry-picked.
___
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] Changes to the plugin registration API

[Guy Harris]

On Dec 3, 2023, at 10:30 PM, Anders Broman  wrote:

> Does this mean that we are no longer allowing private closed source plug-ins 
> not distributed outside of companies?

To quote the GPL v2 FAQ's question+answer "When is a program and its plug-ins 
considered a single combined program?":

https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins

"It depends on how the main program invokes its plug-ins. If the main program 
uses fork and exec to invoke plug-ins, and they establish intimate 
communication by sharing complex data structures, or shipping complex data 
structures back and forth, that can make them one single combined program. A 
main program that uses simple fork and exec to invoke plug-ins and does not 
establish intimate communication between them results in the plug-ins being a 
separate program.

If the main program dynamically links plug-ins, and they make function calls to 
each other and share data structures, we believe they form a single combined 
program, which must be treated as an extension of both the main program and the 
plug-ins. If the main program dynamically links plug-ins, but the communication 
between them is limited to invoking the ‘main’ function of the plug-in with 
some options and waiting for it to return, that is a borderline case.

Using shared memory to communicate with complex data structures is pretty much 
equivalent to dynamic linking."

which, combined with the question+answer "If I add a module to a GPL-covered 
program, do I have to use the GPL as the license for my module?":

https://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense

"The GPL says that the whole combined program has to be released under the GPL. 
So your module has to be available for use under the GPL.

But you can give additional permission for the use of your code. You can, if 
you wish, release your module under a license which is more lax than the GPL 
but compatible with the GPL. The license list page gives a partial list of 
GPL-compatible licenses."

This at least suggests that, unless we explicitly have a statement allowing 
private closed source plug-ins not distributed outside of companies, the 
question as to whether we allow private closed source plug-ins not distributed 
outside of companies is one that may require a lawyer familiar with the GPL to 
look at the GPL and determine what, absent such a statement, is allowed.

Absent any special exception we grant, that would seem to imply that the 
combination of Wireshark and any dynamically-linked plugin for Wireshark is, at 
least in the view of the FSF, "a single combined program, which must be treated 
as an extension of both the main program and the plug-ins", which seems to 
imply that the combination, at least, is licensed

For what it's worth, the impression *I* had is that plugins are licensed under 
the GPL v2, so that, at minimum, anybody who gets a binary to such a plugin is 
entitled to the source code *and* is allowed to modify that source code and to 
redistribute the unmodified or modified source code under the terms of the GPL.
___
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] The If_fcslen option unit mismatch

[Guy Harris]

On Nov 1, 2023, at 2:49 AM, Jaap Keuter  wrote:

> There’s a recent issue raised on a mismatch between the pcapng spec and 
> Wireshark interpretation of it. The issue revolves around the unit used for 
> the If_fcslen option in the pcapng file format.
> The Wireshark issue is here: 
> https://gitlab.com/wireshark/wireshark/-/issues/19174
> Apparently this was already identified in 2019, by Guy in the pcapng 
> specification.
> The pcapng issue is here: 
> https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/issues/60
> However, this was never resolved, as in, a conclusion was never reached.
> How should we progress with this, now that it has become a noticed problem? 
> Guy, do you have additional insights since the initial report from 2019?

It should be resolved by making Wireshark conform to the pcapng specification.

That has been done in the main branch in

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

and in the 4.2 branch in

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

and in the 4.0 branch in

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

and in the 3.6 branch in

https://gitlab.com/wireshark/wireshark/-/merge_requests/13008
___
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] question on validation of a dissected string from a BASE_CUSTOM hf item

[Guy Harris]

On Sep 7, 2023, at 9:15 AM, John Dill  wrote:

> I have a question whether I can get the dissected string of the BASE_CUSTOM 
> header field so that I can do analysis on it and convert it to floating point 
> to do range analysis so I can issue an expert info if the value is valid but 
> out of range.

...

> Is there a way for me to peel the dissected result string from "ti" after the 
> proto_tree_add_item call so that I can do validation and range checking for 
> expert info?

Do you want the *dissected result*, or do you want MHz_Frequency and 
KHz_Frequency or, alternatively, as Frequency, being a sufficiently-large 
integral type in units of KHz?

"Validation and range checking" sounds as if it might be something such as "is 
this frequency within the valid range?" (e.g., neither DC nor daylight are in 
the valid range), which might be easier to do on the frequency as a number 
rather than by undoing the conversion to a string.

If so, perhaps what's called for is a new mechanism to provide private 
*encodings*, so that the dissectors registration routine might do something 
such as

guint32 enc_frequency;

...

enc_frequency = register_integer_encoding_uint64(my_frequency_routine);

where "encode_frequency() would take a tvbuff and an offset (and possibly other 
arguments as necessary) and provides a 64-bit unsigned integer.  Then you could 
do

ti = proto_tree_add_item(word_tree, 
hf_XTS_5000_APX_8000_Receive_Frequency, tvb, offset, 6, enc_frequency);

with the registration routine returning an encoding value guaranteed not to 
collide with any predefined encodings for that type or with any other 
registered encoding.

On Sep 14, 2023, at 9:52 AM, John Dill  wrote:

> I parse 1553 data

What is "1553"?

IEEE 1553 is "IEEE Standard for Voltage Endurance Testing of Form-Wound Coils 
and Bars for Hydrogenerators", which is probably not it.

MIL-STD-1553 is a databus, which seems more like the sort of thing for which 
Wireshark could be involved.

> over ethernet and often times the encodings for certain data items can be... 
> creative.  I would certainly prefer to mod a way in Wireshark to use the 
> custom function once for the display and return the dissected display string 
> as part of adding the item to the proto_tree for expert_info validation (an 
> example expert_info is when something demarcated as spare in the expected 
> data is non-zero, indicating some kind of data definition drift to equipment 
> over time).
> 
> My use case is kind of an amalgam of 
> proto_tree_add_item_ret_display_string_and_length, but the header field 
> represents a 16-bit up to 64-bit integer that is set to BASE_CUSTOM with a 
> function that returns the resulting dissected string from the custom function 
> pointer.

A custom encoding of the proposed sort, and a custom formatter, could both be 
used; the custom decoder routine could either itself add an expert info item, 
or could include both a decoding routine and a checking routine to add expert 
info.

This could be combined with a custom *display* routine.
___
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] Option to disable Expert Info for issue with frame length

[Guy Harris]

On Jul 24, 2023, at 1:47 AM, CheeHow WEE  wrote:

> Thanks for explaining a detailed "possible" implementation of the packet 
> alignment in previous mails.
> It's actually performed within the given PCIe based FPGA capture card, hence 
> the packets are stored in the card's memory (presumably a ring buffer) by 
> firmware aligned to a certain boundary for efficiency reasons.
> In our case, it's 32 bits.

Are the packets in the capture card's buffer in the form of pcap Packet 
Records, with the card putting a pcap Packet Record header in front of each 
packet's data, so that you can just write data to disk directly from the card's 
buffer (or have the card's buffer transferred into host memory and then writing 
to disk directly from host memory)?

And does "aligned to a certain boundary for efficiency reasons. In our case, 
it's 32 bits." mean that 1) the Packet Records are all padded to 32 bits in the 
buffer and 2) that the Captured Packet Length field in the Packet Record 
headers is, rather than the number of captured bytes in the packet, the number 
of packet bytes in the packet *rounded up to a multiple of 4 bytes*?

If so, does the capture card support "slicing" packets, so that not all bytes 
in the packet on the network are in the packet in the capture?

> The main concern from our side is actually Wireshark added Commit 8674eea7 
> and fixed Issue 18312, there're a lot of error frames that are marked as 
> opposed to earlier versions.
> It causes temporal understanding mismatch when a user reads a PCAP generated 
> by our capture system on Wireshark.
> We would like to request a "reverse" of the commit by having an option.

"You have a problem.  You add an option to work around the problem.  You now 
have two problems." :-)

Is there some reason why an option is preferable to, for example, changing the 
pcap specification, so that Captured Packet Length > Original Packet Length 
means that the Packet Record is padded, and the real Captured Packet Length is 
equal to the Original Packet Length?  The lack of an option means that 
Wireshark Just Works with both normal pcap files and padded pcap files, with 
users not having to worry about correctly setting an option?

(And libpcap should be changed as well, for the same reason.)
___
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] Option to disable Expert Info for issue with frame length

[Guy Harris]

On Jul 18, 2023, at 8:10 PM, CheeHow WEE via Wireshark-dev 
 wrote:

> There's a "padding" added for a 4-bytes aligned PCAP writing API.
> - I understood that the latest Wireshark app dev logic such that length 
> should not be lesser than captured length.
> - In highspeed performance (scale of > 100 million packets per second) PCAP 
> writing, it's necessary to form a bulk hence the 4-bytes aligned packet size 
> was formulated.

By "In highspeed performance (scale of > 100 million packets per second) PCAP 
writing, it's necessary to form a bulk" do you mean that, in order to be able 
to write packets at high speed, you buffer up a large number of pcap Packet 
Records in memory and then write a buffer out in one write operation, and that 
aligning the Packet Records on 4-byte boundaries means that when you put a 
Packet Record into the buffer, you're storing 4-byte values on 4-byte 
boundaries and copying packet data to a 4-byte boundary, thus not getting any 
penalties for doing misaligned stores?

If so, note that pcapng blocks are always aligned on 4-byte boundaries, so if 
you write a pcapng file in this fashion, it doesn't require any hacks to code 
that reads the file.

> - For offset padding, a junk trailer bytes are added to a packet to the full 
> packet size.
> - Example.:
> Frame length: 194 bytes (not multiple of 4)
> Capture length: 196 bytes (size of a written packet)
> Trailer length: 2 bytes
> 
> I can't argue that in this case the capture length is the universal truth, 
> but at least it's mitigated to avoid actual malformed packet.
> Consider following scenario also:
> Frame length: 193 bytes (not multiple of 4) <-- Actual captured packet
> Capture length: 196 bytes (size of a written packet)
> Trailer length: 2 bytes
> There's 1 byte missing, and in this case it's a real malformed packet from 
> the perspective of a captured device.

If the "actual captured packet" is 193 bytes long, then, in a padded pcap file, 
there would need to be *3* bytes of trailer.  If the packet was *supposed* to 
be 194 bytes long, but whatever software constructed it left one byte out, 
then, as code that reads padded pcap files would mark that packet as having a 
captured length of 193 bytes and an original length of 193 bytes, and the 
dissector would presumably run out of bytes, as it'd be dissecting something 
that *should* have been 194 bytes long, and would show an error.
___
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] Option to disable Expert Info for issue with frame length

[Guy Harris]

On Jul 18, 2023, at 8:10 PM, CheeHow WEE via Wireshark-dev 
 wrote:

> There's a "padding" added for a 4-bytes aligned PCAP writing API.
> - I understood that the latest Wireshark app dev logic such that length 
> should not be lesser than captured length.
> - In highspeed performance (scale of > 100 million packets per second) PCAP 
> writing, it's necessary to form a bulk hence the 4-bytes aligned packet size 
> was formulated.
> - For offset padding, a junk trailer bytes are added to a packet to the full 
> packet size.
> - Example.:
> Frame length: 194 bytes (not multiple of 4)
> Capture length: 196 bytes (size of a written packet)
> Trailer length: 2 bytes

Section 5 "Packet Record" of the current version of the pcap specification:


https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcap.html#name-packet-record

says:

Captured Packet Length (32 bits):
an unsigned value that indicates the number of octets captured 
from the packet (i.e. the length of the Packet Data field). It will be the 
minimum value among the Original Packet Length and the snapshot length for the 
interface (SnapLen, defined in Figure 1).

Original Packet Length (32 bits):
an unsigned value that indicates the actual length of the 
packet when it was transmitted on the network. It can be different from the 
Captured Packet Length if the packet has been truncated by the capture process; 
it SHOULD NOT be less than the Captured Packet Length.

A pcap file writer MAY write an Original Packet Length that is 
less than the Captured Packet Length if both the Captured Packet Length and the 
Original Packet length came from a file in which a packet had an Original 
Packet Length less than the Captured Packet Length; otherwise, it MUST write an 
Original Packet Length that is greater than or equal to the Captured Packet 
Length.

A pcap file reader MAY convert an Original Packet Length that 
is less than the Captured Packet Length to a value that is greater than or 
equal to the Captured Packet Length.

Packet Data:
the data coming from the network, including link-layer headers. 
The actual length of this field is Captured Packet Length. The format of the 
link-layer headers depends on the LinkType field specified in the file header 
(see Figure 1) and it is specified in [I-D.ietf-opsawg-pcaplinktype].

If you want to have a mechanism to use to pad pcap packet records to a multiple 
of 4 bytes, then:

1) that's going to require some changes to code that reads pcap files 
(libpcap, Wireshark's libwiretap, etc.);

2) that's going to require a change to the pcap specification.

Some possible changes to the pcap specification:

1) The specification can be changed to indicate that Captured Packet 
Length > Original Packet Length means that:

the full packet data has been captured and written to the file;

the Original Packet Length field indicates the amount of packet 
data;

{Captured Packet Length} - {Original Packet Length} is the 
amount of padding added after the packet data;

or

2) we introduce new magic numbers for "padded pcap" files, which means 
we could, for example, state that in "padded pcap" files, all Packet Records 
are padded to a multiple of 4 bytes.
___
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] Handling larger than 2 GB packets in dissectors

[Guy Harris]

On Jul 10, 2023, at 12:18 PM, Markku Leiniö  wrote:

> Anyway, to the point. In Zabbix protocol header 
> (https://www.zabbix.com/documentation/current/en/manual/appendix/protocols/header_datalen)
>  the normal data length is 4-byte unsigned integer ("uint32"). However, there 
> is a flag for large packets, used in specific Zabbix proxy configurations 
> where the configuration sizes are over 4 GB, and in those cases the data 
> length is 8-byte unsigned integer ("uint64"). (Plus it uses compression, and 
> the specified maximum uncompressed packet size is currently 16 GB.)
> 
> In Wireshark the dissector functions use a signed integer ("gint", 32-bit, 
> right?)

Right.

> as the length and start/offset parameters.
> 
> Assuming that I would like to handle the full >2 GB protocol packets in 
> Wireshark (I don't know how crazy or practical idea that would even be), how 
> should that be done? For example, if I would like to give the user the 
> possibility to right-click the huge JSON blob (in the Zabbix packet) and copy 
> it to somewhere else for inspecting, what would I need to do to get past the 
> 2 GB (signed 32-bit integer) limit?

You would need to change Wireshark:

1) not to use negative offsets to mean "offset from the end of the 
packet" (I don't know whether that's used anywhere) and not to use a length of 
-1 as meaning "to the end of the tvbuff" (there are already "to the end of the 
rebuff" APIs that should be used instead, although there may have to be more 
added) and not to use negative offsets or lengths for any other purposes;

2) to, having made the changes in 1), use 64-bit *unsigned* values as 
offsets within packets and lengths of packets.

This would still require reassembling packets into single chunks within the 
address space.
___
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] Wireshark 4.0.1 clone and build fails with test failures and complaints about paths prefixed in the source directory

[Guy Harris]

On May 4, 2023, at 10:16 AM,   
wrote:

> Succeeded by -- creating C:\Project\wireshark, cloning in to 
> C:\Project\wireshark\wireshark, making C:\Project\wireshark\build, and 
> running CMake from within C:\Project\wireshark\build
>  
> My build directory was also a peer, but not named ‘build’, and not under 
> C:\Project\wireshark.

It's... not a requirement that the build directory be named "build".  I have 
C:\Development\wireshark with the Wireshark Git tree and 
C:\Development\wsbuild64 as the build directory.

In C:\Users\guy\bin (yes, I'm a Unix person; why do you ask? :-)) I have 
scripts setup-wireshark.bat:

set WIRESHARK_BASE_DIR=C:\Development
set WIRESHARK_QT6_PREFIX_PATH=\Qt\6.2.4\msvc2019_64

to set up a command-line window for building Wireshark, cmake-wireshark.bat:

cmake -G "Visual Studio 17 2022" -A x64 -DENABLE_LTO=off ..\wireshark

run in the build directory to run CMake, and build-wireshark.bat:

msbuild /m /p:Configuration=RelWithDebInfo Wireshark.sln

run in the build directory to build Wireshark.
___
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] Option to disable Expert Info for issue with frame length

[Guy Harris]

On Mar 29, 2023, at 10:10 AM, Duy Khanh Pham  wrote:

> From your article, I understand that the Captured Packet Length is the Frame 
> Length/Length on wire/real length and Original Packet Length is the "Capture 
> Length/captured length" in the attached picture.
> 
> My issue is that the capture card in our system always writes packets with 
> "Original Packet Length" bigger than or equal to the "Captured Packet Length" 
> (attached example pcap file). In your article, "Original Packet Length" can 
> be greater than "Captured Packet Length", so I don't think that is an error 
> from my capture card.

Did you mean to say "Original Packet Length" when you said "Captured Packet 
Length" and to say "Captured Packet Length" when you said "Original Packet 
Length"?

The Internet Draft in question says that the "Original Packet Length" is the 
frame length/length onwire/real length:

Original Packet Length (32 bits): an unsigned value that indicates the 
actual length of the packet when it was transmitted on the network.

and that the "Captured Packet Length" is the number of bytes in the capture:

Captured Packet Length (32 bits): an unsigned value that indicates the 
number of octets captured from the packet (i.e. the length of the Packet Data 
field).

That is the exact *opposite* of

the Captured Packet Length is the Frame Length/Length on wire/real 
length and Original Packet Length is the "Capture Length/captured length"

___
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] Option to disable Expert Info for issue with frame length

[Guy Harris]

On Mar 22, 2023, at 11:40 AM, Duy Khanh Pham via Wireshark-dev 
 wrote:

> My case for this request is when doing network data capturing with a capture 
> card. The capture card always sets the capture length to a multiple of 4 due 
> to performance requirement.
>  
> As a result, the real length will always be less than or equal to the set 
> captured length.

What do you mean here by "capture length"?

In the record header of packet records in pcap files:


https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcap.html#name-packet-record

the two length fields are defined as follows:

Captured Packet Length (32 bits):
an unsigned value that indicates the number of octets captured 
from the packet (i.e. the length of the Packet Data field). It will be the 
minimum value among the Original Packet Length and the snapshot length for the 
interface (SnapLen, defined in Figure 1).

Original Packet Length (32 bits):
an unsigned value that indicates the actual length of the 
packet when it was transmitted on the network. It can be different from the 
Captured Packet Length if the packet has been truncated by the capture process; 
it SHOULD NOT be less than the Captured Packet Length.

A pcap file writer MAY write an Original Packet Length that is 
less than the Captured Packet Length if both the Captured Packet Length and the 
Original Packet length came from a file in which a packet had an Original 
Packet Length less than the Captured Packet Length; otherwise, it MUST write an 
Original Packet Length that is greater than or equal to the Captured Packet 
Length.

A pcap file reader MAY convert an Original Packet Length that 
is less than the Captured Packet Length to a value that is greater than or 
equal to the Captured Packet Length.

and, in the block header of Enhanced Packet Blocks in pcapng files:


https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcapng.html#name-enhanced-packet-block

they are defined as follows:

* Captured Packet Length (32 bits): an unsigned value that indicates 
the number of octets captured from the packet (i.e. the length of the Packet 
Data field). It will be the minimum value among the Original Packet Length and 
the snapshot length for the interface (SnapLen, defined in Figure 10). The 
value of this field does not include the padding octets added at the end of the 
Packet Data field to align the Packet Data field to a 32-bit boundary.

* Original Packet Length (32 bits): an unsigned value that indicates 
the actual length of the packet when it was transmitted on the network. It can 
be different from the Captured Packet Length if the packet has been truncated 
by the capture process; it SHOULD NOT be less than the Captured Packet Length.

A pcapng file writer MAY write an Original Packet Length that is less 
than the Captured Packet Length if both the Captured Packet Length and the 
Original Packet length came from a file in which a packet had an Original 
Packet Length less than the Captured Packet Length; otherwise, it MUST write an 
Original Packet Length that is greater than or equal to the Captured Packet 
Length.

A pcapng file reader MAY convert an Original Packet Length that is less 
than the Captured Packet Length to a value that is greater than or equal to the 
Captured Packet Length.

Unless the capture card is slicing packets should, both the "captured length" 
and the "real length" should have the *exact same value*, which should reflect 
the number of bytes worth of packet data, *not* including any padding added by 
the capture card.  In addition, the padding should *not* be written to the 
capture file.

So what does the "capture length" refer to for your capture card?
___
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] macOS Xcode build failure on multiple commands producing same directory

[Guy Harris]

On Mar 1, 2023, at 7:18 AM, Alexander Kapshuk  
wrote:

> Pointers on how to proceed with this would be much appreciated.

Short-term?

Build with make - or Ninja - instead (that's how the Wireshark buildbots 
operate).  Attempting to figure out why this is an issue with Xcode will 
probably take time.
___
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] Dissecting pcapng local block types

[Guy Harris]

On Feb 1, 2023, at 12:58 AM, Joakim  wrote:

> if you manage to add a dissector table that would be great! I believe my 
> company too will implement non-standard blocks so it would be very convenient 
> to have it available.

Note that what's being discussed here would *only* handle dissecting the 
non-standard blocks when you're dissecting the structure of the pcapng file the 
same way that we can dissect the structure of, for example, JPEG files; it 
won't affect the handling of the block in libwiretap nor will it affect the 
handling of it in libwireshark when you're reading a pcapng file as a capture 
file rather than as some type of file whose internal structure is to be 
dissected.

We already have a plugin mechanism in libwiretap for the first of those 
(although the interface could, I think, be improved; I'll look at some work I 
did on that) and a plugin mechanism in libwireshark (currently using the 
REC_TYPE_FT_SPECIFIC_{EVENT,REPORT} block type, but that might also be 
improved).

However, you might want to look at implementing *custom* blocks, instead.  If 
your company has a Private Enterprise Number:

https://en.wikipedia.org/wiki/Private_Enterprise_Number

it can use them, and would not have to worry about some other organization 
using the same block number that you use.
___
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] Dissecting pcapng local block types

[Guy Harris]

On Jan 28, 2023, at 3:19 PM, Martin Mathieson via Wireshark-dev 
 wrote:

> I have 5 non-standardised/local block types that are in-use within my 
> company, that are in the 'local' range  0x8000-0x.
> 
> My first thought was to add a dissector table (pcapng.block-types ?) by 
> 'Block Type Code' in file-pcapng.c, then have dissectors register by adding 
> themselves to the table.
> 
> However, looking at the dissector code, it appears that just registering a 
> dissector would not work well, and that there are several points where 
> file-pcapng needs to reference block-type-specific information:
> 
> - a name to show for the block (currently fixed vals[] for standard block 
> types)

That's a problem not unique to pcapng blocks.

There exists a next-protocol type field for which we have a dissector table, 
named "ethertype", but a dissector registering itself in that table can't also 
add an entry to the etype_vals[] table.

It might be nice to have a mechanism to solve that in general.

However...

> - a callback function for handling the body of the block type
> - options handling (another dissector callback and maybe vals[] ?)

...those are specific to pcapng block types.  There are other cases a protocol 
offers its own registration routine to allow sub dissectors to register more 
than just a dissector, e.g. rpc_init_prog() for ONC RPC and dcerpc_init_uuid() 
for DCE RPC.  It's harder to generalize that in a "static" (compile-time) 
fashion; it'd either involve:

passing a generic pointer, where the parent and child dissector agree 
on the type of structure to which that generic pointer points;

adding parent-dissectors-specific registration routines to the API (as 
is the case with, for example, ONC RPC and DCE RPC - I think there are other 
examples);

passing a key-value store, which is somewhat like the generic pointer, 
except that there came be some run-time checking done by the callee.

So, for now:

> So maybe the dissector for these types could register this information (per 
> block id) in its handoff function, and file-pcapng.c would look up a table 
> when handling entries in the 'local' range.

...perhaps the second solution would be the right one, at least for now, with 
the handoff function calling pcapng's "register a local block type" routine.

> I do notice handling for BLOCK_DARWIN_PROCESS (0x8001) is already 
> built-in to file-pcapng.c...

Whatever mechanism we use should also support moving Apple's process info block 
out of file-pcapng.c as well.
___
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] What is the best way to locate [GLib CRITICAL] -- g_string_free: assertion 'string != NULL' failed

[Guy Harris]

On Dec 23, 2022, at 4:17 PM,   
wrote:

> I run Wireshark 4.1.0 with my plugin dissector. It runs well, dissects 
> packets, reports issues, and behaves as expected. I can load a capture file, 
> that has packets of my protocol, exit Wireshark, and get no output to the 
> command line. I can load another capture file, that has packets of my 
> protocol, and get many many errors like:
> ** (wireshark:n) hh:mm:ss.fff [GLib CRITICAL] -- g_string_free: 
> assertion 'string != NULL' failed
> where:
>   • n is always the same number within a single run of Wireshark, and 
> changes from run to run.

It's the process ID of the process running Wireshark.

>   • The timestamps can be 0.01 to 0.03 seconds apart and give me more 
> than 60 in a second.

The code that's trying to free something "pointed to" by a null pointer is 
being executed many times within a second.

>   • The list is output whenever I run a display filter or clear the 
> display filter.

The packets are redirected when that happens, so it's probably happening within 
a dissector.

>   • The list seems to be the same size whether the filter returns all 
> packets, or some, or even two.

When a display filter is applied, it's applied to *all* packets.

> Maybe it is getting this error in my dissector or in another one.

Almost certainly.  My guess is that it's your dissector; what happens if you 
remove your dissector?

> Is the error saying that it is trying to free a non-null string that has 
> already been freed?

The beginning of g_string_free() is

gchar *
g_string_free (GString  *string,
   gboolean  free_segment)
{
  gchar *segment; 

  g_return_val_if_fail (string != NULL, NULL);

and the g_return_val_if_fail() call is what's failing.

> In any event, are there any recommendations for trying to locate this error?

Look for all places in your code where you're calling g_string_free() and make 
sure they can't be called with a null pointer.
___
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] can't compile wireshark version 4.0

[Guy Harris]

On Oct 20, 2022, at 10:08 PM, Guy Harris  wrote:

> Nope, do
> 
>   if (!g_ascii_isprint(ba[i]) && !g_ascii_iscntlr(ba[i])) {

Done in

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

with a backport to the 4.0 branch in

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

and to the 3.6 branch in

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

___
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] can't compile wireshark version 4.0

[Guy Harris]

On Oct 20, 2022, at 5:15 PM, Guy Harris  wrote:

> Or just
>   if (!g_ascii_isprint(ba[i])) {
> 
> as g_ascii_isprint() 1) is a macro, so no subroutine call overhead and 2) 
> already correctly handles both signed and unsigned char.

Nope, do

if (!g_ascii_isprint(ba[i]) && !g_ascii_iscntlr(ba[i])) {
___
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] can't compile wireshark version 4.0

[Guy Harris]

On Oct 20, 2022, at 4:31 PM, Guy Harris  wrote:

>   #if CHAR_MIN == 0
>   #define CHAR_VALUE_IS_NEGATIVE(c)   (0)
>   #else
>   #define CHAR_VALUE_IS_NEGATIVE(c)   ((c) < 0)
>   #endif
> 
>   if ((CHAR_VALUE_IS_NEGAIVE(ba[i]) || ba[i] >= ' ') && ba[i] != 
> (char)0x7f && !g_ascii_isprint(ba[i])) {

Or just
if (!g_ascii_isprint(ba[i])) {

as g_ascii_isprint() 1) is a macro, so no subroutine call overhead and 2) 
already correctly handles both signed and unsigned char.
___
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] can't compile wireshark version 4.0

[Guy Harris]

On Oct 20, 2022, at 4:02 PM, Guy Harris  wrote:

> Definitely signed, unless I'm missing something.

Please hand me the Sad Old Man With Fading Memory prize of the year.

*Nothing guarantees that a char is signed*.  This is still true as of C18:

An object declared as type char is large enough to store any member of 
the basic execution character set. If a member of the basic execution character 
set is stored in a char object, its value is guaranteed to be nonnegative. If 
any other character is stored in a char object, the resulting value is 
implemen- tation-defined but shall be within the range of values that can be 
represented in that type.

This dates, as I remember, back to some instruction sets having a 
sign-extending byte load instruction and others having a non-sign-extending 
byte load instruction.

The "signed" keyword was added to C to allow code that expects a char-sized 
signed integer value type to say "signed char"; for generality, you can say 
"signed short int" or "signed int", or "signed long int" or..., but that's 
redundant.

So, given that this is the result of

> [compiling] wireshark version 4.0 on Raspberry Pi ubuntu 22.04

perhaps ARM32 or ARM64, whichever this is, is a target with *unsigned* char 
variables, so that "signed char" is an 8-bit signed integral type and both 
"char" and "unsigned char" are 8-bit unsigned integral types.

And, at least according to this StackOverflow item:


https://stackoverflow.com/questions/2054939/is-char-signed-or-unsigned-by-default

on *most* platforms char is unsigned on ARM - "iOS", presumably meaning "all 
Apple operating systems" at this point, is different (sort of makes sense for 
macOS, to avoid throwing in Another Portability Problem when adding Apple 
silicon support, and maybe, given that a ton of code from the kernel on up to 
frameworks in iOS came from macOS, they did that to simplify porting to iOS.  I 
think Apple silicon macOS is the first target for which we've done main-branch 
builds, so the "sorry, char is unsigned" problem didn't show up for us.

So code should not assume that char is signed or that it's unsigned.

This might call for a test such as

#if CHAR_MIN == 0
do "char is unsigned" stuff
#else
do "char is signed" stuff
#endif

e.g.

#if CHAR_MIN == 0
#define CHAR_VALUE_IS_NEGATIVE(c)   (0)
#else
#define CHAR_VALUE_IS_NEGATIVE(c)   ((c) < 0)
#endif

if ((CHAR_VALUE_IS_NEGAIVE(ba[i]) || ba[i] >= ' ') && ba[i] != 
(char)0x7f && !g_ascii_isprint(ba[i])) {

and hope that the compiler doesn't warn that we're doing "0 || x", because, in 
*that* case, we'd need to do something more complicated.
___
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] can't compile wireshark version 4.0

[Guy Harris]

On Oct 20, 2022, at 9:54 AM, Fulko Hew  wrote:

> My guess as to what could be wrong according to the error is that
> ba[i] < '\0' is 'always false'  because ba (although declared as a 
> QByteArray) is probably
> an unsigned byte array,

Qt 5.12.12 qbytearray.h:

inline char *data();

...

inline char operator[](int i) const;
inline char operator[](uint i) const;
inline QByteRef operator[](int i);
inline QByteRef operator[](uint i);

...

inline char QByteArray::operator[](int i) const
{ Q_ASSERT(uint(i) < uint(size())); return d->data()[i]; }
inline char QByteArray::operator[](uint i) const
{ Q_ASSERT(i < uint(size())); return d->data()[i]; }

...

inline QByteRef QByteArray::operator[](int i)
{ Q_ASSERT(i >= 0); return QByteRef(*this, i); }
inline QByteRef QByteArray::operator[](uint i)
{ return QByteRef(*this, i); }
inline QByteRef QByteArray::front() { return operator[](0); }
inline QByteRef QByteArray::back() { return operator[](size() - 1); }

Definitely signed, unless I'm missing something.

Qt 6.2.4 qbytearray.h:

inline char *data();

...

inline char operator[](qsizetype i) const;
[[nodiscard]] inline char [](qsizetype i);
inline QByteRef operator[](int i);
inline QByteRef operator[](uint i);

...

inline char QByteArray::operator[](qsizetype i) const
{ Q_ASSERT(size_t(i) < size_t(size())); return d.data()[i]; }

...

inline char ::operator[](qsizetype i)
{ Q_ASSERT(i >= 0 && i < size()); return data()[i]; }
inline char ::front() { return operator[](0); }
inline char ::back() { return operator[](size() - 1); }

Also definitely signed, unless I'm missing something.
___
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] wireshark extension for a Kernel Module (like Usbmon)

[Guy Harris]

On Mar 6, 2022, at 3:52 PM, Christian  wrote:

> Hello out there, I created a kernel probe module and I want to watch the
> outputs of this module with pcap/Wireshark. Just like usbmon. So I
> defined a char device in the dev-directory /dev/kpnode from which the
> pcap interface can read the output of that module. In order to enable
> Wireshark to read from this device, I started to place a handler
> function into libpcap:
> In pcap.c I put in
> #ifdef PCAP_SUPPORT_KPNODE
> #include "pcap-kpnode.h"
> #endif
> and later:
> #ifdef PCAP_SUPPORT_KPNODE
>   { kpnode_findalldevs, kpnode_create },
> #endif
> further down:
> #ifdef PCAP_SUPPORT_KPNODE
>   || strstr(device, "kpnode") != NULL
> #endif
> 
> The functions kpnode_findalldevs and kpnode_create are in my files
> pcap-kpnode.c and pcap-kpnode.h. They are not finished yet but the
> subject of this mail is for now, how to connect these functions into
> libpcap and Wireshark so that they are evoked if a device /dev/kpnode
> emerges.

You do it in libpcap.

Then:

if you have a version of Wireshark that's linked with your version of 
libpcap;

and if kpnode_findalldevs() works, so that its devices show up in 
Wireshark when it calls pcap_findalldevs();

and if kpnode_create() works, so that it can be opened in Wireshark 
when it calls pcap_create() on a kpnode device and it can be activated with 
pcap_activate();

and if dumpcap - which is the program in Wireshark that calls 
pcap_findalldevs(), pcap_create(), and pcap_activate() - in that version of 
Wireshark is set up to run with sufficient privileges to open kpnode devices 
(that may require that it be set-UID to root, or it may not);

and if those devices either use an existing LINKTYPE_/DLT_ value that 
Wireshark can dissect, or it uses a LINKTYPE_USERn/DLT_USERn value and you've 
written a dissector for that type and either built it into Wireshark or built 
it into a plugin for Wireshark and set it up for the USERn value in question;

then it should Just Work in Wireshark.

The bulk of this is a libpcap question, and should be asked on 
tcpdump-work...@lists.tcpdump.org.

The part that's relevant to Wireshark would be:

"How do I build a version of Wireshark that's linked with my version of 
libpcap?"  The answer is "install it on your system, complete with headers - 
the library and headers will, by default, be under /usr/local - and then 
configure Wireshark from scratch; the CMake configuration for Wireshark should 
find the /usr/local version and use your libpcap."

"How do I write a dissector for my new link-layer type (assuming that you can't 
just use an existing LINKTYPE_/DLT_ value)?"  The answer is more complicated.

The rest of your question amounts to

> What did I miss to integrate my handlers into pcap library?

which is a libpcap question and should be asked on 
tcpdump-work...@lists.tcpdump.org.
___
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 breakage on master?

[Guy Harris]

> On Mon, Feb 28, 2022 at 10:58 AM Martin Mathieson via Wireshark-dev 
>  wrote:
> 
>> I am seeing this error on master.  Don't have time to look into it just now, 
>> but I have just made a new VM for building Wireshark.  Which object file is 
>> supposed to implement these?
>> 
>> /usr/bin/ld: run/libwireshark.so.0.0.0: undefined reference to `nds_defrag'

...

> On Feb 28, 2022, at 8:50 AM, Jim Young  wrote:
> 
> Looking at a few of the undefined references with `git grep` it looks
> like they are defined in epan/dissectors/packet-ncp.inc.

...which is included by packet-ncp.c, which is a file *generated* during 
the build process (i.e., it's not in epan/dissectors in the source tree, it's 
in epan/dissectors in the *build* tree) by tools/ncp.py (which, as the name 
suggests, required Python).
___
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] PCAP-over-IP in Wireshark?

[Guy Harris]

On Jan 31, 2022, at 4:56 AM, Erik Hjelmvik  wrote:

> Is there some way to read PCAP-over-IP in Wireshark? I.e. read a PCAP stream 
> over a TCP socket.
> 
> Currently, the best solution to read PCAP-over-IP in Wireshark is by using 
> netcat to read the PCAP stream and forward it to Wireshark's STDIN like this:
> nc localhost | wireshark -k -i -

So this means "stream a pcap file to Wireshark and have it read it as a live 
capture".

Wireshark - well, dumpcap, which does the capturing - has supported capturing 
from a pipe for a while.

Support for capturing from a TCP socket was added at some point; the man page 
doesn't document it all that well:

   −i|−−interface  |rpcap://:/|TCP@:|−
   
   Set the name of the network interface or pipe to use for live
   packet capture.
   
   Network interface names should match one of the names listed in
   "dumpcap −D" (described above); a number, as reported by "dumpcap
   −D", can also be used. If you’re using UNIX, "netstat −i",   ied,
   "ifconfig −a" or "ip link" might also work to list interface names,
   although not all versions of UNIX support the −a option to
   ifconfig.
   
   If no interface is specified, Dumpcap searches the list of
   interfaces, choosing the first non−loopback interface if there are
   any non−loopback interfaces, and choosing the first loopback
   interface if there are no non−loopback interfaces. If there are no
   interfaces at all, Dumpcap reports an error and doesn’t start theg
   capture.
   
   Pipe names should be either the name of a FIFO (named pipe) or "−"
   to read data from the standard input. On Windows systems, pipe   
   names must be of the form "\\pipe\.*pipename*". Data read from
   pipes must be in standard pcapng or pcap format. Pcapng data must
   have the same endianness as the capturing host.

It mentions "TCP@:" in the line describing the interface, but 
doesn't say what it means.

So try

wireshark -k -i TCP@localhost:57012

___
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] Reassembly of split fragments

[Guy Harris]

On Jan 26, 2022, at 1:54 PM, Jaap Keuter  wrote:

> Few remarks. The mix-27010 dissector is made to dissect frames of type 
> WTAP_ENCAP_MUX27010, or PCAP link layer header type, as defined at 
> https://tcpdump.org/linktypes/LINKTYPE_MUX27010.html There it states what the 
> layout in the PCAP packets ought to be. All your variations do not fall into 
> that category, so shouldn't use this PCAP link layer header type, IMHO.

Exactly.

If traffic doesn't match the description in the entry on the page at

https://www.tcpdump.org/linktypes.html

for the link-layer type being used in pcap or pcapng files for that traffic, 
the pcap/pcapng file isn't valid, and one shouldn't expect tcpdump or Wireshark 
or... to be able to handle it.

I.e., if

>> [somebody captures] the serial line traffic in pcap format

then, if they want it to be interpreted as mux27010 traffic, they must 
encapsulate the serial line traffic in the form described on

https://tcpdump.org/linktypes/LINKTYPE_MUX27010.html

*before* they write it to the file.  If that means that reassembly must be done 
before writing to the file, that's the way it is.
___
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] Future of Wireshark's shared library ABI stability

[Guy Harris]

On Jan 20, 2022, at 1:12 PM, Roland Knall  wrote:

> But it was implemented by utilizing heavily a wireshark installation 
> including libwireshark and libwsutil

So why, *other than "because it uses Wireshark libraries intended to provide 
directly useful services such as reading capture files or dissecting packets 
and that use libwsutil"*, would some program outside of Wireshark use wsutil?
___
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] Future of Wireshark's shared library ABI stability

[Guy Harris]

On Jan 20, 2022, at 12:34 PM, Gerald Combs  wrote:

> Q: Should *wsutil* be part of that stable ABI?
> 
> Debian, Ubuntu and (according to rpmfind.net) OpenSuSE and Mageia treat it as 
> such. It would be helpful to know what non-Wireshark packages depend on 
> wsutil in those distributions and elsewhere.

...and, if there are any, to know *why*.
___
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] Issues with cross-compiling

[Guy Harris]

On Jan 16, 2022, at 6:01 PM, Glen Huang  wrote:

> I’m trying to create an OpenWrt package for Wireshark.
> 
> I think I’m pretty close. However, I got stuck at lemon, which if I’m not 
> wrong, should be compiled by my build machine’s compiler. From the source 
> code, I found out it supports the LEMON_C_COMPILER variable, which I assigned 
> with the build machine’s compiler, but after compiling, CMAKE used the target 
> platform’s linking flags for linking, which apparently failed.

At least according to the "Mastering Cmake" boot, if your build process 
requires special tools built from project source in the native environment, 
that's a bit of a pain with CMake:


https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#running-executables-built-in-the-project

I don't know whether newer version of CMake have a built-in concept of "this 
file must be built with a native compiler when doing a cross-build".
___
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] Visual Studio 2022

[Guy Harris]

On Jan 15, 2022, at 3:09 AM, Gisle Vanem  wrote:

> Anders Broman wrote:
> 
>> Hi,
>> Yes sounds like a good idea. Have been contemplating testing it too.
> 
> I just installed the "Build Tools for Visual Studio 2022"
>  
> https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022

"These Build Tools allow you to build Visual Studio projects from a 
command-line interface."

Does that mean

this is Visual Studio without the "Visual", i.e. it's all the 
command-line tools, but without the IDE

or

if you just install Visual Studio, you don't get the command-line tools 
- you also have to install this?

The former sounds like "Command Line Tools for Xcode {version}" on macOS or 
"don't install any IDE" on the free-software UN*Xes (I don't know whether 
Oracle Studio offers that).

The latter seems less likely, as I think most IDEs either run the 
compiler/linker/other tools directly or run some builder program (make, 
msbuild, etc.) that runs the compiler/linker/other tools, but I guess if the 
core of the compiler/linker are in libraries that the command-line tools link 
with and that an IDE program could link with as well (say hello, LLVM), it 
would be possible.
___
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] How do I create a merge request for changes to get into the next 3.6.x release

[Guy Harris]

On Dec 15, 2021, at 10:30 PM, Guy Harris  wrote:

> If the cherry-pick cannot be done automatically, you'll have to do it by 
> hand, in a tree checked out with the release-3.6 branch.  Do the cherry pick 
> - if you're doing it from the command line, do it with "git cherry-pick -x" 
> to include the "Cherry-picked from" text - and fix whatever needs to be fixed 
> before committing.

In this case, I usually replace "Cherry-picked from ..." with "Backported from 
..." to indicate that some additional work was needed.

___
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] How do I create a merge request for changes to get into the next 3.6.x release

[Guy Harris]

On Dec 15, 2021, at 9:05 PM, Richard Sharpe  wrote:

> I have submitted merge requests to fix some problems with the S1G
> radiotap changes and would like to ensure they get into the next 3.6.x
> release because there are now chipsets and adapters shipping with S1G
> (Halow) support.
> 
> So, what sort of merge requests do I need to create?

Cherry-picks, once the merge request to the main branch is merged.

For example, for

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

you'd click on 2b2c81a5 in "Detached merge request pipeline #429891703 passed 
for 2b2c81a5 23 hours ago", which takes you to


https://gitlab.com/wireshark/wireshark/-/commit/2b2c81a551cf6e300578c48afec3e2589910b23b

which is the page for the commit.  Click on "Options" in the upper-right corner 
and select "Cherry pick", and cherry pick it to the release-3.6 branch.

If the cherry-pick cannot be done automatically, you'll have to do it by hand, 
in a tree checked out with the release-3.6 branch.  Do the cherry pick - if 
you're doing it from the command line, do it with "git cherry-pick -x" to 
include the "Cherry-picked from" text - and fix whatever needs to be fixed 
before committing.
___
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] Errors building 3.7 plugins.

[Guy Harris]

On Dec 14, 2021, at 5:49 AM, João Valverde  wrote:

> On 14/12/21 13:39, Gisle Vanem wrote:
>> João Valverde wrote:
>> 
>>> you can (and probably should) include "config.h", just like other Wireshark 
>>> bundled plugins do.
>> 
>> Why does this project not use '-FI./config.h'?
> 
> The header works fine, the consideration is that external plugins can only 
> use the public API, and that header is not part of it.

And should never be part of it - for *any* project that provides headers and 
libraries for other code to use.

One problem is that the configuration settings with which the project was built 
are *not* necessarily the configuration settings with which the other code is 
being built; it might, for example, be compiled with a different compiler - 
which should be permitted as long as the two compilers build code using the 
same compiler-level ABI (calling sequence, etc.).
___
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] Are Capture Filters Implemented in Software or the Network Card?

[Guy Harris]

On Nov 21, 2021, at 6:36 PM, Gene Cumm  wrote:

> FPGA-based network acquisition cards do implement filters in "hardware" (not 
> in the system CPU).  Napatech, Accolade, Silicom and Chelsio have products.  

So change my statement to 

...adapter that do the filtering itself have been built, but libpcap 
has not been modified to recognize those cards and to tell the adapter's 
driver, rather than the kernel's packet capture mechanism, what the filter 
program is, unless the vendors provide their own version of libpcap that can be 
installed and that will be used by Wireshark if it has been installed.

because that's what would be required for a Wireshark capture to have the 
filtering be done by the network adapter.
___
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] Are Capture Filters Implemented in Software or the Network Card?

[Guy Harris]

On Nov 21, 2021, at 11:06 AM, Guy Harris  wrote:

> In the capture mechanisms in most UN*Xes (*BSD, macOS, Linux, Solaris, AIX, 
> and Tru64 UNIX), and in the capture mechanism provided by the WinPcap and 
> Npcap drivers, all packets received by an interface on which capturing is 
> being done are delivered to the capture mechanism in the kernel.  That 
> capture mechanism applies the filter, and only packets that pass the filter 
> are put in a buffer to be delivered to user mode.  The libpcap user-mode code 
> then just sees only the packets that pass the filter, and provides those 
> packets to the program using it, such as tcpdump or dumpcap.  In the case of 
> dumpcap, it writes batches of packets to a capture file as they arrive, and 
> notifies Wireshark or TShark that a batch of packets has arrived.

Solaris *11* - in previous versions, and in HP-UX, the capturing mechanism 
supports filtering, but it's an incompatible filtering mechanism that's not 
capable of supporting all the capabilities of the filtering mechanism used in 
the other OSes, and libpcap doesn't try to use it.

(And in IRIX, there is an even more limited filtering mechanism, which libpcap 
doesn't support.)
___
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] Are Capture Filters Implemented in Software or the Network Card?

[Guy Harris]

On Nov 18, 2021, at 10:53 AM, X Q  wrote:

> This is a question fairly deep in the guts of Wireshark that I could not find 
> an answer to.

It's so deep in the guts of Wireshark that it's not even in Wireshark!

> When a capture filter is implemented are ALL packets sent to 
> Wireshark/Dumpcap/TShark at the software level for filtering

No, they're not.

> or 
> 
> are the packets not matching the filter shedded/ignored by the Network 
> Interface card itself thus reducing strain on the CPU/Network Fabric?

No, they're not.

On UN*Xes, the operating system itself provides a packet capture mechanism.  
Not all UN*Xes provide the same capture mechanism; the libpcap library, which 
is *not* part of Wireshark (it's a separate project with a separate development 
team, although there are people who work on both projects), provides a 
programming interface that supports those capture mechanisms, so that the same 
code can work on *BSD, macOS, Linux, etc..

On Windows, the operating system itself doesn't have such a capture mechanism, 
but it's possible to add drivers that provide such a mechanism.  That's what 
both WinPcap and Npcap do; they provide a driver plus a user-mode library to 
communicate with the driver plus libpcap built to use that user-mode library as 
the capture mechanism.

In the capture mechanisms in most UN*Xes (*BSD, macOS, Linux, Solaris, AIX, and 
Tru64 UNIX), and in the capture mechanism provided by the WinPcap and Npcap 
drivers, all packets received by an interface on which capturing is being done 
are delivered to the capture mechanism in the kernel.  That capture mechanism 
applies the filter, and only packets that pass the filter are put in a buffer 
to be delivered to user mode.  The libpcap user-mode code then just sees only 
the packets that pass the filter, and provides those packets to the program 
using it, such as tcpdump or dumpcap.  In the case of dumpcap, it writes 
batches of packets to a capture file as they arrive, and notifies Wireshark or 
TShark that a batch of packets has arrived.

The filtering is *not* done in the network adapter (which isn't necessarily a 
card - it could be built into the computer); an adapter that does the filtering 
itself could probably be built, and libpcap could be modified to recognize 
cards that can do filtering and to tell the adapter's driver, rather than the 
kernel's packet capture mechanism, what the filter program is.  I don't know of 
any adapters of that sort, however, and libpcap currently has no code to do so.

It's also *not* done in tcpdump or dumpcap; it's done in libpcap.

Thus, the filtering process consumes some CPU on the host, as the packet has to 
be delivered to the capture mechanism (taking some CPU) and must be filtered 
(taking some CPU), but, if the packet doesn't pass the filter, no *further* 
work has to be done on the packet, saving the CPU effort required for 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] USB Attached SCSI dissector

[Guy Harris]

On Oct 25, 2021, at 12:03 PM, Tomasz Moń  wrote:

> The heuristic should not be the main USB traffic detection method
> IMHO. The main thing is that people don't necessarily understand that
> capturing full enumeration sequence (aka starting capture before
> plugging in the device) will give you much better dissection in
> multiple cases.

The main thing is that there's no guarantee that you get the full enumeration.

> Recent libpcap versions
> automatically request device and configuration descriptors on capture
> start (easier version request only device descriptor).

Is this done on FreeBSD, macOS, and Windows?

Or is this Linux-only?
___
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] USB Attached SCSI dissector

[Guy Harris]

On Oct 22, 2021, at 6:06 PM, Aidan MacDonald via Wireshark-dev 
 wrote:

> Second, the hooks provided by the generic USB dissector seemingly aren't a 
> good fit. Basically, it seems to use only the interface class to decide what 
> sub-dissector to call, but UASP uses the mass storage class like the existing 
> Bulk-Only transport dissector. So that dissector is essentially sitting in 
> the way and preventing me from hooking in UASP. (Or at least I think so. 
> Currently I'm just commenting it out the conflicting hooks during testing.)
> 
> I need to look at the interface protocol to determine if the traffic is UASP 
> or not. I think the simplest way to do this is adding a shim dissector for 
> mass storage class which invokes either the BOT or UASP dissector depending 
> on the interface protocol (if known). Does that sound like a good approach?

That seems to make sense.  The current mass storage class dissector just 
registers in the "usb.bulk" and "usb.control" dissector tables based on the 
interface class.

*However*, there's also a *heuristic* dissector registered in the "usb.bulk" 
heuristic dissector table, and *that* looks for what appears to be a signature 
of Bulk-Only Transport packets.  If so, then the *heuristic* dissector should 
directly call the Bulk-Only Transport dissector.  I don't know whether there's 
a heuristic that can recognize UASP traffic; if so, you'll have to write a 
separate heuristic dissector for 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] Siemens S7Comm-Plus protocol support

[Guy Harris]

On Aug 18, 2021, at 11:16 PM, Brett D. Rasmussen via Wireshark-dev 
 wrote:

> I have a question regarding support for the Siemens "s7comm-plus" protocol.
> 

> I'm currently running Wireshark 3.4.7 on a Mac system.  (3.4.7 is the latest 
> version on the Mac)

It's the latest version everywhere, although some Linux distributions/*BSD 
ports or packages/etc. might not yet have the latest version (unlike Windows 
and macOS, where we produce our own builds of the latest release).

> My copy of Wireshark does not yet include the "s7comm-plus" dissector/plugin.

It's not yet part of Wireshark, so you won't get it with a standard release.
 
> Another developer, out on SourceForge.com, has indicated that Wireshark 
> plugin support for the "s7comm-plus" is available out on SourceForge here:
>   https://sourceforge.net/projects/s7commwireshark/
> 
> Will support for the "s7comm-plus" protocol be added to the pre-compiled 
> Wireshark download at some point in the future?

Whether a given protocol will be added in a future release is determined by 
whether somebody takes the time to add it or not; we don't have roadmaps that 
add particular protocols to particular releases.

One of us could take the current version of the plugin and incorporate it into 
Wireshark, but that wouldn't guarantee that later updates from its developer 
would get into Wireshark.  The most recent commit was a month ago, so it's 
still being actively developed, which means that grabbing a snapshot and 
incorporating it into Wireshark might not be the right way to do this.

Thomas, is there any reason not to incorporate this into the regular Wireshark 
release?  I'd mean you wouldn't have to build Windows binaries and offer them 
for releases that include it, and would make it easier for non-Windows users to 
analyze those packets, as they wouldn't have to compile it as a plugin and 
install it themselves.  It appears to be licensed under the GPLv2, so there are 
no licensing issues that I can think of.

> Or, is there a method for adding s7comm-plus support to my current Wireshark 
> installation?

You could:

go to the code tab at 
https://sourceforge.net/p/s7commwireshark/code/HEAD/tree/;

clone the repository;

download the Wireshark 3.4.7 source, so the Wireshark header files are 
available, if you haven't done so already;

run the tools/macos-setup.sh script in the Wireshark source tree, so 
the header files for the support libraries are available, if you haven't done 
so already;

make sure you have Xcode installed;

build it;

install it in the appropriate directory;

but we don't have a tutorial on doing that, so you'd have to figure it out 
yourself or keep asking questions.
___
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] Ericsson ppcap sample capture

[Guy Harris]

On Jul 5, 2021, at 7:38 PM, chuck c  wrote:

> packet-ppcap.c needs the same change that was done for vss in 
> https://gitlab.com/wireshark/wireshark/-/merge_requests/3526
> 
> It's a minor change but I would like to test before and after if possible.
> 
> Can anyone point me to a sample capture for "Proprietary PCAP" ?

That change won't affect dissection (the PPCAP dissector has no preferences 
that would affect dissection, which is why the change is being made in the 
first place), so there's no need for a capture in order to test it.

A sample might still be useful to, for example, test *other* changes, but it 
wouldn't be needed for that change.

___
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 27, 2021, at 6:36 AM, Vincent Randal  wrote:

> On Sat, Jun 26, 2021 at 9:41 PM Guy Harris  wrote:
> 
>> So this isn't really a Wireshark dissector question, it's a protocol design 
>> and encoding question.
> 
> I'd like it not to be an encoding question beyond this: Given I'm using ASN.1 
> to generate dissectors (for the protocols I am designing), which encoding can 
> I use so that I can "see" my messages in the raw data?

In other words, you don't care about wasting ports?

And what do you mean by "see"?

>> The issue isn't "how do I get a Wireshark dissector to distinguish between 
>> different message types without giving each message type its own UDP port", 
>> it's "how do I get *the recipient of the messages* to distinguish between 
>> different message types without giving each message type its own UDP port" - 
>> this would be an issue even if there were no such thing as packet analyzers, 
>> because you'd be wasting the ports even if there were no packet analyzers.
> 
> At this stage Wireshark is the only recipient of these messages that I care 
> about.

I suspect the people developing and testing the receiver side of the protocol 
implementation care about more than that, even if you don't.

> I send the messages using Python asn1tools and receive them using tshark 
> (perhaps also using Lua soon).

No, you *capture* them using TShark.  Does nobody have any programs that have 
the multiple ports in question open, and to which the Python program sends 
them?  (No, TShark does not have those ports open; it receives the packages by 
passively snooping network traffic, whether in promiscuous/monitor mode so that 
it can see "third-party" traffic or on the machine to which the packets are 
being sent so that promiscuous/monitor mode is not necessary.)

>> And it's best thought of not as a question of "using the first octet" as a 
>> question of "somehow encoding the message type in the message itself" - with 
>> Anders' suggestion of a change to the protocol, in BER, the first octet 
>> would contain information other than just the ClassNumber for the item in 
>> the CHOICE, and in PER, with the UNALIGNED variant, the ClassNumber would be 
>> encoded in the minimum number of bits needed to encode the range of 
>> ClassNumbers.
> 
> I am using PER (apparently the ALIGNED variant) because (so far) I can "see" 
> the messages in the raw hexadecimal dump. I want a “null” encoder with this 
> property: pre-encoded message byte = encoded message octet.

"Ability to see certain parts of the message easily in a hex dump" is generally 
not used as a design criterion for protocol encodings, but whatever.

>> The good news is that, if you generate the protocol implementation from the 
>> ASN.1, that will all be done for you - you won't have to write
> 
> I’m not finding freely available tools that finish the job. I’m writing my 
> own tools to fill in the gaps. My tools generate ASN.1 from IEEE source 
> documents (which they update after testing).

So what language are the IEEE source documents using, i.e. what language is the 
*IEEE* using to describe the protocol?

>> the code to parse the encoding of the value, esnacc (which translates from 
>> the IDL, ASN.1, *to* code, it doesn't translate ASN.1 to an IDL) will do 
>> that for you.  The same is true of Wireshark's
> 
> Guy, look at "esnacc -idl" [I merge the output of "esnacc" and "esnacc -idl" 
> to create an IDL that passes "omniidl" syntax checking. I give a variant of 
> this IDL to the IEEE for use as their message descriptions.]

Wait.

So you're using eSNACC to translate from one description language - ASN.1 - to 
*another* description language - CORBA IDL?  And the *latter* is what the IEEE 
are going to use when they publish the specification for the protocol, *not* 
ASN.1?

Note that CORBA IDL has its *own* encoding rules, different from the various 
types of rules that ASN.1 has.  See, for example, section 9, "General Inter-ORB 
Protocol", in Common Object Request Broker Architecture (CORBA) Specification, 
Version 3.3 Part 2: CORBA Interoperability:

https://www.omg.org/spec/CORBA/3.4/Interoperability/PDF

Apparently, there are other flavors of inter-ORB protocol:

https://en.wikipedia.org/wiki/General_Inter-ORB_Protocol

so there may be other encodings.

So, if the IEEE is going to publish the protocol that you're developing as a 
specification in the CORBA IDL language, rather than in the ASN.1 language, 
what will the *IEEE* expect to be the on-the-wire encoding?  *That* is 
ultimately what senders and receivers of these messages will have to implement, 
and what Wireshark will have to decode.
___
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]

So this isn't really a Wireshark dissector question, it's a protocol design and 
encoding question.

The issue isn't "how do I get a Wireshark dissector to distinguish between 
different message types without giving each message type its own UDP port", 
it's "how do I get *the recipient of the messages* to distinguish between 
different message types without giving each message type its own UDP port" - 
this would be an issue even if there were no such thing as packet analyzers, 
because you'd be wasting the ports even if there were no packet analyzers.

And it's best thought of not as a question of "using the first octet" as a 
question of "somehow encoding the message type in the message itself" - with 
Anders' suggestion of a change to the protocol, in BER, the first octet would 
contain information other than just the ClassNumber for the item in the CHOICE, 
and in PER, with the UNALIGNED variant, the ClassNumber would be encoded in the 
minimum number of bits needed to encode the range of ClassNumbers.

(And if there are over 100 different message types, depending on the encoding, 
it might not even fit in one octet, at least for BER.)

The good news is that, if you generate the protocol implementation from the 
ASN.1, that will all be done for you - you won't have to write the code to 
parse the encoding of the value, esnacc (which translates from the IDL, ASN.1, 
*to* code, it doesn't translate ASN.1 to an IDL) will do that for you.  The 
same is true of Wireshark's dissector generation; in neither case would *you* 
need to write a switch statement, or whatever would be involved.
___
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

[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] Getting captured interface name inside plugin

[Guy Harris]

On Jun 7, 2021, at 4:15 AM, Jan Mall  wrote:

> After continuing searching I found this snippet in the UI part:
> "epan_get_interface_name(pinfo->epan, 
> pinfo->rec->rec_header.packet_header.interface_id);"

Note that it is permitted to return NULL.

Note also that there is no guarantee that 
pinfo->rec->rec_header.packet_header.interface_id has a meaningful value; 
unless the WTAP_HAS_INTERFACE_ID bit is set in pinfo->rec->presence_flags, 
pinfo->rec->rec_header.packet_header.interface_id must not be used.

Presumably either:

this is a site-specific use, so you know which interface names have 
which sets of message definitions, and you've hardcoded that into your 
dissector;

this is for a particular capture device, so you know which interface 
names have which sets of message definitions, and you've hardcoded that into 
your dissector;

the message definition files have names that include the interface 
name, so, while the user doesn't have to set preferences for the dissector, the 
user has to set file names for the message definition files;

or something such as that.

> Still wondering if there is maybe a callback/event I could register to get 
> notified as soon as the user starts capturing on a specific interface 
> (including the interface name)?

Note that there is no guarantee that your dissector will only be called if the 
user is doing a capture.  Remember, Wireshark can read saved capture files.

Further note that, unless the saved capture file is a pcapng file, the 
interface ID, and interface names, will not be available.
___
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] Getting captured interface name inside plugin

[Guy Harris]

On Jun 6, 2021, at 5:41 PM, Jan Mall  wrote:

> The ultimate goal is an automotive dissector, which takes abstract network 
> descriptions for automotive buses and dissects the messages on the bus 
> accordingly. But as every bus has a different set of message definitions,

So is there a single LINKTYPE_ value for all those buses, or do they all have 
different LINKTYPE_ values?

If so, what are the LINKTYPE_ values?
___
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] Getting captured interface name inside plugin

[Guy Harris]

On Jun 6, 2021, at 5:13 PM, Jan Mall  wrote:

> I'm currently developing a plugin/dissector (C API), which should have a 
> different dissection behavior depending on the interface Wireshark is 
> currently listening on.

Why?

What is the *ultimate* goal of this?
___
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] Windows HTML Help

[Guy Harris]

On Jun 1, 2021, at 4:14 PM, Gerald Combs  wrote:

> I just discovered that the HTML Help Workshop download link at
> 
> https://docs.microsoft.com/en-us/previous-versions/windows/desktop/htmlhelp/microsoft-html-help-downloads
> 
> no longer works, and the Chocolatey package now downloads from archive.org:
> 
> https://community.chocolatey.org/packages/html-help-workshop#files

Have Microsoft said anything about deprecating HTML Help in favor either of 1) 
some new help mechanism or 2) just use an HTML display tool that you hand the 
URL for your product's documentation?
___
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] Calling a dissector: Type for data parameter

[Guy Harris]

On May 29, 2021, at 12:12 AM, Anders Broman  wrote:

> Shouldn't the caller be calling with the right data type or NULL? So a bug in 
> the MQTT disector?

How can the MQTT dissector determine what the right data type *is* - especially 
given that the dissectors aren't wired in, there's a UAT preference that lets 
the user configure it.

This is where the current mechanism for passing data between dissectors goes 
crashing to the ground.

MQTT passes a topic string, which is just a string, to the dissectors it calls.

JSON expects to be passed a pointer to an http_message_info_t.

JSON registers its non-heuristic dissector by name, and allows it to be used 
with Decode As... for UDP ports.

It might *look* safe if you check the UDP dissector and the dissectors that use 
"media_type" and "grpc_message_type", but the "registers its non-heuristic 
dissector by name" mean there are no guarantees, given that another dissector 
that passes a pointer to something *other* than an http_message_info_t to 
dissectors that are specified by name in a UAT.
___
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] Where do release branches come from?

[Guy Harris]

On May 23, 2021, at 2:43 PM, chuck c  wrote:

> There are currently three active branches: 
> (https://gitlab.com/wireshark/wireshark/-/branches/active)
> master, master-3.2 and release-3.4
> 
> My merge requests are to "master".
> If appropriate, it also gets backported 
> (https://www.wireshark.org/docs/wsdg_html/#ChSrcBackport) to master-3.2 
> and/or release-3.4.
> 
> Soon (for some value of "soon") there will be a 3.6 branch.
> How do commits get from "master" (dev branch) to a stable branch?

The stable branch "branches" off from the main branch at some point; all 
changes in the main branch up to that point are all automatically in the stable 
branch as well.

After that, all changes to the main branch would have to be backported to the 
stable branch if they are to be in the stable branch.

> Will all of the commits in "master" make it to "release-3.6"?

All of the ones made before the branch point will automatically be in 
release-3.6; bug-fix changes made after that should (in the imperative sense) 
be backported to release-3.6, and most, hopefully, will.
___
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] Ethernet dissector

[Guy Harris]

On May 23, 2021, at 8:58 AM, Antonello Tartamo  
wrote:

> The problem is that I don't have a predefined ether type as the ether type 
> field is used as length field.

So the frames start with:

a 6-octet Ethernet destination address;

a 6-octet Ethernet source address;

a 2-octet type/length field with a value <= 1500, indicating that its 
value is a length rather than an Ethernet type?

If so, what follows the type/length field?  An IEEE 802.2/ISO 8802 LLC header, 
with a 1-octet DSAP, a 1-octet LSAP, and a control field?  Or something else?
___
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] my purpose [for building with support for Lua in Linux (Ubuntu 20.04)]

[Guy Harris]

On May 22, 2021, at 1:46 PM, Vincent Randal  wrote:

> On Sat, May 22, 2021 at 3:51 AM Guy Harris  wrote:
>> On May 21, 2021, at 8:03 PM, Vincent Randal  wrote:
>> 
>>> 1. Before running cmake how can I tell the appropriate "with-lua" sort of 
>>> switch is enabled?
>> 
>> By making sure that the appropriate package for Lua is installed.  That's 
>> liblua5.2-dev.
>> 
>> The easiest way to make sure it's installed is to run
>> 
>> tools/debian-setup.sh --install-optional
> 
> Thank you. Graham had the same suggestion. This helped tremendously. I was 
> doing it the hard way trying to manage dependencies myself.

The UNIX section (which should perhaps be called "UN*X" or "UNIX and 
UNIX-like", as it also applies to systems such as most Linux distributions and 
the *BSDs that aren't licensed for the UNIX trademark):


https://www.wireshark.org/docs/wsdg_html_chunked/ChapterSetup.html#ChSetupUNIX

has been expanded recently to give ore instructions on setting up a development 
environment (it's not quite at the "IKEA motorcycle engine", to quote our 
illustrious founder, level that Windows is at, but it *does* involve some work 
for which we should and now do give some help).

It mentions the "set up the development environment scripts" for 
Debian-flavored Linux distributions, RPM-based Linux distributions, Alpine 
Linux, the *BSDs, and macOS.

>>> 3. If it does not find Lua how do I fix that?
>> 
>> Make sure liblua5.2-dev is installed.  (If you've already run CMake before 
>> running tools/debian-setup.sh --install-optional, you *might* have to remove 
>> the directory in which you ran it, create a new directory in which to do the 
>> build, and re-run CMake, so that there isn't any cached "sorry, I didn't 
>> find Lua" indication left around.)
> 
> Thank you. I did have to remove the build directory and re-run cmake in a 
> fresh new (empty) directory.

CMake leaves a bunch of cache information around so it doesn't redo tests that 
it's already done and that "shouldn't" give different results when redone; if 
you change things that CMake doesn't realize *will* change those results, it 
won't retry them.

There may be less "nuke it from orbit, it's the only way to be sure" solutions, 
e.g. removing some specific cache files.

>>> 4. When the build succeeds how do I compensate for the difference sudo and 
>>> non-sudo seem to have on tshark? Non-sudo invokation runs my lua scripts. 
>>> Sudo invocations don't.
>> 
>> Don't run with sudo.  You should *NEVER* run TShark or Wireshark under sudo. 
>>  To quote section 3.11.1 "Packaging Guidelines":
>> 
>>  ...
>> 
>> Instead, run CMake with the option -DDUMPCAP_INSTALL_OPTION=capabilities.  
>> Then, if you install Wireshark with "sudo cmake install", it will install 
>> the dumpcap program with sufficient Linux capabilities to do capturing on 
>> network interfaces.
> 
> Thank you. That works. And -DDUMPCAP_INSTALL_OPTION=suid also seems to work.

It also works.  If you don't care about capturing raw USB traffic, 
-DDUMPCAP_INSTALL_OPTION=capabilities is sufficient, and doesn't grant dumpcap 
quite as much privilege when it starts up (it relinquishes privileges as soon 
as it can, but the less privilege, the better); annoyingly, the devices for 
snooping raw USB traffic require root privilege (at least it's not as annoying 
as macOS Big Sur, where it requires sufficient privilege *and* disabling System 
Integrity Protection - I guess some vendors of USB peripherals asked Apple to 
protect them from reverse engineers or something such as that).

>> 5. And assuming (with some help) I get past the above issues, how much 
>> control can lua scripts expert over tshark and Wireshark?
>> 
>> To see what Lua scripts can do, see Chapter 10 "Lua Support in Wireshark":
>> 
>>  ...
>> 
>> If what you want to do is *not* there, then a Lua script probably *can't* do 
>> it.
> 
> Exactly. I should set my expectations accordingly. Thank you. 

And if there's something you'd *like* it to be able to do, please file an 
enhancement request as an issue at the Wireshark issue list:

https://gitlab.com/wireshark/wireshark/-/issues
___
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] my purpose [for building with support for Lua in Linux (Ubuntu 20.04)]

[Guy Harris]

On May 21, 2021, at 8:03 PM, Vincent Randal  wrote:

> I've plans to use Lua to control tshark behavior in scripts, IF ... I can get 
> Wireshark to build with support for Lua in Ubuntu 20.4, ... But so far I am 
> not having any luck. I found this piece of documentation that says ...
> "Wireshark contains an embedded Lua 5.2 interpreter ..."
> I believe that's true for Windows but not Linux.

On an Ubuntu 20.04 system (virtual machine):

ubu20-04$ apt list | egrep wireshark

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libndpi-wireshark/focal 2.6-5 amd64
libvirt-wireshark/focal-updates 6.0.0-0ubuntu8.9 amd64
libwireshark-data/focal,focal,now 3.2.3-1 all [installed,automatic]
libwireshark-dev/focal 3.2.3-1 amd64
libwireshark13/focal,now 3.2.3-1 amd64 [installed,automatic]
wireshark-common/focal,now 3.2.3-1 amd64 [installed,automatic]
wireshark-dev/focal 3.2.3-1 amd64
wireshark-doc/focal,focal 3.2.3-1 all
wireshark-gtk/focal 3.2.3-1 amd64
wireshark-qt/focal,now 3.2.3-1 amd64 [installed]
wireshark/focal,now 3.2.3-1 amd64 [installed,automatic]

so it has Wireshark installed from an Ubuntu package.

ubu20-04$ which tshark
/bin/tshark

so if I just run "tshark" from the command line, it runs the version installed 
from the standard Ubuntu package.

ubu20-04$ tshark --version
TShark (Wireshark) 3.2.3 (Git v3.2.3 packaged as 3.2.3-1)

Copyright 1998-2020 Gerald Combs  and contributors.
License GPLv2+: GNU GPL version 2 or later 

This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.64.2, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua
5.2.4, with GnuTLS 3.6.13 and PKCS #11 support, with Gcrypt 1.8.5, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.40.0, with brotli, with LZ4,
with Zstandard, with Snappy, with libxml2 2.9.10.

Running on Linux 5.8.0-53-generic, with Intel(R) Core(TM) i9-9980HK CPU @
2.40GHz (with SSE4.2), with 7932 MB of physical memory, with locale en_US.UTF-8,
with libpcap version 1.9.1 (with TPACKET_V3), with GnuTLS 3.6.13, with Gcrypt
1.8.5, with brotli 1.0.7, with zlib 1.2.11, binary plugins supported (0 loaded).

Built using gcc 9.3.0.

so it *is* built with Lua support ("with Lua 5.2.4" in the "Compiled ... with" 
string).

So it is certainly possible to build Lua support into Wireshark if you're 
building it for Linux - the Ubuntu maintainers have done so.

If, however, you want to build your *own* version of Wireshark from source, and 
have it include feature XXX, you must make sure that all the *developer* 
packages needed for feature XXX are installed - having the end-user packages is 
*not* enough, as that provides only enough files to allow programs *already 
compiled* with those packages to run, it's *not* enough to compile programs 
using them, as it doesn't, for example, include header files.

On Debian, and on Debian-based distributions such as Ubuntu, the easiest way to 
do that is to run

tools/debian-setup.sh --install-optional

which will attempt to install all packages needed to build Wireshark *and* all 
packages not required to build Wireshark, but required to add certain features 
to the Wireshark you're building, such as Lua support.

Once you have done that.

> I have lots of questions:
> 1. Before running cmake how can I tell the appropriate "with-lua" sort of 
> switch is enabled?

By making sure that the appropriate package for Lua is installed.  That's 
liblua5.2-dev.

The easiest way to make sure it's installed is to run

tools/debian-setup.sh --install-optional

before running CMake.

> 2. After running cmake how can I tell I got what I wanted i.e. that it found 
> Lua and make will build with support for Lua?

Check the output of CMake to see if it says, in the list shown after "-- The 
following OPTIONAL packages have been found:":

* LUA (required version >= 5.1)

> 3. If it does not find Lua how do I fix that?

Make sure liblua5.2-dev is installed.  (If you've already run CMake before 
running tools/debian-setup.sh --install-optional, you *might* have to remove 
the directory in which you ran it, create a new directory in which to do the 
build, and re-run CMake, so that there isn't any cached "sorry, I didn't find 
Lua" indication left around.)

> 4. When the build succeeds how do I compensate for the difference sudo and 
> non-sudo seem to have on tshark? Non-sudo invokation runs my lua scripts. 
> Sudo invocations don't.

Don't run with sudo.  You should *NEVER* run TShark or Wireshark under sudo.  
To quote section 3.11.1 "Packaging Guidelines":


https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBinary.html#ChSrcVersioning

of the Wireshark Developer's Guide:

Privileges
All function calls that require elevated 

Re: [Wireshark-dev] Status label for issues

[Guy Harris]

On Apr 23, 2021, at 5:29 AM, Uli Heilmeier  wrote:

> Therefore I would like to create these scoped labels [1]:
> 
> ws-status::unconfirmed => This bug has recently been added to the issue 
> tracker. Nobody has confirmed that this bug is
> valid.
> ws-status::confirmed => This bug is valid.
> ws-status::in-progress => This bug is not yet resolved, but is assigned to 
> the proper person who is working on the bug.
> ws-status::invalid => The problem described is not a bug or not our bug.
> ws-status::wontfix => The problem described is a bug which will never be 
> fixed.
> ws-status::fixed => A fix for this bug is checked into master branch.
> ws-status::duplicate => The problem is a duplicate of an existing issue.

The last of those is, well, a duplicate of the "(duplicated)" in the status box 
at the top (if the close is done right, by entering

/duplicate #{bug number}

into a comment and saving the comment).
___
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] Status label for issues

[Guy Harris]

On Apr 26, 2021, at 11:43 PM, Uli Heilmeier  wrote:

> I have no strong feelings about the os::* labels. We can reduce them to 
> os::mac, os::windows, os::linux, os::unix.

So does "unix" mean:

1) has some possibly very-remote code base connection to some UNIX that 
AT put out;

2) is eligible to use the UNIX(R) trademark;

3) other?

If it's 1), then I *guess* Linux is the only UN*X that doesn't fit into that 
category, although macOS, being a 4.4-Lite derivative, would fit into that 
category as well.

If it's 2), then 1) the *BSDs don't count and 2) at least one Linux 
distribution *does* count (EulerOS).

Perhaps the labels should be

os:windows
os:macos
os:linux
os:other-unix

("unix" meaning "Un*X", and "other" meaning "neither macOS nor Linux").  
"os:other" might be enough.
___
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] Rough consensus and quiet humming

[Guy Harris]

https://twitter.com/MeghanEMorris/status/1382109954224521216/photo/1
___
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

[Guy Harris]

On Apr 19, 2021, at 10:02 AM, Richard Sharpe  
wrote:

> On Sun, Apr 18, 2021 at 9:30 PM Guy Harris  wrote:
> 
>> 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).
> 
> I think the problem will be that the radiotap HE and other headers
> support much more info than what you have suggested.

That suggestion was a specific change to deal with a particular problem, not a 
suggestion intended to handle all future issues.  The pseudo-header should be 
expanded to include whatever is needed for all forms of 802.11 metadata.

> Will we also add things like GI, LFT symbol size, # LTF symbols, Pre
> FEC padding, etc, to the pseudo-header?

Yes, we should.

> In addition, radiotap now supports TLVs (since they ran out of bits in
> the features word). However, that is possibly easier to handle, since
> an unknown TLV can simply be displayed as raw bytes.

Yes, the idea was originally that, for any newly-added field, there is:

code that doesn't understand the newly-added field, in which case it 
presumably won't understand fields added after the newly-added field, so it's 
OK to stop parsing at the last field the code *does* understand;

code that does understand the newly-added field, in which case it can 
parse it, and stop if it runs across a field it doesn't understand.

Any code that handles TLVs also needs to handle all the fields added prior to 
the addition of TLVs.

There's also a provision for vendor-specific fields in radiotap.  We might need 
a mechanism to allow dissectors to register to handle either radiotap TLVs or 
vendor-specific fields.

___
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

[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] Writing a wtap module for CommView WLAN Analyzer and Decoder NCFX format files

[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] (1) building Wireshark in build.wireshark fails, (2) how to get dissector details without packet

[Guy Harris]

On Apr 15, 2021, at 3:46 PM, Vincent Randal  wrote:

> I managed to save my terminal window contents. It's over 1MB compressed.

$ mkdir build.wireshark
$ cd build.wireshark
$ cmake .. >cmake.out 2>&1
$ make -j 16 >errs 2>&1
$ ls -lh cmake.out errs
-rw-r--r--  1 gharris  admin19K Apr 15 16:13 cmake.out
-rw-r--r--  1 gharris  admin   243K Apr 15 16:15 errs

Is that the *entire* contents, with all the stuff you did before and after the 
failed build?  If so, the first thing to check is the stuff that's part of the 
failed build; the other stuff is much less likely to be relevant.

___
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] (1) building Wireshark in build.wireshark fails, (2) how to get dissector details without packet

[Guy Harris]

On Apr 15, 2021, at 2:03 AM, Graham Bloice  wrote:

> Wireshark is a complicated project to build.  You can follow the tested way, 
> as shown in the Developers Guide, which is essentially what our Continuous 
> Integration (CI) systems use and most other developers, or you can forge your 
> own path on less travelled routes strewn with rocks, rusty nails and broken 
> glass that you mostly have to deal with on your own.
> 
> Unless you have some inescapable need to do things in a different way, it's 
> easier and more productive to follow the herd.

Building in a subdirectory with a name other than "build" isn't exactly a 
"[route] strewn with rocks, rusty nails and broken glass".  *That* should Just 
Work (at least if the name is all ASCII printable characters and contains no 
spaces); if it doesn't, that's a sign that the build process isn't robust 
enough.

Building in the source directory *itself* is a bit more painful, but that 
doesn't appear to be what we're talking about here; it sounds as if we're 
talking about

mkdir build.wireshark
cd build.wireshark
cmake ..
make
___
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] (1) building Wireshark in build.wireshark fails, (2) how to get dissector details without packet

[Guy Harris]

On Apr 15, 2021, at 8:10 AM, Vincent Randal  wrote:

> Where is the build log?

In the file to which you redirected the standard output and error of the make 
command - or the file created by tee, if piped the standard output and error of 
the make command to "tee errs" so that the errors are printed *and* get written 
to the file "errs".

If you *haven't* redirected the output, it's in your terminal window, so you 
might be able to scroll back to find the error.  (I presume nobody uses *real* 
terminals these days. :-))

> As I scroll back I can see the output shown below. It actually says "Built 
> target qtui" which I reported incorrectly as failing to build qtui. Is there 
> more than one qtui build target?

No, there shouldn't be.
 
> when make fails the build output prior to "Built target qtui" looks like this:
> at the very end we get this:
> [ 84%] Building CXX object 
> ui/qt/CMakeFiles/qtui.dir/wlan_statistics_dialog.cpp.o
> 
> [ 85%] 
> Building C object ui/qt/CMakeFiles/qtui.dir/wireshark-tap-register.c.o
> 
> [ 85%] 
> Building CXX object 
> ui/qt/CMakeFiles/qtui.dir/qtui_autogen/mocs_compilation.cpp.o
> 
> [ 85%] 
> Building CXX object 
> ui/qt/CMakeFiles/qtui.dir/qtui_autogen/EF4ICWSDIF/qrc_about.cpp.o
> 
> [ 85%] 
> Building CXX object 
> ui/qt/CMakeFiles/qtui.dir/qtui_autogen/NQCY4LEWD2/qrc_languages.cpp.o
> 
> [ 85%] 
> Building CXX object 
> ui/qt/CMakeFiles/qtui.dir/qtui_autogen/EF4ICWSDIF/qrc_layout.cpp.o
> 
> [ 85%] 
> Building CXX object 
> ui/qt/CMakeFiles/qtui.dir/qtui_autogen/EF4ICWSDIF/qrc_stock_icons.cpp.o
> 
> [ 85%] 
> Building CXX object 
> ui/qt/CMakeFiles/qtui.dir/qtui_autogen/EF4ICWSDIF/qrc_wsicon.cpp.o
> 
> [ 85%] 
> Building CXX object 
> ui/qt/CMakeFiles/qtui.dir/qtui_autogen/EJRQKI7XPS/qrc_i18n.cpp.o
> 
> [ 85%] Built target qtui
> Makefile:140: recipe for target 'all' failed
> make: *** [all] Error 2

There might be an error further back.  That's why sending the build output to a 
file is useful - you can then, for example, open the file in a text editor and 
look for the word "error" (note that some source files may have "error" in 
their names, so skip them).
___
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] (1) building Wireshark in build.wireshark fails, (2) how to get dissector details without packet

[Guy Harris]

On Apr 15, 2021, at 12:55 AM, Vincent Randal  wrote:

> (1)  building Wireshark in build.wireshark fails
> The solution here is to use "build" as the name of the build directory and 
> then make succeeds. Otherwise, if the build directory has some other name 
> like build.wireshark then make fails at about 70% when building qtui.

What's the error that it reports?  I can't reproduce that on my Mac with the 
current tip of the main branch.

> (2) how to get dissector details without packet
> I see there is "Decode as ..." in the Analzye menu of Wireshark. That looks 
> very useful. I think I can use that to get Wireshark to ... uh well ... 
> decode an already decoded packet as something else.
> 
> But what about something that shows me what Wireshark thinks about a 
> dissector even without a packet? Is that possible? Can Wireshark show me the 
> details of a dissector without a packet to dissect?

That depends on what you mean by "the details of the dissector".  Normally, 
what Wireshark shows is the details of a *packet*, which, obviously, requires a 
packet; what would the details of a *dissector* be?

___
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] How to build the simple ASN.1 UDP-based dissector example (foo)

[Guy Harris]

On Apr 13, 2021, at 5:36 PM, Vincent Randal  wrote:

> If it’s important not to break wireshark-2.6.20

It's not.

All I'm saying there is that there are different levels of support:

for Windows and macOS, we do CI builds, so we know Wireshark builds and 
runs, and supply binaries;

for Linux, we do CI builds, so we know Wireshark builds and runs, and 
supply source tarballs, from which many distributions construct packages;

for FreeBSD/NetBSD/OpenBSD/DragonFly BSD, we don't currently do CI 
builds, but that might be worth looking into for at least some of those OSes, 
and we supply source tarballs, from which at least some of those construct 
packages, so, to that extent, we know it works;

for Solaris, we don't do CI builds, but we supply source tarballs, and 
Oracle might make a package from that - if so, we know that it works;

for AIX, we don't do CI builds, but we supply source tarballs - 
however, I don't know whether anybody packages them, so I don't know whether it 
works;

for HP-UX, we don't do CI builds, but we supply source tarballs - but 
the HP-UX Porting and Archive Centre hasn't offered packages for anything newer 
than 2.6.20, and don't even offer packages for any version of Qt with which 
Wireshark works, so it might be extremely difficult, if not impossible, to make 
any remotely modern Wireshark work, given that they haven't bothered.

2.6.20 is a *REALLY* out-of-date version, and we don't support it; if somebody 
*wants* their plugin to work on it, they can try to make it work, but I don't 
think we think that's at all important.

> and the wide array of operating systems you mentioned previously.

I just mentioned them to indicate why we talk about "Unix and Unix-like 
systems" rather than "Linux" - we're not a "Windows and Linux" application, or 
even a "Windows, Linux, and macOS" application, the goal is to work on as many 
living UN*Xes as we can.  (HP-UX may, at this time, be on life support - I 
don't think HPE have any plans to port it to x86-64, and they *do* plan to 
switch to x86-64 for their hardware, given the death of Itanium.)

> Do you use Homebrew or MacPorts to configure your MacOS build environment for 
> Wireshark development?

No, I just use the tools/macos-setup.sh script.

> It’s been awhile since I used either. Also, I wonder if there are issues with 
> Qt vs XQuartz.

The versions of Qt that Wireshark can use all work directly atop whatever Apple 
calls the graphics layer - they do *NOT* use X11, so they don't require or use 
Xquartz.

And, most of the time, with a small amount of care your code will work on all 
platforms - and a generated ASN.1 dissector is probably even *more* likely to 
Just Work, especially if it doesn't run into any of the compiler warnings our 
build process turns on, as errors, by default.
___
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] How to build the simple ASN.1 UDP-based dissector example (foo)

[Guy Harris]

On Apr 13, 2021, at 9:21 AM, Pascal Quantin  wrote:

> 13 avr. 2021 17:36:20 John Thacker : 
> 
> > Depending on your build system, the other ASN.1 dissectors can be 
> > regenerated with either 
> > 
> > ninja asn1 
> >   Or 
> > make asn1 
> > 
> > without starting the full build process. 
> 
> Those commands will regenerate all the ASN.1 dissectors.

At least on my Mac, "ninja asn1" did "regenerate" them all (making no changes, 
according to "git status"), but when I tried it again in the same build 
directory, Ninja said "ninja: no work to do."
___
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] How to build the simple ASN.1 UDP-based dissector example (foo)

[Guy Harris]

On Apr 13, 2021, at 6:03 AM, Vincent Randal  wrote:

> I'm building Wireshark on Linux. Wireshark documentation refers to it as UNIX 
> or UNIX-like.

Linux is one of the UNIX-like systems we support, yes.  We also officially 
support macOS, and the build process may also work on FreeBSD, NetBSD, OpenBSD, 
DragonFly BSD, Solaris, AIX, HP-UX, etc..  (The hardest part might be getting 
Qt working; the HP-UX Porting and Archive Centre at

http://hpux.connect.org.uk

only has Wireshark 1.10.5 and 2.6.20; they have Qt, but it's only 3.0.5.)
___
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 dissector Wireshark

[Guy Harris]

On Apr 12, 2021, at 10:08 PM, Vincent Randal  wrote:

> Thank you (John) for delving into a nice description of the overall process. 
> I do have a couple more questions for you and the group:
> 1. What is the meaning of "work is in progress to at least read all ASN1 
> specifications" ???
> I'm trying to imagine what that implies. Does it imply some dissectors in 
> ./epan/dissectors/asn1 have an .asn file that is not being read?

No.

It implies that not all of the specifications out there that are in the form of 
text files using ASN.1's descriptive syntax can be handled by asn2wrs, so there 
are some specifications that would need manual tweaking to work with asn2wrs.

That may be the case for some of the epan/dissectors/asn1/*/*.asn files.

I don't know what all the limitations are, or whether anybody's *currently* 
working on removing any such limitations.  I don't think there's much being 
done to the specification for the ASN.1 descriptive syntax, so I don't think 
there's much that would be getting more out of date; it's more a question of 
some features in the X.whatever specs that isn't supported.

The .cnf file's main purpose is to add additional semantics for fields that 
affects the way Wireshark dissects and displays them, over and above what can 
be expressed in the ASN.1 specification language.  For example, a field might 
be specified, in the specification language, as an OCTET STRING, but it might 
contain a blob of data with substructure *not* using the encoding rule for the 
protocol and thus *not* specifiable in the specification.

And, even if it *could* be specified using ASN.1 specification syntax, doing so 
would mean modifying the .asn file, and if the specification is updated, and we 
wanted to update the .asn file to the latest version, we'd have to merge the 
specification changes and our changes.  That's what "Changing the ASN1 file is 
being depreciated as this creates problems when updating protocols." means.
___
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] Bugzilla -> Gitlab failed migration

[Guy Harris]

On Apr 6, 2021, at 12:11 PM, Uli Heilmeier  wrote:

> Just discovered that Bugzilla bugs 5379 [1] and 8161 [2] haven't been 
> migrated successfully to Gitlab issues.
> 
> Both issues have state "opened" and Bugzilla status is "RESOLVED FIXED". 
> Furthermore Bugzilla comments are missing in
> the Gitlab issues.
> 
> A quick search didn't show any additonal bugs where Bugzilla status doesn't 
> match Gitlab state.
> However I'm not sure if other Gitlab issues missing Bugzilla comments too.
> 
> Can someone update the issues accordingly (at least: set state to closed; 
> best: migrate missing comments too)?
> 
> [1] https://gitlab.com/wireshark/wireshark/-/issues/5379
> [2] https://gitlab.com/wireshark/wireshark/-/issues/8161

Fixed as best as I could do so.
___
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] Adding GPS data from Kismet as Expert Info?

[Guy Harris]

On Mar 29, 2021, at 2:13 AM, Erik Hjelmvik  wrote:

> I have discovered that Kismet can generate pcap-ng files that contain GPS 
> coordinates stored in custom option fields. I've started thinking about how 
> this GPS data can be represented in Wireshark or tshark. The GPS options are 
> attached to standard Enhanced Packet Blocks, so they could be considered as 
> meta-data for a frame. Would it make sense to show the lat/long coordinates 
> from the Kismet GPS option as Expert Info (_ws.expert)? Or do you have a 
> better suggestion of how to display this data?

How about adding them as regular protocol tree items under the "Frame" protocol?
___
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] Issue about tvb_reported_length_remaining() and tvb_captured_length_remaining() of tvb passed from Lua

[Guy Harris]

On Mar 27, 2021, at 3:47 AM, qiangxiong.huang  wrote:

> Where is the bug? If it a bug belongs to packet-protobuf.c, I can submit a 
> merge for it. But If it belongs to wslua_tvb.c, who familiar with the code 
> wslua_tvb.c may help fix.

It's a bug in wslua_tvb.c, and it's now fixed (I've backported the fix to the 
3.4 branch, so it should be in the next 3.4.x release).
___
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] Automated builds failing for macOS since MR 2136 was applied

[Guy Harris]

On Mar 27, 2021, at 5:49 AM, Jim Young  wrote:

> We've had failing macOS builds since the commit set from
> https://gitlab.com/wireshark/wireshark/-/merge_requests/2136 was
> applied.

Fixed.
___
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] 16 byte integer decoding

[Guy Harris]

On Mar 22, 2021, at 11:35 AM, Constantine Gavrilov  wrote:

> There are two repeated patterns for this:
> 
> 1. For capacity (bytes, blocks, etc.).
> 2. For units (how many times).
> 
> So, I am thinking about two formats:
> 1. For bytes.
> 2. For units.
> 
> The implementation would get high and low 64-bits, and compute a 64-bit value 
> in units of 10^x (depending on the value) for units, and in units of KiB-ZiB 
> (depending on the value) for bytes.

So a value of 12 would be shown as "1.2 deca-XXX" for units, and a value of 1 
would be shown as "1/1024 KiB bytes" for bytes?
___
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] Is there a way to easily go to the next packet that satisfies a filter string without filtering the packets

[Guy Harris]

On Mar 20, 2021, at 2:23 PM, ronnie sahlberg  wrote:

> Doesn't wireshark already have this?
> 
> CTRL-F and then type in the filter string
> then click "Find" and it will cycle through the packets that are matching.

Yes, "Find" (Ctrl-F on Windows and UN*Xes not named "macOS", Command+F on 
macOS) can search based on:

a pattern-matching expression ("Find" calls it a "Display Filter");

a hex value;

a string;

a regular expression.

The latter three match on raw frame contents; the former is the same as display 
filters, read filters, coloring rule expressions, etc..
___
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] Is gitlab having problems?

[Guy Harris]

On Mar 14, 2021, at 8:18 PM, Richard Sharpe  wrote:

> Seems to be a browser issue. I tried a different browser and it worked
> but the original browser refused to work.

Butbutbut... I thought the Web was a platform?  You mean it's multiple 
incompatible platforms? :-)

File a GitLab issue on that, so they can either fix it or indicate that the 
browser is buggy and needs to have a bug filed against it.
___
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] ASAN - now for Windows

[Guy Harris]

https://devblogs.microsoft.com/cppblog/address-sanitizer-for-msvc-now-generally-available/
___
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] Issue cleanup (admin privs needed)

[Guy Harris]

On Mar 12, 2021, at 10:06 AM, chuck c  wrote:

> https://gitlab.com/wireshark/wireshark/-/issues/16587
> Typing after Display Filter Macro crashes gui
> 
> https://gitlab.com/wireshark/wireshark/-/issues/16778
> Display Filter Macros Crash Wireshark

Fixed (with some liberties taken to add Markdown formatting, making a bulleted 
list out of the original poster's example filter macros).
___
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] Issue cleanup (admin privs needed)

[Guy Harris]

On Mar 12, 2021, at 10:21 AM, Pascal Quantin  wrote:

> Hi Chuck,
> 
> Le ven. 12 mars 2021 à 19:07, chuck c  a écrit :
>> https://gitlab.com/wireshark/wireshark/-/issues/16587
>> Typing after Display Filter Macro crashes gui
>> 
>> https://gitlab.com/wireshark/wireshark/-/issues/16778
>> Display Filter Macros Crash Wireshark
>> 
> Done.

Not yet.  You haven't fixed your own comment in

https://gitlab.com/wireshark/wireshark/-/issues/16587

(the one that begins with "We seem to face a MSVC2019 compiler bug: the crash 
is systematic when using RelWithDebInfo but does not happen in Debug mode.")  
That comment is incorrectly formatted as fixed-width text; only the C code 
should be formatted that way (and it shouldn't be indented as far as it is).

The bulk of the comments in

https://gitlab.com/wireshark/wireshark/-/issues/16778

made prior to the move to GitLab are also all still fixed-width.
___
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] Time to update to Npcap 1.20

[Guy Harris]

It looks as if it fixes some annoying bugs:

https://github.com/nmap/npcap/blob/master/CHANGELOG.md

so if we haven't already updated the Wireshark Windows builds to include the 
1.20 installer, we should do so.

Anybody who's been having problems - especially if they're the ones noted:

https://github.com/nmap/npcap/issues/122
"npcap no longer working. Can't set [Wi-Fi] channel"

https://github.com/nmap/npcap/issues/106
"blocks vmware network stack after wakeup"

https://github.com/nmap/npcap/issues/268
"BSoD crash when upgrading to Npcap 0.9996 or later"

might want to consider updating to 1.20.
___
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 rebase

[Guy Harris]

On Mar 5, 2021, at 3:07 PM, Maynard, Christopher via Wireshark-dev 
 wrote:

>> From: Wireshark-dev  On Behalf Of chuck 
>> c
>> Sent: Friday, March 5, 2021 5:26 PM
>> To: Developer support list for Wireshark 
>> Subject: Re: [Wireshark-dev] Struggling to rebase
>> 
>> But sometimes I'm this guy:
>> https://twitter.com/catalinmpit/status/1301965170076459009
> 
> Naturally, there's a relevant xkcd for this: https://xkcd.com/1597/

https://twitter.com/spences10/status/1301973429206343686

Or, to quote Ellen Ripley:

I say we take off and nuke the entire site from orbit. It's the only 
way to be sure.

___
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] File rename impacts Gitlab history

[Guy Harris]

On Feb 26, 2021, at 8:48 AM, chuck c  wrote:

> https://gitlab.com/wireshark/wireshark/-/commit/50dbe4df7fd7a5e4e1a27fd5046981486d350994
> Rename packet-ssl* to packet-tls*
> 
> Looking through history of 
> https://gitlab.com/wireshark/wireshark/-/commits/master/epan/dissectors/packet-tls.c
> 
> https://gitlab.com/wireshark/wireshark/-/tree/2fd42045f5afb556a03d8a1090f3278c77798766
>  "epan/dissectors/packet-tls.c" did not exist on 
> "2fd42045f5afb556a03d8a1090f3278c77798766"
> 
> Is there any sort of work around (symbolic link?) that could be tracked in 
> Git?

If you can use Full Frontal Command-Line Git, --follow is a helpful command 
line for some Git commands:

$ git log epan/dissectors/packet-tls.c | egrep 
2fd42045f5afb556a03d8a1090f3278c77798766
$ git log --follow epan/dissectors/packet-tls.c | egrep 
2fd42045f5afb556a03d8a1090f3278c77798766
commit 2fd42045f5afb556a03d8a1090f3278c77798766

but it doesn't necessarily work for all commands, and I don't know whether 
there's any special trick for GitLab's Web interface.
___
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] pcapng decoding error when preamble is shortened

[Guy Harris]

On Feb 19, 2021, at 9:50 PM, Jaap Keuter  wrote:

> It’s not a matter of *what* the program is reading, but *where* it's reading 
> in the buffer. This makes it usable for *all* programs reading this file 
> format, not just Wireshark. Prefixing it with zero padding (even a nibble) 
> would achieve that.

As would changing the spec to indicate that the preamble may reflect the length 
of the preamble as received, and thus that it's from 1 to 7 octets.

I infer from what Timmy Brolin, and from IEEE Std 802.3-2018, that there's no 
guarantee that the receiver will see all the preamble bits sent by the MAC 
layer, so I don't see this a indicating how long the packet was on the wire.  
At least as I read section 22.2.3.2.2 "Receive case" of 802.3-2018, in the 
clause talking about 100 Mbit Ethernet, all or none of the preamble may be 
received over the MII - "Table 22–4 depicts the case where no preamble nibbles 
are conveyed across the MII, and Table 22–5 depicts the case where the entire 
preamble is conveyed across the MII." - (and I suspect any value between "all" 
and "none" may be received).

At least as I read Figure 24-11 "Receive state diagram, part a", on the 
wire/fibre, the preamble begins with two special 5-bit code-groups J and K, in 
order, indicating the beginning of a bit stream.  After that come more 5-bit 
code-groups which encode the nibbles of the preamble, SFD, and data (including 
the MAC header, payload, and FCS).  I infer from that diagram that the preamble 
isn't used for synchronization on the wire; it may be used for synchronization 
between the MII and the PHY.

So it sounds as if a short preamble could be received because:

the transmitting station didn't send the entire preamble down its MII 
(which means the transmitter is cheating, given that 22.2.3.2.1 "Transmit case" 
says 7 octets are sent down the MII), and thus it wasn't put on the wire after 
the J/K;

the transmitting station did send the entire preamble down its MII, but 
the receiving station's Reconciliation Sublayer (RS) didn't manage to sync up 
with its Physical Coding Sublayer (PCS) because it didn't sync up with the PCS 
immediately - it needed to see a few bit transitions;

the PCS Just Didn't Bother Sending The Full Preamble.

I don't think bits of the preamble would be lost *over the wire*, as I infer 
that the receipt of the J/K starts the reception process, and if it's not in 
sync with the transmitter at that point, no frame is going to be received.

I also *suspect* that "the PCS Just Didn't Bother Sending The Full Preamble" 
isn't likely to be the cause of a short preamble.

A capture at the RS layer can't, as far as I know, distinguish between the 
first two cases.

The first case indicates that the transmitting station is trying to reduce its 
use of network bandwidth and/or reduce the latency for the packet.

The second case indicates - something?

Other PHYs may behave differently.

The reasons for *not* padding a short preamble that I can see would be

1) extra stuff for the receiver to do if it receives a short preamble;

2) loss of an indication that the preamble is short - that indication 
is presumably of interest to people reading the capture for purposes of 
diagnosing low-level Ethernet issues (meaning "probably of interest to people 
capturing on a network *NOT* using 802.3br" - as far as I know, there's nothing 
about 802.3br that makes the length of the preamble more relevant), otherwise 
nobody'd be asking for dissectors to handle short preambles.

___
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] pcapng decoding error when preamble is shortened

[Guy Harris]

On Feb 16, 2021, at 4:03 AM, Timmy Brolin  wrote:

> In practice, this is what I would propose:
> * Wireshark dissector made capable of accepting any whole-byte preamble 
> length mPackets.
> * mPacket capture devices are made responsible for detecting any frames with 
> non-integer preamble, and correct for it by adding 4 bits extra preamble at 
> the beginning. That way the dissector never has to realign a whole frame on 
> bit level.

I.e., the packet, as stored in a capture file (pcap, pcapng, whatever), will 
have somewhere between 1 and 7 octets of 0x55, followed by an SMD?

> * A capture device which has added 4 bits of preamble, shall indicate this by 
> setting the “unaligned frame error” bit in epb_flags, to let the dissector 
> know that it should ignore the least significant nibble of the first preamble 
> byte.

Why is this necessary?  Is the goal here to indicate the on-the-wire preamble 
length?  If so, why not just write 0x50 rather than 0x55 as the first octet if 
the least significant nibble is a padding nibble?

> While a mPacket with 4 bits of missing preamble is not actually an error, I 
> can think of no other meaningful use for the “unaligned frame error” bit in 
> epb_flags for mPackets. So it should be ok to make use of it for this 
> purpose? Maybe?
> Unless the “unaligned frame error” is actually intended to indicate “dribble 
> error”? (An extra 4 bit nibble at the end of a frame)

Those flags come from an example given in the documentation of the flags field 
of the pcapng Enhanced Packet Block"


https://pcapng.github.io/pcapng/draft-tuexen-opsawg-pcapng.html#name-enhanced-packet-block-flags

which says

link-layer-dependent errors (Bit 31 = symbol error, Bit 30 = preamble 
error, Bit 29 = Start Frame Delimiter error, Bit 28 = unaligned frame error, 
Bit 27 = wrong Inter Frame Gap error, Bit 26 = packet too short error, Bit 25 = 
packet too long error, Bit 24 = CRC error, other?? are 16 bit enough?).

Currently, we support that flag in DOS Sniffer files; we do *not* yet interpret 
the link-layer-dependent errors in pcapng files.

And the "unaligned frame error" should perhaps be renamed "misaligned frame 
error".

See, for example, this page of an Ethernet adapter manual:


https://manualsdump.com/en/manuals/asante_technologies-asante_maccon_family_ethernet_network_cards_for_the_macintosh/142796/53

in which it lists various error indications, including Frame Alignment Error, 
which means the frame didn't not end in an 8 bit boundary.

That says nothing about the preamble.  It's talking about "octet-boundary 
alignment of the end of the frame", to quote section 4.1.2.1.2 "Reception 
without contention":

...It also checks for invalid MAC frames by inspecting the frame check 
sequence to detect any damage to the frame enroute, and by checking for proper 
octet-boundary alignment of the end of the frame. Frames with a valid FCS may 
also be checked for proper octet-boundary alignment.

So there are at least 3 reasons not to use that flag:

1) that's not what its intended use is;

2) it's not currently implemented in the pcapng reader;

3) it's not available in pcap - this isn't a "pcapng decoding error", 
it's a packet decoding error, and there should be as few cases as possible 
where a packet from a pcapng file (if all the interfaces in the pcapng file 
have the same link-layer type and snapshot length) could not be written to a 
pcap file and properly decoded by a program reading the pcap file.
___
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] Help finding the link layer dissector call (netmon_802_11)

[Guy Harris]

On Feb 16, 2021, at 2:41 AM, Shai Shapira via Wireshark-dev 
 wrote:

> I'm researching Microsoft's Network Monitor captures format (.cap files)

Unfortunately, you probably can't download NetMon from Microsoft any more, so 
you probably can't get the help file that documents the capture file format any 
more.

But if you have direct questions about it, I can answer them.

> and I need a lead in WS's code.
> Based on the 'link layer type' parsed from the file header the packets might 
> be 802.11 frames with NM's special header.
> This dissector is known as "netmon_802_11" in wireshark.
> 
> It is the first protocol in every frame's stack and it's registration routine 
> is directly to the "wtap_encap" table like so:
> dissector_add_uint("wtap_encap", WTAP_ENCAP_IEEE_802_11_NETMON, 
> netmon_802_11_handle);
> 
> (from packet-ieee80211-netmon.c)
> 
> Could someone point me to the functoin where the actual 'call_dissector' or 
> 'call_dissector_with_data' is happening for the inital layer?

It's happening in the

switch (pinfo->rec->rec_type) {

case REC_TYPE_PACKET:
if ((force_docsis_encap) && (docsis_handle)) {
dissector_handle = docsis_handle;
} else {
/*
 * XXX - we don't use 
dissector_try_uint_new()
 * because we don't want to have to
 * treat a zero return from the 
dissector
 * as meaning "packet not accepted,
 * because that doesn't work for
 * packets where libwiretap strips
 * off the metadata header and puts
 * it into the pseudo-header, leaving
 * zero bytes worth of payload.  See
 * bug 15630.
 *
 * If the dissector for the packet's
 * purported link-layer header type
 * rejects the packet, that's a sign
 * of a bug somewhere, so making it
 * impossible for those dissectors
 * to reject packets isn't a problem.
 */
dissector_handle =

dissector_get_uint_handle(wtap_encap_dissector_table,

pinfo->rec->rec_header.packet_header.pkt_encap);
}
if (dissector_handle != NULL) {
guint32 save_match_uint = 
pinfo->match_uint;

pinfo->match_uint =

pinfo->rec->rec_header.packet_header.pkt_encap;
call_dissector_only(dissector_handle,
tvb, pinfo, parent_tree,
(void *)pinfo->pseudo_header);
pinfo->match_uint = save_match_uint;
} else {
col_set_str(pinfo->cinfo, COL_PROTOCOL, 
"UNKNOWN");
col_add_fstr(pinfo->cinfo, COL_INFO, 
"WTAP_ENCAP = %d",
 
pinfo->rec->rec_header.packet_header.pkt_encap);
call_data_dissector(tvb, pinfo, 
parent_tree);
}
break;

code in dissect_frame() in epan/dissectors/packet-frame.c

> Also, is that dependent on the file format we are parsing (pcap/pcapmg/cap)

No.  (And there are more formats than those, not that "cap" is a file format - 
several *different* file formats use ".cap" as the suffix, so there's no such 
thing as a ".cap file".)

> or is there a single function all eventually get to?

Yes.  The libwiretap library handles differences between capture file formats, 
supplying packet information in a standard fashion to libwireshark.
___
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] pcapng decoding error when preamble is shortened

[Guy Harris]

At various points in February 2021, Timmy Brolin  wrote:

> Would anyone mind if I submit a merge request which makes Wireshark capable 
> of dissecting all valid Ethernet mPackets according to IEEE 802.3br?

I.e. according to the spec that says, on page 39:

* 99.3.2 Preamble

The preamble in the mPacket shown in part (a) of Figure 99–4 contains 
seven octets. The preamble in the mPacket shown in part (b) of Figure 99–4 
contains six octets. Each octet contains the value of 0x55 (transmitted in 
order from left to right 10101010).

and thus that the preamble field is either 7 octets of 0x55 or 6 octets of 0x55?

> Preamble reduction is quite common practice. In this particular case I have a 
> SGMII RJ45 SFP on the network which randomly chops off one byte of the 
> preamble on some packets. This is common and accepted behavior for various 
> pieces of network equipment. 


Section 12.9.2 "DTE timing" of IEEE Std 802.3-2018 says:

DTEs shall correctly receive frames that are preceded by 13 or more 
bits of preamble plus 8 bits of .

which I assume means that, on the *receiving* end, if you miss up to 43 bits of 
the 56-bit preamble - or up to 35 bits of the 48-bit preamble in some mPackets 
- once you're synced up, and see the SFD, you should continue the reception 
process and hand what you have up to the MAC sublayer.

Most capture devices supply the data handled to the MAC layer in the 
MA_DATA.indication primitive to the host, possibly dropping the 
frame_check_sequence, and that's what the Wireshark Ethernet dissector expects 
as input.  I.e., the packet capture hardware and software is a MAC client.

On the *transmission* side, you're supposed to transmit 7 octet of preamble; I 
haven't seen anything about reducing the size of the *transmitted* preamble 
being acceptable behavior.

Once frame preemption is introduced, the packet capture can be at various 
layers:

1) at the pMac and eMAC layers, as a MAC client, in which case they 
would supply the data handled to the MAC layer in the MA_DATA.indication 
primitive, *possibly* including an indication of the MAC on which the packet 
was indicated (pMAC or eMAC) - that would be post-reassembly of preempt able 
packets;

2) at the MAC Merge sublayer, in which case they get bit streams for 
preemptable and express packets, including the preamble and SFD (see the calls 
to pRX_DATA(PREAMBLE) and pRX_DATA(SFD) in figure 99-6 and eRX_DATA(PREAMBLE) 
and eRX_DATA(SFD) in figure 99-7) - that would be after the MAC Merge 
processing;

3) at the Reconciliation Sublayer, in which case they get bit streams 
for packets, again including the preamble and SFD.

To get mPackets, the tap would, I think, have to be at 3).

That means that, if the *received* preamble can be as little as 13 bits, the 
mPacket could have as few as 13 bits of preamble, meaning that neatly aligning 
the packet for dissection could involve a lot of bit shifting.

Is that what you're proposing?
___
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