OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

@gufus, Just an FYI: LEDE forum, bugs, wiki. On another note I was wondering if your mamba fan procd stuff is in a git somewhere? LEDE has this and it would be nice to have seperate images for mamba and the rest, so as to deal with the fan anomaly.

gufus wrote:

Tryed to upgrade lede

image date:  05-Nov-2016 18:23

root@AC1900M:~# cd /tmp
root@AC1900M:/tmp# sysupgrade -c lede-mvebu-linksys-wrt1900ac-squashfs-sysupgrad
e.bin
Saving config files...
killall: watchdog: no process killed
Sending TERM to remaining processes ... logd rpcd netifd odhcpd crond dnscrypt-proxy uhttpd smbd nmbd collectd dnsmasq ntpd fan_monitor vnstatd sleep ubusd askfirst
Sending KILL to remaining processes ... askfirst
Switching to ramdisk...
Performing system upgrade...
cannot find target partition
@AC1900M:/tmp#

Anyone else see this error?

Yeah, me recently. Using a factory image through luci worked and I've done sysupgrades successfully since.

Edit: sorry was getting mixed up with the platform image check error I also had recently.

For this one I just reflashed the linksys image via serial

(Last edited by listerwrt on 6 Nov 2016, 07:50)

InkblotAdmirer wrote:

I have a script that scrubs the logs every night.  Since Sep 1 (top dest ports dropped by firewall, only those with count over 500):

Count by DST port:
  62318 DPT=23
   2752 DPT=2323
   2499 DPT=22
   1550 DPT=3389
   1175 DPT=80
    715 DPT=443
    662 DPT=8080
    631 DPT=53413
    526 DPT=3306

The 53413 was originally a "huh?" moment, but google it -- there's a well-known vulnerability in netis routers.  But yes, in the last few months the telnet traffic has gone through the roof.

Hi! you can share the script? Thank you!

Foguet wrote:

Hi! you can share the script? Thank you!

Here you go.  Some variables are self-explanatory but these probably aren't:

$TMPFILE is created from log files to be processed
$FILTER is a string to pull out lines from the logs (I add custom text to the drop log in iptables rule)
$REJECT is a string that eliminates lines after $FILTERed

Note I'm lazy on scripts and so $OUTFILE from the first line becomes $INFILE for the actual processing

cat $TMPFILE | grep $FILTER | grep -v $REJECT  > $OUTFILE

rm -f $TMPFILE

INFILE=$STORAGE/$DROP_FILE
OUTFILE=$STORAGE/$PROC_FILE

# find WAN TCP, extract section starting with SRC= and ending with WINDOW=, pipe to sed (add SRC= back) then
#   print SRC/DST IP, protocol, and SRC/DST port
cat $INFILE | grep "eth0.2" | grep "TCP" | awk -v FS="(SRC=|WINDOW=)" '{print $2}' \
  | sed 's/^/SRC=/' | awk '{print $1,$2,$9,$10,$11}' > $TMPFILE
# find WAN UDP, extract section starting with SRC=, pipe to sed (add SRC= back) then
#   print SRC/DST IP, protocol, and SRC/DST port
cat $INFILE | grep "eth0.2" | grep "UDP" | awk -v FS="(SRC=)" '{print $2}' \
  | sed 's/^/SRC=/' | awk '{print $1,$2,$8,$9,$10}' >> $TMPFILE

UIP=$(cat $TMPFILE | grep "SRC" | awk '{print $1}' | sort|uniq | wc -l)

echo "Unique SRC IPs: $UIP"$'\n' > $OUTFILE

echo "Count by SRC IP:" >> $OUTFILE
cat $TMPFILE | grep "SRC" | awk '{print $1}' | sort|uniq -c | sort -b -r | head -n 250 >> $OUTFILE

echo $'\n'"Count by DST port:" >> $OUTFILE
cat $TMPFILE | grep "DPT" | awk '{print $NF}' | sort|uniq -c | sort -b -r | head -n 250 >> $OUTFILE
Villeneuve wrote:

On another note I was wondering if your mamba fan procd stuff is in a git somewhere?

Nope.

None that I know about.

InkblotAdmirer wrote:
Foguet wrote:

Hi! you can share the script? Thank you!

Here you go.  Some variables are self-explanatory but these probably aren't:

$TMPFILE is created from log files to be processed
$FILTER is a string to pull out lines from the logs (I add custom text to the drop log in iptables rule)
$REJECT is a string that eliminates lines after $FILTERed

Note I'm lazy on scripts and so $OUTFILE from the first line becomes $INFILE for the actual processing

cat $TMPFILE | grep $FILTER | grep -v $REJECT  > $OUTFILE

rm -f $TMPFILE

