well what ever its worth.. whenever i've messed up installed packages of screwed the config real bad. I've deleted everything in /overlay, reboot the router and it boots up as new openwrt with default settings.

This suggestion was given to me by someone more experienced several months back when i had just started wetting my feet with openwrt for the time..

PS. I've had a scenario in the past, twice, where i flashed from oem to openwrt and it came back with all my settings!!!

I think it depends what was in your secondary flash or maybe in my case, it had ended up booting the secondary flash that retained my settings... It was something i never looked into it any further but it did happen.

(Last edited by alirz on 29 Jun 2015, 21:02)

I'm getting 50% or more packet loss utilizing the 5gHz network (that's just pinging the router)... also, the timing is sporadic.  All ping requests to the router (in a home environment a tleast) should return in <1ms, and my pings are coming back at 2ms.  Not a huge difference, but indicative of an issue somewhere.

I think you hit the nail on the head run this fw_printenv and in the printout this is there.
firmware_name=blk-mamba.128mb.img
flash_alt_image=tftp $default_load_addr $firmware_name; nand erase $alt_kern_add                                                                                        r 0x4000000;nand write $default_load_addr $alt_kern_addr ${filesize};
flash_pri_image=tftp $default_load_addr $firmware_name; nand erase $pri_kern_add                                                                                        r 0x4000000;nand write $default_load_addr $pri_kern_addr ${filesize};
flash_ubi_image=mw.b 0x2000000 0x00 0x1e00000;tftp $default_load_addr blk-mamba.                                                                                        128mb.ubi.img; nand erase $pri_kern_addr 0x3600000; nand write $default_load_add                                                                                        r $pri_kern_addr 0x3600000
fs=ext2

But I am keeping my usb to ttl cable in its sealed bag. :-)

Thanks, I'll give that a try and post back

root@AC1900M:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 00100000 00020000 "devinfo"
mtd4: 02800000 00020000 "kernel1"
mtd5: 02500000 00020000 "rootfs1"
mtd6: 02800000 00020000 "kernel2"
mtd7: 02500000 00020000 "ubi"
mtd8: 02600000 00020000 "syscfg"
mtd9: 00780000 00020000 "unused_area"
mtd10: 00008000 00008000 "spi0.0"
root@AC1900M:~#

Wiping /overlay should erase everything that's changed in the current flash.

OpenWrt keeps settings in the overlay part of rootfs (rootfs_data UBI volume) of the current flash. Factory (and McWrt) use the syscfg partition. OpenWrt does not store any settings in syscfg (except a backup, see below).

It's a bit tricky when talking about flashing back/forth from factory. When flashing a non-sysupgrade image (e.g. factory image) if keeping settings it will copy settings to /tmp/syscfg/sysupgrade.tgz. Since the syscfg partition is a single partition (unlike rootfs/kernel) and the Linksys firmware doesn't touch it, that'll be there when you flash back to OpenWrt. You would end up with your settings back after all.

Going between OpenWrt images there's no issue if you don't preserve settings. It'll bounce back between the two firmware partitions, and since the flashing process erases the old rootfs_data volume any settings will be gone. Unless there's some sort of warm-boot issue (e.g. factory firmware resets something in the hardware that the OpenWrt drivers don't) there should be no difference between flashing between OpenWrt builds and flashing back to factory first. (edit: and that hypothetical would only matter until you powered off the unit)

If you really wanted to be sure, you can erase the other flash partition before attempting to flash a new image (I never do this). The current rootfs volume is called 'ubi', so you can just grep for 'rootfs':

root@wrt1900ac:/lib/upgrade# grep rootfs /proc/mtd
mtd7: 02500000 00020000 "rootfs2"
root@wrt1900ac:/lib/upgrade# 

That means you should erase 'kernel2' in this case (erasing alt_nand):

mtd erase kernel2

kernel2 overlaps and totally contains rootfs2.

(Last edited by leitec on 29 Jun 2015, 21:19)

@gufus & @leitec Thanks! =]

IMHO

Dual boot set-ups are a pain in the a**.

I ran NAT Tests, and the results were interesting. Two tests. Test 1 without NAT and Test 2 with NAT.

Test 1 (No NAT)  File Transfer
45.9GB File
Start Time 5pm
Time to finish the transfer 9:09 minutes

Test 2 (NAT) File Transfer
45.9GB File
Start Time 5:25pm
Time to finish the transfer 10:34minutes

Throughput Utilization

CPU Utilization %

Load

Seems around 100mbps was lost by using "NAT" as opposed to just layer 2 switching, in this test. I realize people are saying NAT is cpu bound on OpenWrt, but I didn't find it to be CPU bound as the TOP graph above shows. For those who know networking, Layer 3 (Network) is always going to be slower than Layer 2, and inherently so.  Was the slowness due to NAT translations or the IP layer (maybe a combination of the two)?

Load was increased during the download whilst NAT was involved, but I don't believe the load was cpu bound, but IRQ bound.

The below is a sample of highest load processes during NAT download. Notice ksofirqd/0 is eating some processor.

  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
    3     2 root     SW       0   0%  31% [ksoftirqd/0]
  414     2 root     RW       0   0%   6% [kworker/0:2]

A little bit of research about ksofirqd shows the following....

"In some situations IRQs come very very fast one after the other and the operating system cannot finish servicing one before another one arrives. This can happen when a high speed network card receives a very large number of packets in a short time frame.

Because the operating system cannot handle IRQs as they arrive (because they arrive too fast one after the other), the operating system queues them for later processing by a special internal process named ksoftirqd.

If ksoftirqd is taking more than a tiny percentage of CPU time, this indicates the machine is under heavy interrupt load."

So this bears the question.... Has anyone tried to tweak affinity >> smp_affinity  so as to reduce IRQ load?

(Last edited by davidc502 on 30 Jun 2015, 00:46)

We discussed a lot of this a few months back -- around March. At first we could only route about 300-400 Mbps, but a combination of a few system patches (impacting DMA and the CPU idle function) plus RPS/XPS support boosted that up to 900+ Mbps. RPS/XPS is supposed to handle affinity automatically, and it made a huge difference. edit: of course I could be wrong that it can't be tweaked further.

https://forum.openwrt.org/viewtopic.php … 56#p270756

iperf3 is not reporting much in the way of retransmits these days and the transfer is stable, so it might be as good as it gets without bona-fide "Network Fast Path" support. Offloading of any sort improves performance; disabling things like GRO and hardware IPv4 checksums brings routing performance way down (which is why IPv6 or IP packets in 802.1q tagged frames are slower on this HW)

edit: You might be able to squeeze a bit more performance out of it by disabling cpuidle altogether. That costs you power consumption and increased heat, so it's not a great idea.

(Last edited by leitec on 30 Jun 2015, 01:53)

Thanks for the response, and it's good to know this had been looked at, and at a much lower level.

Question:

From this list- which is defined eth1? I can't tell, because it doesn't appear listed. The reason being is, I'd like to change affinity to both processors, as it seems only one is receiving interrupt requests in my tests. It could be this isn't adjustable in that fashion, but thought to look anyway just in case.

root@OpenWrt:/proc/irq/18# cat /proc/interrupts
           CPU0       CPU1
16:     781127     785617  armada_370_xp_irq   5  armada_370_xp_per_cpu_tick
18:     226606          0  armada_370_xp_irq  31  mv64xxx_i2c
19:         21          0  armada_370_xp_irq  41  serial
25:          0          0  armada_370_xp_irq  45  ehci_hcd:usb1
26:     207761          0  armada_370_xp_irq   8  mvneta
27:     756457          0  armada_370_xp_irq  10  mvneta
28:          0          0  armada_370_xp_irq  55  f10a0000.sata
29:      16087          0  armada_370_xp_irq 113  f10d0000.nand
69:          0          0  f1018140.gpio   0  gpio_keys
70:          0          0  f1018140.gpio   1  gpio_keys
87:    2316061          0  armada_370_xp_irq  59  mwlwifi
88:    2282920          0  armada_370_xp_irq  60  mwlwifi
89:          2          0  armada_370_xp_irq  51  f1060900.xor
90:          2          0  armada_370_xp_irq  52  f1060900.xor
91:          2          0  armada_370_xp_irq  94  f10f0900.xor
92:          2          0  armada_370_xp_irq  95  f10f0900.xor
93:          0          0  armada_370_xp_msi_irq   0  xhci_hcd
IPI0:          0          0  CPU wakeup interrupts
IPI1:          0          0  Timer broadcast interrupts
IPI2:       3858     439515  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:         35     431862  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
IPI6:          0          0  IRQ work interrupts
IPI7:          0          0  completion interrupts

From armada-370-xp.dtsi

                        eth0: ethernet@70000 {
                                compatible = "marvell,armada-370-neta";
                                reg = <0x70000 0x4000>;
                                interrupts = <8>;
                                clocks = <&gateclk 4>;
                                status = "disabled";
                        };

                       eth1: ethernet@74000 {
                                compatible = "marvell,armada-370-neta";
                                reg = <0x74000 0x4000>;
                                interrupts = <10>;
                                clocks = <&gateclk 3>;
                                status = "disabled";
                        };

Thanks -- I believe it's this line --  27:     756457          0  armada_370_xp_irq  10  mvneta

It's currently set to 3. there's only 2 procs, so I'm confused.

root@OpenWrt:/proc/irq/27# cat smp_affinity
3

According to affinity setting this should be in HEX, and HEX for 11 is B, and not 3.  Maybe I"m misunderstanding. To take it a step further, it should probably be F to service either processor according to affinity guide.

I'll try some testing... hopefully we won't brick. lol

(Last edited by davidc502 on 30 Jun 2015, 02:35)

03h for binary 11, which has it allowed on both CPUs.

Thanks, I see it now.

(Last edited by davidc502 on 30 Jun 2015, 02:58)

This is what my home network looks like:

All wired equipment is gigabit and all Cat6 cables are less than 20cm long. There is no access whatsoever between LAN1 and LAN2, thus keeping my personal stuff away from anyone connecting to LAN2 (guests, etc.).

nitroshift

(Last edited by nitroshift on 30 Jun 2015, 10:26)

hi all, newbie question here..

I'm currently running CHAOS CALMER (15.05-rc2, r45918) downloaded a week ago from the wiki. How can I keep it updated now?

Can you update the wiki explaining how to upgrade builds?

Regards,
Julián

nvram is broadcom specific, the lack of sanity made ddwrt reuse it on every platform.. If you upgrade openwrt and don't save the config, you start from scratch, there's no need to wipe anything..

Good job. That's certainly one way to do it.

@nitroshift
Off topic. But what are the "media converter" devices in that diagram?

They are devices that convert copper to optical and vice-versa.

How should I go about troubleshooting my issues with the 5gHz network then?  When it comes to troubleshooting the radios, I have a no experience

Does the current firmware for WRT1900 and WRT1200 support OpenVPN as a *Client*?

If so, which firmware version should I download for the WRT1200 (URL please)?
I am a novice so I definitely need a version with a GUI.

TIA!

OpenWrt Chaos Calmer r45952 / LuCI (git-15.163.60978-3bcbfb3) 
Kernel Version 3.18.14

self build - it's been stable for me but i have had some problems with the 5GHz - this has been on a few different builds of openwrt.

i have my wireless set with WPA2-PSK encryption and a password. every now and again i cannot connect to the 5GHz it says wrong password (i am using the correct password). i know what to do because it has happened about 6 times now.

when i investigated the latest occurence the router said it was using WPA2-PSK encryption and my laptop said it was using WPA2.

to get the laptop to connect i turn the encryption off and back on again on the router and set my password again.

now when i check my laptop it says that the 5GHz is using WPA2-PSK. i don't know why this happens but it happens often enough that i now know how to fix it