For years I’ve used an eBay-purchased Net Optics TP-CU3 (now called Ixia TP-CU3-ST) copper 10/100/1000 Ethernet tap along with a StarTech USB 3.0 to Dual Gigabit NIC for getting external network captures from client computers [1]. The fan in the tap is dying and making a lot of noise. While not just irritating, I believe this is causing the tap to overheat resulting in occasional weirdness in the data [2].
As a replacement I now have a SharkTapUSB Gen2 from midBit Technologies, LLC, and so far it’s working great. Being a simpler device, with a USB NIC built in, it’s much more appropriate my needs. Smaller, simpler to connect, quieter (no fans), and easier to teach coworkers to use. At $249.95 (sold solely via Amazon) it’s also priced fairly.
The SharkTapUSB is a single unit about the size of a deck of cards that is inserted between two Ethernet devices and outputs the captured data to either an Ethernet connection or it’s built-in USB 3.0 gigabit NIC. It also gets power from USB 3.0, eliminating an external power supply. This is perfect for what I’m usually doing, which needing to watch data going in and out of a computer and analyze it in Wireshark.
While the TP-CU3 is excellent and served me well, it also was overkill. It has a bunch of features intended for permanent install / data center use, such as bypass relays to maintain connectivity during power failures, forced air cooling, redundant power supplies, and dual gigabit egress links to support monitoring saturated full duplex connections. Even when the built-in cooling fans are working properly, it’s loud enough to be irritating in a normal office (the SharkTap USB is silent).
Compared to the TP-CU3 there are three downsides to the SharkTapUSB, but for my needs I don’t see them being a problem:
- Cannot Capture Sustained Full Duplex Traffic: The SharkTapUSB merges the network traffic between two ports and outputs it to a single gigabit NIC. If the traffic being captured is a sustained, full-duplex gigabit flow, this is too much for the capture interface and data will be lost. For me this amount of traffic is rare in practice, especially in situations where I need an external tap. (The SharkTapUSB has a 256KB buffer to accommodate short bursts of high bandwidth traffic.)
- Link Electrical Status Not Propagated Between Ports: The TP-CU3 uses relays so that when one of the network ports is disconnected electrically the other one is shut down. For example, when the client PC is disconnected, the TP-CU3 drops the electrical link to the switch, so the switch sees the disconnect. The SharkTapUSB does not do this, and keeps the electrical link up on one side when the other is disconnected. Should this be a problem, such as when working with a switch that takes action on link state change, this can be sidestepped by unplugging cables.
- Link Speed Autodetection: The SharkTapUSB cannot be forced to a particular port speed. However, it does set both ports to the lowest autodetected speed, so port speed can be controlled via settings on a connected device.
After looking at the SharkTapUSB’s block diagram I got curious how it’s actually implemented, so I opened it up to see and grabbed some photos of the Rev F PCB (top, bottom, jumper wires on bottom).
Here’s the notable components:
- U1 / Switch With Port Mirroring: a Microchip KSZ9897R Ethernet Switch (datasheet) chip ties everything together. This is a pretty robust switch, but it appears to solely listen in on data flowing betweent the Network PHYs and pass this to the tap ports (RJ45 and USB NIC) while doing a bit of buffering. Also serves as the PHY for the Wired TAP.
- U3: a Microchip PIC16F1823 microcontroller (datasheet) to configure the switch. J1, in the upper left of the board, is the programming header.
- U4 / USB TAP: Realtek RTL8153, the USB 3.0 NIC.
- U6: Microchip 93C66B serial EEPROM (datasheet), to configure U4 (RTL8153).
- U8 & U11 / Ethernet PHYs: Atheros AR8035 PHY (datasheet via Digi-Key). These are the physical transceiver chips for the network ports, connected directly to each other with the switch chip hanging off these lines. (Product page and data sheets available only on request from Qualcomm.)
[1] While captures can be done locally (from within the OS), using tools like Packet Monitor or Wireshark or tcpdump, there are times when an external capture is more useful or the only option, such as:
- Troubleshooting Intel AMT related issues, as AMT sits between the normal NIC and the external port.
- Monitoring PXE.
- OS’ where getting a local capture is complicated, such as Windows PE, embedded stuff in televisions, or mobile OS’ (eg: Android, iOS).
- Investigating hardware offloads, as a local capture will show invalid data for things like TCP checksum as it’s not calculated before reaching the NIC.
[2] I looked into replacing the fan, but this doesn’t seem practical. The fan is a Sunon GB0535AEV1-8.B2445.GN, which is a combination heatsink and fan, and appears to be epoxied in place. While I can get one via eBay sent from China, I’m unsure if I’ll be able to remove the fan without damaging the chip. Instead I’ll keep the mostly-working tap around for rare occasions when full-duplex monitoring is needed, using the SharkTapUSB for day-to-day use. Perhaps in the future I’ll give a heatsink/fan swap a go…