[Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character

[Uli Heilmeier]

Hello list,

I'm currently trying to improve the SMTP dissector regarding the AUTH command.
Up to now I finished the 'AUTH LOGIN' mechanism (s. Bug 8591). Next I
would like to decode the 'AUTH PLAIN' mechanism (RFC 4616).

With the PLAIN mechanism the packet has a base64 encoded string containing:
[authorization user](\x00)[authentication user](\x00)[password]

For example:
dGVzdAB0ZXN0ADEyMzQ= contains test(NUL)test(NUL)1234

I tried to decode the base64 string with the epan_base64_decode() function
(from epan/base64.h). Unfortunately this fails. I only get a wrong three
bytes long string.
I guess the problem is the NUL character as a delimiter.

Do you have an idea if this is bug in the epan_base64_decode() function or
do I have to do the decoding another way?


Thanks a lot!
Sincerely
Uli
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character

[Uli Heilmeier]

Hi,

Thanks for both replies!
I did a complete clean-up of my code and now the decoded string is 14
bytes long. So the epan_base64_decode() function is working correct.

Sorry for the work and the confusion.

There is only one issue left: How can I split up this string. The
g_strsplit() function seems to don't accept NULL as a delimiter.

Thanks!
Uli

Am 20.04.13 11:55, schrieb Jakub Zawadzki:
 Hi,
 
 On Wed, Apr 17, 2013 at 10:27:42PM +0200, Uli Heilmeier wrote:
 With the PLAIN mechanism the packet has a base64 encoded string containing:
 [authorization user](\x00)[authentication user](\x00)[password]

 For example:
 dGVzdAB0ZXN0ADEyMzQ= contains test(NUL)test(NUL)1234

 I tried to decode the base64 string with the epan_base64_decode() function
 (from epan/base64.h). Unfortunately this fails. I only get a wrong three
 bytes long string.
 I guess the problem is the NUL character as a delimiter.

 Do you have an idea if this is bug in the epan_base64_decode() function or
 do I have to do the decoding another way?
 
 From C interactive shell (gdb):
 
 (gdb) call $x = (char *) strdup(dGVzdAB0ZXN0ADEyMzQ=)
 $1 = 0x65b0e0 dGVzdAB0ZXN0ADEyMzQ=
 (gdb) call epan_base64_decode($x)
 $2 = 14
 
 (gdb) x/14c $x
 0x65b0e0:   116 't' 101 'e' 115 's' 116 't' 0 '\000'116 't' 101 
 'e' 115 's'
 0x65b0e8:   116 't' 0 '\000'49 '1'  50 '2'  51 '3'  52 '4'
 
 (gdb) call $x
 $3 = 0x65b0e0 test
 (gdb) call $x + 5
 $4 = 0x65b0e5 test
 (gdb) call $x + 5 + 5
 $5 = 0x65b0ea 1234
 
 Seems to be working ok, can you attach your code?
 
 Regards,
 Jakub Zawadzki

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] epan_base64_decode(): failure when string contains a NUL character

[Uli Heilmeier]

Am 21.04.13 22:29, schrieb Evan Huus:

 There is only one issue left: How can I split up this string. The
 g_strsplit() function seems to don't accept NULL as a delimiter.
 
 It depends what you need the results for. If you just need them
 separated by a NULL then they're already in that state, you can just
 use strlen and pointer arithmetic.

Yeah, your right. This way it was easy to split up the data.
Thanks a lot for this tip.

I added the patch to bug 8600.

 
 If you need discrete copies of each substring in their own memory
 space you can just do the above and then strdup them.
 
 A word of warning though: be sure to sanity check everything, as you
 can't assume that the string coming out of the packet will be sane, or
 will contain the correct number of NULLs (it may not contain any NULLs
 at all, in which case just calling strlen will run past the end of the
 buffer). Also be sure to use managed memory (see doc/README.wmem)
 unless you have a specific reason not to.

Thanks for the warning. I hope I added the right checks to my code.

Cheers
Uli

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] UDP Multicast Statistic: Meaning of "empty speed"

[Uli Heilmeier]

Hi,

I'm trying to finish the German translation for the 2.0 version.
One dialog where I haven't got the gist is "UDP Multicast Statistic".

What does "Stream empty speed" and "Total empty speed" mean in this context?
Is there a difference between "speed" and "bandwidth" for UDP Multicast?

BTW: Is the missing of the right bracket after "(Kb/s" intentionally or is
it a typo?

Your help is greatly appreciated.

Thanks,
Uli
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] QT-GUI Mac: DE Translation: Keyboard shortcuts missing in menu entries

[Uli Heilmeier]

Ok, got it. I've updated the strings in Transifex. 

So I guess the Italian and Polish translation should be reviewed for this issue 
too.

Alexis, thanks for your help.

> Am 16.11.2015 um 09:11 schrieb Alexis La Goutte <alexis.lagou...@gmail.com>:
> 
> Hi Uli,
> 
> After check the last wireshark_de.ts, you have translate Keyboard Accelerator 
> key (for example Ctrl+Down => Strg + Pfeil nach unten) but it is no very 
> needed, if you when to use the same keyboard accelerator key don't translate 
> and Qt will be (normally) translate key.
> You can get more info here : 
> http://doc.qt.io/qt-4.8/linguist-translators.html#changing-keyboard-accelerators
> 
> Regards,
> 
> 
>> On Mon, Nov 16, 2015 at 6:17 AM, Uli Heilmeier <ze...@heilmeier.eu> wrote:
>> Am 16.11.15 um 04:41 schrieb Guy Harris:
>> 
>> >
>> > Those letters in parentheses following "Datei" and "Ansicht" appear to be 
>> > the first letter of the English-language version of the menu name.  Are 
>> > they supposed to be there?  Or is that another issue, possibly related to 
>> > this issue?
>> 
>> They are intentionally. I wanted to have the same letter as in the English
>> version for the [Alt]+[Underlined-Letter] keyboard navigation.
>> If the German translation is missing the necessary letter I've added it in
>> parentheses (like the Chinese translation).
>> 
>> On Mac OS the underline is missing generally in menu entries.
>> 
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] QT-GUI Mac: DE Translation: Keyboard shortcuts missing in menu entries

[Uli Heilmeier]

Am 16.11.15 um 04:41 schrieb Guy Harris:

> 
> Those letters in parentheses following "Datei" and "Ansicht" appear to be the 
> first letter of the English-language version of the menu name.  Are they 
> supposed to be there?  Or is that another issue, possibly related to this 
> issue?

