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.

raven-au wrote:

Yeah, might be lucky but I think that if any of the symbol checksums have changed (likely between 3.14 and 3.18) the module probably won't load.
Don't know if OpenWrt uses any extra module validation options in the kernel config but mostly that isn't done.

To resolve these problems there probably needs to be a packages directory along with builds for manual download and install.
A pain but at this stage probably needed.

Ian

If these were some semi-long maintained fork (like McWRT AA) then I agree that a dedicated package directory could be provided.

However, given that these are fairly ephemeral test builds of trunk snapshots I'm not sure if those producing them would be keen on regenerating all the packages every release (which seems to be about every couple of weeks).

Ultimately, given that trunk now uses 3.18 by default (and CC will too), I guess the main question is why the trunk packages haven't (yet) all been rebuilt for 3.18.

DavidMcWRT wrote:
raven-au wrote:

Yeah, might be lucky but I think that if any of the symbol checksums have changed (likely between 3.14 and 3.18) the module probably won't load.
Don't know if OpenWrt uses any extra module validation options in the kernel config but mostly that isn't done.

To resolve these problems there probably needs to be a packages directory along with builds for manual download and install.
A pain but at this stage probably needed.

Ian

If these were some semi-long maintained fork (like McWRT AA) then I agree that a dedicated package directory could be provided.

However, given that these are fairly ephemeral test builds of trunk snapshots I'm not sure if those producing them would be keen on regenerating all the packages every release (which seems to be about every couple of weeks).

Yes, although we would only need a package repository of packages built against 3.18, so one build should be enough and then a change to the package location in the config should be enough. Although we might need to rebuild them for kernel point releases, but again only once.

DavidMcWRT wrote:

[Ultimately, given that trunk now uses 3.18 by default (and CC will too), I guess the main question is why the trunk packages haven't (yet) all been rebuilt for 3.18.

Indeed, yes, but is 3.18 really going to be the default in CC, there appears to be quite a bit that still uses 3.14?

Ian

(Last edited by raven-au on 27 Jan 2015, 02:57)

DavidMcWRT wrote:

Ultimately, given that trunk now uses 3.18 by default (and CC will too), I guess the main question is why the trunk packages haven't (yet) all been rebuilt for 3.18.

The snapshot for mvebu hasn't built since the 9th, due to the missing symbols in mvebu/config-3.18. You can see the output at the buildbot page: http://buildbot.openwrt.org:8010/builders/mvebu

Some missing symbols were just added recently, so we may see a new build soon with the changes made since the 9th (which, apparently, includes upgrading the kernel and such)

@kaloz

r43974 ---> r44150 went smooth :}

root@AC1900:/tmp# sysupgrade -c openwrt_wrt1900ac_snapshot_sysupgrade.tar
Saving config files...
killall: watchdog: no process killed
Sending TERM to remaining processes ... logd netifd odhcpd crond minidlna uhttpd smbd nmbd collectd ntpd vnstatd dnsmasq fan_monitor sleep ubusd askfirst
Sending KILL to remaining processes ... askfirst
Switching to ramdisk...
Performing system upgrade...
Unlocking kernel1 ...

Writing from <stdin> to kernel1 ...
UBI device number 2, total 296 LEBs (37584896 bytes, 35.8 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
Volume ID 0, size 34 LEBs (4317184 bytes, 4.1 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs", alignment 1
Set volume size to 30220288
Volume ID 1, size 238 LEBs (30220288 bytes, 28.8 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs_data", alignment 1
sysupgrade successful

@lifehacksback

Did you compile with kernel 3.19?

nitroshift

Regarding the wifi speeds: I noticed that if setting the speed from LuCI it doesn't reflect in the wifi configuration. Open /etc/config/wireless and edit the lines related to wifi working mode to read

11bgnac

for 2.4GHz and

11anac

for 5GHz. Speeds are better now, at least for me.

nitroshift

After sysupgrade-ing to r44150 3.18.3 the fan was on full-speed.

nitroshift wrote:

@weedv2

Try flashing the official firmware with

run update_both_images

then flash Kaloz's firmware image from web GUI.

nitroshift

@nitroshift,

since you are online, do you know if you can use the tarball from kaloz to sysupgrade lifehacksback's .img?

Regards,

Andrew.

raven-au wrote:
DavidMcWRT wrote:
digitalgeek wrote:

...so I just tried to install kmod-fs-ntfs, turns out I'm on an older build ???

Firmware Version:  OpenWrt Chaos Calmer r43823 / LuCI Master (git-14.359.33351-5e6c33e) 
Kernel Version:       3.18.1

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-fs-ntfs:
*     kernel (= 3.14.27-1-9a134909592224e5a02f8d510e58ddf8) *
* opkg_install_cmd: Cannot install package kmod-fs-ntfs.

I used the force command, originally I tried with sa command... didn't like that, but I tried again with out. Still no drive listmor available ???

Make sure you're using --force-depends

You'll still get an error message, but hopefully it will have installed.

Yeah, might be lucky but I think that if any of the symbol checksums have changed (likely between 3.14 and 3.18) the module probably won't load.
Don't know if OpenWrt uses any extra module validation options in the kernel config but mostly that isn't done.

To resolve these problems there probably needs to be a packages directory along with builds for manual download and install.
A pain but at this stage probably needed.

Ian

I was looking at the commits for ntfs on git.kernel.org , and it seems there have been a lot of changes to kmod_fs_ntfs between 3.14 and 3.18, so my guess is because of this it will not work on 3.18.

@speedandy

Yes you can.

nitroshift

nitroshift wrote:

@speedandy

Yes you can.

nitroshift

thx..  BTW, is there and IRC that everyone uses for this forum?

gufus wrote:

After sysupgrade-ing to r44150 3.18.3 the fan was on full-speed.

Until cron starts the script wink

speedandy wrote:
nitroshift wrote:

@speedandy

Yes you can.

nitroshift

thx..  BTW, is there and IRC that everyone uses for this forum?

https://openwrt.org/support.html tongue

leitec wrote:
DavidMcWRT wrote:

Ultimately, given that trunk now uses 3.18 by default (and CC will too), I guess the main question is why the trunk packages haven't (yet) all been rebuilt for 3.18.

The snapshot for mvebu hasn't built since the 9th, due to the missing symbols in mvebu/config-3.18. You can see the output at the buildbot page: http://buildbot.openwrt.org:8010/builders/mvebu

Some missing symbols were just added recently, so we may see a new build soon with the changes made since the 9th (which, apparently, includes upgrading the kernel and such)

Thanks for the background.

nitroshift wrote:

Regarding the wifi speeds: I noticed that if setting the speed from LuCI it doesn't reflect in the wifi configuration. Open /etc/config/wireless and edit the lines related to wifi working mode to read

11bgnac

for 2.4GHz and

11anac

for 5GHz. Speeds are better now, at least for me.

nitroshift

I'd noticed the mismatch between luci and /etc/config/wireless some time ago, but since my clients and insidder had reported the correct link/max rates I'd just accepted it.

Have edited my  /etc/config/wireless to your suggested values.

A couple of questions:

1) Is "11bgnac" even valid for 2.4GHZ?

2) I've used the command "wireless" before to restart wireless after doing changes. It doesn't appear to exist in Kaloz's 26th Jan build? (so I did a full reboot)

[edit] I won't be able to properly test any speed improvements until later (and then only up to 'N' speeds since I don't have any AC devices).  What sort of speed improvements are you getting compared to Luci's settings?  Are we talking stock speeds?!

(Last edited by DavidMcWRT on 27 Jan 2015, 12:45)

mojolacerator wrote:
Kaloz wrote:

New test images up:

firstflash: https://downloads.openwrt.org/people/ka … apshot.img
upgrade: https://downloads.openwrt.org/people/ka … pgrade.tar

* 3.18.3
* fan speed control
* CC r44153

