Final 6.2.1 update causing LAN instability/sluggishness

I manually downgraded to connman 1.26 last night pre mdgm RC1 post via SSH, I did not reboot following the re-install. Post the downgrade the router remained accessible as did the wider internet.

This morning the NAS (RN102) auto powered down, post waking the unit up the same issue was evident as before. The router was inaccessible as was the internet. Upon switching off the NAS, the router became accessible without restart as did the wider internet.

I have performed the upgrade to RC1 however this has not remedied the problem. The router is still inaccessible as is the wider internet. The NAS is accessible though.

My main router BT HomeHub 4 does not have the option readily available to stop or turn off IPv6, I have moved to the backup router TP-LINK TD-8817 which does have this option however the router and the internet does still become unavailable almost as soon as the NAS is switched on, the NAS itself is still accessible.

I do not have a great deal of expertise in terms of packet capture of analysis so I have the printouts below in the hope they shed some light -

ifconfig printout - (The NAS had just finished booting when the below was run, I have no applications running bar Anti-Virus Plus)

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:192.168.1.XXX  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: XXXX::2ac6:8eff:fe34:681/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
          RX packets:2054 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9596834 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:512
          RX bytes:403184 (393.7 KiB)  TX bytes:1589665015 (1.4 GiB) 
          Interrupt:10

Should the unit have an inet6 address given that the router shouldn't be giving them out, or is this an auto configured IP?

The TX bytes figure seems huge (my internet is barely 4mbp/s, and I had nothing over the LAN bar the SSH connection)

I also ran tcpdump, I didn't save the capture file unfortunately but can run again if it is any use.

tcpdump -i eth0 --vv

2493 packets captured
3155450 packets received by filter
3152926 packets dropped by kernel

I really have no idea about the packets received or dropped, I am off to Google that.


I hope some of the stats help I am just about to email my logs over and am more than happy to run anything else that would help to assist and solve this problem.