Re: [Wireshark-dev] Tshark closing unexpectedly due to failure reading from file

[Alastair Scott]

Hi John,

Do you know where in the code base I could look for a potential remedy to
this issue? I'm trying to find a place to add a delay to ensure the read
does not come early.

Regards,

Alastair

On Thu, Nov 19, 2020 at 6:15 PM John Sullivan 
wrote:

>
> [gitlab page updated with details]
>
> On Friday, November 20, 2020, 12:15:11 AM, James Ko wrote:
> > Why do we have the difference in read/write timing?
>
> Umm, because you just would, unless the reader and writer end take
> specific measures to avoid that, which they apparently don't. (Note
> that it looks like they *do* take such measures at the *end* of the
> capture, just not on the initial open.)
>
> John
> --
> Dead stars still burn
>
>
___
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] Tshark closing unexpectedly due to failure reading from file

[John Sullivan]

[gitlab page updated with details]

On Friday, November 20, 2020, 12:15:11 AM, James Ko wrote:
> Why do we have the difference in read/write timing?

Umm, because you just would, unless the reader and writer end take
specific measures to avoid that, which they apparently don't. (Note
that it looks like they *do* take such measures at the *end* of the
capture, just not on the initial open.)

John
-- 
Dead stars still burn

___
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] Tshark closing unexpectedly due to failure reading from file

[James Ko]

Hi John,

Thanks for your analysis.  If you still have the strace logs would you
attach them to the bug report together with your analysis?

So I think the questions now are..
Why do we have the difference in read/write timing?
What are the events that need to happen before the first bytes are written
to the /tmp/wireshark file ?
Does the initial SHB to the file get generated from within dumpcap itself
at startup, or does dumpcap wait for the start of the TCP stream with its
own SHB and just pass that data through?  I think it's the latter as you've
proven the temporary file is exactly the same as the source.
Does the delay for TCP connection cause that initial 0 byte read?
What other delays are happening in dumpcap startup for which tshark isn't
allowing enough time?

I see that there is a update_cb parameter to sync_pipe_start() but it is
NULL in the tshark case.  wireshark uses it for ui update. The callback if
it exists is called just before the pipe_input_set_handler().  Perhaps
adding a callback to introduce a delay at this point when connecting to a
TCP socket may help.

Are there any other things we might try to fix or avoid this race condition?

James




On Thu, Nov 19, 2020 at 6:13 AM John Sullivan 
wrote:

> On Monday, November 16, 2020, 8:45:48 PM, Alastair Scott wrote:
> > I've posted an in-depth description of the issue with logs and pcap's
> > attached here: https://gitlab.com/wireshark/wireshark/-/issues/17013
>
> Observations after running under strace with "-f -s 4096" with the
> same capture file (5992 bytes, SHA1 cefbb7):
>
> * tshark execs dumpcap to do the actual "capture" and communicates
> with it over pipes and a temporary file
>
> * Given we're reading from a pcapng file, despite the convoluted data
> path, dumpcap's output to the temp file is actually identical to the
> original pcap file (same size, same sha1sum). This is written out in what
> looks like packet-sized chunks as it reads them from the socket.
>
> * The reading end does three read() calls. The first two between them
> read the first 4096 bytes, the third reads the remaining 1896 bytes.
> The first happens almost immediately after opening the file, the
> second two not until the writing end has finished writing all data
> (which it signals by writing the packet count over the pipe). This is
> the same between failing and successful runs.
>
> * By extracting the data from strace output I can prove that the
> reading end does in fact read all data, and exactly the same data as
> in the original file, even in the failing case. There is no problem
> there.
>
> * One key difference appears to be that in the failing case the first
> read happens before the writing end has written anything at all, and
> reads 0 bytes. The second read then reads 4096 bytes, and the third
> 1896 bytes, before the reading end throws that all away and aborts. In
> the successful case the first read happens late enough to return 28
> bytes, then the second reads asks for (and gets) only 4068 bytes to
> make up the difference to 4096 bytes.
>
> So it looks like a race at the beginning, and even though the complete
> data transfer is executed in all cases, if that initial read didn't
> get the first valid file chunk so the "section header block" can be
> validated, then it will ultimately cause the file to be rejected.
>
> John
> --
> Dead stars still burn
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Compile fails after fetch

