On Saturday, July 20, 2019, 9:10:36 AM, Tomasz Mon wrote:
> On Sat, Jul 20, 2019 at 5:37 AM Tomasz Mon wrote:
>> The advantage of 1) over 2) is the ability to be able, if the CRC is
>> incorrect, to tell what the correct CRC should have been.
>> Approach 2) allows only to veify if the CRC is corre
On Sunday, July 21, 2019, 6:37:48 AM, Tomasz Mon wrote:
> On Sat, Jul 20, 2019 at 8:42 PM John Sullivan wrote:
>> But here we have a fixed 11 bit input
> I am sorry, but I have completely missed out there there are two
> places where CRC5 is calculated:
> * In SETUP, OUT, IN
https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html
On Wednesday, April 15, 2020, 2:54:06 AM, Gerald Combs wrote:
> One the cool things about SharkFest is the Developer Den. It's an open
> meeting room where developers hack on code, and where everyone is invited to
> drop in a
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 interactio
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
[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
Haha! Yes.
The problem is triggered by the specific value you have: 64dad964
Note that the first and fourth bytes are the same, and the second and
third bytes are almost the same.
That value is on the wire here in little-endian order. The problem being
both orders are possible and wireshark doe
On Monday, April 7, 2014, 2:33:08 PM, "ÎÒÏë²»ÎÞÁÄ" wrote:
> why is the ack number of several ack frame in tcp transmission the same?Is
> that the ack of several tcp segments?if so,how to calculate the bytes of data
> that been received every time?
Two possible reasons:
1) The data segments got
On Sunday, June 29, 2014, 12:43:39 PM, Toralf Förster wrote:
> /mew wonders if wireshark should print a warning if a http traffic goes
> over port 443 (eg a TRAC temporarily configured at that port instead of
> 80) but is not encrypted, currently those packets are marked as "SSL"
> but they aren't
On Wednesday, October 29, 2014, 6:42:00 PM, Jeff Morriss wrote:
> On 10/28/14 11:12, ?? wrote:
>> Hi ,
>>
>> If the server does not support 'Window Scale' option, even the
>> client send one packet with WS=256, I thought the real window size
>> should be consider small than 64K.But I can s
On Thursday, November 20, 2014, 4:07:33 PM, ?? wrote:
> Is it possible to get accurate nanosecond info for lua script ? For the
> same packet , I got pinfo.abs_ts == 1416493696.7953 in lua script , but in
> main window the time show as "1416493696.795345000",is it possible to
> got the ac
On Friday, November 28, 2014, 7:13:26 PM, Peter Wu wrote:
> Hi all,
> I mostly use Wireshark GTK, but just tried the Qt UI again. A recurring
> problem was an ASAN crash on shutdown. It turns out that there are many
> users of this pattern:
> recent_add_cfilter(NULL, currentText().toUtf8().co
Given a two packet sequence, with one pdu occupying the whole first
packet plus part of the second, followed by another pdu in the second
packet:
On first first call to get_pdu_len(), a greater number than
tvb_length() is returned. The tcp dissector goes away and waits for
more data. Eventually g
On Monday, June 23, 2008, 6:38:16 PM, Martin Corraine (mcorrain) wrote:
> In the readme.developer, it states you shouldn't use "tvb_get_ntohl(tvb,
> offset);" I tried using tvb_get_letohl (tvb, offset);" However, it
> retrieves the data backwards thus retrieving the wrong value. Any
> suggestions
On Wednesday, July 9, 2008, 5:47:45 PM, Yunfan (Andy) Ying wrote:
> #ifndef _WIN32
> #define INET6_ADDRSTRLEN 46
> #endif
It's probably better to directly #ifndef INET6_ADDRSTRLEN rather than
assume that symbol will always be available alongside _WIN32. (The VS6
built-in headers have all the oth
On Wednesday, September 24, 2008, 6:51:17 AM, Xiao Li wrote:
> Oh, I didn't know the trick of modifying the permission of dumpcap
> -Thanks for pointing this out.
If you setuid root dumpcap, you should probably make sure it's chowned
to root and chgrp it to a limited supplementary group containing
On Thursday, October 16, 2008, 9:56:03 PM, Ramesh Sankaranarayanan wrote:
> The build appeared to run its course( all the packet dissector files were
> compiled) and ended up finally with this error:
> bash -o igncr pod2html --title="The Wireshark
> Network Analyzer 1.1
On Thursday, October 16, 2008, 11:41:07 PM, Bill Meier wrote:
> There are about 300+ non-generated epan/dissector source files which
> include stdio.h and/or stdlib.h
> I've successfully done both a Linux and a Windows build with these
> includes removed from epan/dissector/...
Under which comp
[resend - sorry if you get a dupe!]
On Thursday, October 16, 2008, 10:22:48 PM, Anders Broman wrote:
> Gussing something with Perl?
> Your path perl: /cygdrive/c/Perl/bin/perl
> Mine:
> perl: /usr/bin/perl do you have Cygwin Perl?
Ooh, ooh! I might have an idea here:
ActiveState ActivePerl cu
On Thursday, October 16, 2008, 10:22:48 PM, Anders Broman wrote:
> Gussing something with Perl?
> Your path perl: /cygdrive/c/Perl/bin/perl
> Mine:
> perl: /usr/bin/perl do you have Cygwin Perl?
Ooh, ooh! I might have an idea here:
ActiveState ActivePerl currently installs itself under C:\Perl
On Friday, October 17, 2008, 1:16:42 PM, Ramesh Sankaranarayanan wrote:
> To answer your 2 questions, here is what I see:
> C:\Wireshark>bash bash-3.2$ bash -o igncr echo
> bash: /usr/bin/echo: No such file or directory
Ah yes, I forgot it should be "-c echo". However no matter, the result
shows t
On Monday, October 20, 2008, 8:26:17 PM, [EMAIL PROTECTED] wrote:
> Here's the output I see for your questions:
> 1) C:\wireshark>ls -dl /usr/bin/pod2html*
> lrwxrwxrwx 1 ramesh.sankar mkgroup_l_d 14 Oct 17 14:43 /usr/bin/pod2html ->
> pod2html5.10.0
> --+ 1 ramesh.sankar mkgroup_l_d 2350
On Tuesday, October 12, 2010, 3:27:09 PM, Jeff Morriss wrote:
> I think composite tvbuffs probably do work, but their use is hindered by
> the fact that each tvb that you get (each time a frame is handed to your
> dissector) is freed/reused after the packet is dissected. That is,
> Wireshark doe
On Thursday, March 24, 2011, 8:57:42 PM, Chris Maynard wrote:
> Alexis La Goutte writes:
>> What it the official solution to fix this ?
>> 1) Remove the code
>> 2) Ignore this warning
>> 3) Comment the code add a
>> /* offset += 1; Remove Clang Dead increment */
> Or ... convert the di
On Thursday, May 5, 2011, 9:06:27 PM, Chris Maynard wrote:
> Fernandez, Rafael writes:
>> There are only TCP packets in my capture file.
> That may be true, but as described in the doc/README.developer file in section
> 1.2 Skeleton code,
>A protocol dissector may be called in 2 different w
25 matches
Mail list logo