INFILE=$STORAGE/$DROP_FILE
OUTFILE=$STORAGE/$PROC_FILE

# find WAN TCP, extract section starting with SRC= and ending with WINDOW=, pipe to sed (add SRC= back) then
#   print SRC/DST IP, protocol, and SRC/DST port
cat $INFILE | grep "eth0.2" | grep "TCP" | awk -v FS="(SRC=|WINDOW=)" '{print $2}' \
  | sed 's/^/SRC=/' | awk '{print $1,$2,$9,$10,$11}' > $TMPFILE
# find WAN UDP, extract section starting with SRC=, pipe to sed (add SRC= back) then
#   print SRC/DST IP, protocol, and SRC/DST port
cat $INFILE | grep "eth0.2" | grep "UDP" | awk -v FS="(SRC=)" '{print $2}' \
  | sed 's/^/SRC=/' | awk '{print $1,$2,$8,$9,$10}' >> $TMPFILE

UIP=$(cat $TMPFILE | grep "SRC" | awk '{print $1}' | sort|uniq | wc -l)

echo "Unique SRC IPs: $UIP"$'\n' > $OUTFILE

echo "Count by SRC IP:" >> $OUTFILE
cat $TMPFILE | grep "SRC" | awk '{print $1}' | sort|uniq -c | sort -b -r | head -n 250 >> $OUTFILE

echo $'\n'"Count by DST port:" >> $OUTFILE
cat $TMPFILE | grep "DPT" | awk '{print $NF}' | sort|uniq -c | sort -b -r | head -n 250 >> $OUTFILE

Thank you!!! I try to see statistics gives me smile

How do people feel about using dsa vs. swconfig? Why would you go for one over the other?

@sera

dsa is already defined in the device tree files corresponding to the wrt series, might give it a try anyway.

nitroshift

@nitroshift

Dsa works as advertised, I have no complaints. but the same can be said of swconfig. So I ask in light of eventually moving OpenWrt to use dsa at least for this devices instead. Something like that obviously can't just be done.

Some might remember me pointing out to Chadster having seen several commits wrt dsa in 4.7, in retrospect 4.8 was even bigger in this regard with 4.9 bringing another large chunk while next already has more stuff pending. So someone has gotten serious here. With more vendors jumping onto the dsa bandwagon me thinks swconfig finally lost the race after about a decade. Sure not entirely unexpected. The only thing still in favour of swconfig is that at least in theory you can actually use the 2 Gbit between cpu and switch, though it's on the TODO for dsa.

gsustek wrote:
nitroshift wrote:

Regarding the nand time-out issue, there are talks within the kernel team to completely rewrite the driver, getting rid of data transfer in IRQ handler and replace it with {read,write}_buf in the context of the calling process that asks data to be read / written.

nitroshift

Good news.

hi, is that completed?

sera wrote:

@nitroshift

Dsa works as advertised, I have no complaints. but the same can be said of swconfig. So I ask in light of eventually moving OpenWrt to use dsa at least for this devices instead. Something like that obviously can't just be done.

Some might remember me pointing out to Chadster having seen several commits wrt dsa in 4.7, in retrospect 4.8 was even bigger in this regard with 4.9 bringing another large chunk while next already has more stuff pending. So someone has gotten serious here. With more vendors jumping onto the dsa bandwagon me thinks swconfig finally lost the race after about a decade. Sure not entirely unexpected. The only thing still in favour of swconfig is that at least in theory you can actually use the 2 Gbit between cpu and switch, though it's on the TODO for dsa.

My WAN to LAN throughput testing hasn't been that reliable. I've had the Linux kernel DSA Module built and useable up to 4.7.5 but I'm concerned that the WAN to LAN throughput may not be very good with the Linux kernel Marvell DSA drivers\modules compared to OpenWRT swconfig and it's Marvell switch patches.

If someone could do some WAN to LAN DSA throughput testing with the Linux Marvell DSA driver\modules to confirm that a performance issue exists or that it doesn't exist or was solved with +4.7.5 Linux kernel modules that would be great smile

gsustek wrote:
gsustek wrote:
nitroshift wrote:

Regarding the nand time-out issue, there are talks within the kernel team to completely rewrite the driver, getting rid of data transfer in IRQ handler and replace it with {read,write}_buf in the context of the calling process that asks data to be read / written.

nitroshift

Good news.

hi, is that completed?

Not yet.

nitroshift

Chadster766 wrote:

My WAN to LAN throughput testing hasn't been that reliable.

Your testing or the connection? Harhar.

I can test on 4.8 and up. Can you be a bit more specific as to what you mean with unreliable so I know what issue to look out for?


Chadster766 wrote:

I've had the Linux kernel DSA Module built and useable up to 4.7.5 but I'm concerned that the WAN to LAN throughput may not be very good with the Linux kernel Marvell DSA drivers\modules compared to OpenWRT swconfig and it's Marvell switch patches.

If someone could do some WAN to LAN DSA throughput testing with the Linux Marvell DSA driver\modules to confirm that a performance issue exists or that it doesn't exist or was solved with +4.7.5 Linux kernel modules that would be great smile

Your are probably one of a few who has some serious experience with older kernels and DSA. Would you say DSA is usable in 4.4, just barely or is it more like you have to run synthetic benchmarks to notice that it underperforms?

sera wrote:

I can test on 4.8 and up. Can you be a bit more specific as to what you mean with unreliable so I know what issue to look out for?

The network adapters in my two identical HP Desktops can have performance problems with some devices producing lower than expected iperf results.

(Intel(R) Gigabit CT Desktop and Intel(R) 82579LM Gigabit Network adapters)

sera wrote:

Would you say DSA is usable in 4.4, just barely or is it more like you have to run synthetic benchmarks to notice that it underperforms?

If I remember correctly DSA has been completely useable from kernel 4.4.2 up. My only issue with it was WAN to LAN throughput performance.

When testing WAN to LAN throughput with iperf3 I recommend testing speeds both directions using the "-R" option.

So took a dsa enabled image based on a 4.9 kernel which I had laying around and did run the WAN to LAN and vice versa test. I got roughly 935Mbit in each direction while with swconfig it was 940Mbit iirc. What I noticed is dsa being quite a bit more demanding on cpu and while Shelby can handle that load I wouldn't be surprised if you could actually see a throughput regression on Mamba.

Chadster766 wrote:

If I remember correctly DSA has been completely useable from kernel 4.4.2 up. My only issue with it was WAN to LAN throughput performance.

Thanks for the info. That means dsa is at least a real option.

sera wrote:

So took a dsa enabled image based on a 4.9 kernel which I had laying around and did run the WAN to LAN and vice versa test. I got roughly 935Mbit in each direction while with swconfig it was 940Mbit iirc.

It would be awesome if you could test kernel 4.8.6 stable.

Would there be a reason why using the power switch to turn off and on a WRT1200 v1 would result with SquashFS errors and a Bad Gateway return when trying to access LuCI, but rebooting via cli reboot would result in the errors not occurring?

Kernel 4.4.14 r49953

Tue Nov  8 08:15:58 2016 kern.err kernel: [  765.473270] SQUASHFS error: squashfs_read_data failed to read block 0x1711ab5
Tue Nov  8 08:15:58 2016 kern.err kernel: [  765.480455] SQUASHFS error: Unable to read metadata cache entry [1711ab5]
Tue Nov  8 08:15:58 2016 kern.err kernel: [  765.487268] SQUASHFS error: Unable to read directory block [1711ab5:a3d]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.711906] SQUASHFS error: Unable to read metadata cache entry [1711ab5]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.718754] SQUASHFS error: Unable to read directory block [1711ab5:a3d]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.725853] SQUASHFS error: Unable to read metadata cache entry [1711ab5]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.732709] SQUASHFS error: Unable to read directory block [1711ab5:a3d]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.739579] SQUASHFS error: Unable to read metadata cache entry [1711ab5]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.746411] SQUASHFS error: Unable to read directory block [1711ab5:a3d]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.753289] SQUASHFS error: Unable to read metadata cache entry [1711ab5]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.760130] SQUASHFS error: Unable to read directory block [1711ab5:a3d]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.767012] SQUASHFS error: Unable to read metadata cache entry [1711ab5]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.773844] SQUASHFS error: Unable to read directory block [1711ab5:a3d]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.780659] SQUASHFS error: Unable to read metadata cache entry [1711ab5]
Tue Nov  8 08:16:08 2016 kern.err kernel: [  775.787484] SQUASHFS error: Unable to read directory block [1711ab5:a3]
  • SquashFS errors will appear at semi-regular intervals ranging from 1s - 60s+

(Last edited by JW0914 on 8 Nov 2016, 15:36)

Chadster766 wrote:
sera wrote:

So took a dsa enabled image based on a 4.9 kernel which I had laying around and did run the WAN to LAN and vice versa test. I got roughly 935Mbit in each direction while with swconfig it was 940Mbit iirc.

It would be awesome if you could test kernel 4.8.6 stable.

Good news, I can reproduce your issue on 4.8.6, meaning 4.9 actually has the fix you waited for. Bad news, mwlwifi wont compile on 4.9 right now wink

sera wrote:
Chadster766 wrote:
sera wrote:

So took a dsa enabled image based on a 4.9 kernel which I had laying around and did run the WAN to LAN and vice versa test. I got roughly 935Mbit in each direction while with swconfig it was 940Mbit iirc.

It would be awesome if you could test kernel 4.8.6 stable.

Good news, I can reproduce your issue on 4.8.6, meaning 4.9 actually has the fix you waited for. Bad news, mwlwifi wont compile on 4.9 right now wink

Thanks so much smile

You may have restored my faith in those network adapters I have!

(Last edited by Chadster766 on 8 Nov 2016, 18:05)

JW0914 wrote:

Would there be a reason why using the power switch to turn off and on a WRT1200 v1 would result with SquashFS errors and a Bad Gateway return when trying to access LuCI, but rebooting via cli reboot would result in the errors not occurring?

Kernel 4.4.14 r49953

I am not seeing those errors JW.

root@caiman:/# cat /etc/openwrt_release 
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='49984'
DISTRIB_CODENAME='designated_driver'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_DESCRIPTION='OpenWrt Designated Driver 49984'
DISTRIB_TAINTS='no-all'

root@caiman:/# uname -a
Linux caiman 4.4.14 #1 SMP Tue Nov 8 16:16:12 UTC 2016 armv7l GNU/Linux

@kirkgbr I was asking if there would be a reason for what I was experiencing =]

hi, during the copy od 40GB file from laptop through 1GB cat 6a 400MHz cabel, to 1Tb SATA disk, i got this regulary about 70 seconds drops.  vsftp is using about 20% od CPU.

http://i65.tinypic.com/5d1mhj.png
http://i63.tinypic.com/iekqid.png


netdata logs

 Health alarm 'net_drops.tun0.1hour_packet_drops' = 145.00 - changed status from CLEAR to WARNING
child pid 10155 exited with code 127.
 Health alarm 'net_drops.tun0.1hour_packet_drops' = 0.00 - changed status from WARNING to CLEAR
child pid 10482 exited with code 127.
 Health alarm 'net_drops.br-lan.1hour_packet_drops' = 1.50 - changed status from UNINITIALIZED to WARNING
child pid 11053 exited with code 127.
 Health alarm 'system.cpu.10min_cpu_iowait' = 13.11 - changed status from CLEAR to WARNING
child pid 14783 exited with code 127.
 Health alarm 'disk_space.sda1.out_of_disk_space_time' = 7.13 - changed status from CLEAR to WARNING
child pid 17494 exited with code 127.
 Health alarm 'disk_backlog.sda.10min_disk_backlog' = 2439.44 - changed status from CLEAR to WARNING
child pid 20185 exited with code 127.
 Health alarm 'system.cpu.10min_cpu_iowait' = 32.61 - changed status from WARNING to CRITICAL
child pid 25670 exited with code 127.
 Health alarm 'disk_util.sda.10min_disk_utilization' = 97.37 - changed status from CLEAR to WARNING
child pid 662 exited with code 127.
 Health alarm 'disk_space.sda1.out_of_disk_space_time' = 1.99 - changed status from WARNING to CRITICAL
child pid 2412 exited with code 127.
 Health alarm 'disk_util.sda.10min_disk_utilization' = 99.92 - changed status from WARNING to CRITICAL
child pid 2892 exited with code 127.

netdata logs:

 Health alarm 'disk_backlog.sda.10min_disk_backlog' = 1140.39 - changed status from WARNING to CLEAR
child pid 24255 exited with code 127.
 Health alarm 'disk_util.sda.10min_disk_utilization' = 54.56 - changed status from WARNING to CLEAR
child pid 24263 exited with code 127.
 Health alarm 'disk_space.sda1.disk_space_usage' = 95.01 - changed status from WARNING to CRITICAL
child pid 26954 exited with code 127.
 Health alarm 'system.cpu.10min_cpu_iowait' = 10.82 - changed status from CLEAR to WARNING
child pid 29691 exited with code 127.
 Health alarm 'disk_backlog.sda.10min_disk_backlog' = 2347.22 - changed status from CLEAR to WARNING
child pid 32429 exited with code 127.


http://i63.tinypic.com/28835vd.png

this is through wifi 5GHz, two vsftp threads regular but little longer between drops
why is that? what should i check?

(Last edited by gsustek on 8 Nov 2016, 22:19)

Check to see if sysctl  has a setting vm.min_free_kbytes=16384

Chadster766 wrote:

Check to see if sysctl  has a setting vm.min_free_kbytes=16384


i have:

#memory tunning

vm.min_free_kbytes=65536


is it too much?

gsustek wrote:
Chadster766 wrote:

Check to see if sysctl  has a setting vm.min_free_kbytes=16384


i have:

#memory tunning

vm.min_free_kbytes=65536


is it too much?

IMO its high especially for a WRT1900AC V1.