update autotools files #68
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At least according to the Wireshark STP dissector, SNAP frames with the Cisco OUI and a PID of 0x010c contain BPDUs, for "VLAN Bridge".
When compressing output with -z, we do so by creating a child process to run gzip and pipe to it, and we catch SIGCHLD to clean up after the child process. We don't want the SIGCHLD to show up as an "Interrupted system call" error, so we specify that SIGCHLD should restart, rather than interrupting, system calls.
Some of those warnings are real bugs - some routines whose callers expected them to return values weren't returning values.
…itories. We've created a the-tcpdump-group organization on GitHub, and created repositories for libpcap and tcpdump, owned by them. Those are now the "official" GitHub locations for repositories from which to clone or against which to file issues/pull requests.
Added: * option length check * option type and TCP flags check * more information printed Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Avoid dereferencing rx_cache[RX_CACHE_SIZE], which is one past the last valid element. (This fixes SF bug 3599633 / GH bug 287. I could not identify the name or email address of the original contributor. -- Denis)
- Rename option 31 as SNTP_SERVERS (see RFC4075) - Add decoder for option 56 (NTP_SERVER) from RFC5908
DHCPv6 decoder update
Update .gitignore: add autom4te.cache/
I modified the mac80211 and ath9k kernel module such that extra information regarding rssi, etc are available, which is why I needed the extra bitmap. Capturing the packets is simply a matter of using tcpdump -i wlan0 -w dumpfile.
This bug was discovered and pinned down by Wim Torfs. The code in question handles DLT_IEEE802_11_RADIO datalink type, which consists of a variable-sized header, a variable number of fields and the actual 802.11 frame. The integers contained in the fields are aligned, properly extracting them is exactly the purpose of the existing "cpack" module. The issue with the current code is that it sets alignment base for cpack at the end of the variable-sized header, in other words, 64-bit integers would be properly extracted only so long as the header is 64-bit long, which only happens when the total number of bitmaps in it is odd (the minimum number of bitmaps is one). Once this condition isn't met, as is with two bitmaps, decoding becomes incorrect. The reporter's point that the alignment base must be the beginning of the variable-sized header is accurate. This commit adds a new cpack_advance() function to fast-forward the "c_next" pointer of a cpack_state context by an arbitrary number of octets. The ieee802_11_radio_print() function now uses it to skip the header and all its bitmaps, and the alignment base is now the header start.
- In dhcp6opt_print() constify tp - Add decoder for option 21 (SIP_SERVER_D - RFC3319)
DHCPv6 decoder update
Added: * option length check * option type and TCP flags check * more information printed Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
…6,32}. Bitfields are not one of C's shining points. There is *NO* guarantee in what order bitfields are put within a structure - it's *NOT* necessarily the same as the byte order of the machine, and it's *ESPECIALLY* not guaranteed to be correlated with the value of the LBL_ALIGN definition (that definition has to do with whether unaligned accesses are supported by the hardware). In addition, even if they're declared as unsigned, that doesn't mean they're guaranteed to *be* unsigned. Don't use them. Unaligned accesses are not guaranteed to work, and fields in packets are not guaranteed to be naturally aligned. Use the EXTRACT_nBITS() macros. __attribute((packed))__ is a GCCism, and is not guaranteed to be supported by all compilers with which tcpdump can be compiled. Make integral fields > 1 byte arrays of u_int8_t's (which also lets us avoid the & in the EXTRACT_nBITS() macros). Some systems don't define the PRI[doux]16 and PRI[doux]32 macros, and others define them infelicitously (i.e., for PRI[doux]32, with an "l"; our 32-bit integer types are *not* longs, as we don't care about 16-bit-"int" platforms).
Avoid dereferencing rx_cache[RX_CACHE_SIZE], which is one past the last valid element. (This fixes SF bug 3599633 / GH bug 287. I could not identify the name or email address of the original contributor. -- Denis)
- Rename option 31 as SNTP_SERVERS (see RFC4075) - Add decoder for option 56 (NTP_SERVER) from RFC5908
So don't use it; it's not necessary on any of the platforms on which we work. (The *only* ones that are needed are PRI[doux]64, because sometimes you need %ll[doux], sometimes you need %l[doux], and with MSVC you need whatever its run-time library requires.)
On AIX 5.1, at least when compiling with xlc, the statement
struct mp_remove_addr *rem_addr = (struct mp_remove_addr *) opt;
gets a complaint "Syntax error: possible missing '{'?"
"/usr/include/sys/xmem.h" #defines rem_addr; I've no idea whether we're
indirectly including that, but maybe we are and maybe that's causing the
problem.
- Add decoder for option 24 (DOMAIN_LIST) - Rename option 23 as DNS_SERVERS - Rename option 24 as DOMAIN_LIST - In dhcp6opt_print() constify dh6o
This bug was discovered and pinned down by Wim Torfs. The code in question handles DLT_IEEE802_11_RADIO datalink type, which consists of a variable-sized header, a variable number of fields and the actual 802.11 frame. The integers contained in the fields are aligned, properly extracting them is exactly the purpose of the existing "cpack" module. The issue with the current code is that it sets alignment base for cpack at the end of the variable-sized header, in other words, 64-bit integers would be properly extracted only so long as the header is 64-bit long, which only happens when the total number of bitmaps in it is odd (the minimum number of bitmaps is one). Once this condition isn't met, as is with two bitmaps, decoding becomes incorrect. The reporter's point that the alignment base must be the beginning of the variable-sized header is accurate. This commit adds a new cpack_advance() function to fast-forward the "c_next" pointer of a cpack_state context by an arbitrary number of octets. The ieee802_11_radio_print() function now uses it to skip the header and all its bitmaps, and the alignment base is now the header start.
Clean up white space, just add 104 (the length of the NFLOG header) to the pointer, and return the length of the NFLOG header from nflog_if_print(). Mark the caplen argument to nflog_print() as unused.
The while loop in of10_queue_stats_reply_print() decremented the remaining length by 104 instead of 32. As soon as that happened the decoding didn't proceed/stop in a normal way and was likely to hit snapend. Fixed.
Conflicts: Makefile.in
Typo in a printed text. Closes the-tcpdump-group#321
Fix a strict-aliasing GCC warning in addrtoname.c
Some versions of Sun C support __attribute__ but don't support the "unused" or "format" attributes - they don't fail, but they whine a lot. They also support the "noreturn" attribute, but don't allow it to be applied to function pointers, only to functions. Check whether they can be used without warnings, and use them only if they can.
Remove the vast majority of strict-aliasing warnings from GCC. Make the EXTRACT_ macros inline functions instead.
Pull changes from the GitHub repository.
(At that point, we've already checked whether rc is < 0, so we know it's not.)
Fix the CHANGES list by moving some changes that got in after the 4.4.0 release was made into a list for 4.4.1, and add some additional fixes to that list.
Don't assume we have <stdint.h>. Instead, use the AC_TYPE_ macros to ensure we have the C99 intN_t and uintN_t types; we already include <inttypes.h> in tcpdump-stdinc.h iff we have it. Get rid of the structure declarations in openflow-1.0.h, as they have zero-length arrays (not supported by all the compilers people might be using) and as 1) they're only used in sizeof() and 2) after each one there's an assertion to check that sizeof() returns a specific numerical value so, instead, just #define various _LEN items to those numerical values and use them. Add an openflow.h header with a #define for the length of the basic header, and move the declaration of of10_header_body_print() there.
The first revision of the header file was copied from the original distribution tarball intact to use sizeof() instead of adding new constants on one hand and provide structure definitions for a reference on the other. But as soon as the structures had a portability issue and were removed in commit a6c16ed, the remaining fragments of the header don't justify for a file of its own. This commit maps all relevant bits of the remaining contents of openflow-1.0.h to constants in print-openflow-1.0.c (all being specific to version 1.0 of OpenFlow) and removes the file.
openflow.h in tcpdump doesn't belong to the openflow distribution and shouldn't be attributed to stanford.edu (probably a copy-and-paste case). Replace with 2-clause BSD.
Geonet and calmfast
(the issue was discovered by Gisle Vanem) netinet/in.h shouldn't be included during a Windows compile. The fix is to remove the #include from print-carp.c and let tcpdump-stdinc.h do its job.
It didn't work out-of-the box because my MSVC (v16 from Visual C Express 2010) isn't a C99 compiler; you cannot have code ahead of declarations.
On UN*X, <tcpdump-stdinc.h> already includes it; on Windows, it doesn't exist, and therefore shouldn't be included. Thanks and a tip of the Hatlo hat to Gisle Vanem for this.
The changes mostly avoid using old autotools macros, which are not recommended to be used with newer releases and will be eventually removed.
|
Please re-submit this at https://github.com/the-tcpdump-group/tcpdump; that's now the Official(TM) GitHub repository for tcpdump. |
|
Looks like tcpdump has started using cmake as build system, so there is no point fixing autotools. |
|
libpcap and tcpdump offer both autotools and CMake. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some of the autotools files were quite old, so I am proposing to put a bit new ones in place. In theory the newer copies should have fewer bugs. And as all of the scripts are took from the same version of autoconf, 2.69, they were tested by upstream guys as a combination.