OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

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

@sera

Latest build of LEDE 4.9.17 is fine.  Will build and try swrt @ 4.10 & 4.11 as well and advise

Cheers

@sera, This resolution a few weeks back.

Villeneuve wrote:

@sera, This resolution a few weeks back.

Not quite sure if that is the same thing. That bug (and fix) found by me was just about failing to move/rename a file that existed both on ubifs and overlay. But the filesystem worked otherwise quite ok, so creating, deleting & editing files worked ok. The core reason was a harmful rename action type check introduced in kernel 4.9 merges in Linux upstream. Debugging story in https://bugs.lede-project.org/index.php … ask_id=579

That was not the same as "no settings would be saved" or "read only file system".

(Last edited by hnyman on 27 Mar 2017, 20:35)

dolemhao wrote:

/etc/config/wireless

config wifi-iface
    option  network      'lan'
    option  encryption   'psk-mixed'

config wifi-iface
    option  network      'guest'
    option  encryption   'psk-mixed'

In conjunction with @sera's post, encryption needs to be changed:

  • From:   'psk-mixed'

  • To:        'psk2+ccmp'

(Last edited by JW0914 on 27 Mar 2017, 20:54)

Villeneuve, hnyman

thanks. Yes doesn't look like the same issue. Just from a brief look at the git log there is no obvious suspect. Didn't had a chance to bisect yet but as I was able to reproduce it this morning with what used work it should be straight forward to tell which commit is at fault one I do.

Hi people.
A quick question...

Is there any firmware newer than 10.3.2.0, even in beta state that I can download and test?
I'm having speed and connectivity issues in 17.01.0 at both bands...

Thank you!

(Last edited by angelos on 27 Mar 2017, 21:32)

alpha but reported as unstable here.

Thank's Villeneuve, I will give it a try.

Just sent out another version of the Mamba fan driver. Possibly the final one. Will setup automated bisecting now for the ubifs/overlay regression and if nothing goes wrong I'll have the result in the morning.

@sera

Both Lede @ 4.9.17 and swrt @ 4.10.5 are good wrt saving changes in etc/config

Both swrt @ 4.11-rc3 and 4.11-rc3-next give me a read only etc/config

Lede @ 4.9.17 -> ok

root@WRT3200ACM:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.0M      3.0M         0 100% /rom
tmpfs                   250.6M     92.0K    250.5M   0% /tmp
/dev/ubi0_1              56.8M     56.0K     53.8M   0% /overlay
overlayfs:/overlay       56.8M     56.0K     53.8M   0% /
ubi1:syscfg              70.2M    348.0K     66.3M   1% /tmp/syscfg
tmpfs                   512.0K         0    512.0K   0% /dev
root@WRT3200ACM:~#

swrt @ 4.10.5 -> ok

root@WRT3200ACM:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/ubiblock0_0          3.0M      3.0M         0 100% /rom
/dev/ubi0_1              56.8M     56.0K     53.8M   0% /overlay
overlay                  56.8M     56.0K     53.8M   0% /
tmpfs                   250.7M    428.0K    250.3M   0% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
root@WRT3200ACM:~#

swrt @ 4.11-rc3 -> can't write to etc/config

root@WRT3200ACM:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/ubiblock0_0          3.0M      3.0M         0 100% /rom
/dev/ubi0_1              56.8M     72.0K     53.8M   0% /overlay
overlay                  56.8M     72.0K     53.8M   0% /
tmpfs                   250.5M    548.0K    249.9M   0% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
root@WRT3200ACM:~#

swrt @ 4.11-rc3-next -> can't write to etc/config

root@WRT3200ACM:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/ubiblock0_0          3.0M      3.0M         0 100% /rom
/dev/ubi0_1              56.8M     72.0K     53.8M   0% /overlay
overlay                  56.8M     72.0K     53.8M   0% /
tmpfs                   250.0M    548.0K    249.4M   0% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
root@WRT3200ACM:~#

doITright,

thanks. Bisecting was successful, same result as you, commit d8514d8edb5b ("ovl: copy up regular file using O_TMPFILE") which was added for 4.11 is what breaks ubifs used as an overlay. Will report the regression. Quite possibly your testing and reporting here will be the reason 4.11 final won't be broken upon release, at least not this way.

Will do an swrt release later today which takes care of this and with the very latest Mamba-fan driver already included.

@sera Do you know does anyone try to patch your swrt on top of LEDE?

gsustek,

I only know of Ansuels attempt, given we haven't heard back I assume he didn't succeed. Maybe a project merge under the OpenWrt name happens soon in which case I'd do the porting myself.

---

The root cause of the overlay regression seems to be broken O_TMPFILE support in ubifs, which would be an ancient bug, just never exposed before.

swrt-2017-03-28
---------------

The first notable item is a temporary fix for the regression reported by doITright, so 4.11 and next can be used with the squashfs / overlay based images again. The other one is the possibly definitive driver for the fan.


* linux-4.10: bump to 4.10.6
* linux-4.11: bump 4.11-rc4
* linux-next: bump to next-20170328

* kernel: disable O_TMPFILE in ubifs, corrupts file system, unused
  before 4.11 (reported by doITright)
* kernel: update fan-driver to latest incarnation, already tested by the
  author of the original driver which never made it in.
* kernel: drop fix for uart regression, already in next
* kernel: drop BIT macro patch, already in next

swrt-2017-03-28.tar.xz: https://gpldr.in/v/3dMv615nN8/77o67gXTQfmHsYRd
sha256sum: 0f8c2d2b619692025b4b259dabbae72f129a94b7a61302e38cbe1ed1c0af458d

@sera

Building swrt-2017-03-28 now.

Should be able to cycle through 4.10/11/next on the rango tonight. 

If next behaves overnight, I will put in on one of the mambas in the AM to see if it can survive a work day.

Cheers

Hi witch is the best file system file to flash for rango squashfs or ubifs? I can't find out a good comparison.

Hi tapper,

thought I copy the section from swrt/README but realized I haven't updated that one in a while. So an updated one could be :

Images
======

The are two types of images, the sqaushfs with overlay based images and read
write root based images, both come as factory images (.img) and sysupgrade
tarballs (.tar)

There may be a bug in your current install which prevents proper upgrade using
sysupgrade and *factory* images. Flash those from OEM firmware or via serial
console (tftp / usb), use the tarballs with sysupgrade respectively luci.

Before 4.9 squshfs based images are broken as there is no support in ubifs for
overlayfs. Well, it barely works, but I wouldn't recommend it.

The ubifs based images are a more the standard setup and what most people use
out there. The advantage of the squshfs based images is substantially better
compression and the possibility to implement a failsafe mode. The price is
deleting packages from the rom increase size and there is additional runtime
overhead.  As Linux caches data accessed in RAM and as there is hardly memory
pressure nor much acccess after boot this isn't a big deal, but for some it
might matter.

Let me know if this answers your question sufficiently.

sera wrote:

Hi tapper,

thought I copy the section from swrt/README but realized I haven't updated that one in a while. So an updated one could be :

Images
======

The are two types of images, the sqaushfs with overlay based images and read
write root based images, both come as factory images (.img) and sysupgrade
tarballs (.tar)

There may be a bug in your current install which prevents proper upgrade using
sysupgrade and *factory* images. Flash those from OEM firmware or via serial
console (tftp / usb), use the tarballs with sysupgrade respectively luci.

Before 4.9 squshfs based images are broken as there is no support in ubifs for
overlayfs. Well, it barely works, but I wouldn't recommend it.

The ubifs based images are a more the standard setup and what most people use
out there. The advantage of the squshfs based images is substantially better
compression and the possibility to implement a failsafe mode. The price is
deleting packages from the rom increase size and there is additional runtime
overhead.  As Linux caches data accessed in RAM and as there is hardly memory
pressure nor much acccess after boot this isn't a big deal, but for some it
might matter.

Let me know if this answers your question sufficiently.

Hi thanks yes that helps. BTW were can i find the swrt/README?

@sera

All seems well so far.  Cycled through swrt on the rango @ 4.10.6/4.11.0-rc4/next without any issues

swrt @ 4.10.6 -> ok

root@WRT3200ACM:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/ubiblock0_0          3.0M      3.0M         0 100% /rom
/dev/ubi0_1              56.8M     72.0K     53.8M   0% /overlay
overlay                  56.8M     72.0K     53.8M   0% /
tmpfs                   250.7M    548.0K    250.1M   0% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
root@WRT3200ACM:/#

swrt @ 4.11.0-rc4 -> ok

root@WRT3200ACM:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/ubiblock0_0          3.0M      3.0M         0 100% /rom
/dev/ubi0_1              56.8M     60.0K     53.8M   0% /overlay
overlay                  56.8M     60.0K     53.8M   0% /
tmpfs                   250.5M    708.0K    249.8M   0% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
root@WRT3200ACM:/#

swrt @ 4.11.0-rc4-next -> ok

root@WRT3200ACM:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/ubiblock0_0          3.0M      3.0M         0 100% /rom
/dev/ubi0_1              56.8M     64.0K     53.8M   0% /overlay
overlay                  56.8M     64.0K     53.8M   0% /
tmpfs                   250.0M    552.0K    249.4M   0% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
root@WRT3200ACM:/#

Some quick iperf3 runs on rango @ next:

2.4 GHz radio1 @ 40 MHz:

iperf3 -c 192.168.2.1 -P6 -t 120 -f MB
[SUM]   0.00-120.01 sec  2.42 GBytes  20.7 MBytes/sec                  sender
[SUM]   0.00-120.01 sec  2.42 GBytes  20.7 MBytes/sec                  receiver

iperf3 -c 192.168.2.1 -P6 -t 120 -f MB -R
[SUM]   0.00-120.00 sec  1.36 GBytes  11.6 MBytes/sec    4             sender
[SUM]   0.00-120.00 sec  1.36 GBytes  11.6 MBytes/sec                  receiver

5 GHz radio0 @ 80 MHz:

iperf3 -c 192.168.2.1 -P6 -t 120 -f MB
[SUM]   0.00-120.01 sec  11.0 GBytes  93.5 MBytes/sec                  sender
[SUM]   0.00-120.01 sec  11.0 GBytes  93.5 MBytes/sec                  receiver

iperf3 -c 192.168.2.1 -P6 -t 120 -f MB -R
[SUM]   0.00-120.00 sec  6.46 GBytes  55.1 MBytes/sec  804             sender
[SUM]   0.00-120.00 sec  6.46 GBytes  55.1 MBytes/sec                  receiver

Will try to find some time to repeat the above on the mamba later today

Cheers

@sera why use dsa instead of swconfig?

tapper,

the README gets added by the last patch in the series, so you can find it in the tarball and once applied under swrt/README.

---

doITright,

thanks. Are the iperf results what you expect speed-wise? If yes, then it's down to whether the driver performs stable over a week or two.

---

Ansuel,

Everyone but OpenWrt users will wonder why swconfig if you can have DSA. It's simply superior if it works and that it does now.

@sera

It actually surprised me...  that small run was better than my last mamba test (last summer): 

Mamba 5 GHz @ 80 MHz -> 58 MB/s & 54 MB/s -> LEDE 4.4.15
Rango 5 GHz @ 80 MHz -> 93 MB/s & 55 MB/s  -> swrt next

Will repeat once I have the mamba on the same build of next later today

Cheers

Can to whom it is useful.
In the WRT3200, the power (+ 5.0Volt) of the USB 3.0 port is controlled by the mpp44 output.

doITright,

Yeah, Rango outperforms Shelby as well, similarly to what you are seeing compared to Mamba.

---

ValCher,

mpp44 doesn't match [1], may I ask you were you have this value from?

[1] https://github.com/openwrt/openwrt/pull … 0bacff2a8b

@sera
mpp47 [gpio1 = 15] manages the USB 2.0/eSATA
mpp44 [gpio1 =12] manages the USB 3.0

Check by connecting Flash in USB 3.0 port and run the commands;

echo 44 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio44/direction
echo 1 >/sys/class/gpio/gpio44/value
echo 0 >/sys/class/gpio/gpio44/value

(Last edited by ValCher on 30 Mar 2017, 00:50)

Sorry, posts 14251 to 14250 are missing from our archive.