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.
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)
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=3306The 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!
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
On another note I was wondering if your mamba fan procd stuff is in a git somewhere?
Nope.
None that I know about.
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 $FILTERedNote 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
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.
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?
@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
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
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?
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
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?
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)
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.
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.
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)
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
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
Thanks so much
You may have restored my faith in those network adapters I have!
(Last edited by Chadster766 on 8 Nov 2016, 18:05)
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.
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.
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
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?
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.