Welcome! Log In Create A New Profile

Advanced

NSA-320 kirkwood - eth0 link down/up spam in logs

Posted by Ludacrisvp 
NSA-320 kirkwood - eth0 link down/up spam in logs
February 01, 2016 10:26PM
Im using Bodhi's rootfs and kernel updates.
My rootfs is based on Rootfs Debian-3.16.0-kirkwood-tld-2 (sept 2014) I've since updated to Jessie using apt-get and updated kernel to 4.4 and uboot as well.
I'm booting from a USB drive and have a dual drive RAID 1 setup. I'm also quite certain that I wiped out the stock firmware too when I originally set this up back in 2014.

What I'm seeing logged, this has gone on since day 1, and I was hoping that the upgrades that I was doing might have addressed this but it hasn't.


These 3 lines log around every 300 seconds (5 mins), they log in a few places so after some time they cause some rather large log files.
Feb  1 22:16:49 IQ2700i kernel: [ 3291.719206] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
Feb  1 22:16:49 IQ2700i kernel: [ 3291.725383] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
Feb  1 22:16:49 IQ2700i kernel: [ 3291.735315] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled


I really don't think the link is actually dropping, as I never see packet loss or a connection drop.


IQ2700i# uname -a
Linux IQ2700i 4.4.0-kirkwood-tld-1 #1 PREEMPT Mon Jan 25 20:35:24 PST 2016 armv5tel GNU/Linux
IQ2700i# cat /etc/debian_version
8.3

IQ2700i# cat /etc/network/interfaces
auto lo eth0
iface lo inet loopback
iface eth0 inet static
	address	10.10.10.99
	netmask	255.255.255.0
	network	10.10.10.0
	broadcast 10.10.10.255
	gateway	10.10.10.1

IQ2700i# netstat -i
Kernel Interface table
Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500 0    118006      0      4 0         33730      0      0      0 BMRU
lo        65536 0      1000      0      0 0          1000      0      0      0 LRU

IQ2700i# ifconfig -a
eth0      Link encap:Ethernet  HWaddr c8:6c:87:aa:a0:82
          inet addr:10.10.10.99  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::ca6c:87ff:feaa:a082/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:118979 errors:0 dropped:4 overruns:0 frame:0
          TX packets:34609 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:133170674 (127.0 MiB)  TX bytes:6676459 (6.3 MiB)
          Interrupt:86

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1028 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1028 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:123337 (120.4 KiB)  TX bytes:123337 (120.4 KiB)

U-Boot 2015.10-tld-1 (Nov 06 2015 - 16:12:51 -0800)
ZyXEL NSA320 2-Bay Power Media Server


IQ2700i# fw_printenv
baudrate=115200
boot_sata1=mw 0x800000 0 1; setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootdelay=10 $mtdparts; ide reset; ext2load ide 0:1 0x800000 /boot/uImage; ext2load ide 0:1 0x01100000 /boot/uInitrd; bootm 0x00800000 0x01100000
boot_sata2=mw 0x800000 0 1; setenv bootargs console=ttyS0,115200 root=/dev/sdb1 rootdelay=10 $mtdparts; ide reset; ext2load ide 1:1 0x800000 /boot/uImage; ext2load ide 1:1 0x01100000 /boot/uInitrd; bootm 0x00800000 0x01100000
bootcmd=run boot_sata1; run boot_sata2; run bootcmd_usb; usb stop; run bootcmd_rescue; reset
bootcmd_usb=run usb_init; run usb_load_uimage; run set_bootargs_usb; run usb_boot;
bootdelay=4
console=ttyS0,115200
ethact=egiga0
ethaddr=C8:6C:87:AA:A0:82
if_netconsole=ping $serverip
ipaddr=10.10.10.99
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),512K(uboot_env),512K(key_store),512K(info),10M(etc),10M(kernel_1),48896K(rootfs1),10M(kernel_2),-(rootfs2)
ncip=10.10.10.123
netmask=255.255.255.0
partition=nand0,2
set_bootargs_usb=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
usb_device=0:1
usb_init=usb start
usb_load_uimage=mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /boot/uImage
usb_root=LABEL=rootfs
usb_rootdelay=5
usb_rootfstype=ext2
preboot_nc=setenv nc_ready 0; for pingstat in 1 2 3 4 5; do; sleep 1; if run if_netconsole; then setenv nc_ready 1; fi; done; if test $nc_ready -eq 1; then run start_netconsole; fi
preboot=run preboot_nc
serverip=10.10.10.105
arcNumber=3956
load_dtb=ext2load usb 0:1 0x1c00000 /boot/dts/kirkwood-nsa320.dtb
load_initrd=ext2load usb 0:1 0x1100000 /boot/uInitrd
load_uimage=ext2load usb 0:1 0x800000 /boot/uImage
usb_boot=run load_dtb; run load_uimage; if run load_initrd; then bootm 0x800000 0x1100000 0x1c00000; else bootm 0x800000 - 0x1c00000; fi



