I'm running Mint as a firewall (using Shorewall) to protect a school network from bad stuff kids might do on a Raspberry Pi network. The Pis are accessed headless from the school network using VNC or PuTTy on school PCs.

All was working fine, but I rebuilt the firewall with a more current Mint but all other software the same. Now, the NIC connected to the school network is reporting large numbers of dropped RX packets when the TX load is heavy, specifically when VNC on a Pi is continually updating a desktop containing a video window from a Pi camera. As a result the said NIC repeatedly goes DOWN for around 30 secs before briefly recovering.

If I put the old hard disk back with the old system build it works fine. Exact same hardware. This uses a kernel 4.4.0-34 whereas the new build uses 4.8.0-53. The net parameters reported by sysctl show substantial increases for many of them so it wouldn't appear to be a buffering issue.

So what can make a heavy TX load case dropped RX packets, and what can I do about it.

Regards - Philip

Welcome to LQ.
It seems you broke the Golden Rule:"If it ain't broke, don't fix it!"
You can eliminate the hardware, and systematically go through the software. Add in the old kernel, and see does that sort it. Is it handling the camera the same, or is there more resolution or more traffic? Has the workload for the Pi increased? Is it firewall, server, or what? You know what you're looking at, but we haven't a clue. Why not revert to the old setup?

Hello and welcome to LQ.

I guess there are a few things to note. One is total overall load, two might be driver and three driver settings or options maybe. I assume maybe others.

I think I'd run a different distro maybe. Try untangle linux or go with pfsense or some other. Some of the commercial/open distros offer free or low cost for schools.

Mint isn't really what I'd ever use for security. Too much extra stuff by default.

Soooo. You have choices. Use a much newer kernel. 4.12x. Build a dedicated firewall/UTM. Diag what you have.

Unfortunately, Business Kid, all software is broken, which is why you have to patch it to eliminate vulnerabilities. Especially in a firewall!

Transplanting the kernel from the working system to the troublesome one seemed like a good idea until I realised I'd also have to transplant the abi, initrd and System.map along with the vmlinuz, as well as modify the boot menu. And the grub docs gave me a headache last time I delved into them. Seems like good way to get an unbootable system and two headaches for the price of one.

But hey, that triggers another thought:

The build that works was probably built on the firewall itself, but the build that doesn't work was built on a very similar machine at home. I then took the HD into school for final tweaks (in particular, IP addressing schema). But the machine I have at home has more RAM. I'm thinking this might account for the larger net parameters reported by sysctl -a. Could these be unsuitable for the machine with less RAM. Is there a way of getting them recalculated for the different environment? I might try pinching the RAM out of this system and putting it in the school one tomorrow.

And Jefro - maybe I wouldn't start from here if I was starting over, but having invested many, many hours getting to the point where I am, I'm not about to change horses now. I did look at pfsense last Summer but couldn't see how to easily run additional software on it such as a web server. And it's a very different beast with its own learning curve.

Regards - Philip