Re: [Wireshark-dev] RTP player on Windows/Qt 6.x do not play any sound

[Jirka Novak]

Hi,

   When Wireshark 4.0.0 was released, users reported 
https://gitlab.com/wireshark/wireshark/-/issues/18413. I verified it and 
it really happens, but I have no idea why:


1) It looks that Qt 6.x is the reason. Build with Qt 5.x works fine. But 
Qt 6.x code for audio play is very different because of Qt 6.x 
Multimedia API changes.


2) Same code for Qt 6.x works on Linux and probably on Mac, just Win32 
do not work. On the other hand I found no #ifdef WIN32 in related code. 
So probably Qt 6.x on Windows is more sensitive to something.


3) I tested Qt 6.2.3 (used for production) and 6.3.1 in my development 
environment. No difference.


4) I checked Qt bug database and found no related issues.

5) I tested v4.0.0 tag and master, none of it works. There is high 
probability that it do not work on Windows with Qt 6.x for longer period 
and I didn't noticed it - I'm mainly developing on Linux.


6) All other and audio related functions works fine so it looks that the 
wireshark code is correct.


By fortune, I found it. Multimedia framework of Qt6 obviously process 
audio slightly different way on Win32 then on other platforms. As 
consequence, it changes states of multimedia objects and sends events 
different way. It triggered race condition on Win32 which randomly 
caused observed misbehaving.


Best regards,

Jirka Novak

___
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] RTP player on Windows/Qt 6.x do not play any sound

[Jirka Novak]

Hi,

  When Wireshark 4.0.0 was released, users reported 
https://gitlab.com/wireshark/wireshark/-/issues/18413. I verified it and 
it really happens, but I have no idea why:


1) It looks that Qt 6.x is the reason. Build with Qt 5.x works fine. But 
Qt 6.x code for audio play is very different because of Qt 6.x 
Multimedia API changes.


2) Same code for Qt 6.x works on Linux and probably on Mac, just Win32 
do not work. On the other hand I found no #ifdef WIN32 in related code. 
So probably Qt 6.x on Windows is more sensitive to something.


3) I tested Qt 6.2.3 (used for production) and 6.3.1 in my development 
environment. No difference.


4) I checked Qt bug database and found no related issues.

5) I tested v4.0.0 tag and master, none of it works. There is high 
probability that it do not work on Windows with Qt 6.x for longer period 
and I didn't noticed it - I'm mainly developing on Linux.


6) All other and audio related functions works fine so it looks that the 
wireshark code is correct.


Any ideas or advices are welcomed.

Best regards,

Jirka Novak
___
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 extcap "API"

[Jirka Novak]

Hi,

  I drawn attached diagram. It can became part of developers doc when 
finished. Please, comment it.



Wireshark is the one who creates command line for extcap - name of
binary and its parameters. This information should be passed to helper
and it will run command line. How to pass this information to helper?


I think just appending extcap binary and commandline after "--" helper
commandline argument is all that is needed.


Yes, it makes sense.


How Wireshark will control helper?
We can't use signals on Win32. So pipe or windows events?


I think single character (e.g. 'q' for graceful termination, and 't'
for termination) write to a pipe is all that is needed. The pipe can
be duplex as it will be Windows only.


I think wireshark do not need to distinguish which phase of shutdown is 
requested because wireshark do not know whether extcap requires/supports 
it. Therefore it would send 'q' and later 't' for every extcap. It looks 
useless for me.
I think that just shutdown should be requested (e.g. by QUIT word as for 
dumpcap) and helper will send signal and then terminate the process.
Of course, wireshark must wait for helper termination and it can take a 
little more than 30 seconds (timeout for graceful shutdown).

Duplex pipe looks useless to me for same reason.

Best regards,

Jirka

ws-capture_graceful_shutdown.dia
Description: application/dia-diagram
___
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 extcap "API"

[Jirka Novak]

Hi,


On Tue, Aug 23, 2022 at 6:24 PM Jirka Novak  wrote:

The problem with GenerateConsoleCtrlEvent() is that the caller has to
be attached to the target process console. While we could technically
do so, it requires freeing any already open console because process
can be attached to at most one console. The pretty much only sane
solution to the problem is to have a helper program between Wireshark
and extcap.

The helper would simply spawn extcap with provided parameters and
accept commands from Wireshark e.g. on pipe. The commands would be to
gracefully terminate (CTRL_C_EVENT or CTRL_BREAK_EVENT) and forcefully
terminate (TerminateProcess()). Note that the helper must not be
forcefully terminated as it would leave the extcap running.

While far from ideal, I think the helper is the only sensible
approach. Note that GLib gspawn-win32-helper does something different,
so going back to the GLib helper is not what this is all about.


Even I understand reasons, it looks to me very complex. I'm sorry, but
my Win32 skills are too low to make it.


Nobody says that you have to write it yourself. I understand your
desire to have things available quickly, but I believe this should be
part of the gradual extcap refinement that is ongoing (and led to
seemingly unrelated changes like the leaking handles fixes, GLib event
loop integration and significant mmdbresolve speedup) and not just
slapped together.


Yes, I was looking to "quick" solution as I updated extcap to require 
graceful shutdown and it is crossplatform. *nix world is solved and I'm 
working mainly on it, so I can wait with Windows side.

I want to help, if I'm capable of it.

I agree with you, that it makes sense to invest effort to better and 
scalable solution. Lets focus on it.


There is my view of discussed proposal:

wireshark(1) - something(2) - helper(3) - signals(4) - extcap(5)

(1) Wireshark should be able to start extcap. Wireshark must be able to 
query for parameters of a extcap and should support control pipes (UI 
stuff, works nowadays).
(2) We are looking for any solution there. It can be pipe as for dumpcap 
nowadays, but other options are welcomed.
(3) helper is responsible for extcap control. On Win32 it should handle 
console stuff and allows us to use signals between helper and extcap on 
Win32.

(4) *nix or Win32 console signals are used there
(5) Extcap should be simple and we prefer to use OS specific features - 
signals for graceful shutdown. Extcap can be written in any language, 
can be single or multiplatform. Extcap should be modified if and only if 
it requires graceful shutdown.


Points to discuss:
It the diagram complete?
I'm not sure about dumpcap. There is dumpcap started for every extcap, 
which reads data from extcap and pass it to wireshark.

Does helper staff involve it?

Helper will help us with solving Win32 stuff. Do we need it just on 
Windows or on every platform?
For *nix it is useless I think, but using same approach on every 
platform can be useful.


There is negotiation between wireshark and extcap before extcap is 
started - it provides wireshark with name of extcap, supported 
interface, required parameters...

I think it would stay as it is. So helper will not be used there.

When extcap prints anything to STDOUT or STDERR, it is passed to 
Wireshark (there are extcap console works running). STDERR is shown as 
error/information to a user when extcap is finished. We must pass this 
thru helper.

How helper's STDOUT/STDERR will be handled?

Extcap can support control pipes. They are passed to extcap as parameters.
I think that control pipes will bypass helper. I mean parameters/names 
of pipes will be passed thru helper, but helper will not 
open/close/touch control pipes.


Wireshark is the one who creates command line for extcap - name of 
binary and its parameters. This information should be passed to helper 
and it will run command line. How to pass this information to helper?
I'm afraid that pass it as command line parameters can create issues - 
e.g. same parameter name for helper (it needs some) and for extcap, 
special character escaping, ...

So I propose some other way, but I have no proposal.

How Wireshark will control helper?
We can't use signals on Win32. So pipe or windows events?

What about writing notes/discussed points to a document/wiki?

Best regards,

Jirka
___
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] Missing text2pcap-scanner.l in repository

[Jirka Novak]

Hi,


    By chance I noticed that there is text2pcap-scanner.c which is
based
on text2pcap-scanner.l, but the file is not in repository.
    It was there, but was removed.

    Was removal intended?


Yes, ui/text_import_scanner.l now handles processing both for text2pcap 
and for the "Import from Text" feature within the GUI, so that they 
share code and functionality doesn't get out of alignment. There's a 
large set of text2pcap changes mentioned in the release notes for 4.0


I see, thank you for explanation.

Best regards,

Jirka

___
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] Missing text2pcap-scanner.l in repository

[Jirka Novak]

Hi,

  By chance I noticed that there is text2pcap-scanner.c which is based 
on text2pcap-scanner.l, but the file is not in repository.

  It was there, but was removed.

  Was removal intended?

Best regards,

Jirka
___
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 extcap "API"

[Jirka Novak]

Hi,

Adding another helper may be helpful, as it would probably gives us 
greater control, and maybe also solve the "helper-script" issue in the 
future by putting that stuff inside Wireshark? I am just wondering if it 
is worth the effort. We can obviously strive for a perfect - no user 
interaction required - solution, but do we really need to be perfect here?


In my experience, as long as we can solve the real issue - the zombie 
processes - and have minimal interaction by the creators of the original 
extcaps we should be fine. Now as I understand it, we can achieve that 
at some level with one of the proposed solutions above, just not in an 
ideal way, right?


I wrote my notes and thoughts in previous email.

I am fine with having developers adapt their script, as long as there is 
some form of compatibility mode, and maybe some warning displayed before 
starting a non-converted extcap


API with pipe is backward compatible. Therefore non-converted extcaps 
can run as before.
I just think that warning about non-converted extcap is not required. a 
extcap was working before, without graceful shutdown, therefore it is 
not required for the extcap. When author learns that graceful shutdown 
is available and is useful for the extcap, they can adapt it.

But it is optional from my point of view.

Best regards,

Jirka
___
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 extcap "API"

[Jirka Novak]

Hi,


What do you think about that options?


I have no idea why you didn't even consider sending CTRL_BREAK_EVENT
using GenerateConsoleCtrlEvent() as a graceful shutdown mechanism on
Windows. Wireshark creates all extcaps with a hidden console window
(CREATE_NEW_CONSOLE and SW_HIDE flags set).

CTRL_BREAK_EVENT is really simple to handle on extcap side, as it only
requires calling SetConsoleCtrlHandler() to register a handler. The
handler will be called in separate thread (unlike UNIX signals), but
the issues related to the separate thread are exactly the same in any
of the three methods you proposed. Registering handler is really an
opt-in, as the default handler simply terminates the process.


I'm sorry, my understanding was it is in !2063. I was wrong, I will try it.


The problem with GenerateConsoleCtrlEvent() is that the caller has to
be attached to the target process console. While we could technically
do so, it requires freeing any already open console because process
can be attached to at most one console. The pretty much only sane
solution to the problem is to have a helper program between Wireshark
and extcap.

The helper would simply spawn extcap with provided parameters and
accept commands from Wireshark e.g. on pipe. The commands would be to
gracefully terminate (CTRL_C_EVENT or CTRL_BREAK_EVENT) and forcefully
terminate (TerminateProcess()). Note that the helper must not be
forcefully terminated as it would leave the extcap running.

While far from ideal, I think the helper is the only sensible
approach. Note that GLib gspawn-win32-helper does something different,
so going back to the GLib helper is not what this is all about.


Even I understand reasons, it looks to me very complex. I'm sorry, but 
my Win32 skills are too low to make it.


The proposal described above combines two approaches - windows signals 
and windows pipe.
What I see as missing in discussion is that even extcap will receive 
"just" windows signal, extcap must be adapted to handle graceful 
shutdown. And sequence will be:


wireshark - pipe - helper - signal - extcap

and to achieve it, we have to modify wireshark, write helper and modify 
extcap.
Extcap have to be adapted only if it requires graceful shutdown. But if 
it requires it, it must be adapted. If it will not be adapted (do not 
require graceful shutdown), it will be terminated as nowadays.


Won't be easier to say, that when author have to modify extcap, they 
will use the pipe?
Yes, it is a little more work on extcap side, but it must be touched 
anyway. With pipe we will save a lot of effort on wireshark/helper and 
complexity of overall solution will be much lower.


Proposal with pipe I made is backward compatible so when extcap is not 
modified to support graceful shutdown, it do not expose support of pipe. 
Therefore wereshark do not create pipe, do not pass it to extcap and 
terminate it as before.


One more note...
*nix world use signals and graceful shutdown is already implemented on 
wireshark side. When extcap needs graceful shutdown, it should be 
modified to process SIGTERM.
If the extcap should work on Windows too, extcap must support Windows 
signals CTRL_BREAK_EVENT in addition to SIGTERM. The code is similar, 
but there are differences so code must support two ways how to stop it.
If we will use pipe, it can be used on *nix and Windows world same way 
(except #ifdef to use correct API calls). Isn't it better?


I imagine that wireshark will work in that case this ways:
When shutdown of extcap is requested:
1) If pipe is supported, ask extcap for graceful shutdown. When timer 
expires, kill/terminate extcap.