They are intentionally. I wanted to have the same letter as in the English
version for the [Alt]+[Underlined-Letter] keyboard navigation.
If the German translation is missing the necessary letter I've added it in
parentheses (like the Chinese translation).

On Mac OS the underline is missing generally in menu entries.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Release process: Transifex Sync

[Uli Heilmeier]

Hi,

First of all a huge Thank you to all the developers for a gorgeous 2.0.0 
release!

I saw that the language files haven't been updated before building 2.0.0.
Therefore the latest translations like 'Next Packet in Conversation' and my 
fixes for the keyboard shortcuts in the German translation are missing.

Wouldn't it make sense to have a Transifex sync step in the release process?

Any opinions or doubts?

Cheers 
Uli
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] QT translation: lock keyboard shortcut terms?

[Uli Heilmeier]

Hi list,

At the moment the translation source files ui/qt/wireshark_xx.ts contains
all the keyboard shortcuts (e.g. like 'Ctrl+Home'). Therefore these terms
are also listed in Transifex.

However these terms are translated "automatically" with the qt_xx.qm
files. Doing a manually translation breaks the display of the shortcuts in
the UI (s.
https://www.wireshark.org/lists/wireshark-dev/201511/msg00101.html).

I did the mistake to translate the terms some month ago and another
member of the German Transifex team has done the same mistake this week.

How can we prevent this?
* Remove keyboard shortcuts from the wireshark_xx.ts file (if feasible)
* Lock the terms (non writeable) in Transifex (if feasible)
* Establish a review process (like Gerrit) for translation files

At the moment the translation is synced automatically (also for master-20).

Any opinions?

Cheers
Uli
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] QT translation: lock keyboard shortcut terms?

[Uli Heilmeier]

Hi Alexis,

> How can we prevent this?
> * Remove keyboard shortcuts from the wireshark_xx.ts file (if feasible)
> 
> After a check, yes, it is possible to remove (via Qt Design for example
> "Close"
> diff --git a/ui/qt/main_window.ui b/ui/qt/main_window.ui
> index 021d788..881f6c7 100644
> --- a/ui/qt/main_window.ui
> +++ b/ui/qt/main_window.ui
> @@ -817,7 +817,7 @@
>  Close this capture file
> 
> 
> -Ctrl+W
> +Ctrl+W
> 
> 
>  false
> 
> and after it is remove from ts file
> 

Sounds good. I would vote for removing the terms from the ts files.

If no one complains I will upload a patch with fixed ui file in the next days.

> * Establish a review process (like Gerrit) for translation files
>
> It is possible to have "Reviewer" on Transifex, if you are interresed and
> can add you to reviewer group for check german translation
>

Keeping the automatic sync (without review) is ok for me when we've
removed the shortcuts from ts file.

Cheers
Uli
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] QT translation: lock keyboard shortcut terms?

[Uli Heilmeier]

Am 04.04.16 um 08:07 schrieb Michal Labedzki:
> Please note that some translations (not Wireshark only!) translate
> arrow keys names (Up, Down, Left, Right).
> For example: Polish. (I think it based on the fact that Enter,
> Backspace, Shift, Ctrl, Alt, PrintScreen, Insert, Esc, etc. has
> English name on the button, but arrows have only arrows (pictogram),
> so it is better to translate them. So I am ok to lock all shortcut
> without those with arrow and also if someone requests something... Let
> me think... we should ask Russian, Chinese, etc. what they have on the
> keyboard?

Fair enough.
I've checked some qt_XX.qm files coming with Qt:
--
/var/tmp/qt_cs.ts:Down
/var/tmp/qt_cs.ts-Dolů
--
/var/tmp/qt_de.ts:Down
/var/tmp/qt_de.ts-Runter
--
/var/tmp/qt_hu.ts:Down
/var/tmp/qt_hu.ts-Le
--
/var/tmp/qt_ja.ts:Down
/var/tmp/qt_ja.ts-↓
--
/var/tmp/qt_ko.ts:Down
/var/tmp/qt_ko.ts-아래
--
/var/tmp/qt_pl.ts:Down
/var/tmp/qt_pl.ts-Dół
--
/var/tmp/qt_ru.ts:Down
/var/tmp/qt_ru.ts-Вниз
--
/var/tmp/qt_zh_CN.ts:Down
/var/tmp/qt_zh_CN.ts-Down


Therefore I think there is no need to translate the terms manually.

However Qt doesn't provide qt_xx.qm files for all languages we have in
Transifex (at least my Qt installation). But for every language where we
have active contributions.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Commits 13dc91f5b or 9fbd4e6fc: addr_resolv.c fail to compile (async_dns_queue_head)

[Uli Heilmeier]

I've pushed a commit to Gerrit: https://code.wireshark.org/review/15106
Hope this is ok to fix this issue.

Quoting Uli Heilmeier <ze...@heilmeier.eu>:


Hi list,

my build system has failed to compile current master branch since  
commits 13dc91f5b or 9fbd4e6fc.


The error is:
---
In file included from  
/usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h:9:0,

 from /usr/include/glib-2.0/glib/gtypes.h:32,
 from /usr/include/glib-2.0/glib/galloca.h:32,
 from /usr/include/glib-2.0/glib.h:30,
 from addr_resolv.c:93:
addr_resolv.c: In function 'host_name_lookup_init':
addr_resolv.c:2659:14: error: 'async_dns_queue_head' undeclared  
(first use in this function)

 g_assert(async_dns_queue_head == NULL);
  ^
addr_resolv.c:2659:14: note: each undeclared identifier is reported  
only once for each function it appears in

---

c-ares is not available on my system:
---
Use c-ares library : no (name resolution will be disabled)
---

In addr_resolv.c:2659 async_dns_queue_head is called without a  
preliminary '#ifdef HAVE_C_ARES' statement


Any ideas to fix it?

Cheers
Uli




___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Commits 13dc91f5b or 9fbd4e6fc: addr_resolv.c fail to compile (async_dns_queue_head)

[Uli Heilmeier]

Hi list,

my build system has failed to compile current master branch since  
commits 13dc91f5b or 9fbd4e6fc.


The error is:
---
In file included from  
/usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h:9:0,

 from /usr/include/glib-2.0/glib/gtypes.h:32,
 from /usr/include/glib-2.0/glib/galloca.h:32,
 from /usr/include/glib-2.0/glib.h:30,
 from addr_resolv.c:93:
addr_resolv.c: In function 'host_name_lookup_init':
addr_resolv.c:2659:14: error: 'async_dns_queue_head' undeclared (first  
use in this function)

 g_assert(async_dns_queue_head == NULL);
  ^
addr_resolv.c:2659:14: note: each undeclared identifier is reported  
only once for each function it appears in

---

c-ares is not available on my system:
---
Use c-ares library : no (name resolution will be disabled)
---

In addr_resolv.c:2659 async_dns_queue_head is called without a  
preliminary '#ifdef HAVE_C_ARES' statement


Any ideas to fix it?

Cheers
Uli

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How to get calling dissector

[Uli Heilmeier]

Thanks for your idea. It's exactly the way Michael did it with his improvement 
for my patch:
https://code.wireshark.org/review/#/c/25509/

Am 29.01.18 um 21:01 schrieb Shai Shapira:
> I believe there's another possible approach here:
> Register the dissector once with proto_register_protocol (as usual), which 
> assumed caller is TCP
> register another dissection function (for SMP) using  
> create_dissector_handle_with_name called something like "smp.tds" 
> than look for this name when retrieving the dissector handle in the TDS 
> dissector
> 
> This means you should have 2 'entry point' functions to your dissector 
> (usually there's only one dissect_PROTO).
> This way by writing different dissection/payload handling code in those two 
> functions you can react differently to
> different calling protocols (tcp calls will trigger the first function, TDS 
> will trigger the second etc)
> 
> 
> 2018-01-29 21:26 GMT+02:00 Uli Heilmeier <ze...@heilmeier.eu 
> <mailto:ze...@heilmeier.eu>>:
> 
> Thanks a lot Roland.
> 
> Now that I know what to look for packet-sip.c gives a nice example.
> 
> Cheers
> Uli
> 
> Am 29.01.18 um 18:03 schrieb Roland Knall:
> > Short answer: packet_info->layers should get you the list of protocols 
> called before yours. If you iterate, you should
> > see the other protocols before yours. In packet.c:754 you see the code 
> adding to the list. 
> >
> > Not sure though, how stable that interface is. It is pretty in-depth 
> for span, so you should be save to use it, but not
> > sure, if it is official, or if there is another way.
> >
> > cheers
> > Roland
> >
> > On Sun, Jan 28, 2018 at 10:59 PM, Uli Heilmeier <u...@heilmeier.eu 
> <mailto:u...@heilmeier.eu> <mailto:u...@heilmeier.eu 
> <mailto:u...@heilmeier.eu>>> wrote:
> >
> >     Hi all,
> >
> >     TL,DR:
> >     How does a dissector know which dissector called it?
> >
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] How to get calling dissector

[Uli Heilmeier]

Thanks a lot Roland.

Now that I know what to look for packet-sip.c gives a nice example.

Cheers
Uli

Am 29.01.18 um 18:03 schrieb Roland Knall:
> Short answer: packet_info->layers should get you the list of protocols called 
> before yours. If you iterate, you should
> see the other protocols before yours. In packet.c:754 you see the code adding 
> to the list. 
> 
> Not sure though, how stable that interface is. It is pretty in-depth for 
> span, so you should be save to use it, but not
> sure, if it is official, or if there is another way.
> 
> cheers
> Roland
> 
> On Sun, Jan 28, 2018 at 10:59 PM, Uli Heilmeier <u...@heilmeier.eu 
> <mailto:u...@heilmeier.eu>> wrote:
> 
> Hi all,
> 
> TL,DR:
> How does a dissector know which dissector called it?
> 
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] How to get calling dissector

[Uli Heilmeier]

Hi all,

TL,DR:
How does a dissector know which dissector called it?

Long version:
I’m currently implementing a dissector for „Session Multiplex Protocol“ (SMP) 
[1] requested in bug 14110 [2].
The Tabular Data Stream (TDS; MS SQL Server) protocol depends on SMP when using 
the MARS feature [3].

SMP runs on top of TCP and is a session layer protocol. SMP however has no 
identifier to specify the next protocol.
When TDS uses SMP the SMP payload itself is TDS. Resulting in dissector stack: 
Ethernet/IP/TCP/TDS/SMP/TDS.

I want to call the TDS dissector for the SMP payload data only when it was 
called by TDS. Otherwise just display the data as hex.
How can I get the information which dissector called my dissector?

Any ideas are welcome. Thanks!

[1]: https://msdn.microsoft.com/en-us/library/cc219643.aspx
[2]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14110
[3]: 
https://docs.microsoft.com/en-us/sql/relational-databases/native-client/features/using-multiple-active-result-sets-mars

Cheers Uli
___
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] 2.6 branch planning and post-branch changes

[Uli Heilmeier]

> 
>> Renaming protocols to match current reality, e.g. "bootp" to "dhcp" and 
>> "ssl" to "tls".
> 
> The latter makes sense; the former is a little weird, given that, 
> technically, DHCP is a protocol that's implemented with BOOTP options, but if 
> there's not much BOOTP-without-DHCP traffic now, it probably won't bother 
> people that they need to type "dhcp" to refer to BOOTP.
> 

What about having a display filter alias „dhcp“ for „bootp“? This way 
inexperienced users would be able to see DHCP by using „dhcp“ as a filter.

-1 for renaming „bootp"
+/- 0 for renaming „ssl"
___
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] Latest transifex update

[Uli Heilmeier]

Hi,

with today's automated Transifex update the master-2.6 branch lists 2880 
untranslated strings (at least for German). All
strings have been translated in the past.
So it seems there went something wrong.

Can someone check the sync?

Cheers
Uli
___
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] Config files: profiles folder vs. "default" personal folder

[Uli Heilmeier]

With my latest VLAN resolving commit [1] Stig noted that we have some 
inconsistency where we search for personal
configuration files.

Quote:
>We now have files which are:
>
>1. Only loaded from the current profile. This is "hosts" and "ss7pcs".
>2. First loaded from current profile and then loaded from the "Default" 
>profile if not in current profile. This is
>"subnets", "services" and now "vlans".
>3. Only loaded from the "Default" profile. This is "ethers", "ipxnets" and 
>"enterprises.tsv".

Loading hosts from a profile folder depends also on a preference.

As Stig has suggested it would make sense to have one logic for all such files.

Any opinions?

I favour way 2 (first current profile -> fall back to default)

Cheers
Uli


