Tue Feb 04, 2025 11:07 pm
It may, because my assumption was that the NFS client and the NFS server "take a shortcut" in terms that the communictaion between them doesn't get to the router's CPU. If your device supports IP routing in hardware (L3HW), this variant is still possible although they are in different subnets so L2 forwarding in hardware is not sufficient as an explanation. Without L3HW, the explanation must be different. If that is the case, try setting hw on the /interface/bridge/port row to no, but it is kind of cargo cult suggestion - I know this helps in another scenario were it does not seem logical (with hw set to yes, the sniffer doesn't see either the packets the router sends itself or the ones it receives, I never remember which direction is affected), but it should not be the case here as both directions (client to server and server to client) are both incoming and outgoing from the point of view of the router so they should be sniffed anyway.
As you wrote that you could see the NFS client to request its IP address (via DHCP I guess), I assume that you are familiar with the TZSP encapsulation and that Wireshark indeed does receive all the packets that did reach the CPU and match the sniffer filter condition.
I also assume that you cannot see any other traffic to/from the client than the DHCP one? Because Wireshark allows to disable dissectors of known protocols, so the actual NFS traffic may be shown as "undissected TCP" one.