2) If pipe is not supported, kill/terminate extcap immediately.

Best regards,

    Jirka Novak
___
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 extcap "API"

[Jirka Novak]

Hi,


3) It makes sense to me even I didn't tried it yet. My understanding of
documentation is that 3) is more preferred in Win32 world.
I see important that name of event must be agreed between wireshark and
extcap. E.g. if generic "Wireshark_shutdown" is used, it shutdowns every
extcap including ones called from different wireshark application. I
think it should not work this way.
Name of Event can be new parameter for extcap, but it requires cmd line
change.
We can try to derive name of Event from filename/pipe to which extcap
writes output. It is different value for every wireshark/extcap
combination. It do not require any changes on command line.
I found no other dependency for use of Events. It looks promising to me.


I don't like this idea because it requires too much effort on the
extcap side to implement just shutdown (the control pipe atleast could
be extended with other uses).


I think so.


On the other hand 2) depends on support on extcap side, but proposed
library solves it.


You assume every extcap developer will happily use the library, but
there are valid reasons not to: license (extcap does not have to be GPL
compatible) and language.


I was not aware of this. Therefore documentation should describe details 
for developers.



What do you think about that options?


I have no idea why you didn't even consider sending CTRL_BREAK_EVENT
using GenerateConsoleCtrlEvent() as a graceful shutdown mechanism on
Windows. Wireshark creates all extcaps with a hidden console window
(CREATE_NEW_CONSOLE and SW_HIDE flags set).

CTRL_BREAK_EVENT is really simple to handle on extcap side, as it only
requires calling SetConsoleCtrlHandler() to register a handler. The
handler will be called in separate thread (unlike UNIX signals), but
the issues related to the separate thread are exactly the same in any
of the three methods you proposed. Registering handler is really an
opt-in, as the default handler simply terminates the process.


I'm sorry, my understanding was it is in !2063. I was wrong, I will try it.

Best regards,

Jirka
___
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 extcap "API"

[Jirka Novak]

Hi,


One of the benefits of the extcap-cli is, that we can and currently do, send an 
API version to the extcap utility which would allow breaking changes while 
still enabling a compatibility mode for older versions. Because of that, I 
think 2 would be an ideal scenario, just define the response to the API call.

1) is not an option. We have extcaps implemented in C, Python, Powershell, 
Delphi, Go, I even know of one implemented as windows batch script. Only a 
limited version of them would be able to implement the window reliably. Also, 
the general idea for extcap utilities is, that they are universally usable 
across platforms, this dependency is a bit too much.

So it is either between 2) or 3) and from my POV we should choose the option 
the promises to be more reliable, no matter about changing the extcap side of 
things.

One thing though. Whatever the solution, we should try to provide a „don’t 
care“ mode. Otherwise most developers will have to die be into cross-Plattform 
development stuff, and as most external extcaps I know about are written by 
sysadmins or internal devs for very specific usecases, I fear that might turn 
people off from using the api in the first place.


You mention one point of view I missed - many different languages/tools 
to create extcap. I think that in this case 2) is the only option.
In addition, I'm afraid that 2) should be used for *nix systems and for 
Windows too.
Now we use 1) for *nix systems and we are thinking about 2) for Windows. 
Even it was clear and OK to me before, now I see it as too complex - two 
approaches, based on OS.
I know that 1) (signals) is common in *nix world and we can use it, I 
think than new approach should allow us to use it in any OS.


Best regards,

Jirka Novak

___
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 extcap "API"

[Jirka Novak]

Hi,


On Sat, Aug 6, 2022 at 1:09 PM Jirka Novak  wrote:

Extcap API:
i)  When extcap is started, dumpcap pass name of pipe to it and where it
expects captured data.
ii)  STDOUT/STDERR is used to report messages/errors of extcap to
wireshark, but it is shown/evaluated at the end of capture which
triggers e.g. #17827. STDIN is closed/not used.


STDOUT/STDERR is now (!7673 [1]) read during capture. STDOUT is
ignored, like it always was. STDERR is collected for later use.


It works, thank you.


Now I want to implement graceful shutdown. I mean that wireshark
notify extcap it should end, cleanup and terminates. If extcap do not
finish graceful shutdown in time (timer), it is killed as before.


I checked latest changes in master and I made additional research... I 
see multiple options how to implement graceful shutdown and I propose we 
should agree on common direction or at least discuss options.


Lets split the issue in two parts - *nix like systems and Windows/Win32 API.

For *nix like systems changes from !7673 works fine. SIGTERM is send 30 
seconds before SIGKILL is sent. So extcap has 30 seconds for graceful 
shutdown. If the shutdown is faster than 30 seconds, it makes no issue 
to wireshark (no 30 seconds UI hang or so).
If extcap do not require graceful shutdown or do not support it, SIGTERM 
is not handled and it will kill extcap immediately.


In !5489 I made extcap/extcap-base.[ch] library calls which allows any C 
based extcap to use it. But I plan to extract it to different MR...


For Windows/Win32 we still have no solution. There are two MRs -
!2063 and !5489.
1) !2063 tries to use Win32 WM_CLOSE signal.
2) !5489 tries to use named pipe to pass information from wireshark to 
extcap (same way as wireshark controls dumpcap nowadays).
3) I'm non Win32 specialist, but it looks there is another option - 
Windows Event Objects (see 
https://docs.microsoft.com/en-us/previous-versions/ms811896(v=msdn.10)?redirectedfrom=MSDN#ucmgch09_topic3)


My thoughts...

I think that *nix part is solved, just extcap side library is missing. 
We must focus on Windows part.


My goal is to prepare library calls (at least for C) which will hide 
details for developer and there will be just callback and/or global flag 
that extcap should finish its work. Extcap author can use it if graceful 
shutdown is required.


1) Looks limiting to me, because my understanding is that it requires 
that extcap must create hidden window to be able to receive WM_xxx signals.
I'm afraid it can be limiting/additional complexity for extcaps. I can't 
evaluate whether it has any other consequences for extcap code.


2) It works, but it requires change how command line is parsed, because 
name of named pipe must be passed to extcap. !5489 implements it as new 
pipe even there are control pipes which are already processed by API. 
Patch can be modified in that area.

Library for C is proposed and it automates cli parsing.

3) It makes sense to me even I didn't tried it yet. My understanding of 
documentation is that 3) is more preferred in Win32 world.
I see important that name of event must be agreed between wireshark and 
extcap. E.g. if generic "Wireshark_shutdown" is used, it shutdowns every 
extcap including ones called from different wireshark application. I 
think it should not work this way.
Name of Event can be new parameter for extcap, but it requires cmd line 
change.
We can try to derive name of Event from filename/pipe to which extcap 
writes output. It is different value for every wireshark/extcap 
combination. It do not require any changes on command line.

I found no other dependency for use of Events. It looks promising to me.

Pros of 1) and 3) is that Wireshark do not have to care whether extcap 
supports it. If it does, it will process signal or event. If it doesn't, 
Wireshark can send them and nothing bad happens to wireshark nor extcap.
On the other hand 2) depends on support on extcap side, but proposed 
library solves it. In other words, if extcap do not expose support for 
it, wireshark do not call it and no graceful shutdown is issued.


What do you think about that options?

Best regards,

    Jirka Novak
___
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 UDP dissector finds RTP protocol

[Jirka Novak]

Dear Chandramohan,

I am curious  to understand how wireshark detects RTP protocol using UDP 
dissector


There is the procedure (see epan/dissectors/packet-udp.c: 
decode_udp_ports()). It works for any UDP based protocol, just for RTP 
are a few additional setting.


Procedure how to use wanted sub-dissector for UDP based traffic (I'm 
referring RTP):


1) There is record that the traffic is part of existing conversation and 
it is RTP protocol. Conversation can be recorded as sourceIP:sourcePort 
or destinationIP:destinationPort and combination.
Conversations are created by other dissectors which see signalization 
that says that the traffic is RTP. E.g. SIP/SDP, H.323, SKINNY and others.


2) Table with well known ports for protocols (e.g. 53 = DNS) is checked. 
There is no record for RTP, but a user can use 'Decode As' and set a 
port as RTP manually (table can be saved for later use).


3) Wireshark (UDP dissector) blindly tries every UDP based protocol 
which allows heuristics. If its sub-dissector says "OK", it is decoded 
as the protocol.


Step 2 causes that if RTP uses well know port (there are many in RTP 
range), it is never recognized as RTP ad is incorrectly decoded as other 
protocol.


Step 3 causes (because protocols are just "tried") that it can happen 
that traffic is guessed incorrectly. So even it is RTP, other 
sub-dissector was tried before and said OK incorrectly.


There are settings related to steps 2/3:
i) Preferences -> Protocols -> UDP -> Try heuristics sub-dissectors first
ii) Analyze -> Enabled Protocols -> RTP -> rtp_udp (BTW you can 
enable/disable many other protocols there).


When i) is checked, steps 2 and 3 are swapped. So RTP is recognized even 
uses well known port. But it increases false positives.


When ii) is unchecked, no heuristics is made for RTP. So RTP is then 
recognized only when signaling is seen in advance (step 1) or 'Decode 
as' is used (step 2).


Best regards,

        Jirka Novak
___
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] Parameters for extcap

[Jirka Novak]

Hi,

  just for reference...

On 11/30/21 09:49, Roland Knall wrote:

Both issues where done so by design.

For the password, there was a reasonable concern, that passwords may be 
read-out. Now, you could argue, that monitoring the cumpcap call gives 
you the password anyway, which is correct. The intended 
usecase originally was to use the password together with ssh, which was 
later superseded by using the identity file, which can be stored normally.


It is done in !5519.

As for empty values, we have no possibility to detect, if the empty 
value you entered is the default one, or if it is a new set value. 
Therefore empty was implemented as "return default value". One could 
argue, that default values should only be used, if you reset the 
complete configuration, but than you could not reset an individual 
configuration.


It is prepared in !5538 and it is waiting for review/acceptance.

Best regards,

    Jirka Novak
___
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] wslog, windows, pytest, and heap corruption

[Jirka Novak]

Hi,

  just for reference...

  I created issue #17827 which describes issue with logging when extcap 
is run on windows. I'm not sure whether it is related to John's issue as 
I don't think extcap dies - I see it in processes, but it stops in 
execution. On the other hand it is related to extcap, logging and 
windows so it might be related.


Best regards,

Jirka Novak

___
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] wslog, windows, pytest, and heap corruption

[Jirka Novak]

Dear John,

I was working on a MR for moving the text2pcap/text_import debug over to 
the ws_log features and I ran into a seemingly bizarre problem. Setting 
the log level to a non-default value causes the pytest procedures to 
fail with heap corruption on the Gitlab Windows CI.

...


I'm touching similar issue just on Windows platform when running extcap 
from Wireshark. Extcap dies when logging level is set to file and file 
size increases by subsequent ws_log related writes over 4192 bytes.


I found that if I disable part of code, it works fine including writing 
messages to log. Can you try it too:


wsutil/wslog.c in log_write_dispatch() comment out second call of 
log_write_do_log():


diff --git a/wsutil/wslog.c b/wsutil/wslog.c
index f0f87eaa6e..8e49b6200c 100644
--- a/wsutil/wslog.c
+++ b/wsutil/wslog.c
@@ -965,11 +965,14 @@ static void log_write_dispatch(const char *domain, 
enum ws_log_level level,

 user_format, user_ap, registered_log_writer_data);
 }
 else {
+   // TODO: Fix it
+/*
 log_write_do_work(console_file(level), 
console_color_enabled(level),

 get_localtime(tstamp.tv_sec, ),
 tstamp.tv_nsec,
 domain, level, file, line, func,
 user_format, user_ap);
+   */
 }

A few weeks ago I worked with João Valverde on changes in logging for 
extcaps, but I don't think we touched this part.

João Valverde, can you check our findings?

Best regards,

Jirka Novak
___
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] pre-commit error: extcap.c: error: found these preference variables used in more than one prefs_register_*_preference:

[Jirka Novak]

Hi,

I understand the check now. So I can propose to to add exceptions to 
check. checkAPIs.pl has exceptions for many other checks so it can be 
extended to e.g. ignore arg->pref_valptr in this case.


Sure... it is a practical solution, at least until no one can 
understand anymore what checkAPIs.pl is or does. We still have a few 
years left for that so no worries. :-)


In all seriousness I think that is fine to move your MR forward. No 
one should be expected to fix the limitations of checkAPIs.pl IMO.


I will add exception to checkAPIs.pl in separate MR and then compilation 
will pass...


done as part of updated !5519. I expect it will be compiled with no 
issues now.


Best regards,

    Jirka Novak
___
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] pre-commit error: extcap.c: error: found these preference variables used in more than one prefs_register_*_preference:

[Jirka Novak]

Hi,


This was added in commit 1089bdb7d4911a5508f86a0eea59418b424b265c.

 Catches mistakes where the same variable is populated by 
multiple preferences:
 prefs_register_bool_preference(epl_module, "show_soc_flags", 
"text1", "desc1",

 _soc_flags);
 prefs_register_bool_preference(epl_module, "show_soa_flags", 
"text2", "desc2",

 _soc_flags);


The problem is that the script is naive, because it assumes that if a 
variable appears in more than one call in the source code it will be 
used more than once in compiled code, which is clearly not the case.


It's a limitation of trying to parse C using regular expressions. I 
think you should just remove the check in checkAPIs.pl.


I understand the check now. So I can propose to to add exceptions to 
check. checkAPIs.pl has exceptions for many other checks so it can be 
extended to e.g. ignore arg->pref_valptr in this case.


Sure... it is a practical solution, at least until no one can understand 
anymore what checkAPIs.pl is or does. We still have a few years left for 
that so no worries. :-)


In all seriousness I think that is fine to move your MR forward. No one 
should be expected to fix the limitations of checkAPIs.pl IMO.


I will add exception to checkAPIs.pl in separate MR and then compilation 
will pass...


Best regards,

Jirka Novak
___
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] pre-commit error: extcap.c: error: found these preference variables used in more than one prefs_register_*_preference:

[Jirka Novak]

Hi,


This was added in commit 1089bdb7d4911a5508f86a0eea59418b424b265c.

     Catches mistakes where the same variable is populated by multiple 
preferences:
     prefs_register_bool_preference(epl_module, "show_soc_flags", 
"text1", "desc1",

     _soc_flags);
     prefs_register_bool_preference(epl_module, "show_soa_flags", 
"text2", "desc2",

     _soc_flags);


The problem is that the script is naive, because it assumes that if a 
variable appears in more than one call in the source code it will be 
used more than once in compiled code, which is clearly not the case.


It's a limitation of trying to parse C using regular expressions. I 
think you should just remove the check in checkAPIs.pl.


I understand the check now. So I can propose to to add exceptions to 
check. checkAPIs.pl has exceptions for many other checks so it can be 
extended to e.g. ignore arg->pref_valptr in this case.


Best regards,

Jirka Novak
___
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] pre-commit error: extcap.c: error: found these preference variables used in more than one prefs_register_*_preference:

[Jirka Novak]

Hi,

  I'm working on !5519 - Prefs/Extcap: Added support for password which 
is never stored on the disk.

  It is done and working, but I can't pass pre-commit check. It says:

$ bash ./tools/pre-commit 'HEAD^1'
extcap.c: error: found these preference variables used in more than one 
prefs_register_*_preference:

(const char **)arg->pref_valptr

which is caused by tools/checkAPIs.pl

  The error is caused by code:

if (arg->arg_type == EXTCAP_ARG_PASSWORD)
{
  prefs_register_password_preference(dev_module, pref_name_for_prefs,
pref_title, pref_title, (const char **)arg->pref_valptr);
} else {
  prefs_register_string_preference(dev_module, pref_name_for_prefs,
pref_title, pref_title, (const char **)arg->pref_valptr);
}

  The code is correct. I briefly checked checkAPIs.pl and I don't 
understand aim of the check so I don't know how to resolve it.


  Can I ask for help?

Best regards,

    Jirka Novak
___
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] Wireshark do not stop extcap on exit if no packets received yet

[Jirka Novak]

Hi,

  I noticed issue #17781.
  I think that something like:

if (capture_in_progress)
  captureStop();

  should be used.
  I spend several hours with finding correct place where to fix it, but
with no success. I'm not able to track as signals are passed in the code
in this case (no data captured yet).
  Can I ask someone to advice me? I will finish patch then...

Best regards,

Jirka
___
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] How to allow Wireshark to stop extcap on Windows?

[Jirka Novak]

Hi,

  I'm working on ciscodump extcap tool. I'm touching issue with allow
the tool to cleanup when Wireshark stops the capture.

  When a extcap tool is started, Wireshark just creates a pipe, starts
the application and reads the pipe. The application feeds packets and
when it decides, it stops (e.g. expected count of packets reached) and
exits. Wireshark notice it and that is done.
  When Wireshark needs to stop the capture, it closes the pipe and
terminates the application.

  On a Unix like systems, application receives SIGPIPE (if it tries to
write to closed pipe) and then SIGTERM so can detect it and can cleanup.
  On Windows, pipe is closed and application is terminated and there is
no way how application can detect it. See extcap.c, extcap_if_cleanup()
and wsutil/ws_pipe.c, ws_pipe_close() and Win32 API TerminateProcess()
documentation.

  There is prepared way to communicate with extcap with additional
pipes, but is used just in specific situation.

  So I learn that there is no way how to stop extcap on Windows gracefully.

  I got idea:
  There is pipe for sending data from extcap to Wireshark. It is used
unidirectional nowadays. What about to use it bidirectional?
  Extcap can read it and e.g. if there is any data, it stops. Or we can
implement more advanced method/more commands.
  BTW there is similar solution between wireshark and dumpcap I found.

  It is clear that this idea requires reader on extcap side which
probably mean second thread.
  It is obvious too, that many extcaps do not need this and will never
try to read from pipe. So Wireshark can write to pipe, but should be
aware it may fail and application must be terminated as nowadays.
  Therefore my idea is to use some kind of timer - send message to stop,
wait some fixed time and terminate application as nowadays. If the
application will finish sooner, timer will be canceled.

  My idea is to:
- update wsutil/ws_pipe.c or extcap.c to write to the pipe
- update extcap/extcap_base.c to read from pipe (start thread?)
- update extcap/extcap_base.c to provide simple API to register callback
when pipe read happened
  - if no API used, no read from pipe will be started so it is "legacy"
procedure for simple extcaps

  Any comments and ideas welcomed.

Best regards,

    Jirka Novak
___
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 troubleshoot extcap applications?

[Jirka Novak]

Hi Roland,

> Could we additionally add a note to README.extcap? Just in case, some
> external extcap tools sumble across this as well?

I think there is no README.extcap. There is just extcap.adoc, but it is
about application, not about code/API. BTW I'm missing it.

Or do you think any other specific document?

> Also, one more thing, have you tested with tshark only or also using qt?
> Qt in general redirects all std... pipes, which should not matter as we
> are started through dumpcap. 

I tested it with Wireshark/Qt. I can retest it with tshark too, good point.

> Also, please test on Windows, as it behaves a little different from
> Linux/mac in the case of pipes/standard pipes

I tested my try on Windows, but plan is to retest it on all three
platforms (Linux/Mac/Windows) before merge.

Best regards,

Jirka
___
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] How to troubleshoot extcap applications?

[Jirka Novak]

Hi,

  I noticed issue below and I propose a solution for it. Can I ask for
comments?

  Every extcap tool has --debug and --debug-file options, but when they
are used, it do "nothing". File is created, but it is empty.
  Later I found that it must be used with --log-level=debug to really
log messages.
  The issue is that when you increase --log-level, it logs to console
(STDERR). So when extcap is started from Wireshark, it mixes log output
with packet data and wireshark gets confused and I found no way how to
make it operational.
  In other words you can't use debug of extcap from Wireshark.

  In code I found that the reason is that wsutils/wscode.c writes every
message to STDERR. If application registers additional file, it is
copied to it too, but output to STDERR is made in every case.
  Applications can replace default writer to STDERR, but no extcap do it.

  My proposal is to modify extcap/extcap-base.c:
1) When --debug is used, set log level to debug so you don't have to add
--log-level
2) If --log-file used, register custom log writer with
ws_log_init_with_writer() which will discard all messages so just write
to file will be made.
3) Update log init in every extcap

  Change is quite simple, but involves all extcaps. I already tested it
and it works. I'm just not sure every extcap.
  I'm ready to prepare patch.

Best regards,

Jirka
___
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] Parameters for extcap

[Jirka Novak]

Dear Roland,

> Both issues where done so by design.

I expect so, but it makes issues during use :-(

> For the password, there was a reasonable concern, that passwords may be
> read-out. Now, you could argue, that monitoring the cumpcap call gives
> you the password anyway, which is correct. The intended
> usecase originally was to use the password together with ssh, which was
> later superseded by using the identity file, which can be stored normally.

Yes, but e.g. many our Cisco devices do not support identity file use :-(
Nevertheless, is password stored in memory during runtime so big issue?

I'm thinking about multiple approaches:
a) Allow to store password in memory during runtime
b) Keep 'password' as it is for backward compatibility and create
'runtime-password' type which will store password during runtime and
editor will warn about the risk. extcaps must be updated to use this new
item type.
c) Wireshark will remember that some password item was used during last
run and reopen extcap dialog to enter it again.

I prefer a) or b) because c) is annoying.

> As for empty values, we have no possibility to detect, if the empty
> value you entered is the default one, or if it is a new set value.
> Therefore empty was implemented as "return default value". One could
> argue, that default values should only be used, if you reset the
> complete configuration, but than you could not reset an individual
> configuration.

I understand the background, but how to solve it. Modify advanced
settings API to be able to clear a setting? But it involve editor to add
'set default' button which will call the new API?

Best regards,

Jirka

___
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] Parameters for extcap

[Jirka Novak]

Hi,

  Wireshark is able to run external captures (extcap). Extcap tools can
provide configuration description which Wireshark shows as dialog and
stores in advanced properties.
  I'm observing two strange things I understood as bug.

1) If the tools provides as type of setting 'password', it is not stored
permanently. It is correct.
The issue is, that password is not remembered over runtime. So if I run
extcap twice in row, second run has empty password :-(
I think it is related to #14221, but I think that it should remember
password till application is closed.

2) If the tool provides default value for a setting, it is stored in
preference. If I change the value, it is stored too. It is correct.
The issue is, that if I clear the value to do not pass the value to
extcap (it is not required), the empty value is not stored so next run
default value is again used.

Both issues are very annoying.

My plan is to change it:
- remember password during runtime
- store empty values

My worry is about storing empty values to preferences. I'm afraid that
the framework uses empty value to remove settings from preference.

Can I ask for comments and advices before I will proceed?

Best regards,

Jirka Novak
___
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 stop extcap gracefully

[Jirka Novak]

Hi Roland,

> Due to the nature of extcaps, they are not explicitly closed. Instead,
> you should monitor the created pipes. Dumpcap closes those pipes when
> the capture has finished. We do send them a kill signal, but due to the
> nature of the signal handling, this signal may be missed.
> 
> The sure fire way is, if the pipe gets closed, end the extcap from the
> extcap side.

can you point me to place where pipes are controlled on extcap side? I
see common framework there, but I'm not sure where the place is exactly...

Thank you in advance,

Jirka

___
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] How to stop extcap gracefully

[Jirka Novak]

Hi,

  I'm working on ciscodump extcap.
  The the application creates settings on Cisco device and when it ends,
it clears settings.
  The issue is that when capture is stopped during capture, the
application is stopped and settings stays on Cisco device.

  I added signal handling to ciscodump so when it is stopped from CLI,
it cleanups as expected. I'm capturing TERM and INT signals. But it
looks that when it is run from wireshark, application is terminated and
signal is not thrown.
  Can I ask someone to help me/explain how extcaps are stopped to adapt
to it?

  I know how unix signals works, I'm just missing information how
wireshark terminates extcaps.

Best regards,

Jirka
___
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 generate epan/dissectors/packet-skinny.c?

[Jirka Novak]

Hi ALexis,

> from packet-skinny.c.in 
> # Dependencies:
> # - python2.x
> # - cog.py: (pip install cogapp / http://nedbatchelder.com/code/cog/
> )
> # - python.xml
> # - python.xml.sax
> #
> 
> Tested on Ubuntu 18.04 (TLS) (with python2) and work for me..

Thank you for test. So it looks that issue is in python2 vs. python3.

For my fedora python2 is available only in python 2.7 version which is
not supported anymore so I can't build it.
I will check whether I can update the script to run on python 3...

Best regards,

Jirka

___
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] How to generate epan/dissectors/packet-skinny.c?

[Jirka Novak]

Hi,

  based on notice of Jörg Mayer (thank you), I tried to generate
epan/dissectors/packet-skinny.c from epan/dissectors/packet-skinny.c.in.
  The command line should be:

cog.py -D xmlfile=tools/SkinnyProtocolOptimized.xml -d -c -o
epan/dissectors/packet-skinny.c epan/dissectors/packet-skinny.c.in

  but it fails with error:

Traceback (most recent call last):
  File "epan/dissectors/packet-skinny.c.in", line 109, in 