[1]: https://code.wireshark.org/review/c/33387/
___
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] Passwordlist in Wireshark - User feedback wanted

[Uli Heilmeier]

> We would like your feedback on that topic

* Speaking as the "application owner" of Wireshark in our group of companies I 
see no reason to ban Wireshark with such
a function. => +1 to implement it

* Speaking as a former network admin team lead, having a preference to disable 
the tool window would be fine. I've
always tried to protect myself from "acquiring too much" knowledge, like "I'm 
currently only interested in solving your
HTTP perf problem and not in getting your stupid password.

Cheers
Uli
___
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] Release lifetime and version number changes?

[Uli Heilmeier]

+1 for having only two supported stable versions.
One as a „long term support“ branch (e.g. 2.6 at the moment)
and one „normal“ stable (eg. 3.0 atm or next 3.2)

+1 for keeping odd minor numbers for development versions.
Maybe having a monthly rolling release with latests features to have more test 
users would make sense.

Cheers
Uli

> Am 12.04.2019 um 01:54 schrieb Gerald Combs :
> 
> We currently have three active release branches: 3.0, 2.6, and 2.4. This is 
> because we support each release branch for a set amount of time (typically 24 
> months after the initial .0 release) and our last three .0 releases were less 
> than 12 months apart. However, having many active branches can sometimes 
> cause confusion[1] and far fewer people download the "Old Old Stable" release 
> than the "Old Stable" or "Stable" releases. Would it make sense to have only 
> two release branches active at any given time, e.g. by adjusting our release 
> branch lifetimes to "24 months or whenever we have two newer active branches, 
> whichever comes first"?
> 
> We've also been using odd minor numbers for development releases and even 
> minor numbers for stable releases[2] for many years now. We don't make very 
> many development releases and instead tend to have one or more release 
> candidates after branch is created. Would it make sense to drop the even/odd 
> scheme and make the next major release 3.1.0?
> 
> [1] 
> https://ask.wireshark.org/question/8433/why-are-multiple-versions-released-at-once/
> [2] https://wiki.wireshark.org/Development/ReleaseNumbers
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Bug 15709: Segfault on MacOS; help wanted

[Uli Heilmeier]

Hi list,

I'm stumbled over a segfault [1] in Wireshark and I'm currently trying to solve 
it. However I'm totally lost and need
some hints to go on.

The crash is a EXC_BAD_ACCESS when typing or pasting in a malformed string 
(with non-hex characters) as an Initiator
Cookie in the ISAKMP IKEv1 Decryption Table.

Debugging this with lldb shows that ikev1_uat_data_update_cb() of uat_new() is 
called, sets err to "Length of
Initiator's COOKIE must be %d octets (%d hex characters)" and returns FALSE.
However the error message is not displayed and WS crashes in the 
isakmp_init_protocol() function when calling
'memcpy(ic_key, ikev1_uat_data[i].icookie, COOKIE_SIZE);'. As far as I can see 
this is because ikev1_uat_data[i].icookie
is NULL.

A simple workaround would be to check icookie_len before calling memcpy (see 
patch below). But I think the root cause is
in the handling of the UAT.
lldb shows here most of the time assembler code (the qt libs stuff), and I'm 
lost.

Would it make sense to have a post_update_cb() function and check here for the 
input?
What's the difference between update_cb() and post_update_cb()?
Should I look anywhere else?

Any hints welcome how I can debug this.

Thanks & Cheers
Uli

[1]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15709


 patch:

diff --git a/epan/dissectors/packet-isakmp.c b/epan/dissectors/packet-isakmp.c
index c434c23ccc..5f4a09e776 100644
--- a/epan/dissectors/packet-isakmp.c
+++ b/epan/dissectors/packet-isakmp.c
@@ -5861,14 +5861,16 @@ isakmp_init_protocol(void) {
   free_cookie_key, free_cookie_value);

   for (i = 0; i < num_ikev1_uat_data; i++) {
-ic_key = (guint8 *)g_slice_alloc(COOKIE_SIZE);
-memcpy(ic_key, ikev1_uat_data[i].icookie, COOKIE_SIZE);
+if (ikev1_uat_data[i].icookie_len == COOKIE_SIZE) {
+  ic_key = (guint8 *)g_slice_alloc(COOKIE_SIZE);
+  memcpy(ic_key, ikev1_uat_data[i].icookie, COOKIE_SIZE);

-decr = create_decrypt_data();
-memcpy(decr->secret, ikev1_uat_data[i].key, ikev1_uat_data[i].key_len);
-decr->secret_len = ikev1_uat_data[i].key_len;
+  decr = create_decrypt_data();
+  memcpy(decr->secret, ikev1_uat_data[i].key, ikev1_uat_data[i].key_len);
+  decr->secret_len = ikev1_uat_data[i].key_len;

-g_hash_table_insert(isakmp_hash, ic_key, decr);
+  g_hash_table_insert(isakmp_hash, ic_key, decr);
+}
   }
   ikev2_key_hash = g_hash_table_new(ikev2_key_hash_func, ikev2_key_equal_func);
   for (i = 0; i < num_ikev2_uat_data; 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] Bug 15709: Segfault on MacOS; help wanted

[Uli Heilmeier]

Thanks a lot Peter for your help!

> Also if you have not already, build with cmake -DENABLE_ASAN=1. I
> suspect that it might blow up with a use-after-free warning before the
> NULL pointer dereference.

Yes, you're right. After compiling it with -DENABLE_ASAN=1 and 
-DCMAKE_BUILD_TYPE=Debug it fails at:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x0)
frame #0: 0x7fff588c9d89 
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 169
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
->  0x7fff588c9d89 <+169>: movq   (%rsi), %rcx
0x7fff588c9d8c <+172>: movq   (%rsi,%rdx), %r8
0x7fff588c9d90 <+176>: movq   %rcx, (%rdi)
0x7fff588c9d93 <+179>: movq   %r8, (%rdi,%rdx)
Target 0: (Wireshark) stopped.


=
==18967==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 
0x7fff588c9d89 bp 0x7ffee4d3a9c0 sp
0x7ffee4d3a9c0 T0)
==18967==The signal is caused by a READ memory access.
==18967==Hint: address points to the zero page.
#0 0x7fff588c9d88 in _platform_memmove$VARIANT$Haswell 
(libsystem_platform.dylib:x86_64+0x1d88)
#1 0x10e624854 in __asan_memcpy 
(libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x59854)
#2 0x116c36936 in isakmp_init_protocol packet-isakmp.c:5866
#3 0x118e76e4a in call_routine packet.c:247
#4 0x10d8637ec in g_slist_foreach (libglib-2.0.0.dylib:x86_64+0x5c7ec)
#5 0x118e76f59 in init_dissection packet.c:328


So I will have a look at the UAT part.

Cheers
Uli
___
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] German translation issues

[Uli Heilmeier]

Hi Roland

> ", %Ln profile(s) skipped" has been translated with "%1" instead of "%Ln" 
> leading to a display error (%xx must be copied
> 1:1 as Qt uses that to format the values differently)

Fixed

>
> "copy" in the context as noun is translated as "kopieren" when it should be 
> "Kopie". With copy, there is a context
> provided (noun) to allow differentiation between other instances of "copy"

has been fixed by yourself

I haven't been aware about the context info...

Cheers
Uli
___
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] Bug 16294, in_progress?

[Uli Heilmeier]

Hi Jaap,

I’ve set it to IN_PROGRESS as I’m working on a patch. I thought that's what the 
status field was for. ;-)
Change will include support for draft-ietf-idr-segment-routing-te-policy-08 and 
draft-ietf-idr-tunnel-encaps-15.

Cheers
Uli

> Am 27.12.2019 um 20:29 schrieb Jaap Keuter :
> 
> Hi Uli,
> 
> You’ve changed the bug to IN_PROGRESS, do you intend to push a change for 
> this?
> I’ve got one ready, so if you can’t I can.
> 
> Thanks,
> Jaap
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Wiki EditorGroup request

[Uli Heilmeier]

Hi,

Can someone be so kind and add me (UliHeilmeier) to the EditorGroup at 
wiki.wireshark.org?

Thanks!

Cheers
Uli
___
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] Managing Gitlab Issues

[Uli Heilmeier]

Hi list,

I’ve tried to update the instructions to report an issue (fka bug) in the wiki 
[1].

There are some things we need to sort out. (Maybe this has already been done on 
the core list.)

* Do we want to have labels to mark the status of an issue? With Bugzilla we 
had Confirmed, Incomplete, In Progress etc. I would like to have labels for 
status additionally to the existing labels.

* Who should be able to edit issues (e.g. adding labels)? According to Gitlab 
documentation [2] the Reporter role can do it. However the Reporter role also 
allows to see issues which are marked as confidentially.

* It would make sense to have templates for issues [3]. Has anyone already 
prepared this? Otherwise I will create one and submit a MR?

Cheers

[1] https://gitlab.com/wireshark/wireshark/-/wikis/ReportingBugs
[2] https://docs.gitlab.com/ee/user/permissions.html
[3] https://docs.gitlab.com/ee/user/project/description_templates.html
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Managing Gitlab Issues

[Uli Heilmeier]

> Am 04.09.2020 um 14:59 schrieb Dario Lombardo :
> 
> On Fri, Sep 4, 2020 at 1:12 PM Uli Heilmeier  <mailto:ze...@heilmeier.eu>> wrote:
> Hi list,
> 
> I’ve tried to update the instructions to report an issue (fka bug) in the 
> wiki [1].
> 
> There are some things we need to sort out. (Maybe this has already been done 
> on the core list.)
> 
> * Do we want to have labels to mark the status of an issue? With Bugzilla we 
> had Confirmed, Incomplete, In Progress etc. I would like to have labels for 
> status additionally to the existing labels.
> 
> Personally I don't like this. Labels are best to mark the issues as belonging 
> to a component, a version and so on. I don't see the need to stick with 
> gerrit's model, unless we really like it. Again, personally I liked gerrit's 
> labels, but I won't miss it, and I think that model can be left behind.
>  

I'm sorry I was unclear. I’m talking about the Status field of Bugzilla. Not 
Gerrit labels. With Bugzilla a new bug had (normally) the status ‚Unconfirmed‘ 
at the beginning. When someone was able to reproduce the issue the bug had the 
status ‚Confirmed‘. If something was missing (a capture file for example) the 
status was ‚Incomplete‘. When someone was working on a fix the status was ‚In 
Progress‘.
This is currently missing with Gitlab Issues. There is only ‚Open‘ and ‚Closed‘.

Therefore I suggest we use labels to mark the status of an issue.

> 
> * Who should be able to edit issues (e.g. adding labels)? According to Gitlab 
> documentation [2] the Reporter role can do it. However the Reporter role also 
> allows to see issues which are marked as confidentially.
> 
> I'm not sure I got your point. Just a few people (not including the whole 
> core-dev group) have internal access to the project. Just Gerald and a few 
> have. Other code-devs are in a group allowed to merge, but they're not 
> project members. How would you leverage the confidentiality feature?

With Bugzilla I (as a normal contributor) was able to set the status of a bug 
(not limited to my own created ones). Also I was able to correct the 
classification etc. At the moment I’m not able to do this with Gitlab issues. 
When we can have a new group to edit/label issues I’m totally fine. 

>  
> 
> * It would make sense to have templates for issues [3]. Has anyone already 
> prepared this? Otherwise I will create one and submit a MR?
> 
> This would help for sure. Please submit a MR for that.

Will 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] Code of Conduct for our community

[Uli Heilmeier]

Am 05.08.20 um 19:06 schrieb Richard Sharpe:
> On Wed, Aug 5, 2020 at 8:49 AM Uli Heilmeier  wrote:

Thanks for your feedback Richard!

>> As discussed in the last Remote Developer Den meeting I see a Code of 
>> Conduct (CoC) as helpful for our community.
> 
> Why? Nothing is broken at the moment, so nothing needs fixing, AFAICT.

For me this is about improving and not about fixing.

> I would suggest the following alternative approach that the Samba team
> seems to have adopted:
> 
> https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely

The Samba CoC can also be a starting point. I'm missing here a clear 
encouragement for diversity and openness.
The scope should also be a broader (we have ask.wireshark.org and Sharkfest 
etc.).

> As far as I can recall, there have been no instances of the behavior
> the Contributor Covenant seems to protect against, so what is the
> point here?

It defines clear expectations and rules. Of course it can't protect against 
violating the rules (like it is with all
kind of rules and laws).

Cheers
Uli
___
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] GitLab migration update

[Uli Heilmeier]

Am 24.08.20 um 06:33 schrieb Gerald Combs:

> The issue creation script made the repository private in order to avoid rate 
> limiting. If you do this through the web interface, you're presented with a 
> nice, clear warning that you'll sever the relationship of any forked 
> repositories:
> 
> https://docs.gitlab.com/ee/public_access/public_access.html#reducing-visibility
> https://gitlab.com/gitlab-org/gitlab/-/issues/33358
> https://gitlab.com/gitlab-org/gitlab/-/issues/22417
> https://gitlab.com/gitlab-org/gitlab/-/issues/19111
> 
> If you do it from the API there's no warning. Unfortunately this means that 
> if you were proactive an forked https://gitlab.com/wireshark/wireshark then 
> you either need to rename or remove your current repository and fork again. 
> Sorry about the hassle.

You don't have to do this. There is also the option to set "forked from" 
repository with an API call.

With httpie you have to call:
http POST 
'https://gitlab.com/api/v4/projects/%2Fwireshark/fork/7898047?access_token='

7898047 is the ID of https://gitlab.com/wireshark/wireshark

You can create the API Token in your gitlab user profile -> 'Access Tokens'. 
Before the call it could be necessary to
remove the fork relationship (Project settings -> General -> Advanced -> 
'Remove fork relationship').


___
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] Managing Gitlab Issues

[Uli Heilmeier]

> I'm sorry I was unclear. I’m talking about the Status field of Bugzilla. Not 
> Gerrit labels. With Bugzilla a new bug had
> (normally) the status ‚Unconfirmed‘ at the beginning. When someone was able 
> to reproduce the issue the bug had the
> status ‚Confirmed‘. If something was missing (a capture file for example) the 
> status was ‚Incomplete‘. When someone was
> working on a fix the status was ‚In Progress‘.
> This is currently missing with Gitlab Issues. There is only ‚Open‘ and 
> ‚Closed‘.
> 
> Therefore I suggest we use labels to mark the status of an issue.
> 

I still prefer to have some status labels. However as there is no feedback it's 
seems I'm the only one. :-(

> 
> With Bugzilla I (as a normal contributor) was able to set the status of a bug 
> (not limited to my own created ones). Also
> I was able to correct the classification etc. At the moment I’m not able to 
> do this with Gitlab issues. When we can have
> a new group to edit/label issues I’m totally fine. 

I'm also not able to add a existing label (enhancement) to an issue created by 
myself. So it seems there is some setting
denying this.

>> * It would make sense to have templates for issues [3]. Has anyone 
>> already prepared this? Otherwise I will create
>> one and submit a MR?
>>
>>
>> This would help for sure. Please submit a MR for that.
> 
> Will do so.

Templates for FeatureRequest and Bug are active.


___
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] Code of Conduct for our community

[Uli Heilmeier]

All,

As discussed in the last Remote Developer Den meeting I see a Code of Conduct 
(CoC) as helpful for our community.
I've always felt comfortable and welcome in the Wireshark community. But I'm a 
white old man so my view may have some bias.

I propose that we adopt the "Contributor Covenant" version 2 [1] for our 
community.
This is a well established CoC with a good scope (including code review, 
mailing lists, ask.wireshark.org, Sharkfest).

The instance to handel reports should be a team consisting of 3 or 5 well 
accepted community members (not only core
devs). The email address to reach them should be an alias or so 
(repo...@wireshark.org).
We should have a wiki page where the team members are listed (similar to 
node.js [2]).

[3] gives a nice overview of CoC and is a good starting point to read. [4] is a 
scientific paper discussing some aspects
of different CoC.

So, what's your opinion? Any concerns? Any suggestions?

Cheers
Uli

[1] https://www.contributor-covenant.org/version/2/0/code_of_conduct.html
[2] https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md
[3] https://opensource.guide/code-of-conduct/
[4] https://www.win.tue.nl/~aserebre/SANER2017.pdf


___
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] About i18n Translation

[Uli Heilmeier]

> 2. Do the projects in https://www.transifex.com/wireshark/wireshark/ still 
> work like  "12.2.4.5. Internationalization and Translation" of 
> https://www.wireshark.org/docs/wsdg_html_chunked/ChUIQt.html#_source_code_overview
>  says, **each week** translations are automatically synchronized with the 
> source code?

Yes, there is an automatic sync between Transifex and Gitlab repo each Sunday 
for all branches.
___
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] Tweak bug template to get _all_ version info

[Uli Heilmeier]

Created MR for this:
https://gitlab.com/wireshark/wireshark/-/merge_requests/832

Am 03.11.20 um 08:22 schrieb Jaap Keuter:
> Hi,
> 
> Again it’s seems difficult to get people to add _all_ version informalities 
> when filing a bug report. Only the version string is copied then.
> 
> We’ve introduced a “Copy to clipboard’ button on the About Wireshark dialog 
> for this. Can the template be adjusted to direct users to use that button and 
> past the copied information?
> 
> Thanks,
> Jaap
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> 
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Managing Gitlab Issues

[Uli Heilmeier]

Yes, currently normal users have no right to add labels to own created issues.
The FeatureRequest template includes a label. However it is not added when a 
user creates an issue due to the missing rights.

We should:
* give users the right to add labels to their own issues
* give (all or at least regular) contributors the rights
   - to add labels to issues
   - to assign issues to themselves
* create another template for Website issues (I will push a MR for this)

Furthermore I still believe we need some status labels to have a better 
overview of all open issues.

Cheers
Uli

> Am 31.10.2020 um 17:47 schrieb chuck c :
> 
> 
> Public (non-core ?) users do not have access to add labels to an issue.
> Can a template add labels when the issue is created?
> Can there be a template for website corrections/updates?
> 
> https://www.wireshark.org/lists/wireshark-dev/201809/msg00090.html
> 
> 
> 
>> On Sat, Sep 19, 2020 at 6:08 AM Uli Heilmeier  wrote:
>> 
>> > I'm sorry I was unclear. I’m talking about the Status field of Bugzilla. 
>> > Not Gerrit labels. With Bugzilla a new bug had
>> > (normally) the status ‚Unconfirmed‘ at the beginning. When someone was 
>> > able to reproduce the issue the bug had the
>> > status ‚Confirmed‘. If something was missing (a capture file for example) 
>> > the status was ‚Incomplete‘. When someone was
>> > working on a fix the status was ‚In Progress‘.
>> > This is currently missing with Gitlab Issues. There is only ‚Open‘ and 
>> > ‚Closed‘.
>> > 
>> > Therefore I suggest we use labels to mark the status of an issue.
>> > 
>> 
>> I still prefer to have some status labels. However as there is no feedback 
>> it's seems I'm the only one. :-(
>> 
>> > 
>> > With Bugzilla I (as a normal contributor) was able to set the status of a 
>> > bug (not limited to my own created ones). Also
>> > I was able to correct the classification etc. At the moment I’m not able 
>> > to do this with Gitlab issues. When we can have
>> > a new group to edit/label issues I’m totally fine. 
>> 
>> I'm also not able to add a existing label (enhancement) to an issue created 
>> by myself. So it seems there is some setting
>> denying this.
>> 
>> >> * It would make sense to have templates for issues [3]. Has anyone 
>> >> already prepared this? Otherwise I will create
>> >> one and submit a MR?
>> >>
>> >>
>> >> This would help for sure. Please submit a MR for that.
>> > 
>> > Will do so.
>> 
>> Templates for FeatureRequest and Bug are active.
>> 
>> 
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Calling a dissector: Type for data parameter

[Uli Heilmeier]

With MR 2706 [1] the MQTT dissector calls now subdissectors with 
call_dissector_with_data() [2]. Previously this was call_dissector().

With this change the JSON dissector crashes WS with a memory access segfault 
(while using MQTT decode topic as option).
This is because for JSON we expect http_message_info_t for data pointer [3]. 
MQTT hands over a pointer to a char array (topic_str) for data.

How do we handle data type for the data parameter pointer? Would it make sense 
to compare at least the size of data with the size of http_message_info_t?

I don’t know any way to check the data type of a pointer address location.

Cheers
Uli

[1]: https://gitlab.com/wireshark/wireshark/-/merge_requests/2706/
[2]: 
https://gitlab.com/wireshark/wireshark/-/merge_requests/2706//diffs#07171e000b3caaabee32ab5dc04a5d28efbaaae3_755_755
[3]: 
https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-json.c#L221
___
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

[Uli Heilmeier]

Makes sense for me. I will change the MQTT dissector to call 
call_dissector_with_data() only for sparkplug payload.

> Am 29.05.2021 um 09:12 schrieb Anders Broman  >:
> 
> Hi,
> Shouldn't the caller be calling with the right data type or NULL? So a bug in 
> the MQTT disector?
> Regards
> Anders
> 
> 
> Den lör 29 maj 2021 09:07Uli Heilmeier  > skrev:
> With MR 2706 [1] the MQTT dissector calls now subdissectors with 
> call_dissector_with_data() [2]. Previously this was call_dissector().
> 
> With this change the JSON dissector crashes WS with a memory access segfault 
> (while using MQTT decode topic as option).
> This is because for JSON we expect http_message_info_t for data pointer [3]. 
> MQTT hands over a pointer to a char array (topic_str) for data.
> 
> How do we handle data type for the data parameter pointer? Would it make 
> sense to compare at least the size of data with the size of 
> http_message_info_t?
> 
> I don’t know any way to check the data type of a pointer address location.
> 
> Cheers
> Uli
> 
> [1]: https://gitlab.com/wireshark/wireshark/-/merge_requests/2706/ 
> 
> [2]: 
> https://gitlab.com/wireshark/wireshark/-/merge_requests/2706//diffs#07171e000b3caaabee32ab5dc04a5d28efbaaae3_755_755
>  
> 
> [3]: 
> https://gitlab.com/wireshark/wireshark/-/blob/master/epan/dissectors/packet-json.c#L221
>  
> 
> ___
> Sent via:Wireshark-dev mailing list  >
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> 
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> 
>  mailto:wireshark-dev-requ...@wireshark.org 
> ?subject=unsubscribe
> ___
> Sent via:Wireshark-dev mailing list  >
> Archives:https://www.wireshark.org/lists/wireshark-dev 
> 
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev 
> 
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe 
> 

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Status label for issues

[Uli Heilmeier]

Am 24.04.21 um 13:31 schrieb Jirka Novak:

>   I propose one more kind of label/labels. It is more about interaction
> with reporter of the issue - "waiting for response". There are many
> issues opened for years where last message is request for sample or more
> information. I think that if such issue is opened for years with no
> reaction, it is useless and should be closed.

Yes, I fully agree. Great idea.
___
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

[Uli Heilmeier]

Am 26.04.21 um 11:49 schrieb Roland Knall:
> 
> I suggest we create a wiki page for that discussion first, and if we can 
> figure that out create the labels. 
> 

I've created 
https://gitlab.com/wireshark/wireshark/-/wikis/Discussion-Issues-Labels to 
discuss labels for 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] Status label for issues

[Uli Heilmeier]

I see your point.

We had this status field at Bugzilla and it worked sufficiently well (at least 
for dissector bugs).

At the moment it is very hard to see if someone has already had a look at an 
issue, if she/he was able to reproduce it,
if a sample capture is missing etc.

Regarding additional tooling I will have a closer look at triage-ops the next 
days.


Am 27.04.21 um 09:06 schrieb Roland Knall:
> 
> I have especially an issue with the new ws-status labels and their 
> transitions. Judging from a company, where we have
> about 50 developers whose daily bread it is to transition properly in Jira, I 
> cannot see an open-source project with no
> additional tooling to properly transition between e.g. unconfirmed => 
> confirmed => in-progress.
> 
> That is my main concern. 
___
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

[Uli Heilmeier]

Diff between current and proposal list:

- incident
- question
- cli::tshark
+ ui::tshark
- ui::gtk
- version::0.x
- version::1.0
- version::1.10
- version::1.12
- version::1.2
- version::1.4
- version::1.6
- version::1.8
- version::2.0
- version::2.2
- version::2.4
- version::2.6
- version::3.0
+ version::outdated
+ ws-status::unconfirmed
+ ws-status::confirmed
+ ws-status::waiting-for-response
+ ws-status::in-progress
+ ws-status::invalid
+ ws-status::wontfix
+ ws-status::fixed
+ ws-status::duplicate

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


Am 26.04.21 um 23:13 schrieb Roland Knall:
> The list seems to be duplicated with the lists from above. Anyhow, it seems 
> we just have too many labels already, and I
> am still not convinced that they can be used properly and consistently at 
> this point
> 
> I would clean up the proposal list first, then from there figure out which 
> items we need on the list
> 
> cheers
> Roladn
___
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

[Uli Heilmeier]

Am 27.04.21 um 09:06 schrieb Guy Harris:

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

Yes, you're totally right. os::windows, os::macos, os::linux and os::other 
should be enough.

Currently we have os::unix with the description "AIX, HP-UX, Solaris, and other 
Unices"
___
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

[Uli Heilmeier]

Am 27.04.21 um 09:28 schrieb Guy Harris:
>> 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).

Yes, I'm aware of it. This is something I've already mentioned in my first 
mail. For this label only automation (bot)
makes sense. As long as there is no automation we will have a closed issue with 
a false state.

For the Gitlab API there is no difference between manually closed issued and 
issues marked as duplicate.
Both have the state closed. Marked as duplicate issues have a additional note 
with text "marked this issue as a
duplicate of #iid".
___
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] Bugzilla -> Gitlab failed migration

[Uli Heilmeier]

Hi,

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

Cheers
Uli

___
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] Closing issue 15128

[Uli Heilmeier]

Hi List,

Would someone who has the necessary rights please be so kind and close issue 
15128 [1]?
I am missing the necessary permission.

Cheers
Uli


[1] https://gitlab.com/wireshark/wireshark/-/issues/15128
___
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] Status label for issues

[Uli Heilmeier]

Hi everyone,

For issues (especially bugs) I really miss the status field which was available 
with Bugzilla.

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.

Scoped labels are mutually exclusive.

Setting the label requires manual interaction. So yes, this label won't reflect 
the real state when the issue is closed
automatically (for example when a MR referencing this issue is merged or when 
the issue is marked as an duplicate).

Furthermore a normal user is not allowed to set labels at the moment. Having 
the label in the issue template won't add
the label when opening an issue.

Maybe we need another bot (like triage-ops [2]) to set labels automatically.
Does anyone have experience with triage-ops bot (or any other bot managing 
issues) and Gitlab and can share some insides?

Any objections? Comments are very welcome.

Cheers
Uli

[1]: 
https://docs.gitlab.com/ee/user/project/labels.html#workflows-with-scoped-labels
[2]: https://gitlab.com/gitlab-org/quality/triage-ops
___
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] Default value for new UAT field

[Uli Heilmeier]

With commit d38de4c0 [1] a new field for the I/O graphs UAT has been 
introduced. With this using io_graphs settings
generated with 3.4 (or before) fails in 3.6 [2].

Before releasing 3.6.0 I really want to fix this issue by setting a default 
value when the field is missing in the
io_graphs file. However, I have no idea how to do this.

I've looked at all the uat_new(), uat_load() etc. functions without getting an 
idea.

Can someone help me and point me in the right direction? Thanks!

Cheers
Uli


[1]: 
https://gitlab.com/wireshark/wireshark/-/commit/d38de4c03e258d56f5b74d27d3d2d47d4cd524eb
[2]: https://gitlab.com/wireshark/wireshark/-/issues/17623
___
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] tsharkd: possible to start capture ?

[Uli Heilmeier]

I see the list of available commands here:
https://wiki.wireshark.org/sharkd-JSON-RPC-Request-Syntax.md#status >
which is very cool but they only refer to loaded files, not live
analysis ? is that possible ? how hard would it be ?


Sharkd doesn't support starting/stopping a live capture at the moment.



NB: I've tried to go on irc (freenode) but #wireshark seemed awfully
quiet (~20 persons and no official topic) Same on libra. I couldn't
find any mention of the wireshark IRC channel on the wiki/website even
though I've used it several times in the past and it was quite
helpful. Has it moved somewhere else ? matrix maybe (please let it be
matrix :) ) ? Did I miss a reference somewhere ?


There is no "official" IRC channel. The existing one has "moved" to Libera (s. also 
https://www.wireshark.org/lists/wireshark-dev/202106/msg00041.html).


For questions there is https://ask.wireshark.org. Maybe there will be a "official" 
Discord server in the "future".

Cheers
Uli
___
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] Unable to manually create a MR

[Uli Heilmeier]

Hi Dario


Hi list,
my regular workflow is to push on a branch on my fork, then go to the main merge requests page, where I am proposed for 
creating a new merge request. This works as expected.
However if I click on "new merge request" I land on a page where the source and destination branch can be selected. The 
weird thing is that I expected to be able to select a branch from my fork, while I can only choose the main repo. Is 
something wrong happening on gitlab.com  or is it happening to my memory?


I have the same behavior. I'm not able to switch to my repo when using the "New merge request" button on 
https://gitlab.com/wireshark/wireshark/-/merge_requests.


My workflow: Going to the branches of my repo (https://gitlab.com//wireshark/-/branches) and use the "Merge 
request" button of the branch I want to merge. After clicking "Change branches" I can select the wireshark/wireshark 
master repo and branch as target.


Cheers
Uli

___
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 User's Guide error

[Uli Heilmeier]

Thanks Morten for reporting this.

Fixed in !6114

Am 02.02.22 um 17:23 schrieb Morten Brørup:

Dear Richard Sharpe, Ed Warnicke, Ulf Lamping,

Chapter 7.5 in the Wireshark User's Guide error (https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html 
) says:


TCP Keep-Alive

Set when the segment size is zero or one, the current sequence number is one byte less than the next expected sequence 
number, and any of SYN, FIN, or RST are set.


It should say:

TCP Keep-Alive

Set when the segment size is zero or one, the current sequence number is one byte less than the next expected sequence 
number, and none of SYN, FIN, or RST are set.


Please refer to the TCP packet dissector source code for confirmation:

https://github.com/boundary/wireshark/blob/master/epan/dissectors/packet-tcp.c#L950 



Med venlig hilsen / kind regards

*Morten Brørup*

CTO

*SmartShare Systems A/S*

Tonsbakken 16-18

DK-2740 Skovlunde

Denmark

Office  +45 70 20 00 93

Direct  +45 89 93 50 22

Mobile +45 25 40 82 12

m...@smartsharesystems.com 

www.smartsharesystems.com 


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Crash in RDP/EGFX dissector

[Uli Heilmeier]

Hi Christian,

> 1. Is this issue known? I tried to look it up on gitlab but I did not
> find anything relevant. Should I file an issue on gitlab?

Yes, please open a new issue for this using the bug template. Please attach a 
sample capture to reproduce the bug.

> 2. Can the EGFX decoder be turned off? I need the decoder for virtual
> channels though.

Yes. EGFX dissector can be disabled. In the UI: Analyze -> Enabled Protocols -> 
Search for EGFX

Cheers
Uli

___
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