Edited 1 time(s). Last edit at 02/01/2016 10:28PM by Ludacrisvp.
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
February 01, 2016 11:35PM
Ludacrisvp,

Nothing strange about what you posted above. I vaguely remember somebody has reported seeing this, and iirc it was ethernet cable problem. Have you tried with a different cable?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
February 02, 2016 07:21PM
Went from my home made CAT6 cable to a store bought one... no change.
Also changed switch ports... no change.

Still seeing this logged.

-- typical logged lines --
Feb  2 19:02:11 IQ2700i kernel: [34517.452174] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
Feb  2 19:02:11 IQ2700i kernel: [34517.458198] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
-- cable swap start --
Feb  2 19:03:20 IQ2700i kernel: [34586.725483] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
Feb  2 19:03:52 IQ2700i kernel: [34618.893547] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
-- cable swap completed -- 
Feb  2 19:07:20 IQ2700i kernel: [34826.613900] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
Feb  2 19:07:20 IQ2700i kernel: [34826.620165] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
Feb  2 19:07:20 IQ2700i kernel: [34826.630098] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
-- port swap start --
Feb  2 19:07:53 IQ2700i kernel: [34860.102667] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
Feb  2 19:07:56 IQ2700i kernel: [34862.995091] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
-- port swap completed --
Feb  2 19:12:30 IQ2700i kernel: [35136.903402] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
Feb  2 19:12:30 IQ2700i kernel: [35136.909425] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled

When I was on stock firmware there was no indications of link loss in the logs.
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
February 02, 2016 07:49PM
This may be of interest:

IQ2700i# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Half 1000baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: external
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: d
	Link detected: yes
IQ2700i# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Half 1000baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: external
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: d
	Link detected: no

That seemed odd to me that Link detected had shown Yes and No... so I did a couple while loops:

Note that with a 1 second sleep its 'yes' every time.
IQ2700i# while (true) do ethtool eth0 |grep det;sleep 1; done
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes
	Link detected: yes


Now when I take the sleep out and have it run as fast as it can there are a lot of 'no link' mixed in.

IQ2700i# while (true) do ethtool eth0 |grep det; done
	Link detected: yes
	Link detected: no
	Link detected: no
	Link detected: no
	Link detected: no
	Link detected: no
	Link detected: yes
	Link detected: no
	Link detected: yes
	Link detected: no
	Link detected: yes
	Link detected: no
	Link detected: yes
	Link detected: yes
	Link detected: no
	Link detected: no
	Link detected: no
	Link detected: yes
	Link detected: no
	Link detected: yes

Also, my switch is an unmanaged 16 port rack mount 1Gbps (Monoprice) that also supports EEE (Energy Efficient Ethernet), could this relate to the link up/down?
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
February 03, 2016 11:12AM
shame you cant run the same on your switch + this will rule out a possible hardware fault with the switch.

Im favouring the error is at the switch end and you are logging it at your device end
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
February 03, 2016 11:28AM
> Im favouring the error is at the switch end and
> you are logging it at your device end

This.

@Ludacrisvp, I think if the NSA320 is close to the router, try plug it in directly to the router port.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
February 03, 2016 05:21PM
bodhi Wrote:
-------------------------------------------------------
> > Im favouring the error is at the switch end and you are logging it at your device end
> This.
> @Ludacrisvp, I think if the NSA320 is close to the
> router, try plug it in directly to the router port.

