Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add --time-t-size option to print the size of time_t in bits #1147

Merged
merged 2 commits into from
Sep 27, 2024

Conversation

fxlb
Copy link
Member

@fxlb fxlb commented Mar 12, 2024

Have tests/TESTrun run "./tcpdump --time-t-size and set HAVE_TIME_T_64
key based on that.

This will permit to run tests based on time_t size (32-bit or 64-bit).

Also:

Add eight time test files with packet dates in 2038, 2039, 2106 and 2107

Each capture file contains one packet.

time_2038.pcap: 2038-01-01 00:00:00
time_2038_max.pcap: 2038-01-19 03:14:07
time_2038_overflow.pcap: 2038-01-19 03:14:08
time_2039.pcap: 2039-01-01 00:00:00
time_2106.pcap: 2106-01-01 00:00:00
time_2106_max.pcap: 2106-02-07 06:28:15
time_2106_overflow.pcapng: 2106-02-07 06:28:16
time_2107.pcapng: 2107-01-01 00:00:00

The packet time when > 2038-01-19T03:14:07Z cannot be correctly printed
if time_t size is 32 bits (overflow).
Some tests are run only if HAVE_TIME_T_64 is set. it depends on the
output of "./tcpdump --time-t-size" (32 or 64).

A 32-bit unsigned time_t goes until 2106-02-07T06:28:15Z.
All values above require a pcapng file.

@fxlb fxlb marked this pull request as draft March 12, 2024 17:30
@fxlb fxlb force-pushed the sizeof_time_t branch 6 times, most recently from ceb3e95 to 3b6ff61 Compare March 16, 2024 16:38
@fxlb fxlb force-pushed the sizeof_time_t branch 3 times, most recently from e0a36cd to 5c09904 Compare March 22, 2024 12:57
@fxlb
Copy link
Member Author

fxlb commented Sep 17, 2024

Test on linux-armv7l with autoconf 2.72.
libpcap: Add AC_SYS_YEAR2038_RECOMMENDED in configure.ac. ./configure shows: checking size of time_t... 8
tcpdump: Add AC_SYS_YEAR2038_RECOMMENDED in configure.ac. ./configure shows: checking size of time_t... 8.
tcpdump --version shows: 32-bit build, 64-bit time_t
make check shows: 0 tests failed

(In libpcap, AC_SYS_LARGEFILE can be remove if AC_SYS_YEAR2038_RECOMMENDED is added.)

Tested also with libpcap version 1.10.5 and tcpdump version 4.99.5 (same patch): 0 tests failed

$ ./tcpdump --version
tcpdump version 4.99.5
libpcap version 1.10.5 (with TPACKET_V3)
OpenSSL 3.0.2 15 Mar 2022
SMI-library: 0.4.8
32-bit build, 64-bit time_t

@fxlb
Copy link
Member Author

fxlb commented Sep 17, 2024

Test on linux-mips with autoconf 2.72.
libpcap: Add AC_SYS_YEAR2038_RECOMMENDED in configure.ac. ./configure shows:
checking for gcc option to enable large file support... -D_FILE_OFFSET_BITS=64
checking for gcc option for timestamps after 2038... support not detected
configure: error: in '/home/buildbot-worker/tmp/libpcap':
configure: error: could not enable timestamps after mid-January 2038.
This package recommends support for these later
timestamps. However, to proceed with signed 32-bit
time_t even though it will fail then, configure with
'--disable-year2038'.

$ apt list libc6-dev
libc6-dev/oldoldstable,now 2.28-10+deb10u1 mips [installed,automatic]

2.28 < 2.34, minimal version to support the preprocessor macro _TIME_BITS (to have support with -D_TIME_BITS=64).

@fxlb fxlb changed the title [TEST ONLY] CI test to print sizeof(time_t) on various hosts [TEST ONLY] CI test for support for ensuring time_t is Y2038-safe Sep 17, 2024
@infrastation
Copy link
Member

For reference, MC includes a lot in the --version output, because it is also a project with a long history of portability:

GNU Midnight Commander 4.8.28
Built with GLib 2.80.3
Built with S-Lang 2.2.4 with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, fish
Data types:
 char: 8; int: 32; long: 32; void *: 32; size_t: 32; off_t: 64;

Have tests/TESTrun run "./tcpdump --time-t-size and set HAVE_TIME_T_64
key based on that.

This will permit to run tests based on time_t size (32-bit or 64-bit).
@fxlb fxlb force-pushed the sizeof_time_t branch 5 times, most recently from da7d8f4 to 78ee203 Compare September 26, 2024 18:53
Each capture file contains one packet.

time_2038.pcap:		   2038-01-01 00:00:00
time_2038_max.pcap:	   2038-01-19 03:14:07
time_2038_overflow.pcap:   2038-01-19 03:14:08
time_2039.pcap:		   2039-01-01 00:00:00
time_2106.pcap:		   2106-01-01 00:00:00
time_2106_max.pcap:	   2106-02-07 06:28:15
time_2106_overflow.pcapng: 2106-02-07 06:28:16
time_2107.pcapng:	   2107-01-01 00:00:00

The packet time when > 2038-01-19T03:14:07Z cannot be correctly printed
if time_t size is 32 bits (overflow).
Some tests are run only if HAVE_TIME_T_64 is set. it depends on the
output of "./tcpdump --time-t-size" (32 or 64).

A 32-bit unsigned time_t goes until 2106-02-07T06:28:15Z.
All values above require a pcapng file.
@fxlb fxlb changed the title [TEST ONLY] CI test for support for ensuring time_t is Y2038-safe Add --time-t-size option to print the size of time_t in bits Sep 27, 2024
@fxlb
Copy link
Member Author

fxlb commented Sep 27, 2024

(After this PR more steps are needed for Y2038-safety.)

@fxlb fxlb marked this pull request as ready for review September 27, 2024 14:40
@fxlb fxlb merged commit a41457a into the-tcpdump-group:master Sep 27, 2024
20 checks passed
@fxlb fxlb deleted the sizeof_time_t branch September 27, 2024 21:32
samuel40791765 added a commit to aws/aws-lc that referenced this pull request Dec 12, 2024
The CI issues we've been having stems from some new tests tcpdump has
for the upcoming 2038 problem. However, these tests will fail with
outdated versions of libpcap that don't support the preprocessor macro
`_TIME_BITS` (Documented in
the-tcpdump-group/tcpdump#1147)

**Tcpdump's fixed the issue when running release-check:
the-tcpdump-group/tcpdump@0546e6a.
Release-check already runs with check and runs all the tests, but with a
more defined process.**
Since upstream's just running release-check to encapsulate everything, I
think we can just run release-check here to get rid of CI issues.

### Call-outs:
N/A

### Testing:
CI

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.
torben-hansen pushed a commit to torben-hansen/aws-lc that referenced this pull request Dec 13, 2024
The CI issues we've been having stems from some new tests tcpdump has
for the upcoming 2038 problem. However, these tests will fail with
outdated versions of libpcap that don't support the preprocessor macro
`_TIME_BITS` (Documented in
the-tcpdump-group/tcpdump#1147)

**Tcpdump's fixed the issue when running release-check:
the-tcpdump-group/tcpdump@0546e6a.
Release-check already runs with check and runs all the tests, but with a
more defined process.**
Since upstream's just running release-check to encapsulate everything, I
think we can just run release-check here to get rid of CI issues.

### Call-outs:
N/A

### Testing:
CI

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license and the ISC license.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants