Time Stamp Command

[joelcorporan]

How I use the tstamp for the network adapter. This is what I'm typing,

sudo tcpdump -j pcap_list_tstamp_types(pcap_tstamp_adapter() dst port 57441 -tttt -s 65535 -w

but doesn't not work. What I need to do?

[guyharris]

You need to type

tcpdump -J

to see what time stamp types tcpdump supports. Then you need to type

tcpdump -j <value> dst port 57441 -tttt -s 65535 -w <filename>

where is one of the time stamp types listed by tcpdump -J and is the name of the file to which you want to save the raw binary form of the packets (i.e., that file will _NOT_ be a text file, it'll be a file that you'll have to read with tcpdump or Wireshark or some other program if you want to see what the packets were).

If tcpdump -J prints a message saying that "Time stamp type cannot be set for" the interface in question, then you can't use -j, and you can't control what type of time stamp will be done for the packets.

Note, by the way, that the -t flag controls how time stamps are printed; it does not affect how they're saved to a raw binary file, so -tttt has no effect when you use it with -w. If you want to see the packets printed, then use -tttt or whatever form of -t flag you want, but don't use the -w flag.

[joelcorporan]

This is what it said,

host (Host)
adapter (Adapter)
adapter_unsynced (Adapter, not synced with system time)

[joelcorporan]

I type this,

sudo tcpdump -j adapter dst port 57441 -s 65535 -w <file.pcap>

But does not work...

tcpdump: SIOCSHWTSTAMP failed: Invalid argument

[guyharris]

To quote a comment in the libpcap code for Linux:

         * XXX - we can't ask a device whether it supports
         * hardware time stamps, so we just claim all devices do.

so, unfortunately, the mere fact that tcpdump -J gives those three types doesn't mean that they'll work on your network adapter. (Thanks, Linux kernel developers!)

You probably have a network adapter that doesn't do its own time stamping, so your only choice is "host" - which is the default.

[guyharris]

I just checked a change to libpcap that, with sufficiently recent kernels, will ask the kernel what time stamps the device supports ("sufficiently recent" to support asking the kernel that question), and only report the time stamp types that the kernel says are supported for the device.

[ykondrashyn]

I've got a similar issue while using adapter_unsynced time stamp type. Does it mean that it is not supported?

# tcpdump -j adapter_unsynced -i ixeth0
tcpdump: WARNING: SIOCSHWTSTAMP failed: Numerical result out of range
Warning: Kernel filter failed: Bad file descriptor
tcpdump: can't remove kernel filter: Bad file descriptor

Here is some hardware properties.

# ethtool -T ixeth0
Time stamping parameters for ixeth0:
Capabilities:
    hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
    software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
    hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
    software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
    software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
    hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
    off                   (HWTSTAMP_TX_OFF)
    on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
    none                  (HWTSTAMP_FILTER_NONE)
    ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
    ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
    ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
    ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
    ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
    ptpv2-l2-event        (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)
    ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
    ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
    ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
    ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
    ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)

# modinfo ixgbe
filename:       /lib/modules/3.10.71/kernel/drivers/net/ixgbe/ixgbe.ko
version:        4.3.15
license:        GPL
description:    Intel(R) 10 Gigabit PCI Express Network Driver

[joelcorporan]

Is it build-in or an external network card?

[ykondrashyn]

@joelcorporan, it is an external 10GbE network card. Here is a lspci excerpt:

02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)

[ykondrashyn]

Most likely it is an ixgbe issue

ixgbe_ptp.c
924:    case HWTSTAMP_FILTER_ALL:
925-        /* The X550 controller is capable of timestamping all packets,
926-         * which allows it to accept any filter.
927-         */
928-        if (hw->mac.type >= ixgbe_mac_X550) {
929-            tsync_rx_ctl |= IXGBE_TSYNCRXCTL_TYPE_ALL;
930:            config->rx_filter = HWTSTAMP_FILTER_ALL;
931-            adapter->flags |= IXGBE_FLAG_RX_HWTSTAMP_ENABLED;
932-            break;
933-        }
934-        /* fall through */
935-    default:
936-        /* register RXMTRL must be set in order to do V1 packets,
937-         * therefore it is not possible to time stamp both V1 Sync and
938-         * Delay_Req messages unless hardware supports timestamping all
939-         * packets => return error
940-         */
941-        adapter->flags &= ~(IXGBE_FLAG_RX_HWTSTAMP_ENABLED |
942-                    IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER);
943-        config->rx_filter = HWTSTAMP_FILTER_NONE;
944-        return -ERANGE;
945-    }

82599 network card does not satisfy a condition "hw->mac.type >= ixgbe_mac_X550" , so next it jumps to default and the instruction on line #944 leads to "Numerical result out of range" error.

