[Wireshark-dev] Trouble uploading Wireshark enhancement

[Fulko Hew]

I've enhanced a Lua based dissector, and have also rewritten it
in 'C' so that it can be included in the next release of Wireshark.

Now I'm trying to submit it.  My last submission was back in 2007,
and things have changed a little since then.

I believe? the latest doc on how to submit changes are in:

https://gitlab.com/wireshark/wireshark/-/wikis/Development/SubmittingPatches#a-super-short-overview-of-git

After being a developer for 45 years, I never had to use git until now, so
I'll
admit I don't know anything about git, and I'm trying to follow those
instructions.

I got to the point of 'commit' and then 'git push downstream +HEAD'
and I get the error:

fatal: 'downstream' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

What am I doing wrong?
___
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] Buildbot crash - what did I break?

[Gerald Combs]

On 10/22/20 11:08 AM, Pascal Quantin wrote:
> Hi Chuck
> 
> Le jeu. 22 oct. 2020 à 20:06, chuck c  > a écrit :
> 
> https://gitlab.com/wireshark/wireshark/-/issues/16939
> Buildbot crash output: fuzz-2020-10-20-17042.pcap
> 
> Git commit
> commit 5b242d62b045e6c85a0119c5271d0b072707c79a
> Author: Chuck Craft mailto:bubbas...@gmail.com>>
> Date:   Tue Sep 8 21:59:02 2020 -0500
> 
>     WIN32 logging: connect stdio earlier in main()
> 
> 
> https://gitlab.com/wireshark/wireshark/-/commit/5b242d62b045e6c85a0119c5271d0b072707c79a
> 
> But it seems it might be this commit instead?
> 
> https://gitlab.com/wireshark/wireshark/-/commit/0ceb46e1c28d1094a56aefa0ebf7d7c0e00f8849
> proto: add support for FT_BYTES in proto_tree_add_bits
> 
> 
> It's not you: you get the reference of the changeset that was fuzzed, which 
> is not necessarily the one that introduced the issue.

Including the commit message in something that runs infrequently probably isn't 
the best idea. I'll take a look at removing 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

Re: [Wireshark-dev] Buildbot crash - what did I break?

[Pascal Quantin]

Hi Chuck

Le jeu. 22 oct. 2020 à 20:06, chuck c  a écrit :

> https://gitlab.com/wireshark/wireshark/-/issues/16939
> Buildbot crash output: fuzz-2020-10-20-17042.pcap
>
> Git commit
> commit 5b242d62b045e6c85a0119c5271d0b072707c79a
> Author: Chuck Craft 
> Date:   Tue Sep 8 21:59:02 2020 -0500
>
> WIN32 logging: connect stdio earlier in main()
>
>
> https://gitlab.com/wireshark/wireshark/-/commit/5b242d62b045e6c85a0119c5271d0b072707c79a
>
> But it seems it might be this commit instead?
>
> https://gitlab.com/wireshark/wireshark/-/commit/0ceb46e1c28d1094a56aefa0ebf7d7c0e00f8849
> proto: add support for FT_BYTES in proto_tree_add_bits
>

It's not you: you get the reference of the changeset that was fuzzed, which
is not necessarily the one that introduced the issue.

Best regards,
Pascal.
___
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] Buildbot crash - what did I break?

[chuck c]

https://gitlab.com/wireshark/wireshark/-/issues/16939
Buildbot crash output: fuzz-2020-10-20-17042.pcap

Git commit
commit 5b242d62b045e6c85a0119c5271d0b072707c79a
Author: Chuck Craft 
Date:   Tue Sep 8 21:59:02 2020 -0500

WIN32 logging: connect stdio earlier in main()

https://gitlab.com/wireshark/wireshark/-/commit/5b242d62b045e6c85a0119c5271d0b072707c79a

But it seems it might be this commit instead?
https://gitlab.com/wireshark/wireshark/-/commit/0ceb46e1c28d1094a56aefa0ebf7d7c0e00f8849
proto: add support for FT_BYTES in proto_tree_add_bits
___
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] Create dissctor groups to easily dissable unneded protocols.

[Anders Broman via Wireshark-dev]

 

 

From: Wireshark-dev  On Behalf Of chuck c
Sent: den 21 oktober 2020 17:52
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Create dissctor groups to easily dissable unneded 
protocols.

 

>The Frame protocol (and a dozen others) can not be disabled:

> /* You can't disable dissection of "Frame", as that would be
>  tantamount to not doing any dissection whatsoever. */
>proto_set_cant_toggle(proto_frame);

> 

>Would there be a group that lists these?

 

I think it could be done – not sure what the use case would be, other than 
creating a list.

/Anders

 

On Wed, Oct 21, 2020 at 9:34 AM Anders Broman via Wireshark-dev 
mailto:wireshark-dev@wireshark.org> > wrote:

Hi,

In the developers den we discussed the possibility of disabling unneeded 
protocols and I brought up the idea of protocol groups. If there is interest in 
this feature

I would need help with the GUI part – volunteers? As a PoC I was thinking of 
something along these lines.

Turn all protocols of – enable the group “basic” which would then be the basic 
protocols you would need in most cases like

Ethernet -VLAN-IP4/IPv6-TCP UDP SCTP ICMP ICMP6 ARP more? We don’t need a 
comprehensive list here and now these might do for the PoC.

Once the basic group is there we might start to look at large groups of 
specialized protocols most people would want to turn off like

USB Bluetooth ZigeBee, telco(?) might be candidates. 

 

This would be the API to register in a group, only allowed group names(we make 
list) to be accepted at registry time, possibly

Have a register group name routine? But the poc may not have to be more 
complicated than this.

--- a/epan/proto.c

+++ b/epan/proto.c

@@ -343,21 +343,22 @@ static header_field_info hfi_text_only =

{ "Text item",  "text", FT_NONE, BASE_NONE, NULL, 0x0, NULL, HFILL };

int hf_text_only = -1;

 

-/* Structure for information about a protocol */

+/** Structure for information about a protocol */

struct _protocol {

-   const char *name;   /* long description */

-   const char *short_name; /* short description */

-   const char *filter_name;/* name of this protocol in filters */

-   GPtrArray  *fields; /* fields for this protocol */

-   int proto_id;   /* field ID for this protocol */

-   gbooleanis_enabled; /* TRUE if protocol is enabled */

-   gbooleanenabled_by_default; /* TRUE if protocol is enabled by 
default */

-   gbooleancan_toggle; /* TRUE if is_enabled can be changed */

-   int parent_proto_id;/* Used to identify "pino"s (Protocol 
In Name Only).

+   const char *name;   /**< long description */

+   const char *short_name; /**< short description */

+   const char *filter_name;/**< name of this protocol in filters */

+   const char* group_name; /**< name of the "group" this protocol 
belongs to */

+   GPtrArray  *fields; /**< fields for this protocol */

+   int proto_id;   /**< field ID for this protocol */

+   gbooleanis_enabled; /**< TRUE if protocol is enabled */

+   gbooleanenabled_by_default; /**< TRUE if protocol is enabled by 
default */

+   gbooleancan_toggle; /**< TRUE if is_enabled can be changed 
*/

+   int parent_proto_id;/**< Used to identify "pino"s (Protocol 
In Name Only).

For dissectors that need a protocol 
name so they

can be added to a dissector table, but 
use the

parent_proto_id for things like 
enable/disable */

-   GList  *heur_list;  /* Heuristic dissectors associated with 
this protocol */

+   GList  *heur_list;  /**< Heuristic dissectors associated 
with this protocol */

};

 

/* List of all protocols */

@@ -7208,8 +7209,14 @@ check_valid_filter_name_or_fail(const char *filter_name)

}

 

int

-proto_register_protocol(const char *name, const char *short_name,

-   const char *filter_name)

+proto_register_protocol(const char* name, const char* short_name, const char* 
filter_name)

+{

+   return proto_register_protocol_and_group(name, short_name, filter_name, 
NULL);

+}

+

+int

+proto_register_protocol_and_group(const char *name, const char *short_name,

+   const char *filter_name, const char* group_name)

{

protocol_t *protocol;

header_field_info *hfinfo;

@@ -7248,6 +7255,7 @@ proto_register_protocol(const char *name, const char 
*short_name,

   protocol->name = name;

protocol->short_name = short_name;

protocol->filter_name = filter_name;

+   protocol->group_name = group_name;

protocol->fields = NULL; /* Delegate until actually needed */

protocol->is_enabled =