Full image for me has impressive Wireless speeds. Fan comes on full at reboot, shuts off after about a minute, and I haven't heard it since. Ad blocking works too.

I had

echo 0 > /sys/devices/pwm_fan/hwmon/hwmon0/pwm1

in my /etc/rc.local as a hold-over from the previous fan control scripts, so fan is off for me almost straight away.

mojolacerator wrote:
Kaloz wrote:

New test images up:

firstflash: https://downloads.openwrt.org/people/ka … apshot.img
upgrade: https://downloads.openwrt.org/people/ka … pgrade.tar

* 3.18.3
* fan speed control
* CC r44153

Full image for me has impressive Wireless speeds. Fan comes on full at reboot, shuts off after about a minute, and I haven't heard it since. Ad blocking works too.

What are your radio settings in /etc/config/wireless? 11bgnac (2.4) and 11anac (5GHz) are per nitroshift's suggestions or something else?  If something else could you test between those and nitroshift's suggestions and let us know if there's any difference/further improvement?

Thanks.

DavidMcWRT wrote:
mojolacerator wrote:
Kaloz wrote:

New test images up:

firstflash: https://downloads.openwrt.org/people/ka … apshot.img
upgrade: https://downloads.openwrt.org/people/ka … pgrade.tar

* 3.18.3
* fan speed control
* CC r44153

Full image for me has impressive Wireless speeds. Fan comes on full at reboot, shuts off after about a minute, and I haven't heard it since. Ad blocking works too.

What are your radio settings in /etc/config/wireless? 11bgnac (2.4) and 11anac (5GHz) are per nitroshift's suggestions or something else?  If something else could you test between those and nitroshift's suggestions and let us know if there's any difference/further improvement?

Thanks.

Mode: Legacy
Band: 2.4 ghz
Channel: 1

Mode: AC
Band: 5 ghz
Channel: 48
Width: 80

Both using WPA2-PSK

Both show up as : 802.11bgnac

(Last edited by mojolacerator on 27 Jan 2015, 13:02)

speedandy wrote:
raven-au wrote:
DavidMcWRT wrote:

Make sure you're using --force-depends

You'll still get an error message, but hopefully it will have installed.

Yeah, might be lucky but I think that if any of the symbol checksums have changed (likely between 3.14 and 3.18) the module probably won't load.
Don't know if OpenWrt uses any extra module validation options in the kernel config but mostly that isn't done.

To resolve these problems there probably needs to be a packages directory along with builds for manual download and install.
A pain but at this stage probably needed.

Ian

I was looking at the commits for ntfs on git.kernel.org , and it seems there have been a lot of changes to kmod_fs_ntfs between 3.14 and 3.18, so my guess is because of this it will not work on 3.18.

Yeah, I haven't looked at the how this works in OpenWrt but if the module is built independently, as a number of them are, then changes to the upstream kernel shouldn't matter, changes to the VFS would be the concern. For example, there were some changes (IIRC) to the inode VFS callbacks for the overlayfs merge that might be relevant.

But really we won't know until there's a build log against 3.18 available.
Ian

mojolacerator wrote:
DavidMcWRT wrote:
mojolacerator wrote:

Full image for me has impressive Wireless speeds. Fan comes on full at reboot, shuts off after about a minute, and I haven't heard it since. Ad blocking works too.

What are your radio settings in /etc/config/wireless? 11bgnac (2.4) and 11anac (5GHz) are per nitroshift's suggestions or something else?  If something else could you test between those and nitroshift's suggestions and let us know if there's any difference/further improvement?

Thanks.

Mode: Legacy
Band: 2.4 ghz
Channel: 1

Mode: AC
Band: 5 ghz
Channel: 48
Width: 80

Both using WPA2-PSK

Both show up as : 802.11bgnac

Thanks.

I'm guessing that's from the GUI.  What are your corresponding values in /etc/config/wireless? - particularly for the two lines "option hwmode" ?

@DavidMcWRT

to reset wireless network, the command is

wifi

nitroshift

Sorry, posts 2676 to 2675 are missing from our archive.