0

I want to capture ethernet packets with my raspberry pi's ethernet port. I know I could create an ethernet bridge between two ethernet ports on the raspberry and analyze the packets internally with tcpdump. But I need the entire thing to not rely on the raspberry being on.

So I want to use an ethernet splitter to connect one end of the ethernet cable to the rasbperry. For this to work, the raspberry must do no low level ethernet stuff, it must only listen.

Is it possible?

guerlando
  • 1
  • 3
  • You could use a hub with at least 3 ports. Make sure you get a hub and not a switch (unless the switch has a port mirroring feature) – Torin Sep 25 '18 at 07:15

1 Answers1

1

What you are asking for is possible, but not with a passive splitter. You need an active device to do it. Every managed switch I have worked with has had a feature to do what you are asking for.

You only need 3 ports. I don't know if switches with that few ports exist. But managed switches with 8 ports capable of doing the job certainly do exist.

kasperd
  • 29,894
  • 16
  • 72
  • 122
  • You could use a "Throwing Star" LAN tap (https://greatscottgadgets.com/throwingstar/) which splits off the transmit pairs of each side of a connection to a separate connector. You do need two ethernet interfaces. Then use tcpdump on both interfaces to get the complete conversation. This is completely passive as the transmit from the listening interfaces is not connected. – wurtel Sep 25 '18 at 13:34
  • @wurtel There is a lot of caveats to that way of tapping into Ethernet. The documentation mentions a bunch of them: It degrades signal quality which potentially cause poor performance. It deliberately degrades signal quality enough to make Gigabit Ethernet impossible (because tapping Ethernet like that doesn't work with Gigabit communication). It requires two interfaces to see traffic in both directions. With those limitations there is very little advantage left compared to simply configuring two interfaces in a bridge. – kasperd Sep 25 '18 at 13:52
  • @wurtel What the documentation doesn't mention is that it assumes the two interfaces used to monitor the traffic somehow manage to detect a link and the correct link speed without having participated in the negotiation. And it assumes the passive interfaces cannot accidentally mess with the link negotiation between the other two devices. With those limitations one should really check the list of compatible network interfaces before using it (and I don't know if such a list is being maintained). Looking at the reviews of the produce you'll find a few simply stating that it doesn't work. – kasperd Sep 25 '18 at 13:56