A managed switch would have been nice, but rather cost prohibitive so yes it is a shame that I can't run that on the switch side.

My router does happen to be sitting on top of the switch, so yes it is close by.
Buffalo WXR-1900DHP running DD-WRT v3.0-r28493M std (12/10/15)
Linux WXR-1900DHP 3.10.94 #5207 SMP Thu Dec 10 06:57:16 CET 2015 armv7l DD-WRT

The only thing connected to router is Cable Modem via WAN port and the 16 port switch, and a dozen or so wireless clients, and now the NAS.

However still no joy....

-- start cable move to router --
Feb  3 17:10:56 IQ2700i kernel: [114241.766652] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
Feb  3 17:11:04 IQ2700i kernel: [114250.438443] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled
-- completed --
-- about 5 mins later another error logged --
Feb  3 17:15:12 IQ2700i kernel: [114498.176611] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
Feb  3 17:15:12 IQ2700i kernel: [114498.182727] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, full duplex, flow control disabled

In the end I suppose it is entirely possible that the NIC is bad on the NSA-320 but it just feels so much like log spam based on how it is performing.

If you have an idea on how to do any sort of port monitoring on ddwrt that might be useful to see as well.
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
February 10, 2016 04:27AM
Hi,

in linux-arm kernel recently there were some reports which suggested
it might be worth to try disabling TCP offloading in

/etc/network/interfaces:

auto eth0
iface eth0 inet dhcp
offload-rx off # disables TCP RX offloading
offload-tx off # disables TCP TX offloading

in order to work around a regression introduced with kernel 4.4, so that the
network interface mv643xx loses connection after a few minutes to some hours;
anyway it will need bisecting the commits for 4.4 to find the problematic changes,..

please have a look if that solves your problems also (further down in that thread)
see also the second report:

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405633.html
https://lists.debian.org/debian-arm/2016/01/msg00100.html

best wishes pbg4
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
June 21, 2017 10:05AM
pbg4 Wrote:
-------------------------------------------------------
> offload-rx off # disables TCP RX offloading
> offload-tx off # disables TCP TX offloading
> best wishes pbg4

Bringing back a thread from the grave...
Still having issues with this, however now it has become a problem rather than just log spam.
I did put a nice hack of a workaround in place though, which led to a second workaround being needed.

I was on 4.4.0 for about 280 days of uptime until a power outage exhausted my UPS and the NAS shutdown.
Upon restoring power this log spam became an actual outage after a few minutes.
Took me a while to figure it out (thought maybe it was panicing or something and just hanging).
I had to keep hard powering it off and on to see what was going on, I spent some time getting the LEDs to work which hadn't been a priority since I never had it in visual range.
What this highlighted was that there was still disk access to the root drive (I boot from USB stick and the dual SATA drives are RAID1 data only).
So this clued me into the system still being online.
I then jumped into a screen session and setup a 'while loop' to keep 'upping' the interface to see if that was what was going on.
This worked, but then I noticed that I couldn't reach the internet from it anymore, DNS didn't work (nslookup for anything to 8.8.4.4 failed).
I noticed I could get responses to DNS if i used my router, which led me to /etc/resolv.conf not containing any DNS servers anymore, I manually added a DNS server.
Then I checked netstat -rn and realised that I was missing the standard routes, I manually added the routes and things started working again.

With those workarounds in place, I completed update to latest kernel in hopes of an accidental fix, no dice.

IQ2700i# uname -a
Linux IQ2700i 4.11.3-kirkwood-tld-2 #1 PREEMPT Tue Jun 6 17:01:17 PDT 2017 armv5tel GNU/Linux


IQ2700i# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
IQ2700i# route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.10.10.1 dev eth0
IQ2700i# route add -net 10.10.10.99 netmask 255.255.255.255 gw 127.0.0.1 dev lo
IQ2700i# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.10.10.1      0.0.0.0         UG        0 0          0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.10.10.99     127.0.0.1       255.255.255.255 UGH       0 0          0 lo

