1

I'm having an hard time figuring out why can't I capture the packets flowing between two devices, in both directions, using a self made Ethernet tap, with copper cable, which looks just like this one:

enter image description here

Both end devices (say, A and B) are connected to a switch. But since the sniffer (a regular laptop) only has one Ethernet port I can't perform the sniffing, like it is presented in most cases (e.g. Wireshark Example using Network Tap), where the traffic from TX and RX is received on a Sniffer with 2 interfaces.

So, in order to "solve" this issue, I just plugged the 2 (tap) connector ports to the ones on the switch and, finaly, 1 port from the switch to the sniffer. I thought the packets would just be broadcasted but every time I plug the connectors to the switch the connection between A and B is interrupted (can't ping from A to B and vice versa). I made an illustration of the scenario:

enter image description here

What kind of problem is the switch experiencing when I perform this connection? is it really necessary a commercial tap (those devices with 3 ports: A, B and sniffing port)?

Any ideas?

PS: I don't want to use port mirror or a hub. I want a passive tap.

TheCleaner
  • 32,352
  • 26
  • 126
  • 188
bulkmoustache
  • 137
  • 2
  • 5
  • 1
    It's a switch...switches don't broadcast traffic like hubs do. All the tap will do is cause a "broadcast storm" and lock up the switch. Sort of like when you use the "port 5" and "uplink" ports at the same time. – Nathan C Jun 17 '13 at 00:51
  • Your first link is dead – Journeyman Geek Jun 17 '13 at 01:01
  • 1
    To clarify: A hub does not broadcast traffic to all ports, it floods traffic to all ports. A broadcast is comprised of data that is meant for all devices on the same layer 2 network and has a layer 2 broadcast address as the destination (FF-FF-FF-FF-FF-FF) or it is comprised of data that is meant for all devices on the same layer 3 network and has a layer 3 broadcast address as the destination (192.168.1.255 for instance on the 192.168.1.0/24 layer 3 network). A hub floods all traffic to all ports, even when that traffic is unicast in nature (traffic that is meant for a single host). – joeqwerty Jun 17 '13 at 01:12
  • What you need to do is fool the switch to also send the packets destined to the host you're sniffer to your sniffer using a technique known as ARP spoofing. https://en.wikipedia.org/wiki/ARP_spoofing. Because as others have pointed out, the sniffer won't get the packets when connected like this. – hookenz Jun 17 '13 at 03:34
  • 3
    Why in the name of anything sane would you want to tap a network line this way? Your passive tap shown in the photo will almost certainly disrupt the link (likely introducing transmit/receive errors)... – voretaq7 Jun 17 '13 at 05:21

1 Answers1

7

The problem you are experiencing is that the switch does not act like a hub. It only sends traffic down the link that it needs to go down, if it knows what that is (and it builds this information by watching and seeing which MAC addresses are on which port).

If you want to do this, you either need to connect your sniffer so that the traffic has to go through it, use a port mirror, or put the sniffer with one of the devices you're sniffing traffic for on a passive, non-switching hub. The only thing you can do which won't require additional hardware is port mirroring or cloning (which you should do if you can, because this is completely transparent to the devices under monitoring).

As it happens, the type of "commercial tap" you have described is effectively a hub.

Your tap doesn't work for a few reasons. The net effect it will have is that, assuming the switch sees the ports as being connected at all (which it may not, because it may attempt to detect polarity and discover that only one pair is connected to each port), traffic toward the switch will be doubled, and the switch will become confused as to which port the host you are trying to tap is actually on (and may try to send packets out the port with the host's transmit pair on it, despite the physical absence of its own transmit pair). There may also be some electrical consequences to this arrangement which might render the signals unintelligible to devices on either end.

Additionally, the traffic on the device's receive pair will be completely garbled by the switch. The switch will transmit broadcast packets down the wire twice, oblivious to the conflict this causes, and this is likely why you find connectivity ceases when you connect this.

Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
  • Whilst you're right, the actual problem the op is saying is that when his tap is connected, all communications on the wire cease, rather than he can't capture them. – Mark Henderson Jun 17 '13 at 01:32
  • I added some information to explain the reason for that, but the solution is the same. – Falcon Momot Jun 17 '13 at 03:43
  • I did try using a hub before posting this issue but the problem persisted. I forgot to mention one thing that might be intriguing: Once I plug the RJ45 jack to one of the connectors of the tap, the connection is interrupted. In other words, the other end of the cooper cable is not connected to the switch or hub. And that's all it takes for the connection (e.g. ping between A and B) to be interrupted. When I unplug the jack on the tap, both devices keep pinging each other. – bulkmoustache Jun 17 '13 at 17:27
  • 1
    Yes, that is exactly right. Signal reflections are a thing, especially at high frequencies. – Falcon Momot Jun 17 '13 at 17:56