# Ethernet hardware loopback

I am working on a hardware implementation using a PHY chip that allows far-end loopback, that is, data from the host that is sent to this chip is echoed back exactly as received. I wanted to create some software that would use this loopback to test the hardware out, but the echoed data has the source and destination addresses set to the same values as when they went out from the computer.

Is it possible to automatically differentiate the transmitted frames from the received frames, since they have the same source and destination addresses? Wireshark sees both the transmitted and the received packets, and I don't see any indication as to which is which in the display. Obviously (?), the earlier one should be the transmitted frame, but I don't know of any way to tell programatically.

Is there a way to tell the transmitted from the received and filter out the transmitted frame?

edit retag close merge delete

but the echoed data has the source and destination addresses set to the same values as when they went out from the computer.

The addresses you're referring to are the MAC addresses? Or IP addresses? Or both? To clarify, the transmitted and received frames are both completely identical?

( 2019-07-20 15:40:06 +0000 )edit

Do your test packets have an IP header? If so is the network interface on the source set for "IPv4 Checksum Offload"? (On Windows this is on the Network Interface properties under the Advanced tab)

If the interface is adding the IPv4 checksum then your outgoing packets will have an ip.checksum = 0x0000 in the packet capture. Wireshark gets them before the NIC has added the checksum.

To see outbound set a display filter for "ip && ip.checksum==0x0000" For inbound the packets should arrive with a valid checksum so "ip && !ip.checksum==0x0000" (The "ip" may not be needed but that way you're sure to not get other broadcast packets)

( 2019-07-20 15:59:23 +0000 )edit

For inbound the packets should arrive with a valid checksum

And for outbound they might do so as well, if the checksum is being done by the host rather than the network adapter, so "ip && ip.checksum==0x0000" is not guaranteed to work as a check for outgoing packets.

( 2019-07-20 16:11:46 +0000 )edit

As @bubbasnmp alluded to, if the capturing is taking place on the same machine as the transmitting host, then there may be a few ways to differentiate the frames, even if the frame data itself is completely identical (including MAC addresses). One such method with respect to checksums was just mentioned, noting the caveat that @Guy Harris mentioned.

Another potential method would be that if the frames are smaller than the minimum frame size (60 bytes, not including FCS), then the transmitted packets won't have any frame padding added yet, so the length of the transmitted frame will be smaller than the length of the received frame. Thus, you may be able to filter/mark transmitted packets as using a filter such as frame.len < 60.

Read more about local capturing and its impact at @Jasper's blog: The drawbacks of local packet captures, which in this particular ...(more)

( 2019-07-20 16:23:13 +0000 )edit

Hi all. These are raw Ethernet frames that are 1344 bytes in length. It appears that the checksum is added/checked in the NIC, as Wireshark doesn't see it in either direction. I'm not sure if I can change that in the OS. (Linux 4.18, enp3s2 device) . I'll have a look. But the method suggested by @Guy Harris seems to work great for this.

( 2019-07-22 18:30:59 +0000 )edit

Sort by » oldest newest most voted

Wireshark sees both the transmitted and the received packets

If 1) the host doing the capturing is running an operating system that supports capturing only incoming traffic and 2) you have a sufficiently recent version of libpcap and tcpdump on that host, you can capture with tcpdump, using --direction=in and a -w option to write the capture to a file, and the resulting file will have only incoming packets. You can then have Wireshark read that capture file.

OSes that support it:

• possibly Solaris 11.

although, unfortunately, Apple screwed up and --direction might not work on macOS.

more