I added the options to disable offloading to the interface as you suggested, rebooted, however no change.
I then poked around with ethtool a bit and verified offloading was off, I noted generic offloading was still on, so I disabled that as well with ethtool and still no dice.

IQ2700i# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
	tx-checksum-ipv4: on
	tx-checksum-ip-generic: off [fixed]
	tx-checksum-ipv6: off [fixed]
	tx-checksum-fcoe-crc: off [fixed]
	tx-checksum-sctp: off [fixed]
scatter-gather: on
	tx-scatter-gather: on
	tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
	tx-tcp-segmentation: off [fixed]
	tx-tcp-ecn-segmentation: off [fixed]
	tx-tcp-mangleid-segmentation: off [fixed]
	tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]





For reference, my scripts for workarounds and LEDs.
IQ2700i# cat /etc/init.d/ethernet-keepalive
#! /bin/sh
# /etc/init.d/ethernet-keepalive
#
# Keep that damn link up!
while (true) do ifconfig eth0 10.10.10.99 netmask 255.255.255.0 up; /root/fix-routes.sh; sleep 2; done &
exit 0

IQ2700i# cat /root/fix-routes.sh
#!/bin/sh
# what the f*ck happened to the network routes?
# Fixing the f*cking network
route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.10.10.1 dev eth0 2> /dev/null
route add -net 10.10.10.99 netmask 255.255.255.255 gw 127.0.0.1 dev lo 2> /dev/null
# should be good now

IQ2700i# cat /etc/init.d/enable-leds
#! /bin/sh
# /etc/init.d/enable-leds
# This method of enabling LEDs, borrowed from another user post on this forum, 
# highly modified to be more logical in my mind.
	# Enable USB light for root (boot) drive present
	echo default-on > /sys/class/leds/nsa320\:green\:usb/trigger
	# Enable Copy light for root drive access
	# optionally enable this LED for fun
	# echo default-on > /sys/class/leds/nsa320\:green\:copy/trigger
	echo usb-host > /sys/class/leds/nsa320\:red\:copy/trigger

	# Enable HDD lights both green to indicate populated
	echo default-on > /sys/class/leds/nsa320\:green\:hdd1/trigger
	echo default-on > /sys/class/leds/nsa320\:green\:hdd2/trigger
	# Enable HDD red blink on access per drive
        echo ide-disk1 > /sys/class/leds/nsa320\:red\:hdd1/trigger
        echo ide-disk2 > /sys/class/leds/nsa320\:red\:hdd2/trigger

	# Not sure of how cpu utilization will trigger the orange LED for system status
	echo cpu0 > /sys/class/leds/nsa320\:orange\:sys/trigger

	# Enable a standard green LED for "good" system staus
	echo default-on > /sys/class/leds/nsa320\:green\:sys/trigger

exit 0

Edit:
Forgot to mention I also updated uBoot to the latest version, this problem also got me to use netconsole again.
I've noted that it doesn't work at all when you're on WiFi, had to be hardwired to the network to use it.



Edited 1 time(s). Last edit at 06/21/2017 10:08AM by Ludacrisvp.
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
June 26, 2017 08:52AM
I disabled auto-negotiation on the NSA-320 and it made it several hours without logging any link issues.
I think I'm going to disable my workarounds and see how it goes.

I also renamed the interface from eth0 to egiga0 just for fun.

What seemed odd is that while on auto-negotiate 'mii-tool' says it negotiated half duplex 1Gb flow control.
This is what led me to try to disable auto negotiate.
IQ2700i# mii-tool egiga0 -v
egiga0: negotiated 1000baseT-HD flow-control, link ok
  product info: vendor 00:50:43, model 41 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

And 'ethtool' says it is full duplex, doesn't mention flow control:
IQ2700i# ethtool egiga0
Settings for egiga0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: No
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

And the log says 1Gb full duplex with no flow control:
Jun 25 22:05:55 IQ2700i kernel: [  736.021515] mv643xx_eth_port mv643xx_eth_port.0 egiga0: link up, 1000 Mb/s, full duplex, flow control disabled

So to recap, some of it thinks it is half duplex, some think it is full duplex, some thinks there is flow control, some does not.