skinny = xml2skinny.xml2obj(xmlfile)
  File
"/home/novakji/vyvoj/netsystem.cz/wireshark/wireshark-repo/tools/parse_xml2skinny_dissector.py",
line 974, in xml2obj
return builder.root._attrs.values()[0]
TypeError: 'dict_values' object is not subscriptable

  It calls tools/parse_xml2skinny_dissector.py internally. My first
worry was that this python script is not designated for python3, but it
is probably not the case.
  I briefly reviewed parse_xml2skinny_dissector.py and I found no error
except it reads tools/SkinnyProtocolOptimized.xml with no syntax error,
but output is empty so line

return builder.root._attrs.values()[0]

  fails because there is no index 0.

  I'm using Linux/Fedora. Can someone check whether the script works on
different environment?

  BTW it looks that packet-skinny.c was not made from packet-skinny.c.in
for long time as they e.g. use different methods for memory allocation
(pinfo->pool vs. wmem_packet_scope()).

Best regards,

Jirka

___
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] Sample of IAX2 with RTP

[Jirka Novak]

Hi,

  first: I didn't received this response from mailing system even I'm
receiving other wireshark-dev communication as expected. I noticed it in
archive...

> Be very careful to not change any calculation made in accordance to
> RFC 3550.
> People depend on these algorithms as well as the naming used.

  Yes, I'm aware of it. I'm going to change/fix calculation of mean
value of jitter which is not described in RFC 3550 by my opinion and I
think there is clear mistake as it do not calculate mean value of the
jitter, but mean value of one of internal variables used for calculate
jitter. So in some cases it calculates obvious nonsense.
  Please, check https://gitlab.com/wireshark/wireshark/-/issues/17600 if
I'm correct.

  Nevertheless I'm still missing IAX2 with RTP sample...

Best regards,

        Jirka Novak


___
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] Sample of IAX2 with RTP

[Jirka Novak]

Hi,

  there is observed misbehaving in RTP jitter mean calculation
(https://gitlab.com/wireshark/wireshark/-/issues/17600). I'm going to
fix it.
  There is very similar code in IAX2 analysis and it looks there is same
issue too. I plan to fix it too, but I have no IAX2 sample with RTP to
verify it.
  Can I ask someone to publish short sample?

  I expect that sample will show forward and reverse stream in
Telephony->IAX2 Stream Analysis.
  Please, send it as response to this email or attach it to mentioned issue.

  If it will be permitted, I will publish it in sample library of Wireshark.

Best regards,

    Jirka Novak
___
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 disable QT_MULTIMEDIA_LIB during cmake

[Jirka Novak]

Hi Roland,

  I see your merge request. So my task is to review it and make it
running with QT_MULTIMEDIA_LIB undefined, right? BTW it was my original
idea to do.

Best regards,

Jirka Novak
___
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] How to disable QT_MULTIMEDIA_LIB during cmake

[Jirka Novak]

Hi,

  I would like to test whether #ifdef QT_MULTIMEDIA_LIB are correct in
source code so I need to disable it during cmake detection. Is there
something like there was --nofeature in autoconfigure?

Best regards,

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

[Jirka Novak]

Hi Uli,

> 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]:
> ...
> 
> Any objections? Comments are very welcome.

  I agree with you. I'm missing this information about created issues too.
  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.

Best regards,

Jirka
___
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] How to recognize that live capture is running?

[Jirka Novak]

Hi,

  I need to show a button in a dialog just in case that live capture is
running, but I'm not able to find how to get this information.
  I'm able to get information about change of state during e.g. closing
capture, but not get current state.
  Can anyone advice me, how to get current status?

Best regards,

Jirka Novak
___
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] Fwd: Tshark feature request

[Jirka Novak]

Hi,

> I hope you are doing well, We are looking for feature request on Tshark,
> 
> We would like to have mean,avg and max delta values print out,

I propose to create change request on
https://gitlab.com/wireshark/wireshark/-/issues

I propose to clarify which formula you would like to use for 'Mean' and
'Avg'. For example provide formulas, short sample and expected results
for formula - you can probably use RTP Analysis to get inputs for
calculation.

Best regards,

        Jirka Novak
___
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] Proposal: New set of help pages for VoIP dialogs

[Jirka Novak]

Hi Jaap,

> You could instead think about adding to the user guide, where this stuff 
> should be in the first place.

I updated user guide, but even it was merged, old pages are shown on:

https://www.wireshark.org/docs//wsug_html_chunked/ChTelRTPAnalysis.html

Do you know correct procedure to publish it?

Best regards,

Jirka

___
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] Proposal: New set of help pages for VoIP dialogs

[Jirka Novak]

Hi,

  I'm working on VoIP dialogs for several weeks. RTP Player was
significantly changed, there are more available actions in other VoIP
dialogs too and I plan to update wiki pages for it.
  What I found is that e.g. RTP Player changes are so big that it is
difficult to describe current behaving and new behaving on one page.
  My proposal is to create "version 2" wiki pages for that dialogs.
Version 1 will up to 3.4, version 2 will be from 3.5.

  Does this idea fits into Wireshark's wiki concept?

  If so, the question is how to connect new pages to global list of
pages in wiki to make it clear?
  Any comment welcomed.

Best regards,

    Jirka Novak
___
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] File extension is missing on Linux when WiresharkFileDialog::getSaveFileName/QFileDialog::getSaveFileName is used

[Jirka Novak]

Hi,

  I noticed that when I would like to save e.g. diagram exports with
Wireshark (not main dialog Save/Save As), it offers me e.g. .pdf, .ps
and other extensions in save dialog. When I write just name of file and
commit the dialog, created file has correct content (PDF, PS, ...), but
filename is missing extension.
  I tested it and it happens just on Linux, but on every Linux I tested
- multiple distributions from past years. On MAC or Windows it works fine.

  I checked the code and it looks that
WiresharkFileDialog::getSaveFileName calls QFileDialog::getSaveFileName
and it returns just name without extension. I tested it with
QFileDialog::DontUseNativeDialog flag too, but same results.
  Then I compared it with CaptureFileDialog and there is method which
checks whether file extension is there and then adds it if it is missing.
  Therefore it looks like Qt feature and some parts of Wireshark code
are aware of it and fix it and some do not.

  Should I try to modify WiresharkFileDialog to handle it for all cases?

Best regards,

Jirka Novak
___
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] How to decode specific packet with custom Decode as from dialog?

[Jirka Novak]

Hi,

  I'm using wireshark for RTP analysis. Very often I analyze pcaps where
is no signaling packets therefore Wireshark is not able to recognize RTP
packets and I have to use Decode as for every stream in file. It is
boring work...

  My idea is to write a tool which will propose RTP stream candidates. I
would like to allow the tool to check whether packet is really RTP - it
will try to decode one or a few packets as RTP.
  I found that I don't know how to do it. There are two issues I identified:
1) How to decode just the specific packet?
There is sequence of calls e.g. in PacketListRecord::dissect() which
decode packet. My understanding is that it decodes current packet where
pcap is positioned and I found no call to "seek" to specific packet by
its number. On the other hand goToPacked do so...
I would like to avoid retap of whole pcap if possible.

2) How to use new Decode as rule temporary?
Decode as dialog saves it to preferences, but I hope there is simpler way.

Can I ask for help and guidance?

Best regards,

    Jirka Novak
___
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] Missing ChTelRtpPlayer page in Wireshark documentation

[Jirka Novak]

Hi,

  I noticed that Rtp Player dialog help button points to:

https://www.wireshark.org/docs/wsug_html_chunked/ChTelRtpPlayer.html

  but it doesn't exist. I believed it is just typo in page name but I
found there is no similar page here nor in Wiki.
  Is it possible to check whether this page was there in past and was
removed or it didn't existed ever?

Best regards,

Jirka Novak
___
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] Counterpart shortcut for Select All

[Jirka Novak]

Hi,

  Wireshark implements Select All in many dialogs, but I'm missing
Select None and/or Invert Selection. Select All is mapped to common Ctrl+A.
  Select None is implemented in a few dialogs, but I'm missing shortcut
for it. Invert Selection is not implemented.

  I plan to add it to dialogs, but I'm not sure which shortcuts I should
use. There is no widely used shortcuts for it...
  I propose:

Select None - Ctrl+Shift+A
Invert Selection - Ctrl+I

  Ctrl+Shift+A is used in Wireshark for opening dialog for selecting
configuration profiles. It works only in main window and I don't think
it will cause any issues if same shortcut will be used in dialogs for
different purpose.
  Ctrl+I is used in graphs for zoom in, but it is just alternative
shortcut. Main shortcut for zoom in is key +, Ctrl+I is not listed in
menus nor in documentation. It might be released probably.

  Any feedback welcomed.

Jirka Novak

___
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] Procedure to solve/close issues in Gitlab

[Jirka Novak]

Hi Pascal,

> Le mar. 9 févr. 2021 à 12:51, Jirka Novak  <mailto:j.no...@netsystem.cz>> a écrit :
> 
> Hi,
> 
>   what is proposed procedure to solve and close issues in Gitlab?
> 
>   During conversion to gitlab all bugzilla issues were created as
> issues. I reviewed many voice related issues, made solutions (e.g.
> patches) for them and updated issues, but they are still open even it
> makes no sense anymore.
> 
> 
> When you have a MR fixing a given bug, please add a fixes #XXX comment
> in you commit message so that GitLab can close the issue automatically.
> It will avoid the need to manually close them afterwards.

OK, for next time.

>   Can I or someone else close them?
> 
> I do not know if you have the rights to close an issue in  GitLab, but
> if not leave a comment and we will close them for you.

Please, find all issues with 'rtp' in description and about half has
note from me at end that they are solved and can be closed.
My plan is to review the rest, but it will take some time...

Best regards,

    Jirka Novak

___
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] Procedure to solve/close issues in Gitlab

[Jirka Novak]

Hi,

  what is proposed procedure to solve and close issues in Gitlab?

  During conversion to gitlab all bugzilla issues were created as
issues. I reviewed many voice related issues, made solutions (e.g.
patches) for them and updated issues, but they are still open even it
makes no sense anymore.
  Can I or someone else close them?

Best regards,

Jirka Novak

___
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 mean "Error: Found prohibited APIs in ..." error during build?

[Jirka Novak]

Hi,

