[tcpdump-workers] uint_XX_t, u_int_XX_t and NFLOG test case
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 automatic builds (linked from www.tcpdump.org), but on one of the servers it sometimes recovered on itself and then failed again. All that said, it never failed in a live shell on the same server. But now it did: Failed test: nflog-e 1,4d0 < version 0, resource ID 20, family IPv4 (2), length 180: 74.82.42.42.53 > 10.0.0.20.42585: 17265 1/0/0 A 93.184.216.119 (45) < version 0, resource ID 20, family IPv4 (2), length 192: 74.82.42.42.53 > 10.0.0.20.45190: 52954 1/0/0 2606:2800:220:6d:26bf:1447:1097:aa7 (57) < version 0, resource ID 20, family IPv4 (2), length 184: 74.82.42.42.53 > 10.0.0.20.44031: 8279 1/0/0 A 93.184.216.119 (49) < version 0, resource ID 20, family IPv4 (2), length 196: 74.82.42.42.53 > 10.0.0.20.48736: 2122 1/0/0 2606:2800:220:6d:26bf:1447:1097:aa7 (61) So, finally it had reproduced at hand and the reason for tcpdump not decoding DLT_NFLOG was that HAVE_PCAP_NFLOG_H was not defined at compile time and the following was in config.log: configure:7341: checking for pcap/nflog.h configure:7341: /usr/gcc/4.3/bin/gcc -c -DINET6 -I/usr/inet6/include -g -O2 -I./../libpcap conftest.c >&5 In file included from conftest.c:71: ./../libpcap/pcap/nflog.h:43: error: expected specifier-qualifier-list before 'u_int8_t' ./../libpcap/pcap/nflog.h:49: error: expected specifier-qualifier-list before 'u_int16_t' ./../libpcap/pcap/nflog.h:55: error: expected specifier-qualifier-list before 'u_int16_t' ./../libpcap/pcap/nflog.h:61: error: expected specifier-qualifier-list before 'u_int16_t' ./../libpcap/pcap/nflog.h:67: error: expected specifier-qualifier-list before 'u_int64_t' configure:7341: $? = 1 The checks for other libpcap headers also failed due to the same error: checking for pcap/bluetooth.h... no checking for pcap/nflog.h... no checking for pcap/usb.h... no 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 are many old libpcap installations around. Other opinions are welcome. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] uint_XX_t, u_int_XX_t and NFLOG test case
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 are many old libpcap installations around. Other opinions are welcome. 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 define u_intXX_t as uintXX_t, for XX = 8, 16, 32, 64, so we're using the new configure tests to appropriately define them. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] uint_XX_t, u_int_XX_t and NFLOG test case
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 define u_intXX_t as uintXX_t, for > XX = 8, 16, 32, 64, so we're using the new configure tests to appropriately > define them. OK, done. It passes the tests on all the platforms The Written Word have, including several flavors of Solaris/AIX/HP-UX. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New LINKTYPE_ for EPON
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 interpret the standard differently, and instead of dumping them out of > the dissector entirely, I thought I could throw them a helpful error with > a hint towards fixing their implementation. I believe the description > should stay the same: that the preamble is 6 octets long with an optional > idle (0x55) octet preceeding, depending on system alignment. 8 octets > would be an error and needs correction in the PON sniffer implementation. If that's what the description says, then the Wireshark dissector should treat frames with two 0x55's as an error, rather than trying to work around them. Wireshark or tcpdump dissectors shouldn't "extend" the description on tcpdump.org; the whole point of those descriptions is to allow people to write dissectors for a given LINKTYPE_/DLT_ value *without* having to look at tcpdump or Wireshark source - if the description doesn't allow somebody to write a program that handles those headers the same way tcpdump or Wireshark do, because they also need to know about special processing tcpdump or Wireshark does, then the description is incomplete and needs to be completed. > Here's the problem as I see it: DPoE is simply an extension of (the unused > and ignored) part of EPON, not a completely different format. But it requires that the header be processed differently; "completely" is irrelevant - the purpose of a LINKTYPE_/DLT_ value is to indicate to the code processing a capture how it should process the header indicated by the value. > Another problem is that EPON and DPoE system equipment can interoperate to > some level, and the PON sniffer has no way of knowing whether the traffic > it's seeing is DPoE or regular EPON. There would be no determine which > LINKTYPE_ to put in the pcap file without human intervention. ... > A piece of equipment > sniffing the data should already know what it's capturing is EPON. Unless I'm missing something, the first of those paragraphs says the hardware *doesn't* know whether the octet in question is 0x55 or an encryption field, so it doesn't know whether it's capturing standard EPON or EPON with the DPoE encryption extension. If that's the case, so that a human has to indicate how the octet should be interpreted in any case, a single LINKTYPE_/DLT_ value is OK. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/libpcap failure
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 article on Coverity Community. Last few lines of cov-int/build-log.txt should indicate 85% or more compilation units ready for analysis For more detail explanation on the error, please check: https://communities.coverity.com/message/4820 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/libpcap success
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.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] New Defects reported by Coverity Scan for the-tcpdump-group/libpcap
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 in fread()
*** CID 711715: Same on both sides (CONSTANT_EXPRESSION_RESULT)
/usr/include/x86_64-linux-gnu/bits/stdio2.h: 279 in fread()
273 __extern_always_inline __wur size_t
274 fread (void *__restrict __ptr, size_t __size, size_t __n,
275FILE *__restrict __stream)
276 {
277 if (__bos0 (__ptr) != (size_t) -1)
278 {
>>> CID 711715: Same on both sides (CONSTANT_EXPRESSION_RESULT)
>>> The expression "1 /* !0 */ || 1 /* !0 */" does not accomplish anything
>>> because it evaluates to either of its identical operands, "1 /* !0 */".
279 if (!__builtin_constant_p (__size)
280 || !__builtin_constant_p (__n)
281 || (__size | __n) >= (((size_t) 1) << (8 * sizeof (size_t) /
2)))
282 return __fread_chk (__ptr, __bos0 (__ptr), __size, __n,
__stream);
283
284 if (__size * __n > __bos0 (__ptr))
To view the defects in Coverity Scan visit,
http://scan.coverity.com/projects/120?tab=Overview
To unsubscribe from the email notification for new defects,
http://scan5.coverity.com/cgi-bin/unsubscribe.py
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/libpcap success
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.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/tcpdump success
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.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/libpcap success
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.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/tcpdump success
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.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/tcpdump success
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.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/libpcap success
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.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Coverity Scan: the-tcpdump-group/tcpdump success
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.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New LINKTYPE_ for EPON
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 caused it to never get to lists.tcpdump.org. Send mail logs please... >> I only put in the first "if" clause because some PON sniffer manufacturers >> may interpret the standard differently, and instead of dumping them out of >> the dissector entirely, I thought I could throw them a helpful error with >> a hint towards fixing their implementation. I believe the description >> should stay the same: that the preamble is 6 octets long with an optional >> idle (0x55) octet preceeding, depending on system alignment. 8 octets >> would be an error and needs correction in the PON sniffer implementation. > If that's what the description says, then the Wireshark dissector > should treat frames with two 0x55's as an error, rather than trying to > work around them. > Wireshark or tcpdump dissectors shouldn't "extend" the description on > tcpdump.org; the whole point of those descriptions is to allow people > to write dissectors for a given LINKTYPE_/DLT_ value *without* having > to look at tcpdump or Wireshark source - if the description doesn't > allow somebody to write a program that handles those headers the same > way tcpdump or Wireshark do, because they also need to know about > special processing tcpdump or Wireshark does, then the description is > incomplete and needs to be completed. +5 >> A piece of equipment >> sniffing the data should already know what it's capturing is EPON. > Unless I'm missing something, the first of those paragraphs says the > hardware *doesn't* know whether the octet in question is 0x55 or an > encryption field, so it doesn't know whether it's capturing standard > EPON or EPON with the DPoE encryption extension. > If that's the case, so that a human has to indicate how the octet > should be interpreted in any case, a single LINKTYPE_/DLT_ value is > OK. But, if the human has to say which thing is being captured, shouldn't we want to capture what the human thought as different types? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Coverity Scan: the-tcpdump-group/libpcap success
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 makes me return to a web site. I guess I'll turn them off. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New LINKTYPE_ for EPON
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 > that field is just part of the preamble, and LINKTYPE_DPON or > LINKTYPE_CABLELABS_DPOE, in which it's an encryption enabled/key ID field > > or > > 2) if that field will *never* have the value 0x55 in a DPoE capture, > and will *always* have the value 0x55 in a regular EPON capture, use that to > determine what the field is. According to http://www.cablelabs.com/wp-content/uploads/specdocs/DPoE-SP-SECv2.0-I03-140327.pdf (BTW, 5 googolplex cheers to CableLabs for not putting their specifications behind a @#$%@@$$# paywall!), the octet before the LLID will always have the bit value 010101EK, where E is the "Enc", or "data transferred is cypher text" bit, and "K" is the "key identification number used to encrypt the frame", with the number in question being either 0 or 1, obviously. So a value of 0x55, i.e. 01010101, has the "data transferred is cypher text" bit clear, and the "key identification number" bit being 1 but presumably being *irrelevant*, as the "data transferred is cypher text" bit is clear and the frame is *not* encrypted. Furthermore, the spec also says "When encryption is disabled, the DPoE System MUST set the 1Down security octet to a value of 0x55." 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 not encrypted; if that octet is 0x54, report it as an error, as encryption is disabled but the security octet is *not* 0x55; if that octet is 0x56, report it as "encryption enabled, key ID 0", and treat the frame as encrypted; if that octet is 0x57, report it as "encryption enabled, key ID 1", and treat the frame as encrypted; with no preference needed? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New LINKTYPE_ for EPON
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 not encrypted; > > if that octet is 0x54, report it as an error, as encryption is disabled > but the security octet is *not* 0x55; > > if that octet is 0x56, report it as "encryption enabled, key ID 0", and > treat the frame as encrypted; > > if that octet is 0x57, report it as "encryption enabled, key ID 1", and > treat the frame as encrypted; > > with no preference needed? Or, as per 6.2 "10G Zero-Overhead Cipher Suite (10Down, 10Bi)" (hey, I'll take 10Gb to the home, or even the neighborhood!): if that octet has the value 01010101, show it as a preamble octet, and treat the frame as not encrypted; if that octet has the value XX00, where XX is not 010101, report it as an error, as encryption is disabled but the security octet is *not* 0x55; if that octet has the value XX10, report it as "encryption enabled, key ID 0", treat the frame as encrypted, and show XX as "LSB of the MPCP time of the frame DA at the transmitter"; if that octet has the value XX11, report it as "encryption enabled, key ID 1", treat the frame as encrypted, and show XX as "LSB of the MPCP time of the frame DA at the transmitter". ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