ixgbe_type.h
3406-enum ixgbe_mac_type {
3407-   ixgbe_mac_unknown = 0,
3408-   ixgbe_mac_82598EB,
3409-   ixgbe_mac_82599EB,
3410-   ixgbe_mac_X540,
3411:   ixgbe_mac_X550,
3412:   ixgbe_mac_X550EM_x,
3413-   ixgbe_num_macs
3414-};

Unsafe solution is to modify the condition to accept 82599 network card:

ixgbe_ptp.c
936-        if (ixgbe_mac_82599EB == hw->mac.type || hw->mac.type >= ixgbe_mac_X550) {
937-            printk("!!!VERY UNSAFE STEP!!!\n")
938-            tsync_rx_ctl |= IXGBE_TSYNCRXCTL_TYPE_ALL;
939-            config->rx_filter = HWTSTAMP_FILTER_ALL;
940-            adapter->flags |= IXGBE_FLAG_RX_HWTSTAMP_ENABLED;
941-            break;

Now it works!

[guyharris]

What happens if you run the command

tcpdump -J -i ixeth0

That should, with a sufficiently recent version of the kernel and libpcap, report only the time stamp types supported by the interface in question.

[ykondrashyn]

@guyharris

# tcpdump -J -i ixeth0
Time stamp types for ixeth0 (use option -j to set):
  host (Host)
  adapter_unsynced (Adapter, not synced with system time)

BTW, "-J" worked the same way (contained same output) before patching ixgbe, errors occurred only when "-j" option was provided.

[ykondrashyn]

Here is my tcpdump, libpcap an kernel versions:

# tcpdump --version
tcpdump version 4.7.4
libpcap version 1.7.4
# uname -a
Linux DEVICE 3.10.71 the-tcpdump-group/tcpdump#1 SMP Wed May 4 13:55:20 PDT 2016 x86_64 GNU/Linux

[guyharris]

OK, so that version of libpcap supports asking the device what timestamp types it supports, and, in fact, that appears to have succeeded, as it didn't list "adapter" as a type, just "host" and "adapter_unsynced" (if libpcap can't get a list of supported types, it falls back on "host", "adapter", and "adapter_unsynced", some of which could fail).

And, in the 3.10.71 kernel as downloaded from kernel.org, the ixgbe_get_ts_info() routine in the ixgbe driver says that ixgbe_mac_X540 and ixgbe_mac_82599EB support hardware time stamping.

But the ixgbe_ptp.c in your code example doesn't match what's in the 3.10.71 kernel, so presumably your kernel isn't from a straight-from-Linus kernel.

[guyharris]

Sigh. It appears that the ETHTOOL_GET_TS_INFO ioctl provides a list of supported filter, but that the ixgbe driver does not indicate that any device supports HWTSTAMP_FILTER_ALL.

Libpcap should check for HWTSTAMP_FILTER_ALL and, if it's not set, indicate that only software time stamping is supported - and I should ask on linux-netdev whether the ixgbe driver should indicate that HWTSTAMP_FILTER_ALL is supported for the X550 but not anything else.

[guyharris]

I've made that change to libpcap - and changed it to treat ERANGE for an attempt to set hardware time stamping as meaning "hardware time stamping not supported", and reporting it as a warning - in change c119a71.

I've asked on linux-netdev at http://marc.info/?l=linux-netdev&m=146318183529571&w=2

This means that, with a tcpdump built with the current tip-of-the-master-branch libpcap,

tcpdump -J -i ixeth0

will probably "Time stamp type cannot be set for ixeth0", even though it can for the X550, because of the driver bug(?).

It also means that, with an unmodified driver, and a tcpdump built with the current tip-of-the-master-branch libpcap,

tcpdump -j adapter_unsynced -i ixeth0

should issue a warning but not fail; if it fails, that's another bug.

Whether your driver change will actually make hardware time stamping work is another matter. You'd have to ask the Intel people about that.

[AqsaKashaf]

Hi, I have a similar issue. My tcpdump -J gives me only host option. But my NIC supports hardware timestamping.
Time stamping parameters for eth6:

Capabilities:
        hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
        software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
        hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
        software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
        software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
        hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)

PTP Hardware Clock: 7
Hardware Transmit Timestamp Modes:
        off                   (HWTSTAMP_TX_OFF)
        on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
        none                  (HWTSTAMP_FILTER_NONE)
        ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
        ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
        ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)

[guyharris]

Hi, I have a similar issue. My tcpdump -J gives me only host option. But my NIC supports hardware timestamping.

Please file this in the libpcap issue list as a separate issue, as it might be due to a different problem.