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

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:

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

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

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

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,

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

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:

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

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: >> &g

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

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

[Wireshark-dev] Release process: Transifex Sync

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

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

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

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

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

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

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 >

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

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: --- I

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

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,

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

he 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 ni

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

gt; 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? >

[Wireshark-dev] How to get calling dissector

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

Re: [Wireshark-dev] 2.6 branch planning and post-branch changes

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

[Wireshark-dev] Latest transifex update

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

[Wireshark-dev] Config files: profiles folder vs. "default" personal folder

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

Re: [Wireshark-dev] Passwordlist in Wireshark - User feedback wanted

> 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

Re: [Wireshark-dev] Release lifetime and version number changes?

+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

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

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

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

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

Re: [Wireshark-dev] German translation issues

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

Re: [Wireshark-dev] Bug 16294, in_progress?

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

[Wireshark-dev] Wiki EditorGroup request

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

[Wireshark-dev] Managing Gitlab Issues

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,

Re: [Wireshark-dev] Managing Gitlab Issues

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

Re: [Wireshark-dev] Code of Conduct for our community

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

Re: [Wireshark-dev] GitLab migration update

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

Re: [Wireshark-dev] Managing Gitlab Issues

> 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

[Wireshark-dev] Code of Conduct for our community

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"

Re: [Wireshark-dev] About i18n Translation

> 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

Re: [Wireshark-dev] Tweak bug template to get _all_ version info

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

Re: [Wireshark-dev] Managing Gitlab Issues

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

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

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

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

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

Re: [Wireshark-dev] Status label for issues

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

Re: [Wireshark-dev] Status label for issues

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.

Re: [Wireshark-dev] Status label for issues

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

Re: [Wireshark-dev] Status label for issues

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 +

Re: [Wireshark-dev] Status label for issues

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.

Re: [Wireshark-dev] Status label for issues

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

[Wireshark-dev] Bugzilla -> Gitlab failed migration

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

[Wireshark-dev] Closing issue 15128

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] Status label for issues

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.

[Wireshark-dev] Default value for new UAT field

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.

Re: [Wireshark-dev] tsharkd: possible to start capture ?

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

Re: [Wireshark-dev] Unable to manually create a MR

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

Re: [Wireshark-dev] Wireshark User's Guide error

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

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

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