[Mora, Jorge]

Hello Pascal,

Great! It compiled.


--Jorge

From: Wireshark-dev  on behalf of Pascal 
Quantin 
Reply-To: Developer support list for Wireshark 
Date: Thursday, November 19, 2020 at 12:02 PM
To: Developer support list for Wireshark 
Subject: Re: [Wireshark-dev] Compile fails after fetch

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


Hi Jorge,
Le jeu. 19 nov. 2020 à 18:08, Pascal Quantin 
mailto:pas...@wireshark.org>> a écrit :
Hi Jorge,

Le jeu. 19 nov. 2020 à 17:51, Mora, Jorge 
mailto:jorge.m...@netapp.com>> a écrit :
Hello,

After a git fetch, compile fails with the following:
[ 50%] Building C object 
epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o
/home/mora/wireshark/epan/dissectors/packet-quic.c:603:1: error: 
‘quic_are_ciphers_initialized’ defined but not used [-Werror=unused-function]
quic_are_ciphers_initialized(quic_ciphers *ciphers)
^
cc1: all warnings being treated as errors
make[2]: *** [epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o] Error 1
make[1]: *** [epan/dissectors/CMakeFiles/dissectors.dir/all] Error 2

$ git log
commit 1d7bc367e943464f912a67ad436fabddb1a61a37
Author: Anders Broman 
mailto:anders.bro...@ericsson.com>>
Date:   Wed Nov 18 13:56:52 2020 +0100

GSM A Common: Dissect polygon points


Two weeks ago I did a git fetch and I was able to compile with no problems.

See https://gitlab.com/wireshark/wireshark/-/merge_requests/974

You can pull master branch, the issue is now fixed. Thanks for reporting it.


Best regards,
Pascal.



--Jorge

___
Sent via:Wireshark-dev mailing list 
mailto: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
___
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] Compile fails after fetch

[Pascal Quantin]

Hi Jorge,

Le jeu. 19 nov. 2020 à 18:08, Pascal Quantin  a
écrit :

> Hi Jorge,
>
> Le jeu. 19 nov. 2020 à 17:51, Mora, Jorge  a
> écrit :
>
>> Hello,
>>
>>
>>
>> After a git fetch, compile fails with the following:
>>
>> [ 50%] Building C object
>> epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o
>>
>> /home/mora/wireshark/epan/dissectors/packet-quic.c:603:1: error:
>> ‘quic_are_ciphers_initialized’ defined but not used
>> [-Werror=unused-function]
>>
>> quic_are_ciphers_initialized(quic_ciphers *ciphers)
>>
>> ^
>>
>> cc1: all warnings being treated as errors
>>
>> make[2]: *** [epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o]
>> Error 1
>>
>> make[1]: *** [epan/dissectors/CMakeFiles/dissectors.dir/all] Error 2
>>
>>
>>
>> $ git log
>>
>> commit 1d7bc367e943464f912a67ad436fabddb1a61a37
>>
>> Author: Anders Broman 
>>
>> Date:   Wed Nov 18 13:56:52 2020 +0100
>>
>>
>>
>> GSM A Common: Dissect polygon points
>>
>>
>>
>>
>>
>> Two weeks ago I did a git fetch and I was able to compile with no
>> problems.
>>
>
> See https://gitlab.com/wireshark/wireshark/-/merge_requests/974
>

You can pull master branch, the issue is now fixed. Thanks for reporting it.


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

Re: [Wireshark-dev] Compile fails after fetch

[Pascal Quantin]

Hi Jorge,

Le jeu. 19 nov. 2020 à 17:51, Mora, Jorge  a écrit :

