Update:
Updated the thread name as it looks like the problem is how to sniff in general traffic between two wifi clients in the same subnet.
Currently when default-forwarding is enabled in the wireless interface traffic does not reach the cpu and is handled by the wifi chip (e.g. packet sniffer/torch are useless).
When default forwarding is disabled clients cannot speak to each other ... What is the equivalent of port mirroring for the wifi chip?
===========================================================================
Hi Mikrotik guru's

I am a software developer so excuse my *naive* understanding of network communication

So I have a server and a client that speak to each other using UDP.
Both are connected via Wifi on the same mikrotik router.
Mikrotik router is updated to the latest version - I have tested with two different models, same problem.
I want to check the traffic between client/server with the packet sniffer that is part of the mikrotik UI (under tools).
What I have done so far:

First Verify that traffic is really going on the dedicated interfaces, for that purpose I have ran wireshark on on the box where the server is and send traffic from the client using the capture filter "udp" on the wifi interface of the server - the packets show in wireshark with "Source" and "Destination" "Protocol" etc. decoded by wireshark and the payloads look ok (well the response from the server is somehow padded with gazzilion of 00s but that is probably because of packet fragmentation of MTU expiration .... anyway, it works well and the client can decode id fine - just wanted to mention that if this will help)

Second Start packet sniffer on the mikrotik in the most verbose mode ever: Sniff anything on all interfaces (check the attached sniffer.png for a screenshot). So I do it like this:
1. start packet sniffer
2. do a simple UDP communication and
3. stop it so that the limit of 100kb is not reached.
For my surprise there is no trace whatsoever of the udp packets in the packets captured by the sniffer ...

Third I have tried the trick with streaming the packets to a machine which runs wire shark and using the "udp port 37008" capture filter - same result (I have disabled the "WCCP" as it was clashing with TZSP used by mikrotik to channel the traffic)

So I am sure I am doing something pretty stupid but I cannot figure out what is it?

p.s.
On the https://wiki.mikrotik.com/wiki/Manual:T ... et_Sniffer page there is one line that says:
"Packet sniffer is a tool that can capture and analyze packets that are going to, leaving or going through the router (except the traffic that passes only through the switch chip)."
My understanding is that UDP traffic is not passing through the switch chip as that is not Ethernet traffic but over wifi and the packets are going through the router. But it might be that my understand is of "switch chip" is not correct - may be the traffic is going thought this mysterious "switch chip". If you say that is the usecase how can I capture the traffic?

p.p.s.
You might say "well you already have wireshark installed use that!" ... unfortunately for me i do not have the permission to install wireshark (or any other for that matter) unauthorized software on peoples servers in order to do traffic troubleshooting.

Best Regards

I never use the built in packet sniffer tool in winbox or the web interface, but i do use mangle rules to "sniff tzsp" (action) to a wireshark box, target port 37008 / "tzsp" in wireshark, since tzsp uses udp it can be tricky/shitty to filter in wireshark for udp but it can be done, sorta.

Thanks for the suggestion, but that did not help either ...
Here is what I did:
Setup a mangle rule on chain "forward" (I guess that is the correct one reading https://wiki.mikrotik.com/wiki/Manual:I ... ter#Chains) note: (Just for the sake of testing i have tried with all other chains - same result). Then protocol "UDP" and then sniff TZSP and stream on 37008 to a machine with wireshark.
Then on the target machine I had two wiresharks running, one listening for the TZSP packets directed to 37008 and one with a packet filter of only UDP.
Observed result:
Wireshark with only UDP filter: Sees the packets coming on the wlan interface
Wireshark with TZSP filter: Does not see the packets! It sees some other UDP packets that the source machine sends to other destinations (line DNS and stuff) but not the UDP packates directed to the other machine with runs the UDP server.

Then i read a bit more and tried "Torch": https://wiki.mikrotik.com/wiki/Manual:T ... l_torch.29 on wlan interface ... same result! I can see traffic flowing to other destinations but not traffic to the machine running the UDP server.

Can that be that the two machines somehow speak to each other directly via wifi without going through the router?! ... That is something that would explain why the target machine sees the traffic and the router does not. Or may be the packet sniffing tools in mikrotiks are buggy when dealing with UDP (I doubt that:)

Note: I am not using wifi direct between the two machines, they are simply connected to the router via WIFI and it is my (perhaps naive) expectation that they speak to each other via the router

Best Regards
Ivan

Did you take in account that traffic between devices in the same network is not going through the router but are connected through the switch?

This switching is often done on hardware level and so invisible for the sniffer.

The funny thing is that I have to place filters to keep out that local traffic from the RB 750G3/760IGs router. I never could activate the switch hardware that would do that.

Can you elaborate a bit more on this one with the switch chip and the filters? Where are those filters and how are they configured?
p.s.
I have read about https://wiki.mikrotik.com/wiki/Manual:S ... _Mirroring and my understanding is that WLAN traffic does not go through the switch chip? I have tried to do port mirroring and as sources it accepts only Ethernet interfaces. e.g. the port mirroring of the Switch Chip works like "Copy all the traffic from the device plugged on port1 and send it to port5" (and then you put a PC with wirshark on port5 and see all the traffic).

Okay after 4 days of reading hundreds of ways to sniff some packets looks like i missed this very good hint in the "Note" section for "Torch"

Note: Wireless clients which belong to the same subnet and have enabled default-forwarding communicate through wireless chip. This traffic will not be seen by the torch tool.

Do my clients belong to the same subnet? - YES
is "default-forwarding" enabled in the wireless intrerface - YES (I want the clients to be able to talk to each other)
result: Traffic is flowing through the "wireless chip" and cannot be seen by the torch tool. (that makes way more sense than the slightly misleading info on the "sniffer" tool which speaks about the "switch chip")

So the question is then: What is the port mirroring equivalent for the "wireless chip"? Or is there some way to grab the traffic flowing from the wireless chip?

is "default-forwarding" enabled in the wireless intrerface - YES (I want the clients to be able to talk to each other)

You don't really need default-forwarding enabled, if your wifi is connected to any bridge:

• When it is enabled, packets go from client, to wireless chip and then to second client.
• When it is disabled, packets go from client to wireless chip, to bridge, to wireless chip and then finally to second client. (unless you have bridge filtering which will prevent that)

Difference will be a little higher CPU load - nothing really serious as it is just wifi with limited speed.

slightly misleading info on the "sniffer" tool which speaks about the "switch chip"

I wouldn't call it misleading but can definitely be confusing for some people. In both cases (wireless chip and switch chip), you should perceive these as little black-boxes connected to CPU via external line (even if the switch chip or wireless chip is included in chipset module). Unless data flows through the line to CPU, it will be invisible to CPU. And as the switch chip is much more common source of issues (almost every RB has one and usually people want to utilize HW offload of their bridges), mikrotik staff apparently added warning for switch chip. (probably after some complain that sniffer didn't show packets flowing straight from ethernet through switch to another ethernet)
In the end, however, you are right - it should mention wireless chip as well.

Or is there some way to grab the traffic flowing from the wireless chip

My recommendation is to disable default-forwarding and let data flow through bridge (even if it is just temporary for your test). Default forwarding is just another of many optimizations (hw offload, fast-forward, fast-path, fast-track etc...) which negatively interfere with debugging tools. These optimizations will always interfere because their intended purpose is to speed up packet handling by disabling unnecessary operations

Thanks a lot, that makes more sense - unfortunately somehow the moment I disable default forwarding clients immediately stop speaking to each other (just like it is advertised)
My config is like this:
one bridge named "bridge"
one port named "wlan1" connected to "bridge" you can check "bridge.png"

Any other ideas?

Am I the first person in the world to try sniff communication between wifi clients in the same subnet?

Okay another try: Can someone point me to info how to make the clients talk to each other without using default-forwarding? (Obviously the moment you have default-forwarding the traffic does not reach the router but is handled inside the hardware chip)

The problem: most switch-es and bridges don't seem to consider forwarding ethernet frame to the ingress port. It is reasonable: if receiving device was on the same physical ethernet port (either same collision domain or behind another switch), it is reasonable to assume it would have received the original ethernet frame in the first try. If switch would re-transmit the same ethernet frame to the ingress port, receiving device would see duplicate frame.

To the use case: AP acts of a kind of a switch or bridge between wireless clients (and upstream connection). It can be pictured as if every client had separate ethernet port on AP (WiFi by design is point-to-multipoint technology). If default-forwarding is disabled, AP will not send received wireless packet through wireless again (similar to port-isolation on ethernet switch), it will only pass such packet to CPU (bridge) which will not return that packet back to AP (see first paragraph). Or AP even won't pass packet to CPU if it could identify receiver as wireless client ...
If, on the other hand, default-forwarding is enabled, AP will forward packet to the receiving wireless client autonomously and will never hit CPU (bridge) for you to sniff. The only possibility would be if AP could be configured for traffic mirroring ... I don't remember seeing such configuration possibility but that doesn't say there isn't one.

Workaround might be to use virtual AP and create different APs for different clients. That way you would have separate interfaces you can sniff on. There might be some way to force devices to only connect to their AP using access lists (and virtual APs can all have same SSID).