> > Change calls to open() to call ws_open(), instead, so that, on
> Windows, they can handle UTF-8 pathnames (by turning them into
> UTF-16 pathnames and passing them to routines that take UTF-16
> pathnames, rather than using various code page encodings for strings).
> >
> > Also use ws_close() instead of close().  (The ws_ calls, on
> Windows, also call the Visual Studio C library routines that
> implement UN*X-style APIs, with an underscore preceding the UN*X API
> name.)
> 
> Thank you for explanation and I understand the reasons, but I don't
> think it is possible in this case. Classes extending QIODevice where
> open/close are parent methods I must call/override.
> It looks that it is false positive check. Is there any way how to add
> exception to check in this case?
> 
> THere is already some code in checkAPIs.pl file to identify false positives:
> 
>                 # Match function calls, but ignore false positives from:
>                 # C++ method definition: int MyClass::open(...)
>                 # Method invocation: myClass->open(...);
>                 # Function declaration: int open(...);
>                 # Method invocation: QString().sprintf(...)
>                 while (${$fileContentsRef} =~ m/ \W (?|\w\ )
> (?                 {
>                         $cnt += 1;
>                 }
>                 if ($cnt > 0) {
>                         push @{$foundAPIsRef}, $api;
>                         $groupHashRef->{function_counts}->{$api} += 1;
>                 }
> 
> This probably needs to be improved for your use case.

The solution was to fully clasify parent's methods. E.g. open() to
QIODevice::open(). This is already checked in checkAPIs.pl and it solved
the issue.

Thank you all for help.

    Best regards,

Jirka Novak

___
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 mean "Error: Found prohibited APIs in ..." error during build?

[Jirka Novak]

Hi,

> > Also use ws_close() instead of close().  (The ws_ calls, on
> Windows, also call the Visual Studio C library routines that
> implement UN*X-style APIs, with an underscore preceding the UN*X API
> name.)
> 
> Thank you for explanation and I understand the reasons, but I don't
> think it is possible in this case. Classes extending QIODevice where
> open/close are parent methods I must call/override.
> It looks that it is false positive check. Is there any way how to add
> exception to check in this case?
> 
> 
> THere is already some code in checkAPIs.pl file to identify false positives:
> 
>                 # Match function calls, but ignore false positives from:
>                 # C++ method definition: int MyClass::open(...)
>                 # Method invocation: myClass->open(...);
>                 # Function declaration: int open(...);
>                 # Method invocation: QString().sprintf(...)
>                 while (${$fileContentsRef} =~ m/ \W (?|\w\ )
> (?                 {
>                         $cnt += 1;
>                 }
>                 if ($cnt > 0) {
>                         push @{$foundAPIsRef}, $api;
>                         $groupHashRef->{function_counts}->{$api} += 1;
>                 }
> 
> This probably needs to be improved for your use case.

OK, I will try it.

    Best regards,

Jirka Novak

___
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 mean "Error: Found prohibited APIs in ..." error during build?

[Jirka Novak]

Hi,

>>  I commited patch and pipeline failed because:
>>
>> ...
>> FAILED: ui/qt/CMakeFiles/checkAPI_ui-qt
>> ...
>> Error: Found prohibited APIs in utils/rtp_audio_silence_generator.cpp: open
>> Error: Found prohibited APIs in utils/rtp_audio_routing_filter.cpp: open
>>
>>  but message gives me no hint what to change.
> 
> Change calls to open() to call ws_open(), instead, so that, on Windows, they 
> can handle UTF-8 pathnames (by turning them into UTF-16 pathnames and passing 
> them to routines that take UTF-16 pathnames, rather than using various code 
> page encodings for strings).
> 
> Also use ws_close() instead of close().  (The ws_ calls, on Windows, also 
> call the Visual Studio C library routines that implement UN*X-style APIs, 
> with an underscore preceding the UN*X API name.)

Thank you for explanation and I understand the reasons, but I don't
think it is possible in this case. Classes extending QIODevice where
open/close are parent methods I must call/override.
It looks that it is false positive check. Is there any way how to add
exception to check in this case?

    Best regards,

Jirka Novak
___
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] What mean "Error: Found prohibited APIs in ..." error during build?

[Jirka Novak]

Hi,

  I commited patch and pipeline failed because:

...
FAILED: ui/qt/CMakeFiles/checkAPI_ui-qt
...
Error: Found prohibited APIs in utils/rtp_audio_silence_generator.cpp: open
Error: Found prohibited APIs in utils/rtp_audio_routing_filter.cpp: open

  but message gives me no hint what to change. Compilation and code
works fine, just this check failed.

See https://gitlab.com/j.novak/wireshark/-/jobs/1016432967

  What to check or change?

Best regards,

Jirka Novak
___
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] Dissector functions and variables that could be static

[Jirka Novak]

Hi,

  I checked the code I know:

> epan/dissectors/packet-rtp-events.c (01a0 D> 
> rtp_event_type_values_ext) is not referred to so could be static? (in>
header)
It is used in UI, outside of dissectors. Therefore it should be exported.

> epan/dissectors/packet-rtp.c (06d0 T rtp_dyn_payload_remove)
> is not referred to so could be static? (in header)
> epan/dissectors/packet-rtp.c (0660 T
> rtp_dyn_payload_replace) is not referred to so could be static? (in header)
> epan/dissectors/packet-rtps.c (0e20 D class_id_enum_names)
> is not referred to so could be static?

That two functions are not used at all. Can we remove them?

Best regards,

        Jirka Novak
___
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] Revive the happy-shark repository?

[Jirka Novak]

Hi,

> Years ago we added a repository for dissector regression tests at
> https://github.com/wireshark/happy-shark. Unfortunately it hasn't
> received much attention, and instead we've been adding dissector tests
> in the main repository. Should we
> 
> - Import happy-shark into GitLab and move our current dissector tests
> there?
> 
> - Retire happy-shark and do all of our testing in the main repository?
> 
> - Something else?
> 
> I'm leaning toward the first option for the simple reason that it will
> minimize the number of files we accrue in test/captures.

I'm personally missing happy-shark alive. Very often I'm looking for a
sample which contains e.g. correct sequence of messages for a protocol
on the Internet (with no success). I imagine it has potential to be
world wide library of samples...
But in this case it should contain not only sample, but its
description/context where and why it was collected and how it should be
decoded. I proposed this to happy-shark long time ago.

Back to the questions. I think that before the decision we should agree
on the goal and related process. There are my ideas.

When I added samples to happy-shark, my idea was to use it as QA tool.
Therefore for each sample I stored description why sample is there and
what is important to check during decoding. For some samples e.g. I
stored "script" which extracted e.g. sequence numbers only which where
then compared.
Then I added versioning of output - to be able to track that e.g.
wireshark version 2.0 decoded the sample some way and the version 2.2 do
it different way. Both cases could be correct because there was
change/improvement in decoding between versions.
I proposed to store outputs from each last version in branch and a few
development branches.

It is possible to use it different way too - e.g. between version 2.0
and 2.2 this set of samples is decoded different way. Someone should
check why?
If it is correct, store new output in repository. If it is incorrect, we
can ask author of change to fix it and provide them with sample where
the issue is observed.

The idea described above mean that there should be a team which will be
engaged on every "stable" release and will check whether all samples are
decoded expected way.
For it, separate project is probably more suitable.

Another point of view is that we can trigger same check for every build
and notify author that a new change introduced change in decoding of
sample1, sample3101, ... Author than should check it and if new decoding
is correct, all sample outputs should be updated by the author as part
of patch. For some changes it could be very extensive task.
For this case, make happy-shark as part of repository is probably more
suitable.

The question is whether author (everyone) should be allowed to update
stored/compared outputs. If they do it incorrectly, QA check will pass
even decoding is incorrect.
On the other hand, if we create team for it, I'm not sure whether we can
find team which will understand every protocol to be able to decide
whether new change is correct or not.
We are working in open source, therefore open approach is more suitable
I think.

There might be something in between.
Store happy-shark in separate repository. A user can decide whether it
will be cloned locally. If so, special build script or target will check
samples with local build. If not, it will be skipped.
On gitlab triggered builds, happy-shark will be available every time and
checks will be done. Fixing of decoding of failed samples might be
optional. We can record/track which commit broken which samples.
For every build we can create "statistics" e.g. how many samples are
decoded correct way (mean same way as stored in happy-shark repository).

    Best regards,

Jirka Novak
___
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 disable controls in dialog when capture file is closing

[Jirka Novak]

Hello Jim,

> The following two commits might give some insight:

Thank you for list of commits, I checked it.
I made !1649/8dd84917136e763c08be821cef360a225baa089e which corrected
all my observations and notes.

Best regards,

    Jirka Novak
___
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] How to disable controls in dialog when capture file is closing

[Jirka Novak]

Hi,

  I would like to disable a button in dialog (QT UI) when capture file
is closing. I studied existing code, reused pattern other dialogs use
and I'm afraid it doesn't work as intended. I mean disabling of
buttons/controls doesn't work in any child of WiresharkDialog.
  Can I ask for verification and help?

  Basic idea is that update of UI is done with updateWidgets(). When
capture file is closed, file_closed_ variable is set to true and UI is
redrawn.
 Therefore pattern is:

updateWidgets() {
...
  button->setEnabled(!file_closed_);
...
}

  I found that it doesn't work. E.g. try existing code:
1) open any capture with TCP packets (just to be able to use dialog I
propose)
2) open Statistics->Conversations, select TCP Tab and click on one row.
Follow Stream button is enabled.
3) Now close the capture file. Header of dialog changes to [no capture
file], but Follow Stream button is still enabled.
4) You have to click on other row in list and Follow Stream button is
disabled now.

  You can repeat this procedure with any dialog which uses buttons in
many stable versions in past (for sure to 2019).
  My first worry was that I made mistake in code, but after checking the
code I'm afraid that framework is wrong...

  How it is indended to work:
  When capture file is closed, WiresharkDialog::captureEvent() receives
event CaptureEvent::Closing. Based on this event captureFileClosing() is
called. It calls current class captureFileClosing(), all its predecessor
and then WiresharkDialog::captureFileClosing() {
{
if (file_closed_)
return;

removeTapListeners();
updateWidgets();
}

  Therefore I learn that if I overwrite captureFileClosing() it would work:

captureFileClosing() {
  button->setEnabled(false);
}

  but it doesn't. Technically it does, but right after it
updateWidgets() is called from WiresharkDialog::captureFileClosing() and
it does:

  button->setEnabled(!file_closed_);

  and because file_closed_ is not set yet, button is enabled again.
  This is reason why it doesn't work in Statistics dialog (except
Statistics dialog reenables the button in different method then
updateWidgets(), but reason/dependency is the same).

  When I studied the code deeper, I found that there is:

void WiresharkDialog::captureEvent(CaptureEvent e) {
...
case CaptureEvent::File:
switch (e.eventType())
{
case CaptureEvent::Closing:
captureFileClosing();
break;
case CaptureEvent::Closed:
captureFileClosing();
file_closed_ = true;
break;
default:
break;
}
...
}

  There you can see that captureFileClosing() is called before
file_closed_ is set and therefore any updateWidgets() which checks
file_closed_ can't disable button during captureFileClosing(). And in
real, many of dialogs do not disable buttons correctly nowadays even
it's code do its best.
  I was surprised how it happend and I found that in past file_closed_
was set before captureFileClosing() and there were two methods called:
captureFileClosing() and captureFileClosed(). They were removed during
optimalizations of the code and I'm afraid it broken the framework.

  Did I missed something? Should I try fix the framework? Is there
anyone who remembers why framework was changed to current state?

Best regards,

    Jirka Novak
___
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] Fwd: bug 11723

[Jirka Novak]

Dear Anirudh,

> I don't know why the RTP player is not able to play the audio in my case.

can you provide me with a sample? I modified RTP player some time ago
therefore I will check it with code.

> Your observation is clearly bug. Do you plan to fix it yourselves?
> 
> Yes, I will definitely try to fix it and submit a patch.

OK.

    Jirka Novak
___
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] Fwd: bug 11723

[Jirka Novak]

Dear Anirudh,

> I am already working on the latest developer build cross checked with
> the command "git status" and version displaying from the " help -> about
> wireshark " is developer version 3.3.0.   

I'm sorry, I incorrectly understood the issue.
I confirm that I see increasing counter of packets and extending
Comments after every press of Play Streams. It happens with any pcap
with VoIP calls I tested.
On the other hand, I see correctly decoded audio.

Your observation is clearly bug. Do you plan to fix it yourselves?

    Jirka Novak
___
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] Fwd: bug 11723

[Jirka Novak]

Hi,

> > While I was exploring the bug
> > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11723
> >
> > i encountered the RTP player was not able to play the audio even after
> > re-opening it again and again. After reaching the state as shown
> in the
> > screenshot, I clicked the play button but nothing happened. Am I doing
> > something wrong or is it the bug which needs to be resolved.
> 
> If you scroll a bit to the right in the initial dialog (or resize the
> window), can you see "22" in the Packets column? Following the steps in
> Bug 11723, opening the VoIP calls dialog initially shows "11". When I
> press "Play Streams", the contents will only appear once the column
> reaches "22".
>  
> 
> okay, I got this. The value of the packet switches to 22 from 11, and so on.
> 
> If I close the RTP Player dialog again, and press "Play Streams" again,
> then the contents will be empty. I have not investigated why this
> happens, but it might be related to some state in the dialog not being
> cleared when the "tap" mechanism[1] used by the RTP player passed
> through it. That could also explain the 11 -> 22 -> 33 -> ... Packets
> bug. And yes, it is an open bug, feel free to investigate it and submit
> a patch for it. :-)

It looks like issue I fixed some time ago in master branch. Try latest
developer build for master if you still see it.
BTW I hope I fixed the issue with "Warn remove_tap_listener(): no
listener found with that tap data" mentioned in the bug too.

Jirka Novak
___
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 transfer change in dissector from master to current branch?

[Jirka Novak]

Hi Roland,

> Usually only bugfixes and minor features are added to the master branch.
> In your case, you changed the RTP dissector quite a lot (judging from
> your patch https://code.wireshark.org/review/#/c/29129/) and most of
> those seem to be the implementation of new features, not bugfixes.
> Therefore I do not think merging them to the master would follow the
> guideline for merging to the master branch.

you are right I changed the code significantly. On the other hand it was
just refactoring before I was able to add decoding of a new items in
RTP/ED-137 which is minor feature adding :-)
OK, I will wait. Thank you for clarification.

Best regards,

        Jirka Novak
___
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] How to transfer change in dissector from master to current branch?

[Jirka Novak]

Hi,

  I made multiple/incremental changes in a dissector and I made it in
master branch. Changes were merged and are part of development build and
works.
  As changes do not depend on any new feature in master and are just
update of the dissector, I wish to make them available to current stable
branch.
  How to do so? Should I commit it as one big patch again?

Best regards,

Jirka Novak
___
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 code recognizes that processing of all packets with tap was finished?

[Jirka Novak]

Hi Guy,

>>  The problem in this case I see with GUI. Imagine use case:
>> 1) User starts live capture
>> 2) User open a dialog where initiate operation which save file with
>> "finish" callback
> 
> If you can do a save while a capture is still in progress (a save, not an 
> "export specified packets"), that sounds like a bug, unless it somehow 
> manages to have the capture being done switch from writing to the temporary 
> file to the resulting saved file (unless the "save" just means moving the 
> file from the temporary directory to another directory and renaming it), and 
> does *not* end up causing the "finish" callback to be called.

you are right, it looks like bug/programmer error.
On the other hand it, to avoid it, it means that from now (when "finish"
call back will be implemented), each place using tapping with "finish"
must check whether it is running on live capture or not.
I'm afraid that such API will be difficult to use.

Jirka Novak
___
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 code recognizes that processing of all packets with tap was finished?

[Jirka Novak]

Hi Peter,

>> My idea is that I will add "finish" callback. It will be called at the
>> end of capture file. Probably "draw" and "finish" sequence will be called.
>> Imagine that I want to write a code which will write some packets to a
>> file. File has header, body and footer. Therefore I will add header at
>> beginning, every "packet" callback will write data and idea is that
>> "finish" callback will write the footer.
>> Note: I will use no remove_tap_listener in example above.
> 
> In your earlier post, you presented freeing resources as use case, but
> writing a footer is a different use case.

Yes, you are right. I'm thinking about multiple use cases and the one
with file saving I used as easy to understand example :-)

Side note:
I briefly reviewed places where taps are used and my feeling is that
many usages do not clear memory - they don't clear structures created
during tapping. Some of them have "reset" call back, but do not call it
at the end, some of them do not handle it at all.
Therefore one of my ideas was to call "reset" callback during
remove_tap_listener(). But later I found that some code use structures
from tapping after remove_tap_listener() so it will break it.
I found that in description of tapping there is no advices/rules how to
work with memory after tapping is finished.

>> What is not clear to me what should happen when live capture is running?
>> I'm afraid that if I will call "finish" at the end of current live
>> capture (and write footer), later received packet will be delivered to
>> "packet" callback and will be written to end of file behind footer.
>> On the other hand if I will not call "finish" on live capture ever (or
>> only when live capture is finished), it makes no sense too - application
>> will never close the file.
>>
>> How to handle this case?
> 
> For the freeing of resources case, how can you know for sure that a
> resource is no longer used? If there is a condition for that, you could
> do it from the "packet" callback as well I suppose?

That is correct, but I have to check in every "packet" callback whether
it is right time to do so. Therefore "finish" callback looks better to me.

> For the footer scenario, if you write it too early, the file can no
> longer be extended. You can only reliably complete it when the user
> stops the packet capture. Potentially you could check for the elapsed
> time between the last relevant packet and the current packet time from
> the "packet" callback and decide on writing a footer. Or rely on the
> "draw" callback to process a snapshot (and calculate times from there).
> (An additional "finish" callback would still be necessary in case the
> "draw" callback decides to delay writing the footer.)

Yes, there are many approaches - I'm just thinking about options...
BTW if I will modify tapping, I must update documentation and there
should be clearly stated how "finish" call back works.

Another reason why I'm thinking about "finish" callback is voice replay
of multiple streams. My idea is to tap all streams, extract voice from
each and then "prepare" them to replay - mix it. Mix should be called in
"finish" call back - it is similar to footer for file save example.
There is same problem with live capture. Probably it is bigger problem
because play dialog stays open and with alive capture and you can't
decide to e.g. call remove_tap_listener(). In other words there is no
point where tapping code can decide that everything is finished and can
start to play.
Maybe, play dialog for live capture must say it can't play or there must
be a button "play now" which will probably remove listeners and detach
from tapping live stream.

Note: The reason why I'm thinking about mixing is that I found no
reliable way how to play synchronized multiple audio streams with Qt.
Therefore the only way I see is to mix it together to one stream and
play it then.

Best regards,

Jirka Novak
___
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 code recognizes that processing of all packets with tap was finished?

[Jirka Novak]

Hi,

>> What is not clear to me what should happen when live capture is running?
>> I'm afraid that if I will call "finish" at the end of current live
>> capture (and write footer), later received packet will be delivered to
>> "packet" callback
> 
> If you call "finish" at the *end* of the current live capture, there won't 
> *be* any later received packets.
> 
> ("End of the current live capture" means "the entire capture is finished", 
> not "we've finished reading the current batch of packets".)

  yes, it makes sense.
  The problem in this case I see with GUI. Imagine use case:
1) User starts live capture
2) User open a dialog where initiate operation which save file with
"finish" callback
3) User waits some time (e.g. till progress bar finishes) - application
will receive packets, but no "finish" callback was called
4) User closes the dialog and believes that everything is OK, but it is
not OK

  It shows that application/dialog must (some of options):
a) notify user that live capture is running and operation can't be used
in point 2)
b) or notify user that live capture is running and file is not complete
in point 3/4)
c) dialog must call remove_tap_listener() before close and
remove_tap_listener() must call "finish"

  Probably c) makes sense and can be implemented.

Best regards,

Jirka Novak
___
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 code recognizes that processing of all packets with tap was finished?

[Jirka Novak]

Hello,

  I responding with delay...

> On Jun 21, 2018, at 12:26 PM, Jirka Novak  wrote:
> 
>>>> What is correct way to recognize that capture processing with tap was
>>>> finished?
>>>
>>> There isn't one, unfortunately.  We'd have to change the tap mechanism to 
>>> introduce a "we're done processing packets" callback to provide that.

I'm thinking about it and I can't make clear decision about the topic,
see below.

My idea is that I will add "finish" callback. It will be called at the
end of capture file. Probably "draw" and "finish" sequence will be called.
Imagine that I want to write a code which will write some packets to a
file. File has header, body and footer. Therefore I will add header at
beginning, every "packet" callback will write data and idea is that
"finish" callback will write the footer.
Note: I will use no remove_tap_listener in example above.

What is not clear to me what should happen when live capture is running?
I'm afraid that if I will call "finish" at the end of current live
capture (and write footer), later received packet will be delivered to
"packet" callback and will be written to end of file behind footer.
On the other hand if I will not call "finish" on live capture ever (or
only when live capture is finished), it makes no sense too - application
will never close the file.

How to handle this case?

Best regards,

Jirka Novak
___
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] Where to store temporary data during processing RTP data?

[Jirka Novak]

Hello,

  I plan to unify processing of voice RTP data in wireshark. I plan to
focus on decoding data for replaying (player, save as au etc). The
target is to be able to play multiple streams in player which requires
to mix multiple streams together.
  I reviewed code and found that part of code stores temporary voice
data in memory, part in temp files. When I unify code, only one method
must be used.
  Do anyone has any points to discuss about this topic?

  There are my points:
  Storing in memory was used by GTK code and is used by most library
methods. When RTP stream is long, it consumes memory, but provides
faster processing. If there will be a lot of long RTP streams, memory
can be depleted.
  Storing on disk avoids depletion of memory, but e.g. mixing of
multiple streams is slower.
  Moving in stream during replay (start at, forward, back, ...) do not
depend on method of storing data.

  Any comments are welcomed.

Best regards,

Jirka Novak
___
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 code recognizes that processing of all packets with tap was finished?

[Jirka Novak]

Hi,

>>  What is correct way to recognize that capture processing with tap was
>> finished?
> 
> There isn't one, unfortunately.  We'd have to change the tap mechanism to 
> introduce a "we're done processing packets" callback to provide that.

  should I try to do so?
  I found at least two places where it should be useful:
1) my case, of course :-)
2) sharkd (see sharkd_session.c, taps_free)

  Therefore I think it would be useful.

Best regards,

    Jirka Novak
___
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] How code recognizes that processing of all packets with tap was finished?

[Jirka Novak]

Hello,

  I'm using tap interface. During packet callback I create per packet
structure. I use this structure during draw callback.
  My question is when I can release this structure? I mean when I can be
sure it will not be used any more - after call of draw last time?

  Documentation (doc/README.tapping) says that draw callback can be
called multiple times during capture processing (e.g. for Qt it is
called every 2-3 seconds). Therefore I can't release such structure
during call of draw.
  Documentation says that reset callback is called only when capture is
reread.
  Therefore I can't find a place/callback which is called once per
capture analysis and after the last packet in capture.

  What is correct way to recognize that capture processing with tap was
finished?

Best regards,

Jirka Novak
___
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 test sharkd?

[Jirka Novak]

Dear Michal,

> There is a lack of documentation.

  thank you for quick response.

  As coincidence I'm working on unifying rtp related stuff - most of it