Now my settings are as follows:
IQ2700i# ethtool -s egiga0 duplex full speed 1000 autoneg off

IQ2700i# mii-tool egiga0 -v
egiga0: 1000 Mbit, full duplex, link ok
  product info: vendor 00:50:43, model 41 rev 0
  basic mode:   10 Mbit, full duplex
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

IQ2700i# ethtool egiga0
Settings for egiga0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: off
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
June 26, 2017 09:28AM
Is there a better way to disable auto-negotiation?
I re-vamped the init.d script I had.

Currently using this:
IQ2700i# cat /etc/init.d/ethernet-keepalive
#! /bin/sh
# /etc/init.d/ethernet-keepalive
#
# Keep that damn link up!

# bypassing loop and disabling auto negotiation instead
# while (true) do ifconfig egiga0 10.10.10.99 netmask 255.255.255.0 up; /root/fix-routes.sh; sleep 1; done &

# disable auto negotiate
mii-tool egiga0 >> /var/log/messages
logger -t Ethernet "Disable auto negotiate and set speed correctly"
ethtool -s egiga0 duplex full speed 1000 autoneg off 2>> /var/log/messages
mii-tool egiga0 >> /var/log/messages
sleep 5
mii-tool egiga0 >> /var/log/messages
# just in case ...
ifconfig egiga0 10.10.10.99 netmask 255.255.255.0 up
/root/fix-routes.sh

exit 0
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
June 26, 2017 04:49PM
Ludacrisvp,

> Is there a better way to disable auto-negotiation?
> I re-vamped the init.d script I had.

If you need to turn auto-neg off, it's cleaner to turn of in /etc/network/interfaces. You can run ethtool in that script.

But I've found it really strange that ony certain NSA320/325 boxes have this problem (a few others have reported this spamming problem before). My NSA325V2 running 24/7 and I never saw this spamming problem. And the NSA320 & 325 use the same network chip. This makes me suspect the network environment more than the kernel. Have you tried to change your setup temporarily (such as plugging everthing into the same Gbit switch) to see if this problem will go away? if that happens then perhaps the router ports or the switch ports are the reason for network up/down.

Update:

Another possible reason is some application daemon running and it brought the network up/down periodically. Is there anything running periodically at the same the network down/up occured?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 06/26/2017 07:28PM by bodhi.
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
June 26, 2017 04:53PM
Here is my NSA325v2 ethtool output.

~# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Full 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: No
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: g
	Link detected: yes

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Re: NSA-320 kirkwood - eth0 link down/up spam in logs
June 26, 2017 10:25PM
bodhi Wrote:
-------------------------------------------------------
> This makes me suspect the network environment more than the kernel. Have you tried to change
> your setup temporarily (such as plugging everything into the same Gbit switch) to see if this problem
> will go away? if that happens then perhaps the router ports or the switch ports are the reason for network up/down.
>
> Update:
>
> Another possible reason is some application daemon running and it brought the network up/down periodically.
> Is there anything running periodically at the same the network down/up occurred?

I've tried 3 routers and my normal 1Gb 16 port switch along with various cables, both store purchased and ones that I've made.
It has been direct connected to a Buffalo WXR-1900DHP, Buffalo WZR-N600DHP, Netgear WNDR-3400, and the 16 port rack mount Monoprice switch.

Regardless of what it has been connected to it has done this spamming, only after the power outage after being up for ~270 days did it become something that actually took the network down enough that it caused issues, seems like an odd coincidence. It never had issues on the factory firmware with link up / down, but as I don't believe there was access to logging I can't say for sure if there wasn't logging for me to see.

This box, and my network are split between 2 UPS and the NAS did safely shut down due to low battery power based on logging, so I'm not concerned about a power surge causing an issue.

As the timing of the link down / up is so sporadic I can't imagine there is any sort of application or daemon causing it.
Furthermore, since going non-auto-negotiate there hasn't been a single occurrence of a link issue.

I've moved the networking changes for autonegotiation into the correct location and disabled the script method, thanks for that tip.



Edited 1 time(s). Last edit at 06/26/2017 10:27PM by Ludacrisvp.
Author:

Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: