Solved - or rather, workaround found.
For the record, the problem seems to be a regression in the e1000e
driver or firmware between Mint 17 and 18, or a difference between the
32 and 64 bit versions. I had the school network on the motherboard NIC
(this is the one that was causing the trouble) and the Pi network on a
PCI NIC. Having rebuilt the system yet again to no avail, I swapped over
the two interfaces, and lo and behold - problem vanished!
Actually, I've just checked that the driver is the same (v3.2.6-k) but
the firmware has gone from 0.13-4 (works) to 1.8-0 (troublesome), and
I've moved from a 32 bit system (works) to a 64 bit system
(troublesome). The motherboard NIC on the system I have at home, which I
believe is the same or similar, is Intel 82579LM.
Regards - Philip
On 26/07/2017 02:20, Tom Eastep wrote:
> On 07/25/2017 11:52 AM, Philip Le Riche wrote:
>> OK, so I'm still bashing my head against a brick wall with this, and so
>> far the brick wall is holding out better than my head. With school hols
>> started I now have much greater access to the system.
>>
>> The problem is severe in the following situation: running VNC client on
>> a school PC controlling a Pi on the other side of the firewall. The Pi
>> runs a face follower program which continuously displays image captures
>> from the camera, causing continual screen refreshes to be sent to the
>> VNC client. The firewall NIC on the school network side repeatedly goes
>> DOWN for around 30 secs at a time. ip -s link ls shows it's getting
>> large numbers of dropped packets. In this situation, control of the
>> session from the VNC client is almost impossible.
>>
>> Yesterday I tried 2 things, with interesting results:
>> 1. I completely rebuilt the system from scratch, installing Shorewall 5
>> instead of Shorewall 4, and with kernel 4.8.0-53. The problem remains.
>> 2. I dug out an old hard disk with a version of the system I built last
>> Summer (if not before) and kernel 4.4.0-34. All other hardware was
>> unchanged. The problem disappeared!
>>
>> This seems to indicate software, not hardware. No clues that I can spot
>> in /var/log/messages.
>>
>> Comparing the outputs of sysctl -a on the 2 systems shows various
>> parameters changed, but nearly all increased. (My best guess had been
>> that a kernel buffer needed to be larger.) See
>> blueskylark.org/stuff/sysctl-diffs.txt for an sdiff - old system on the
>> left, new on the right.
>>
>> /etc/shorewall/interfaces is identical between systems (except for
>> commented lines) and the only differences in shorewall.conf are in
>> logging and verbosity.
>>
>> Any suggestions?
>>
> Not really. I know of nothing in a Shorewall configuration that could
> produce these symptoms. One thing I noticed in the diff you posted was
> that the 'new' output showed nothing from net.netfilter, but I don't
> know if that is significant.
>
> -Tom
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
