This is neat.<p>A word of caution, depending on how the network is laid out, this could cause severe bandwidth overhead if there isn't a dedicated, and unmonitored, interface for the capture to flow over.<p>One needs to be careful not to have the captured traffic flowing out to the monitor via an interface that's being monitored, otherwise load will snowball.<p>The example here omits eth1, so I'm presuming that's the path the capture takes, but it would have been nice to see the author call this out. Otherwise, without some sort of capture-side filter, which the fritzdump.sh script and example doesn't seem to include, the capture will include a copy of the monitoring stream and the bandwidth will snowball.<p>There's also the issue of the monitoring port likely not able to capture full bandwidth of the aggregate of the other ports being monitored. Since the buffer in the device likely isn't unlimited, there's a possibility for lost data during times of high traffic.