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.
Chadster, no -- it's not meant to discourage you from updating that driver. The opposite, actually: I'm saying that the driver itself is the key piece, with or without NFP. NFP, I think, is a dead end that requires too much maintenance. The point in stating that the factory firmware is not using it is to show that you don't need it.
Nitroshift got the Marvell driver to work with 3.18, I recall, and it sped things up for him quite a bit.
(Last edited by leitec on 11 Jun 2016, 15:27)
Chadster, no -- it's not meant to discourage you from updating that driver. The opposite, actually: I'm saying that the driver itself is the key piece, with or without NFP. NFP, I think, is a dead end that requires too much maintenance. The point in stating that the factory firmware is not using it is to show that you don't need it.
Nitroshift got the Marvell driver to work with 3.18, I recall, and it sped things up for him quite a bit.
Just to confirm the above. Working with Marvell code is tough, though.
nitroshift
Chadster, no -- it's not meant to discourage you from updating that driver. The opposite, actually: I'm saying that the driver itself is the key piece, with or without NFP. NFP, I think, is a dead end that requires too much maintenance. The point in stating that the factory firmware is not using it is to show that you don't need it.
Nitroshift got the Marvell driver to work with 3.18, I recall, and it sped things up for him quite a bit.
Thanks for your recommendations and for checking out the mvebu_net driver for me 
leitec wrote:Chadster, no -- it's not meant to discourage you from updating that driver. The opposite, actually: I'm saying that the driver itself is the key piece, with or without NFP. NFP, I think, is a dead end that requires too much maintenance. The point in stating that the factory firmware is not using it is to show that you don't need it.
Nitroshift got the Marvell driver to work with 3.18, I recall, and it sped things up for him quite a bit.
Thanks for your recommendations and for checking out the mvebu_net driver for me
Good luck, and sorry my writing is... confusing 
iPerf WAN to LAN testing
root@lede:~# cat /dev/mtd3|grep -E "modelNumber|hw_revision"
hw_revision=1
modelNumber=WRT1200AC
root@lede:~# uname -a
Linux lede 4.4.12 #1 SMP Sat Jun 11 14:47:08 UTC 2016 armv7l GNU/Linux
Windows iPerf Client:
C:\Users\chad\Downloads\iperf-3.0.11-win32>iperf3 -c 192.168.200.1
Connecting to host 192.168.200.1, port 5201
[ 4] local 192.168.1.2 port 19772 connected to 192.168.200.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 95.5 MBytes 801 Mbits/sec
[ 4] 1.00-2.00 sec 96.6 MBytes 809 Mbits/sec
[ 4] 2.00-3.00 sec 96.1 MBytes 806 Mbits/sec
[ 4] 3.00-4.00 sec 96.8 MBytes 812 Mbits/sec
[ 4] 4.00-5.00 sec 95.9 MBytes 805 Mbits/sec
[ 4] 5.00-6.00 sec 97.1 MBytes 815 Mbits/sec
[ 4] 6.00-7.00 sec 96.0 MBytes 805 Mbits/sec
[ 4] 7.00-8.00 sec 96.3 MBytes 808 Mbits/sec
[ 4] 8.00-9.00 sec 96.2 MBytes 807 Mbits/sec
[ 4] 9.00-10.00 sec 92.7 MBytes 778 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 959 MBytes 805 Mbits/sec sender
[ 4] 0.00-10.00 sec 959 MBytes 805 Mbits/sec receiver
iperf Done.
C:\Users\chad\Downloads\iperf-3.0.11-win32>iperf3 -c 192.168.200.1 -R
Connecting to host 192.168.200.1, port 5201
Reverse mode, remote host 192.168.200.1 is sending
[ 4] local 192.168.1.2 port 19774 connected to 192.168.200.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 76.9 MBytes 645 Mbits/sec
[ 4] 1.00-2.00 sec 77.0 MBytes 646 Mbits/sec
[ 4] 2.00-3.00 sec 80.4 MBytes 675 Mbits/sec
[ 4] 3.00-4.00 sec 80.7 MBytes 677 Mbits/sec
[ 4] 4.00-5.00 sec 80.6 MBytes 676 Mbits/sec
[ 4] 5.00-6.00 sec 80.4 MBytes 675 Mbits/sec
[ 4] 6.00-7.00 sec 80.4 MBytes 675 Mbits/sec
[ 4] 7.00-8.00 sec 80.6 MBytes 676 Mbits/sec
[ 4] 8.00-9.00 sec 80.4 MBytes 674 Mbits/sec
[ 4] 9.00-10.00 sec 80.3 MBytes 673 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 798 MBytes 669 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 798 MBytes 669 Mbits/sec receiver
iperf Done.
iPerf WAN to LAN testing
root@lede:~# cat /dev/mtd3|grep -E "modelNumber|hw_revision"
hw_revision=1
modelNumber=WRT1900AC
root@lede:~# uname -a
Linux lede 4.4.12 #1 SMP Sat Jun 11 14:47:08 UTC 2016 armv7l GNU/Linux
Windows iPerf Client:
C:\Users\chad\Downloads\iperf-3.0.11-win32>iperf3 -c 192.168.200.1
Connecting to host 192.168.200.1, port 5201
[ 4] local 192.168.1.2 port 19850 connected to 192.168.200.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 65.9 MBytes 553 Mbits/sec
[ 4] 1.00-2.00 sec 67.8 MBytes 569 Mbits/sec
[ 4] 2.00-3.00 sec 69.2 MBytes 580 Mbits/sec
[ 4] 3.00-4.00 sec 69.0 MBytes 579 Mbits/sec
[ 4] 4.00-5.00 sec 67.7 MBytes 568 Mbits/sec
[ 4] 5.00-6.00 sec 68.9 MBytes 578 Mbits/sec
[ 4] 6.00-7.00 sec 70.1 MBytes 588 Mbits/sec
[ 4] 7.00-8.00 sec 68.7 MBytes 577 Mbits/sec
[ 4] 8.00-9.00 sec 68.1 MBytes 571 Mbits/sec
[ 4] 9.00-10.00 sec 69.1 MBytes 580 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 685 MBytes 574 Mbits/sec sender
[ 4] 0.00-10.00 sec 685 MBytes 574 Mbits/sec receiver
iperf Done.
C:\Users\chad\Downloads\iperf-3.0.11-win32>iperf3 -c 192.168.200.1 -R
Connecting to host 192.168.200.1, port 5201
Reverse mode, remote host 192.168.200.1 is sending
[ 4] local 192.168.1.2 port 19852 connected to 192.168.200.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 53.4 MBytes 448 Mbits/sec
[ 4] 1.00-2.00 sec 58.0 MBytes 486 Mbits/sec
[ 4] 2.00-3.00 sec 61.0 MBytes 512 Mbits/sec
[ 4] 3.00-4.00 sec 61.6 MBytes 517 Mbits/sec
[ 4] 4.00-5.00 sec 61.2 MBytes 514 Mbits/sec
[ 4] 5.00-6.00 sec 61.4 MBytes 515 Mbits/sec
[ 4] 6.00-7.00 sec 61.5 MBytes 516 Mbits/sec
[ 4] 7.00-8.00 sec 61.2 MBytes 513 Mbits/sec
[ 4] 8.00-9.00 sec 61.2 MBytes 513 Mbits/sec
[ 4] 9.00-10.00 sec 61.4 MBytes 515 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 602 MBytes 505 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 602 MBytes 505 Mbits/sec receiver
iperf Done.
iPerf WAN to LAN testing
WRT1900AC V1 Stock Firmware Version: 1.1.10.167514
Windows iPerf Client:
C:\Users\chad\Downloads\iperf-3.0.11-win32>iperf3 -c 192.168.200.1
Connecting to host 192.168.200.1, port 5201
[ 4] local 192.168.1.2 port 20259 connected to 192.168.200.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 87.1 MBytes 730 Mbits/sec
[ 4] 1.00-2.00 sec 84.1 MBytes 705 Mbits/sec
[ 4] 2.00-3.00 sec 89.8 MBytes 753 Mbits/sec
[ 4] 3.00-4.00 sec 91.9 MBytes 771 Mbits/sec
[ 4] 4.00-5.00 sec 83.7 MBytes 702 Mbits/sec
[ 4] 5.00-6.01 sec 82.6 MBytes 690 Mbits/sec
[ 4] 6.01-7.00 sec 92.0 MBytes 774 Mbits/sec
[ 4] 7.00-8.00 sec 91.7 MBytes 769 Mbits/sec
[ 4] 8.00-9.00 sec 91.6 MBytes 768 Mbits/sec
[ 4] 9.00-10.00 sec 91.6 MBytes 769 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 886 MBytes 743 Mbits/sec sender
[ 4] 0.00-10.00 sec 886 MBytes 743 Mbits/sec receiver
iperf Done.
C:\Users\chad\Downloads\iperf-3.0.11-win32>iperf3 -c 192.168.200.1 -R
Connecting to host 192.168.200.1, port 5201
Reverse mode, remote host 192.168.200.1 is sending
[ 4] local 192.168.1.2 port 20261 connected to 192.168.200.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 75.1 MBytes 630 Mbits/sec
[ 4] 1.00-2.00 sec 75.0 MBytes 629 Mbits/sec
[ 4] 2.00-3.00 sec 75.0 MBytes 630 Mbits/sec
[ 4] 3.00-4.00 sec 75.2 MBytes 631 Mbits/sec
[ 4] 4.00-5.00 sec 74.9 MBytes 628 Mbits/sec
[ 4] 5.00-6.00 sec 75.6 MBytes 634 Mbits/sec
[ 4] 6.00-7.00 sec 75.5 MBytes 633 Mbits/sec
[ 4] 7.00-8.00 sec 75.4 MBytes 633 Mbits/sec
[ 4] 8.00-9.00 sec 75.7 MBytes 635 Mbits/sec
[ 4] 9.00-10.00 sec 75.7 MBytes 635 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 753 MBytes 632 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 753 MBytes 632 Mbits/sec receiver
iperf Done.
1900acs:~# free -m
total used free shared buffers cached
Mem: 513496 75080 438416 1060 5572 15060
-/+ buffers/cache: 54448 459048
Swap: 1048572 0 1048572
root@1900acs:~#
So 459048 free.
Please run the commands while you are having a memory issue.
Well I had an issue with one of the network cards I was using for my performance testing. After I fixed that I ran the WAN to LAN speed tests again.
It provided proof that what the other forum users are saying is true; NFP is no longer needed with these higher end processors 
(Last edited by Chadster766 on 11 Jun 2016, 17:59)
shm0 wrote:Switch/VLAN config:
config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option vid '100' option ports '4 5t' config switch_vlan option device 'switch0' option vlan '2' option vid '2' option ports '2 3 6t' config switch_vlan option device 'switch0' option vlan '3' option vid '3' option ports '0 6t' config switch_vlan option device 'switch0' option vlan '4' option vid '4' option ports '1 6t'When you tried on the other Ethernet port, did you also flip the switch VLAN assignments accordingly? (i.e. swap 5t and 6t where appropriate)
I havent switched here in this case and just replaced everything with eth0.x as some users stated here and for me this is not working.
I am not very experienced with vlans this is actually my first time with vlans :x
So someone can tell me what i do wrong please?
Let me see if i get this right.
We have eth1 switch interface (cpu port 6) and eth0 wan interface (cpu port 5).
Two physical interfaces or?
When we enable vlans through swconfig it layers the vlans upon those devices or?
So why you want to use eth0.x for the eth1 switch interface?
Maybe if you set both cpu ports tagged in all vlans this can work?
what about the bridge interface br-lan? You can also use br-lan.x or?
This is interesting... Dealing with ACS... My initial flash to OpenWrt from stock went well - No issues. However, I built a new image this morning and tried flashing through Luci, and both times failed. A reboot brings up the original image.
I guess I'll try a sysupgrade next.
I havent switched here in this case and just replaced everything with eth0.x as some users stated here and for me this is not working.
I am not very experienced with vlans this is actually my first time with vlans :x
So someone can tell me what i do wrong please?Let me see if i get this right.
We have eth1 switch interface (cpu port 6) and eth0 wan interface (cpu port 5).
Two physical interfaces or?
When we enable vlans through swconfig it layers the vlans upon those devices or?
So why you want to use eth0.x for the eth1 switch interface?
Maybe if you set both cpu ports tagged in all vlans this can work?what about the bridge interface br-lan? You can also use br-lan.x or?
They're two separate ports on a single mvneta interface. For practical purposes they are two interfaces.
When you create a VLAN with swconfig it configures the VLAN on the switch only. The switch will then send out packets to the appropriate port, with tags if specified. If you enabled tagging, you have to then create a tagged interface in OpenWrt, eth0.X or eth1.X.
For eth0.X interfaces, you have to specify port 5t on the switch VLAN config. For eth1.X you have to specify port 6t. That would be why the one configuration worked while the other failed. There's no real reason to use one port or the other. I would personally keep the same ports used in the default config and just add VLANs on top of that, but there's no strict requirement.
As for the bridge, if you add "option type 'bridge'" to your configured network "isolated" you will get a new bridge called "br-isolated".
command line sysupgrade fails too with this error. Anyone seen this before? "## Error: "boot_part" not defined"
root@OpenWrt:~# sysupgrade -v /tmp/openwrt-mvebu-armada-385-linksys-shelby-squashfs-sysupgrade.tar
Saving config files...
etc/config/ddns
etc/config/ddns-opkg
etc/config/dhcp
etc/config/dropbear
etc/config/firewall
etc/config/fstab
etc/config/luci
etc/config/network
etc/config/qos
etc/config/rpcd
etc/config/snmpd
etc/config/system
etc/config/ubootenv
etc/config/ucitrack
etc/config/uhttpd
etc/config/wireless
etc/crontabs/root
etc/dnsmasq.conf
etc/dropbear/dropbear_rsa_host_key
etc/firewall.user
etc/fw_env.config
etc/group
etc/hosts
etc/inittab
etc/luci-uploads/.placeholder
etc/opkg/keys/211382dde7de480a
etc/opkg/keys/42677247841dbd0a
etc/opkg/keys/47187709c0222536
etc/opkg/keys/53d5ba540d26c387
etc/opkg/keys/624309ac872c1055
etc/opkg/keys/876cb6eb1f826309
etc/opkg/keys/92f21d2388babe76
etc/opkg/keys/93c735fe3a8b722f
etc/opkg/keys/a5a504039cd445a3
etc/opkg/keys/a9e3a8effdb07725
etc/opkg/keys/ae6fa5096c3e678
etc/opkg/keys/af22f7a88858c8e9
etc/opkg/keys/afd42d180ebd36b7
etc/opkg/keys/c0e93d387eed7319
etc/opkg/keys/d5126a106191d17d
etc/opkg/keys/d5901c996c28a9d2
etc/passwd
etc/profile
etc/rc.local
etc/shadow
etc/shells
etc/sysctl.conf
etc/sysctl.d/local.conf
killall: watchdog: no process killed
Sending TERM to remaining processes ... logd rpcd netifd odhcpd crond snmpd uhttpd dnsmasq logread /sbin/sysupgrade: line 237: can't open /proc/1883/cmdline: no such file
grep ntpd ubusd askfirst
Sending KILL to remaining processes ... askfirst
Switching to ramdisk...
Performing system upgrade...
## Error: "boot_part" not defined
cannot find target partition(Last edited by davidc502 on 11 Jun 2016, 20:10)
command line sysupgrade fails too with this error. Anyone seen this before? "## Error: "boot_part" not defined"
<snip> ## Error: "boot_part" not defined cannot find target partition
Oh, that looks like a problem that came up recently for an ACS user on the lede-dev mailing list. The u_env partition (u-boot settings) gets wiped out for some reason, and the bootloader doesn't save the defaults to flash on reset. The only way to fix it that I can think of is to connect the serial console, then issue the following from the u-boot prompt:
resetenv; reset
once it restarts, stop u-boot again and issue
saveenv; reset
(this will save the default values back to flash)
Then, let it boot normally.
(Last edited by leitec on 11 Jun 2016, 20:32)
command line sysupgrade fails too with this error. Anyone seen this before? "## Error: "boot_part" not defined"
<snip> ## Error: "boot_part" not defined cannot find target partition
known issue for which Felix added a fix in Lede this weekend.
The aforementioned fix should prevent it from happening again, but you probably have to manually reset the u-boot environment before you can flash a new image.
hi,
can somebody compile astra for wrt1200?
https://bitbucket.org/cesbo/astra
Appreciate everyone's help... Looks like I will be cracking open the ACS and run the command leitec recommended. Fortunately I hear it's easier than V1.
Also looks like I need to put a warning out on the webpage for ACS owners wanting to flash OpenWrt.
Another Also, looks like I might not be sitting on the "LEDE" sidelines as long as I wanted too
Cheers,
(Last edited by davidc502 on 11 Jun 2016, 22:10)
David, if you're loath to open it up you could get a "transplant" from another ACS user's u_env partition and flash that with the "mtd" command. You'll then have to set your unit's MAC address with fw_setenv, but it should otherwise be OK (provided the NAND driver does OK writing it without the fix that JohnnySL mentioned)
The aforementioned fix should prevent it from happening again, but you probably have to manually reset the u-boot environment before you can flash a new image.
Agreed, damage is done, needs to be fixed first.
David, if you're loath to open it up you could get a "transplant" from another ACS user's u_env partition and flash that with the "mtd" command. You'll then have to set your unit's MAC address with fw_setenv, but it should otherwise be OK (provided the NAND driver does OK writing it without the fix that JohnnySL mentioned)
Fortunately, I bought the USB/TTL last year, so it is time I put it to good use, but thanks anyway.
leitec wrote:The aforementioned fix should prevent it from happening again, but you probably have to manually reset the u-boot environment before you can flash a new image.
Agreed, damage is done, needs to be fixed first.
Okay, from the start...
1. I want to fix it first. What commands need to be run? < flashing OpenWrt will re-create the problem again?
2. After the fix, run leitec recommended commands?
Appreciate it, because I want to document what needs to be done.
(Last edited by davidc502 on 11 Jun 2016, 22:54)
Here is the thread being referenced.
davidc502 wrote:command line sysupgrade fails too with this error. Anyone seen this before? "## Error: "boot_part" not defined"
<snip> ## Error: "boot_part" not defined cannot find target partitionknown issue for which Felix added a fix in Lede this weekend.
Could you please reference the commit?
@sera
I think this is what you wanted.