is not published yet. I briefly analysed rtp part of sharkd code and I
see many parts taken from ui/* which introduces code duplication.
  Won't be good idea to share the code with wireshark? E.g. create
ui/sharkd/ (like ui/cli/), use common code and just read/write JSON in
sharkd?
  I'm aware it might require to create library code extracted from all
ui/ to be able to reuse it - it is my current activity.

  I may try to do so, but I don't know purpose (understand client side)
of sharkd. Therefore I'm afraid to changing it...

Best regards,

    Jirka Novak
___
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] How to test sharkd?

[Jirka Novak]

Hi all,

  I'm refactoring RTP related parts of UI and I found that I have to
touch sharkd even too. I would like to test new code and I found that I
don't know how to start/use sharkd.
  Can anyone help me?

  BTW I found no information about sharkd at all. Did I missed something?

Best regards,

Jirka Novak
___
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] Proposal: Multiline display filter input field

[Jirka Novak]

Hi all,

  I would like to discuss topic I have in my head for long time...

  I'm working with wireshark daily and quite often I'm working with long
display filters. I start with:

(ip.addr == 172.16.31.8) && (ip.addr == 172.16.31.24) && (udp.port==8192)

  which we can understand as () && () && ().

  As I'm investigating data, I need to add more addresses to SERVER
list, to CLIENT list etc. E.g.:

((ip.addr == 172.16.31.8) || (ip.addr == 172.16.31.9)) && ((ip.addr ==
172.16.31.24) || (ip.addr == 172.16.31.36)) && (udp.port==8192 ||
udp.port==8194)

  When list of addresses is longer, it is longer then display space for
input item. Then it is very difficult task to find correct place in
input field (SERVER, CLIENT, DATA_FLOW) and edit it.
  Apply as Filter and Prepare as Filter do not help much. Macros do not
help too. Save/restore of filter do not help too as the list of
addresses changes with every pcap.

  Therefore I'm thinking about this:
  Allow display input field to be multiline. Then I can write the filter:

(
ip.addr == 172.16.31.8
) && (
ip.addr == 172.16.31.24
) && (
udp.port==8192
)

 updates will be much easier as the filter is well arranged:

(
(ip.addr == 172.16.31.8) || (ip.addr == 172.16.31.9)
) && (
(ip.addr == 172.16.31.24) || (ip.addr == 172.16.31.36)
) && (
udp.port==8192 || udp.port==8194
)

  Consequences:
  I think that only "a few" changes must be done:
a) every display filter editor item must be changed to multiline
b) every display filter show item must be changed to ignore new line
separators (show filter in compact form)
c) save/restore tools should save/restore filters including new line
separators
d) display filter processor must ignore new line characters

  I think it make sense to implement it in Qt only. I can work on it.

  What do you think about it?

    Best regards,

Jirka Novak
___
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] Packet sample repository/library?

[Jirka Novak]

Hello,

  is there any feedback to pull request about happy-shark?

Sincerely yours,

Jirka Novak
___
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] RTP player - a suggestion

[Jirka Novak]

e only reason it downsamples in the
> first place is because the QCustomPlot it uses to display the audio is
> too slow.
> 
> Hence why I led by talking about the use of QCustomPlot.  I feel that
> it's the root cause of a bunch of problems.  Instead of dealing with
> these various symptoms, it would be better to address the root cause,
> and these other questions (like how to downsample and store audio)
> would go away.
> 
> There shouldn't be any need to downsample the audio at all.  If it is
> downsampled, it should only be for *display*, so ideally it would be
> the widget's job to downsample based on the zoom level.  No code
> external to the widget ought to be downsampling anything.

As I mentioned above, I can work with QCustomPlot and I'm not able to
write different player.

Just note:
RTP processing library must be able to mix RTP audio to output and allow
to downsample streams one by one - both that tasks independently.

> There also shouldn't be any need for temporary files; audio is small
> enough that it can fit in memory.

BTW it is good question to others too - should we really expect that
audio will fit to available (even virtual) memory?
I'm working in area where SIP call and related RTP streams lasts for
weeks. Most of it is an silence, but I need to analyse it "as it is"
before I find "interesting" place in the call.
When you imagine that you need to process multiple RTP streams with week
duration and then create additional mixed stream for playing and then
something more for downsampling...
I have a lot of memory, but I don't thing that everyone has it.

Sincerely yours,

Jirka Novak

___
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] RTP player - a suggestion

[Jirka Novak]

Hi,

>> I disagree.  Right now, the GTK RTP player is the only one that I consider 
>> usable.  By comparison, the Qt RTP player only barely works, and is unusable 
>> if you're dealing with more than one stream.  If these changes can improve 
>> the Qt >version to be about as good as the GTK version was/is, then perhaps 
>> breaking the GTK version is okay.  But don't break/remove the GTK version 
>> *and* leave the Qt version less than fully functional.
>> --
>> Peter Budny
> 
> My thinking is that if fixing the Qt version without too much work means 
> ditching the GTK version that is OK in the development track as the GTK 
> version is still available in older
> Versions. Hopefully a usable Qt version would be available before the next 
> release.

I understand Peter, but I'm afraid it is not possible to change Qt code
without touching GTK. The reason is that both depends on common files in
ui/ (ui/rtp_stream, ui/tap-rtp* etc).
When I started to work on Qt, it induced changes in common ui/ code and
as consequence I broke GTK code.

I might be wrong because my additional aim was to write common code for
RTP analysis too (when you check the code for RTP analysis, you will
again find multiple places with same functionality - GTK, Qt and
TShark). Therefore I had to touch code in common ui/ directory more
often than just RTP player related changes might require.

On the other hand, I'm really afraid that changes for Qt will induce
changes for GTK. The option could be copy all related ui/ files and
split them for GTK and Qt.
But I'm not sure whether it is good approach.

    Sincerely yours,

Jirka Novak

___
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] RTP player - a suggestion

[Jirka Novak]

Hello Erik,

> My proposal:
> Add 'mixer' layer which will provide the following features to improve
> usability:

  I started work on "proof of concept" for very similar idea. I didn't
finished it yet. But I have a few points which I would like to mention
and discuss it there:

1) There are at least four points where is RTP processed to audio - once
for "audio player" and once for "audio save". GTK and Qt UI branch has
own code for it => four places.
I analysed it and found that even Qt code is derived from GTK, it is
slightly different. On the other hand, the main difference is between
code in audio player and audio save in each branch.
Therefore my idea is to extract RTP audio processing code to some kind
of library.
I made part of work on it and found that there is one big issue - GTK
code "idea" is very different to Qt code. Up to now I found no way how
to prepare API for such library which can be used from GTK and Qt code
in parallel.
The question is whether it makes sense to update GTK code when there is
long term idea to leave it? If so, there is much more work than just for Qt.

2) Audio player has multiple ways how to decode RTP - with dejitter
buffer, based on timestamp, uninterrupted mode. But save audio has no
such option and it is very complicated to change it. If it will be
changed, there will be again two places with same options and code.
My idea is to move "save audio" to "audio play" dialog - it will share
common options and control.
BTW it makes to me more sense to control all RTP audio related tasks
from one place.

3) When I analysed GTK and Qt code, I found that there is main
difference between it. GTK stores all RTP data in memory, Qt extract it
to file. Playing is based on extracted data then.
As consequence of it, there are many C structures in GTK/Qt code which
are same named, but slightly different. And there are elements in
structures which are shared but used by GTK or Qt code only.
I think that there must be consensus about storing RTP data during media
processing before any library/mixer should be made. Based on this, code
should be cleared.

Sincerely yours,

Jirka Novak

___
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] Multiple rtp_stream_info structures for RtpAudioStream?

[Jirka Novak]

Hello,

  I'm working on GUI for audio processing and I touched one comment at
beginning of ui/qt/rtp_player_dialog.cpp:

RTP audio streams are currently keyed on src addr + src port + dst addr
+ dst port + ssrc. This means that we can have multiple rtp_stream_info
structs per RtpAudioStream. Should we make them 1:1 instead?

  Does anyone know when it can happen? I mean when rtp tapping can
generate more rtp_stream_info structs per one RTP stream?
  By my knowledge (and I studied the code very deeply), the rtp stream
is keyed exactly by 5-tuple mentioned in comment. Therefore I can't
image situation when it can happen.

  It will help me when anyone will provide capture, when it can happen.
I'm looking forward to test new code with it...

Sincerely yours,

Jirka Novak
___
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] Packet sample repository/library?

[Jirka Novak]

Dear Dario,

> You have to issue a pull request against the upstream of happy-shark,
> using the button in github's website.
> We will start to review it as soon as you do that.

  I'm sorry, I'm not familiar with GIT workflow... I made pull request.

Sincerely yours,

        Jirka Novak


___
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] Packet sample repository/library?

[Jirka Novak]

Hello,

  did anyone reviewed my proposed changes in happy-shark?

Sincerely yours,

Jirka Novak
___
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] What is different in compilation/linking of tshark and wireshark?

[Jirka Novak]

Hi Guy,

> If you're trying to include some of the RTP player's functionality in TShark, 
> then you will have to split that functionality into "the parts that will work 
> in a command-line program as well as in a GUI program" and "the parts that 
> work only in a GUI program", and only link the parts that will work in a 
> command-line program with TShark.
> 
> Everything that contains the words "message_box", "alert_box", or "cf_" 
> requires the GUI.

  it was the point. Now I understand why there is ui/tap-rtp-common.h.
BTW, "common" word do not express real purpose of this file - I will try
to find better name for it...
  Thank you for your help.

        Sincerely yours,

Jirka Novak


___
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] What is different in compilation/linking of tshark and wireshark?

[Jirka Novak]

Hello,

  I'm working on patch for wireshark in rtp area. After a time I found
that I'm not able to link tshark any more.
  I'm able to compile all files for wireshark with Qt and GTK, I'm able
to compile all files for tshark. I'm able to link wireshark and
wireshark-gtk. But once Make starts to link tshark, it ends with error,
see below.

  I'm not aware of touching makefile or such staff. I work in ui/
directory, but I just modify existing .c/.cpp/.h files.
  I'm able to compile my changes therefore I don't expect any errors in
code.
  What is strange to me is that I'm able to link wireshark, therefore my
environment is OK in general. I spend hours with checking linking
process and found no clue for observed behaving.
  I know that when I checkout master, I'm able to compile it. But when I
reapply my patch, I'm again stuck.
  I tried clean etc. with no difference too.
  Does any one have advice to do/to check?

Sincerely yours,

Jirka Novak

Making all in .
make[2]: Entering directory 'wireshark-git'
  PERL version.h
version.h unchanged.
  CXXLDwireshark
  CCLD wireshark-gtk
  CCLD tshark
ui/libui.a(rtp_stream.o): In function `register_tap_listener_rtpstream':
wireshark-git/ui/rtp_stream.c:424: undefined reference to `simple_dialog'
ui/libui.a(rtp_stream.o): In function `rtpstream_scan':
wireshark-git/ui/rtp_stream.c:214: undefined reference to `cf_retap_packets'
ui/libui.a(rtp_stream.o): In function `rtpstream_save_as_rtpdump':
wireshark-git/ui/rtp_stream.c:252: undefined reference to `cf_retap_packets'
ui/libui.a(rtp_stream.o): In function `rtpstream_mark':
wireshark-git/ui/rtp_stream.c:385: undefined reference to `cf_retap_packets'
wireshark-git/ui/rtp_stream.c:385: undefined reference to `cf_retap_packets'
ui/libui.a(rtp_stream.o): In function `rtpstream_scan':
wireshark-git/ui/rtp_stream.c:214: undefined reference to `cf_retap_packets'
ui/libui.a(alert_box.o): In function `failure_alert_box':
wireshark-git/ui/alert_box.c:45: undefined reference to
`vsimple_error_message_box'
ui/libui.a(alert_box.o): In function `open_failure_alert_box':
wireshark-git/ui/alert_box.c:73: undefined reference to `simple_message_box'
ui/libui.a(alert_box.o): In function `read_failure_alert_box':
wireshark-git/ui/alert_box.c:89: undefined reference to `simple_message_box'
ui/libui.a(alert_box.o): In function `write_failure_alert_box':
wireshark-git/ui/alert_box.c:128: undefined reference to
`simple_message_box'
wireshark-git/ui/alert_box.c:122: undefined reference to
`simple_message_box'
ui/libui.a(alert_box.o): In function `vfailure_alert_box':
wireshark-git/ui/alert_box.c:52: undefined reference to
`vsimple_error_message_box'
collect2: error: ld returned 1 exit status
Makefile:1888: recipe for target 'tshark' failed
make[2]: *** [tshark] Error 1
make[2]: Leaving directory 'wireshark-git'
Makefile:3401: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 'wireshark-git'
Makefile:1730: recipe for target 'all' failed
make: *** [all] Error 2
___
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 modify existing RTP conversation?

[Jirka Novak]

Hi,

  did I made wrong code analysis and root cause is somewhere else?

>> I would like to know where this is done:
>>
>>  I analysed the code and found that for #1 is created "full"
>> conversation (full = SRC_IP:SRC_PORT <-> DST_IP:DST_PORT) with UDP as
>> protocol.
>>
>> because that sounds questionable. 
> 
> packet_udp.c: dissect() calls find_or_create_conversation(pinfo) for
> every packet. When packet is new (#1 in my example), it creates new full
> conversation just for UDP layer.
> Conversation is created as full/bidirectional, I checked it with enabled
> DEBUG_CONVERSATION.

    Sincerely yours,

Jirka Novak


___
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] Packet sample repository/library?

[Jirka Novak]

Hi,

> The reason is that you forked happy-shark by hand (by cloning and
> pushing to a brand new repo), and didn't use the "fork" button.
> 
> Look at my fork of happy-shark: https://github.com/crondaemon/happy-shark
> under the repo name, you can see "forked from wireshark/happy-shark". 
> 
> If cloned through github button, you can create a PR against the
> upstream repo

'Fork' is a button - it looks like label for counter. Thank you.

I forked it:

https://github.com/jnovak-netsystemcz/happy-shark

Sincerely yours,

    Jirka Novak

___
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] Packet sample repository/library?

[Jirka Novak]

Hello,

> Feel free to open a pull request against the main repo, so we can start
> the review process.

  I really want, but I was not able to do so even I read github
documentation.
  I was logged in github with my account and when I pressed 'Create pull
request', the button for it is gray and I found no way how to made it
different way.
  Therefore I cloned repository on my account :-(

  I'm looking forward to learn how to do make pull request from main repo.

Sincerely yours,

    Jirka Novak

___
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] Packet sample repository/library?

[Jirka Novak]

Hello,

> Collaborators are people with write access to the repo. You don't need
> it to fork/PR. The repo is forked in your namespace. Can you double
> check, please? 

I see, I made this:

https://github.com/jnovak-netsystemcz/happy-shark

Comments are welcomed.

Sincerely yours,

        Jirka Novak

___
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] Packet sample repository/library?

[Jirka Novak]

Hello,

>>>> 2) Won't be good idea to allow skip a sample from automatic testing
>>>> (because it is for GUI demonstration)?
>>>
>>> You can invoke individual tests (which is most likely what you want when
>>> you are testing changes to a single dissector). GUI versus tshark
>>> single-pass and two-pass (-2) should produce the same results.
>>>
>>
>> Maybe this isn't quite what you meant but it *is* (semi-)normal that 1- and
>> 2- pass results are different.  At least for generated fields (that require
>> information from the first pass to calculate--e.g., links to frames that
>> occur later in the capture).  [Or do those fields not show up in tshark's
>> 2nd pass either?  My memory is fading...]
> 
> You are right, I was a bit imprecise. In the context of VoIP calls, when
> the 1-pass recognizes a conversation, the same conversation *should*
> also be found by the 2-pass. Indeed, dissectors can add extra
> information in the 2-pass (like a "Response in frame X" link) and these
> would show in the tshark -2 output as well.

  do you think it makes sense to store/compare 1-pass and 2-pass outputs
separated?
  If so, should it be stored for each output type (text and pdml)?

Sincerely yours,

Jirka Novak


___
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] Packet sample repository/library?

[Jirka Novak]

Hi Alexis,

> You can "fork" the happy shark repo on Github and make a Pull Request
> (PR) and the code will be review directly on Github

  I can't. Probably I'm not collaborator on happy-shark repository. Can
you add me to collaborator list?

Sincerely yours,

    Jirka Novak


___
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 modify existing RTP conversation?

[Jirka Novak]

Hi,

> I would like to know where this is done:
> 
>  I analysed the code and found that for #1 is created "full"
> conversation (full = SRC_IP:SRC_PORT <-> DST_IP:DST_PORT) with UDP as
> protocol.
> 
> because that sounds questionable. 

packet_udp.c: dissect() calls find_or_create_conversation(pinfo) for
every packet. When packet is new (#1 in my example), it creates new full
conversation just for UDP layer.
Conversation is created as full/bidirectional, I checked it with enabled
DEBUG_CONVERSATION.

Sincerely yours,

        Jirka Novak

___
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 modify existing RTP conversation?

[Jirka Novak]

Hello,

  my question is related to Bug 11446 and behaving I'm observing with
attached sample.
  The issue (demonstrated with my sample) is how RTP stream is decoded
when RTP stream starts before SIP with SDP is captured (you start
capture in mid of session).
  My sample:
#1 - RTP packed (172.16.176.24:5012->172.16.176.11:8204)
#2-#4 - SIP with SDP
#5 - RTP packet (172.16.176.24:5012->172.16.176.11:8204)

  Nowadays #1 and #5 is shown as UDP.
  Expected behaving is that #1 can be shown as UDP, but #5 should be
shown as RTP packet (or #1 and #5 can be shown as RTP packet).

  I analysed the code and found that for #1 is created "full"
conversation (full = SRC_IP:SRC_PORT <-> DST_IP:DST_PORT) with UDP as
protocol.
  SIP/SDP analyse then tries to find conversation for proposed media,
but only in half way (SRC_IP:SRC_PORT or DST_IP:DST_PORT). As
consequence of it (my understanding), it do not find it and creates new
"half" conversation with RTP protocol.
  When #5 is decoded, the "full" conversation is found and it is decoded
as UDP then.
  Is there a way how to solve it?

  I know that there is option for conversation to set packet number from
which is conversation valid. But it do not work in this case, because
"full" conversation does exists.

Sincerely yours,

    Jirka Novak


x4.pcapng.gz
Description: Unix tar archive
___
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] Packet sample repository/library?

[Jirka Novak]

Hello Peter,

> You are right, I was a bit imprecise. In the context of VoIP calls, when
> the 1-pass recognizes a conversation, the same conversation *should*
> also be found by the 2-pass. Indeed, dissectors can add extra
> information in the 2-pass (like a "Response in frame X" link) and these
> would show in the tshark -2 output as well.

  how can I submit my work to happy shark? BTW I prefer commit it to
branch and merge when it will be reviewed...

Sincerely yours,

        Jirka Novak


___
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] RTP player redesign in 2.x makes it worse than the legacy one

[Jirka Novak]

Hello Peter,

> I admit that this is only my opinion, but as someone who uses the RTP Player
> in Wireshare very regularly in my job, I hope you'll give it some
> consideration:
> The UI of the redesigned RTP Player in Wireshark 2.x *sucks*, and its
> usability is much worse than the old one that's now in Wireshark Legacy. To 
> wit:

  I agree with you and with all your comments and I decided to change it.
  On the other hand, my first task is to unify audio processing code -
same task is coded on multiple places and as consequence you can receive
different output for same input. Therefore it will take a time before I
will change features you mentioned.

Sincerely yours,

        Jirka Novak
___
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] Packet sample repository/library?

[Jirka Novak]

Hello Peter,

>> I tried to run make in top directory and it failed for first try :-) I
>> checked the output and found that something changed in DNS dissector and
>> dns.flags.recdesired .. value="1" was in past and now value="".
>> It is probably about signed/unsigned value - not important now.
>> But this issue pointed to me more things:
>> 3) There should be easy way how to describe which wireshark version
>> processed stored PDML file.
>> Probably different outputs should be stored for main branches (2.0, 2.2,
>> ...). It is obvious that each version of wireshark will change (improve)
>> some outputs. Therefore older release will not be able to process it
>> correctly (PDML diff will fail).
>> I think that without output version you can't run regression tests
>> automatically.
> 
> Branches can work, but given that there is only little testdata for now,
> it seems better to track the master branch directly.

I don't think branches are good approach - you are not able to compare
same sample between versions.

>> 5) There should be easy way how to describe which filter should be used
>> for preprocessing PDML. Now only filter.xsl is used.
> 
> XSL is currently the only available format because it is powerful given
> the XML nature. Are there any particular things that are lacking in XSL?

I think that PDML and TEXT output should be stored/compared. TEXT
contains e.g. info column which is not shown in PDML.
Any other format can be added in future - e.g. automated GUI scripts and
outputs as mentioned by Alexis and Graham.

> For now you can file pull requests on the happy-shark project on Github.
> It is still in experimental phase, nothing is set in stone and things
> can change as you see them fit :-)

I prepared scripts and Makefile which express my idea. I attached
modified README.md where I add description of new features. There is
list of files in my test repository to demonstrate future content.
Any comments are welcomed.

./common/copy-all.xsl
./README.md
./Makefile
./tests/dns/qr-1/qr-1.description.txt
./tests/dns/qr-1/qr-1_2.3.pdml
./tests/dns/qr-1/qr-1_2.0.text
./tests/dns/qr-1/qr-1_2.3.text
./tests/dns/qr-1/qr-1.pdml.current
./tests/dns/qr-1/qr-1_2.0.pdml
./tests/dns/qr-1/qr-1.requirements.txt
./tests/dns/qr-1/qr-1.text.current
./tests/dns/qr-1/qr-1.pcapng.gz
./tests/dns/qr-1/filter.xsl
./tests/dns/dns-1/dns-1.requirements.txt
./tests/dns/dns-1/dns-1_2.2.pdml
./tests/dns/dns-1/dns-1_2.0.pdml
./tests/dns/dns-1/dns-1.description.txt
./tests/dns/dns-1/dns-1_2.3.text
./tests/dns/dns-1/dns-1.text.current
./tests/dns/dns-1/dns-1_2.0.text
./tests/dns/dns-1/dns-1.pdml.current
./tests/dns/dns-1/filter.xsl
./tests/dns/dns-1/dns-1.pcapng.gz
./tests/rtp.ed137a/ed137a-1/ed137a-1_2.3.pdml
./tests/rtp.ed137a/ed137a-1/ed137a-1.text.current
./tests/rtp.ed137a/ed137a-1/ed137a-1_2.3.text
./tests/rtp.ed137a/ed137a-1/ed137a-1.requirements.txt
./tests/rtp.ed137a/ed137a-1/ed137a-1.pdml.current
./tests/rtp.ed137a/ed137a-1/ed137a-1.description.txt
./tests/rtp.ed137a/ed137a-1/ed137a-1_2.0.text
./tests/rtp.ed137a/ed137a-1/ed137a-1_2.0.pdml
./tests/rtp.ed137a/ed137a-1/ed137a-1.args
./tests/rtp.ed137a/ed137a-1/ed137a-1.pcapng.gz
./tests/rtp.ed137a/ed137a-1/filter.xsl
./scripts/sample_test.sh
./scripts/sample_make_output.sh
./scripts/sample_verify.sh

Sincerely yours,

Jirka Novak

happy-shark
===
Happy Shark is the regression test framework for Wireshark consisting of a tool
and a collection of capture files.

Running tests
-
Simply invoke `make` or `make -j4` for more parallelism.

Adding a new test
-
Create a new subdirectory under `tests//`.  is name of protocol
subjected to test (e.g. 'dns' or 'rtp.ed137a'). Use same name as display filter in wireshark.
Directory populate with the following files:

 - FOO.pcap.gz or FOO.pcapng.gz - the source file (noncompressed files shall not be used, e.g. 'dns-1.pcapng.gz')
 - FOO.description - description of purpose the file is included (e.g. basic DNS query or RTP header with ED-137A header extension)
 - FOO.requirements - requirements, how tshark/wireshark should process the file (e.g. packet should be decoded by specification of ED-137B, PTT and SQL bits should be shown in packet info column). Requirements can describe non dissector related staff too (e.g. RTP Stream Analysis window should show warning about bad packet sequence, warning should be shown in yellow color).
 - FOO.args - optional file, contains options for tshark to process file as expected (e.g. 'decode as' parameters)
 - FOO_.pdml - the expected processed output from  of tshark in PDML format (e.g. `dns-1_2.0.pcapng.pdml`). Only first two levels of version number are used.
 - FOO_.text - the expected processed output from  

Re: [Wireshark-dev] Packet sample repository/library?

[Jirka Novak]

Hi Peter,

  first: happy-shark is very good idea. All notes above I would like to
discuss and then I will try to add my samples with respect to conclusions...

> For a basic testing framework, have a look at
> https://github.com/wireshark/happy-shark
> 
> To-do: populate the test/ directory with lots of specific samples :-)

This approach looks good to me, I will try to add samples.
What I'm missing there is idea how to add description for a sample - I
mean "description" - why sample is there and "specification" - what
wireshark should do with it.
Testing with PDML is good idea, but it tests dissectors only. Time to
time you want to store sample because GUI should do something with it
(e.g. show it in red).
1) Won't be good idea to ask for e.g. .description.txt and
.specification.txt for each sample?
2) Won't be good idea to allow skip a sample from automatic testing
(because it is for GUI demonstration)?

> I think that happy-shark (which uses PDML output with a XSL
> post-processor) does what you want.

I tried to run make in top directory and it failed for first try :-) I
checked the output and found that something changed in DNS dissector and
dns.flags.recdesired .. value="1" was in past and now value="".
It is probably about signed/unsigned value - not important now.
But this issue pointed to me more things:
3) There should be easy way how to describe which wireshark version
processed stored PDML file.
Probably different outputs should be stored for main branches (2.0, 2.2,
...). It is obvious that each version of wireshark will change (improve)
some outputs. Therefore older release will not be able to process it
correctly (PDML diff will fail).
I think that without output version you can't run regression tests
automatically.
4) There should be easy way how to run custom wireshark version without
modifying Makefile. I have multiple versions for testing. I think
environment variable solve it.
5) There should be easy way how to describe which filter should be used
for preprocessing PDML. Now only filter.xsl is used.

Maintaining such sample repository would be hard work. But I believe
that when there will be rules how to add sample and which information
must be added to it, it will be much easier.

6) Rules must be written.
6) There should be a procedure which check whether repository/new sample
contains expected information. Something like git review procedure for
wireshark source/gerrit.

Sincerely yours,

        Jirka Novak

___
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] RTP sample with wrap around timestamp?

[Jirka Novak]

Hello Erik,

> This one is a little longer, hope it is sufficient for you. Otherwise
> you'll have to wait a bit until I'm home from work.

  this one is OK. Thank you very much.

    Jirka Novak


___
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] RTP sample with wrap around timestamp?

[Jirka Novak]

Hi Erik,

> Is something like this useful for you?

  yes, thank you. Do you have a sample a little longer - e.g. 20-30
packets before and after counter wrap?

Sincerely yours,

    Jirka Novak


___
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] Packet sample repository/library?

[Jirka Novak]

Hello,

  I'm looking for repository/library with packet samples suitable for
developers. I found a lot of repositories over the Internet, but they
just contain samples and you are able to find protocols used in sample
(e.g. RTP).
  As developer when I change part of code, I should retest it with as
much samples as possible to verify whether change works fine with my
sample (why I'm doing a change) and if I didn't break old functionality.
Therefore I should be able to select samples which are relevant to my
change and be able to verify whether it is evaluated as expected.

  To be able to do so, samples should be commented/documented in two ways:
1) What sample contains
2) How it should be decoded/shown in Wireshark

There are a few ideas (I'm working in voice area):

- Sample contains full regular SIP session, with SDP, with related RTP.
RTP is dynamic payload described in SDP.
  - SIP session should be shown
  - SDP should be decoded
  - RTP should be decoded as described in SDP
- Sample contains rejected SIP session because of XXX
  - SIP session should be shown
  - SIP calls view should show call as failed
- Sample contains RTP call with extended header XXX
  - RTP header should be decoded as ...
  - Call Flow should show bit XXX in RTP stream
- Sample contains RTSP session from XXX with RTP media in UDP
  - sample should be decoded
  - RTP should be decoded as described in Transport header
- Sample contains RTP stream with missing packets
  - sample should be decoded
  - RTP Stream Analysis should show sequence error

  In other words, there should be attached specification for Wireshark
developer, how the sample should be processed. Therefore it can be
verified later by man or engine (maybe in future :-)).
  It is obvious that same sample can be used for multiple purposes -
e.g. RTSP with RTP sample can be used for testing RTPS and for RTP too.
Specification can be changed during time. Therefore it should be easy
editable.

  Does anyone know about something I'm looking for?

Sincerely yours,

Jirka Novak
___
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] RTP sample with wrap around timestamp?

[Jirka Novak]

Hello,

  I'm working on RTP dissector and RTP analysis. I would like to test
the code with sample which contain wrap around timestamp - timestamp
which overflow 32bits during the call. Because timestamp is generated
randomly at begin of the flow, it don't have to be call lasting for 2^32
samples :-)
  Do anyone have such sample?

Sincerely yours,

Jirka Novak
___
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