> Hello,
>
>
>
> After a git fetch, compile fails with the following:
>
> [ 50%] Building C object
> epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o
>
> /home/mora/wireshark/epan/dissectors/packet-quic.c:603:1: error:
> ‘quic_are_ciphers_initialized’ defined but not used
> [-Werror=unused-function]
>
> quic_are_ciphers_initialized(quic_ciphers *ciphers)
>
> ^
>
> cc1: all warnings being treated as errors
>
> make[2]: *** [epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o]
> Error 1
>
> make[1]: *** [epan/dissectors/CMakeFiles/dissectors.dir/all] Error 2
>
>
>
> $ git log
>
> commit 1d7bc367e943464f912a67ad436fabddb1a61a37
>
> Author: Anders Broman 
>
> Date:   Wed Nov 18 13:56:52 2020 +0100
>
>
>
> GSM A Common: Dissect polygon points
>
>
>
>
>
> Two weeks ago I did a git fetch and I was able to compile with no problems.
>

See https://gitlab.com/wireshark/wireshark/-/merge_requests/974

Best regards,
Pascal.


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

Re: [Wireshark-dev] Compile fails after fetch

[Ivan Nardi]

Hi
could you share your environment details, please? SO, compiler version
and, particularly, libgcrypt version
Thanks

Ivan

On Thu, 19 Nov 2020 at 17:51, Mora, Jorge  wrote:
>
> Hello,
>
>
>
> After a git fetch, compile fails with the following:
>
> [ 50%] Building C object 
> epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o
>
> /home/mora/wireshark/epan/dissectors/packet-quic.c:603:1: error: 
> ‘quic_are_ciphers_initialized’ defined but not used [-Werror=unused-function]
>
> quic_are_ciphers_initialized(quic_ciphers *ciphers)
>
> ^
>
> cc1: all warnings being treated as errors
>
> make[2]: *** [epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o] 
> Error 1
>
> make[1]: *** [epan/dissectors/CMakeFiles/dissectors.dir/all] Error 2
>
>
>
> $ git log
>
> commit 1d7bc367e943464f912a67ad436fabddb1a61a37
>
> Author: Anders Broman 
>
> Date:   Wed Nov 18 13:56:52 2020 +0100
>
>
>
> GSM A Common: Dissect polygon points
>
>
>
>
>
> Two weeks ago I did a git fetch and I was able to compile with no problems.
>
>
>
>
>
> --Jorge
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Compile fails after fetch

[Mora, Jorge]

Hello,

After a git fetch, compile fails with the following:
[ 50%] Building C object 
epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o
/home/mora/wireshark/epan/dissectors/packet-quic.c:603:1: error: 
‘quic_are_ciphers_initialized’ defined but not used [-Werror=unused-function]
quic_are_ciphers_initialized(quic_ciphers *ciphers)
^
cc1: all warnings being treated as errors
make[2]: *** [epan/dissectors/CMakeFiles/dissectors.dir/packet-quic.c.o] Error 1
make[1]: *** [epan/dissectors/CMakeFiles/dissectors.dir/all] Error 2

$ git log
commit 1d7bc367e943464f912a67ad436fabddb1a61a37
Author: Anders Broman 
Date:   Wed Nov 18 13:56:52 2020 +0100

GSM A Common: Dissect polygon points


Two weeks ago I did a git fetch and I was able to compile with no problems.


--Jorge

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

Re: [Wireshark-dev] Windows build - all_guides fails on .chm files

[chuck c]

Fixed: Microsoft HTML Help Workshop missing.
Todo: Update documentation for creating build machine with link to tools
needed and find link to proper download.

"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe"
-P C:/Development/wireshark/cmake/modules/hhc.cmake
HTML_HELP_COMPILER-NOTFOUND user-guide.hhp

Not found
--
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.17763.
-- Generating build using CMake 3.18.20081302-MSVC_2
-- LTO/IPO is enabled
-- Building for win64 using Visual Studio 16 2019
Working in C:\Development\wireshark-win64-libs

Tag 2020-09-30 found. Skipping.

-- CMake build type: RelWithDebInfo
-- V: 3.5.0-CDC_201118, MaV: 3, MiV: 5, PL: 0, EV: -CDC_201118.
-- Linker flags: /LARGEADDRESSAWARE /MANIFEST:NO /INCREMENTAL:NO /RELEASE
/guard:cf
-- Could NOT find DOXYGEN (missing: DOXYGEN_EXECUTABLE)
-- Could NOT find SpeexDSP (missing: SPEEXDSP_LIBRARY SPEEXDSP_INCLUDE_DIR)
(found version "")
-- Could NOT find HTMLHelp (missing: HTML_HELP_COMPILER)


Download and install HTML Help workshop

-- Found HTMLHelp: C:/Program Files (x86)/HTML Help Workshop/hhc.exe


https://www.wireshark.org/docs/wsdg_html_chunked/ChToolsDocumentationToolchain.html
"4.6.4. HTML Help
HTML Help is used to create the User’s and Developer’s Guide in .chm format.
"


On Wed, Nov 18, 2020 at 8:57 PM chuck c  wrote:

> New  Windows 10 build system so might be due to tool versions.
>
> Any tips on how to diagnose this?
>
>
>   "The build of
> 'C:\Development\wsbuild64\CMakeFiles\470a6095470174e9ce53bf13b7d8b057\developer_guide_chm.rule'
> depends on 'C:\DEVELOPMENT\WSBUILD64\DOCBOOK\DEVELOPER-GUIDE.CHM' which is
> produced by the build of
> 'C:\Development\wsbuild64\CMakeFiles\f552b4b7ccfbf74b38fc77eac37cc368\developer-guide.chm.rule'.
> The items cannot be built in parallel."
>   "The build of
> 'C:\Development\wsbuild64\CMakeFiles\470a6095470174e9ce53bf13b7d8b057\user_guide_chm.rule'
> depends on 'C:\DEVELOPMENT\WSBUILD64\DOCBOOK\USER-GUIDE.CHM' which is
> produced by the build of
> 'C:\Development\wsbuild64\CMakeFiles\f552b4b7ccfbf74b38fc77eac37cc368\user-guide.chm.rule'.
> The items cannot be built in parallel."
>
> 
>
> Build succeeded.
>
> "C:\Development\wsbuild64\docbook\all_guides.vcxproj" (default target) (1)
> ->
> "C:\Development\wsbuild64\docbook\developer_guides.vcxproj" (default
> target) (3) ->
> "C:\Development\wsbuild64\docbook\developer_guide_chm.vcxproj" (default
> target) (4) ->
> (CustomBuild target) ->
>   C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(238,5):
> warning MSB8065: Custom build for item
> "C:\Development\wsbuild64\CMakeFiles\f552b4b7ccfbf74b38fc77eac37cc368\developer-guide.chm.rule"
> succeeded, but specified output
> "c:\development\wsbuild64\docbook\developer-guide.chm" has not been
> created. This may cause incremental build to work incorrectly.
> [C:\Development\wsbuild64\docbook\developer_guide_chm.vcxproj]
>
>
> "C:\Development\wsbuild64\docbook\all_guides.vcxproj" (default target) (1)
> ->
> "C:\Development\wsbuild64\docbook\user_guides.vcxproj" (default target)
> (10) ->
> "C:\Development\wsbuild64\docbook\user_guide_chm.vcxproj" (default target)
> (11) ->
>   C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(238,5):
> warning MSB8065: Custom build for item
> "C:\Development\wsbuild64\CMakeFiles\f552b4b7ccfbf74b38fc77eac37cc368\user-guide.chm.rule"
> succeeded, but specified output
> "c:\development\wsbuild64\docbook\user-guide.chm" has not been created.
> This may cause incremental build to work incorrectly.
> [C:\Development\wsbuild64\docbook\user_guide_chm.vcxproj]
>
> 2 Warning(s)
> 0 Error(s)
>
> Time Elapsed 00:00:05.45
>
___
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] Tshark closing unexpectedly due to failure reading from file

[John Sullivan]

On Monday, November 16, 2020, 8:45:48 PM, Alastair Scott wrote:
> I've posted an in-depth description of the issue with logs and pcap's
> attached here: https://gitlab.com/wireshark/wireshark/-/issues/17013

Observations after running under strace with "-f -s 4096" with the
same capture file (5992 bytes, SHA1 cefbb7):

* tshark execs dumpcap to do the actual "capture" and communicates
with it over pipes and a temporary file

* Given we're reading from a pcapng file, despite the convoluted data
path, dumpcap's output to the temp file is actually identical to the
original pcap file (same size, same sha1sum). This is written out in what
looks like packet-sized chunks as it reads them from the socket.

* The reading end does three read() calls. The first two between them
read the first 4096 bytes, the third reads the remaining 1896 bytes.
The first happens almost immediately after opening the file, the
second two not until the writing end has finished writing all data
(which it signals by writing the packet count over the pipe). This is
the same between failing and successful runs.

* By extracting the data from strace output I can prove that the
reading end does in fact read all data, and exactly the same data as
in the original file, even in the failing case. There is no problem
there.

* One key difference appears to be that in the failing case the first
read happens before the writing end has written anything at all, and
reads 0 bytes. The second read then reads 4096 bytes, and the third
1896 bytes, before the reading end throws that all away and aborts. In
the successful case the first read happens late enough to return 28
bytes, then the second reads asks for (and gets) only 4068 bytes to
make up the difference to 4096 bytes.

So it looks like a race at the beginning, and even though the complete
data transfer is executed in all cases, if that initial read didn't
get the first valid file chunk so the "section header block" can be
validated, then it will ultimately cause the file to be rejected.

John
-- 
Dead stars still burn

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

Re: [Wireshark-dev] About i18n Translation

[Roland Knall]

We currently have no system in place that would allow you to translate any 
texts coming from dissectors or anywhere out of epan for that matter

Kind regards

> Am 19.11.2020 um 14:54 schrieb qiangxiong.huang :
> 
> HI, I have two questions about wireshark i18n:
> 
> 1. Are the files *.po in debian/po only used in debian platform or all 
> platforms (like windows)? 
> (If these *.po are used in all platforms, I think they can also be used to 
> add new strings for title and description preference in 
> epan/dissectors/packet-xxx.c)
> 
> 2. Do the projects in https://www.transifex.com/wireshark/wireshark/ still 
> work like  "12.2.4.5. Internationalization and Translation" of 
> https://www.wireshark.org/docs/wsdg_html_chunked/ChUIQt.html#_source_code_overview
>  says, **each week** translations are automatically synchronized with the 
> source code?
> 
> Regards,
> Huang Qiangxiong
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] About i18n Translation

[qiangxiong.huang]

HI, I have two questions about wireshark i18n:

1. Are the files *.po in debian/po only used in debian platform or all 
platforms (like windows)? 
(If these *.po are used in all platforms, I think they can also be used to add 
new strings for title and description preference in 
epan/dissectors/packet-xxx.c)

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

Regards,
Huang Qiangxiong
___
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] Tshark closing unexpectedly due to failure reading from file

[John Sullivan]

On Monday, November 16, 2020, 8:45:48 PM, Alastair Scott wrote:
> I've posted an in-depth description of the issue with logs and pcap's
> attached here: https://gitlab.com/wireshark/wireshark/-/issues/17013

It might be helpful to specify -f to your strace, as that would
capture tshark's interaction with the TCP socket (which is apparently
done in a background thread so not visible to the non-following
strace.)

John
-- 
Dead stars still burn

___
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] Tshark closing unexpectedly due to failure reading from file

[Guy Harris]

On Nov 19, 2020, at 12:37 AM, James Ko  wrote:

> @Guy.  This is on ubuntu linux distribution.  I'm using Xubuntu 18.04LTS and 
> I believe Alastair is on Ubuntu 16.04LTS.
> Assuming the buffer/page/disk cache is not doing the right thing

