How to get absolute system time in tcpdump output from interface in monitor mode?

tim11g

3/26/24, 4:46 PM

I'm using Ubuntu 22.10 with a wireless interface (Netgear AXE3000, driver mt7921u) in monitor mode, capturing packets with tcpdump (since airodump-ng does not capture the radiotap header).

I start the capture within a script with this command: sudo tcpdump -i $1 -n -w pcap/tcpdump_$5_$4_ch$2.pcap

The pcap file shows relative timestamps starting with 0.000. I would like to display absolute system time. Precision is not critical, +/1 a few seconds is fine.

In the tcpdump man page, I read "-tttt Print a timestamp, as hours, minutes, seconds, and fractions of a second since midnight, preceded by the date, on each dump line."

I have tried the command like this sudo tcpdump -tttt -i $1 -n -w pcap/tcpdump_$5_$4_ch$2.pcap. The output still contains relative timestamp as a single number in the pcap output.

I tried tcpdump --list-time-stamp-types, which only lists the enp0s31f6 Ethernet interface as "Adapter unsynced". It does not list the wlan0mon interface I'm capturing from at all.

Do I need sync the Ethernet interface to system time? If so how? Would it then be possible to sync to Ethernet while capturing from the wlan0mon interface?

1 + 0

sync

networking

tcpdump

Score:0

Ubuntu

Doug Smythies

3/26/24, 5:14 PM

When using the -w directive with tcpdump for writing out a binary file, some of the other directives become meaningless and unused, as dictated by the pcap format. You can use tcpdump again to read the binary file and use the desired command line options.

Example 1, use an intermediate binary file:

doug@s15:~$ sudo tcpdump -i br0 -c 20 -w example1.bin -Z doug
tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20 packets captured
23 packets received by filter
0 packets dropped by kernel
doug@s15:~$ ls -l ex*
-rw-r--r-- 1 doug doug 3058 Mar 26 10:11 example1.bin
doug@s15:~$ tcpdump -n -tttt -r example1.bin
reading from file example1.bin, link-type EN10MB (Ethernet), snapshot length 262144
2023-03-26 10:11:04.180583 IP 192.168.111.1.22 > 192.168.111.122.49902: Flags [P.], seq 2415497751:2415497875, ack 2843214249, win 501, length 124
2023-03-26 10:11:04.235389 IP 192.168.111.122.49902 > 192.168.111.1.22: Flags [.], ack 124, win 1024, length 0
2023-03-26 10:11:04.732544 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:11:04.839004 IP 192.168.111.123.45565 > 52.212.137.244.5223: Flags [P.], seq 929499870:929499920, ack 2175724221, win 274, options [nop,nop,TS val 1742330 ecr 4192344644], length 50
2023-03-26 10:11:04.987732 IP 52.212.137.244.5223 > 192.168.111.123.45565: Flags [P.], seq 1:47, ack 50, win 138, options [nop,nop,TS val 4192384644 ecr 1742330], length 46
2023-03-26 10:11:04.989452 IP 192.168.111.123.45565 > 52.212.137.244.5223: Flags [.], ack 47, win 274, options [nop,nop,TS val 1742367 ecr 4192384644], length 0
2023-03-26 10:11:05.129238 IP 192.168.111.123.43952 > 192.168.111.255.15600: UDP, length 35
2023-03-26 10:11:06.733610 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:11:07.936307 ARP, Request who-has 192.168.111.1 tell 192.168.111.124, length 46
2023-03-26 10:11:07.936331 ARP, Reply 192.168.111.1 is-at f4:6d:04:65:2d:8e, length 28
2023-03-26 10:11:08.734974 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:11:09.499809 ARP, Request who-has 192.168.111.1 tell 192.168.111.137, length 46
2023-03-26 10:11:09.499825 ARP, Reply 192.168.111.1 is-at f4:6d:04:65:2d:8e, length 28
2023-03-26 10:11:10.202306 ARP, Request who-has 192.168.111.123 tell 192.168.111.1, length 28
2023-03-26 10:11:10.204729 ARP, Reply 192.168.111.123 is-at 64:1c:ae:dc:c0:d3, length 46
2023-03-26 10:11:10.737445 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:11:11.128335 IP 192.168.111.123.54112 > 192.168.111.255.15600: UDP, length 35
2023-03-26 10:11:12.738204 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:11:14.740411 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:11:16.743034 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204

Example 2, no intermediate binary file, but save the text file:

doug@s15:~$ sudo tcpdump -tttt -n -i br0 -c 20 > example.txt
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20 packets captured
41 packets received by filter
0 packets dropped by kernel
doug@s15:~$ ls -l example.txt
-rw-r--r-- 1 doug doug 2220 Mar 26 10:13 example.txt
doug@s15:~$ cat example.txt
2023-03-26 10:13:23.532099 IP 192.168.111.1.22 > 192.168.111.122.49902: Flags [P.], seq 2415508519:2415508707, ack 2843217909, win 501, length 188
2023-03-26 10:13:23.579772 IP 192.168.111.122.49902 > 192.168.111.1.22: Flags [.], ack 188, win 1022, length 0
2023-03-26 10:13:24.845673 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:13:26.846690 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:13:28.847504 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:13:29.152613 IP 192.168.111.123.55236 > 192.168.111.255.15600: UDP, length 35
2023-03-26 10:13:30.345180 IP 192.168.111.122.5353 > 224.0.0.251.5353: 0 PTR (QU)? _microsoft_mcc._tcp.local. (43)
2023-03-26 10:13:30.345780 IP6 fe80::27aa:2026:cbf8:31f.5353 > ff02::fb.5353: 0 PTR (QU)? _microsoft_mcc._tcp.local. (43)
2023-03-26 10:13:30.451259 IP 192.168.111.116.55008 > 66.110.49.114.443: Flags [.], seq 1684558270:1684558271, ack 2253231177, win 63805, length 1
2023-03-26 10:13:30.514875 IP 66.110.49.114.443 > 192.168.111.116.55008: Flags [.], ack 1, win 63672, length 0
2023-03-26 10:13:30.849755 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:13:31.346486 IP 192.168.111.122.5353 > 224.0.0.251.5353: 0 PTR (QM)? _microsoft_mcc._tcp.local. (43)
2023-03-26 10:13:31.346756 IP6 fe80::27aa:2026:cbf8:31f.5353 > ff02::fb.5353: 0 PTR (QM)? _microsoft_mcc._tcp.local. (43)
2023-03-26 10:13:32.849965 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:13:33.526249 ARP, Request who-has 192.168.111.1 tell 192.168.111.137, length 46
2023-03-26 10:13:33.526266 ARP, Reply 192.168.111.1 is-at f4:6d:04:65:2d:8e, length 28
2023-03-26 10:13:34.851497 IP 192.168.111.123.8001 > 224.0.0.7.8001: UDP, length 204
2023-03-26 10:13:35.144425 IP 192.168.111.116.55009 > 52.184.216.246.443: Flags [S], seq 1304893579, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
2023-03-26 10:13:35.148849 IP 192.168.111.123.44690 > 192.168.111.255.15600: UDP, length 35
2023-03-26 10:13:35.215857 IP 52.184.216.246.443 > 192.168.111.116.55009: Flags [S.], seq 1012560742, ack 1304893580, win 65535, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
doug@s15:~$

+ 1

tim11g

3/27/24, 1:32 PM

Thanks! I understand now -- tcpdump is capturing the absolute time, but not displaying it by default in wireshark or tshark. I am post-processing the pcap files with tshark, so the place to add the time format is there in tshark. I used `tshark -t ad` and got the full absolute time stamp in the output

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How to get absolute system time in tcpdump output from interface in monitor mode?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.