When my computer is connected directly to mirror port of switch all works. When I send traffic from mirror port over a wireless bridge I only get broadcast traffic. Help asked 15 Oct '16, 08:02 wlm905 |
When my computer is connected directly to mirror port of switch all works. When I send traffic from mirror port over a wireless bridge I only get broadcast traffic. Help asked 15 Oct '16, 08:02 wlm905 |
What type of wireless bridge?
Bridges like this that I have used operate at layer 2, so make forwarding decisions based on layer 2 information, i.e. MAC addresses. So not really a surprise if a mirror port destination traffic will not make it across the bridge. The missing traffic is unicast (per your comment) and that does not belong at the other side of that bridge. You might, sometimes, benefit from the layer 2 device trying to learn source MACs for the forwarding table by flooding unknown traffic, but I wouldn't count on that.
Maybe you want to find a way to encapsulate this unicast traffic and have it sent to you, via unicast, across the bridge? The model could be rpcap, or one of the other streaming capture utilities. It's a little unusual to send mirror port traffic over a wireless bridge - can you share what you are trying to do?
To extend @Bob Jones' explanation, it doesn't really matter whether the bridge is a wireless or wired one.
A switch or bridge sends frames bearing destination MAC addresses yet unknown to it to all output ports (i.e. "floods" all ports with them), so far so good. But it learns the associations between its ports and the MAC addresses from the frames' source MAC addresses.
So what actually happens is that while you monitor the real traffic between, say, MAC address A and MAC address B, both A and B appear as source MAC addresses in the individual frames which the local port of the bridge receives from the monitoring port of the other switch. So it understands both A and B as accessible via its port on which it has seen them, and therefore it doesn't have a reason to forward them to any other port - at best (or worst, as you like) case, it might send them back on the local port.
In the wired case, you could use a hub rather than a bridge, because a hub is an L1 device, not L2, which means it doesn't care about the MAC addresses. But an ordinary wireless bridge is L2-aware in order not to waste the radio bandwidth by sending traffic not meant for the remote end, so it behaves as described above.
So encapsulation of the captured frames, as recommended by @Bob Jones, is normally the only way how to deliver the captured traffic anywhere else than to a NIC directly connected to the monitoring port.
Thanks Bob and sindy for responding. Your answers make sense and saved me from a lot of aggravation.
We run a small wireless ISP and am trying to sniff out Bittorrent use using Wireshark. Our feeder ISP is 6 miles away and I installed a managed switch with a mirror port at that point. All clients including me access this point via UBNT NSM5 radios. Monitoring at the feeder ISP location (at the managed switch) works but is not feasible for any length of time (I'd lose my computer).
So, now to research encapsulation. Thanks again.