I would not make that assumption; as I said, "If this is on UN*X, that would be 
an issue only if your UN*X is really stupid about managing the buffer/page 
cache.  I know of no UN*Xes where that's the case.", and, as far as I know, 
Linux is not stupid about managing the buffer/page cache - I know of *no* 
UN*Xes that are that stupid about managing the buffer/page cache.
___
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] Tshark closing unexpectedly due to failure reading from file

[James Ko]

Good thought.  I've only tried on my laptop.  I'll let Alastair answer
about his setup.
I think we both using Lenovo laptops with SSDs?

I know another colleague has seen similar failures with tshark on a TCP
stream as well.
I can't say that I've ever seen this fail when using wireshark however.
We have reproduced it using different pcapng TCP stream sources.
We have reproduced it with or without tshark filters.

James


On Thu, Nov 19, 2020 at 12:46 AM Graham Bloice 
wrote:

> Have you been able to replicate the issue on another system to rule out a
> local environmental problem?
>
> On Thu, 19 Nov 2020 at 08:37, James Ko  wrote:
>
>> @Guy.  This is on ubuntu linux distribution.  I'm using Xubuntu 18.04LTS
>> and I believe Alastair is on Ubuntu 16.04LTS.
>> Assuming the buffer/page/disk cache is not doing the right thing is there
>> anything we can try to make sure it's consistent?
>>
>> @Jaap.  We will be sure to update to the latest release but I don't
>> expect this will make much difference as the dumpcap/tshark interface has
>> been around for years.
>>
>> James
>>
>> On Wed, Nov 18, 2020 at 9:22 PM Guy Harris  wrote:
>>
>>> On Nov 18, 2020, at 4:25 PM, James Ko  wrote:
>>>
>>> > I've been helping Alastair debug this problem and this is as far as we
>>> got.
>>> > I can only think of a race condition between dumpcap completing the
>>> packet writing to the file and tshark being able to read the expected
>>> number of new packets.
>>> >
>>> > I do see there is fflush() in capture_loop_write_pcapng_cb() before
>>> the capture_loop_wrote_one_packet() which actually increments the number of
>>> available packets.
>>> >
>>> > Do we also need an fsync() here to ensure the data is written to the
>>> disk?
>>>
>>> If this is on UN*X, that would be an issue only if your UN*X is really
>>> stupid about managing the buffer/page cache.  I know of no UN*Xes where
>>> that's the case.
>>>
>>> If this is on Windows, I *still* wouldn't expect it to be the case, at
>>> least on any Windows NT-based version (and we haven't supported Windos
>>> 95/98/Me for a long while, and neither has Microsoft...), as I think it has
>>> the same sort of buffer/page cache as most if not all UN*Xes these days
>>> have.
>>>
>>> I.e., if process A is writing to a file, and process B is reading from a
>>> file, process B's write should immediately update the buffer/page cache, so
>>> process B's read should see it, as long as the read is done after the write.
>>>
>>> flush() just means "do a write to the underlying file immediately"; it
>>> doesn't imply anything more than write() on UN*X or _write() on Windows
>>> (which, in turn, turns into a WriteFile() if you're writing in binary
>>> mode), so it updates the buffer cache but doesn't necessarily update the
>>> file on secondary storage.  mailto:
>>> wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>>
>>
>
> --
> Graham Bloice
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Qt warning on Windows build.

[Anders Broman via Wireshark-dev]

Hi,

Currently there is one Warnimg produced for the Windows build

C:\Development\ewireshark\trunk\ui\qt\widgets\byte_view_text.cpp(187,38):
warning C4996: 'QFont::ForceIntegerMetrics': was declared deprecated
[C:\Development\wsbuild64\ui\qt\qtui.vcxproj]

 

Regards

Anders



smime.p7s
Description: S/MIME cryptographic signature
___
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] Tshark closing unexpectedly due to failure reading from file

[Graham Bloice]

Have you been able to replicate the issue on another system to rule out a
local environmental problem?

On Thu, 19 Nov 2020 at 08:37, James Ko  wrote:

> @Guy.  This is on ubuntu linux distribution.  I'm using Xubuntu 18.04LTS
> and I believe Alastair is on Ubuntu 16.04LTS.
> Assuming the buffer/page/disk cache is not doing the right thing is there
> anything we can try to make sure it's consistent?
>
> @Jaap.  We will be sure to update to the latest release but I don't expect
> this will make much difference as the dumpcap/tshark interface has been
> around for years.
>
> James
>
> On Wed, Nov 18, 2020 at 9:22 PM Guy Harris  wrote:
>
>> On Nov 18, 2020, at 4:25 PM, James Ko  wrote:
>>
>> > I've been helping Alastair debug this problem and this is as far as we
>> got.
>> > I can only think of a race condition between dumpcap completing the
>> packet writing to the file and tshark being able to read the expected
>> number of new packets.
>> >
>> > I do see there is fflush() in capture_loop_write_pcapng_cb() before the
>> capture_loop_wrote_one_packet() which actually increments the number of
>> available packets.
>> >
>> > Do we also need an fsync() here to ensure the data is written to the
>> disk?
>>
>> If this is on UN*X, that would be an issue only if your UN*X is really
>> stupid about managing the buffer/page cache.  I know of no UN*Xes where
>> that's the case.
>>
>> If this is on Windows, I *still* wouldn't expect it to be the case, at
>> least on any Windows NT-based version (and we haven't supported Windos
>> 95/98/Me for a long while, and neither has Microsoft...), as I think it has
>> the same sort of buffer/page cache as most if not all UN*Xes these days
>> have.
>>
>> I.e., if process A is writing to a file, and process B is reading from a
>> file, process B's write should immediately update the buffer/page cache, so
>> process B's read should see it, as long as the read is done after the write.
>>
>> flush() just means "do a write to the underlying file immediately"; it
>> doesn't imply anything more than write() on UN*X or _write() on Windows
>> (which, in turn, turns into a WriteFile() if you're writing in binary
>> mode), so it updates the buffer cache but doesn't necessarily update the
>> file on secondary storage.  mailto:
>> wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>>
>

-- 
Graham Bloice
___
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] Tshark closing unexpectedly due to failure reading from file

[James Ko]

@Guy.  This is on ubuntu linux distribution.  I'm using Xubuntu 18.04LTS
and I believe Alastair is on Ubuntu 16.04LTS.
Assuming the buffer/page/disk cache is not doing the right thing is there
anything we can try to make sure it's consistent?

@Jaap.  We will be sure to update to the latest release but I don't expect
this will make much difference as the dumpcap/tshark interface has been
around for years.

James

On Wed, Nov 18, 2020 at 9:22 PM Guy Harris  wrote:

> On Nov 18, 2020, at 4:25 PM, James Ko  wrote:
>
> > I've been helping Alastair debug this problem and this is as far as we
> got.
> > I can only think of a race condition between dumpcap completing the
> packet writing to the file and tshark being able to read the expected
> number of new packets.
> >
> > I do see there is fflush() in capture_loop_write_pcapng_cb() before the
> capture_loop_wrote_one_packet() which actually increments the number of
> available packets.
> >
> > Do we also need an fsync() here to ensure the data is written to the
> disk?
>
> If this is on UN*X, that would be an issue only if your UN*X is really
> stupid about managing the buffer/page cache.  I know of no UN*Xes where
> that's the case.
>
> If this is on Windows, I *still* wouldn't expect it to be the case, at
> least on any Windows NT-based version (and we haven't supported Windos
> 95/98/Me for a long while, and neither has Microsoft...), as I think it has
> the same sort of buffer/page cache as most if not all UN*Xes these days
> have.
>
> I.e., if process A is writing to a file, and process B is reading from a
> file, process B's write should immediately update the buffer/page cache, so
> process B's read should see it, as long as the read is done after the write.
>
> flush() just means "do a write to the underlying file immediately"; it
> doesn't imply anything more than write() on UN*X or _write() on Windows
> (which, in turn, turns into a WriteFile() if you're writing in binary
> mode), so it updates the buffer cache but doesn't necessarily update the
> file on secondary storage.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe