On Apr 23, 2014, at 9:02 PM, Guy Harris wrote:
> So is there any technical reason *not* to dissect the frame by:
>
> if that octet doesn't have the upper 6 bits as 010101, report it as an
> error;
>
> if that octet is 0x55, show it as a preamble octet, and treat the frame
> as no
On Apr 22, 2014, at 2:29 PM, Guy Harris wrote:
> In addition, the code *still* has a preference to indicate whether the octet
> preceding the mode/LLID is just 0x55 or an encryption enabled/key ID field.
> Either
>
> 1) there should be *two* LINKTYPE_ values - LINKTYPE_EPON, in which
scan-ad...@coverity.com wrote:
> Your request for analysis of the-tcpdump-group/libpcap has been
> completed. The results> should be available now at
> http://scan.coverity.com/
wow, that's a stupidly useless message.
The URL isn't even specific to the project or the run, and it
Guy Harris wrote:
>> I sent this to the list -- twice -- but it never showed up, so I'll just
>> resend it to you. I don't know what's going on.
> Moderation? Michael?
Nothing in the local queue.
Nothing in spam trap. That suggests that your email failed SPF or something
that caus
Your request for analysis of the-tcpdump-group/tcpdump has been completed. The
results
should be available now at http://scan.coverity.com/
Please report any errors to scan-ad...@coverity.com.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcp
Your request for analysis of the-tcpdump-group/libpcap has been completed. The
results
should be available now at http://scan.coverity.com/
Please report any errors to scan-ad...@coverity.com.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcp
Your request for analysis of the-tcpdump-group/tcpdump has been completed. The
results
should be available now at http://scan.coverity.com/
Please report any errors to scan-ad...@coverity.com.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcp
Your request for analysis of the-tcpdump-group/tcpdump has been completed. The
results
should be available now at http://scan.coverity.com/
Please report any errors to scan-ad...@coverity.com.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcp
Your request for analysis of the-tcpdump-group/libpcap has been completed. The
results
should be available now at http://scan.coverity.com/
Please report any errors to scan-ad...@coverity.com.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcp
Your request for analysis of the-tcpdump-group/tcpdump has been completed. The
results
should be available now at http://scan.coverity.com/
Please report any errors to scan-ad...@coverity.com.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcp
Your request for analysis of the-tcpdump-group/libpcap has been completed. The
results
should be available now at http://scan.coverity.com/
Please report any errors to scan-ad...@coverity.com.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcp
Hi,
Please find the latest report on new defect(s) introduced to
the-tcpdump-group/libpcap found with Coverity Scan.
Defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 711715: Same on both sides (CONSTANT_EXPRESSION_RESULT)
/usr/include/x86_64-linux-gnu/bits/stdio2.h: 279
Your request for analysis of the-tcpdump-group/libpcap has been completed. The
results
should be available now at http://scan.coverity.com/
Please report any errors to scan-ad...@coverity.com.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcp
Your request for analysis of the-tcpdump-group/libpcap is failed.
Analysis status: FAILURE
Please fix the error and upload the build again.
Error details:
Build uploaded has not been compiled fully. Please fix any compilation error.
You may have to run bin/cov-configure as described in the arti
On Apr 23, 2014, at 6:58 AM, Philip Rosenberg-Watt
wrote:
> I sent this to the list -- twice -- but it never showed up, so I'll just
> resend it to you. I don't know what's going on.
Moderation? Michael?
> I only put in the first "if" clause because some PON sniffer manufacturers
> may inter
On Apr 23, 2014, at 10:24 AM, Guy Harris wrote:
> I made the change because a 64-bit build on Solaris 8 had to define u_int64_t
> but defined it as "unsigned long long int", which collided with the
> "%l[doux]" that was used as the print format.
>
> Probably the right thing to do here is to d
On Apr 23, 2014, at 3:46 AM, Denis Ovsienko wrote:
> Updating these headers to use uint_XX_t instead of u_intXX_t fixes respective
> detection and the NFLOG test case in particular but it seems tcpdump should
> tolerate the u_intXX_t types from libpcap for indefinitely longer time as
> there
Greetings.
After the recent u_intXX_t type elimination in tcpdump I did a test build on an
OpenIndiana x86_64 VM (which identifies itself as SunOS 5.11) and suddenly it
failed on the NFLOG test case. Interestingly, that test case not just used to
fail on OpenCSW Solaris 10 build servers during
18 matches
Mail list logo
