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.

Which is to be expected given that you state dir "files/etc" is owned by root:root, so permission 644 precludes anybody but the root user from being able to "ls" the dir. See post.

anomeome wrote:

Which is to be expected given that you state dir "files/etc" is owned by root:root, so permission 644 precludes anybody but the root user from being able to "ls" the dir. See post.

They're not owned by root, they're owned by my ubuntu user (which ironically I also informed you of yesterday)... please go back and read my prior posts if you insist on focusing only on what was said in my first few posts about this issue a few days back.  This is the second time you've incorrectly given advice which does not apply due to a failure to read subsequent posts.

By all means though, since you insist on being hubristic, please inform me of the correct way of getting 644 permissions within a compiled image for files and directories within the buildroot/files directory.  If you are personally able to compile an image and have files and directories within the buildroot/files directory end up with 644 permissions in OpenWRT, then you're doing something completely different to the steps given in this thread and within the build wikis.  If this is indeed the case,  please update the wiki with the correct information on how to obtain the proper permissions.

(Last edited by JW0914 on 16 Feb 2016, 01:21)

JW0914 wrote:
anomeome wrote:

Which is to be expected given that you state dir "files/etc" is owned by root:root, so permission 644 precludes anybody but the root user from being able to "ls" the dir. See post.

They're not owned by root, they're owned by my ubuntu user (which ironically I also informed you of yesterday)... please go back and read my prior posts if you insist on focusing only on what was said in my first few posts about this issue a few days back.  This is the second time you've incorrectly given advice which does not apply due to a failure to read subsequent posts.

By all means though, since you insist on being hubristic, please inform me of the correct way of getting 644 permissions within a compiled image for files and directories within the buildroot/files directory.  If you are personally able to compile an image and have files and directories within the buildroot/files directory end up with 644 permissions in OpenWRT, then you're doing something completely different to the steps given in this thread and within the build wikis.  If this is indeed the case,  please update the wiki with the correct information on how to obtain the proper permissions.

Hubris? I was simply offering an explanation as to why you are seeing what you are seeing. Certainly don't know how you take that as hubris, but whatever. You're right, the most likely explanation is a bug in permission rights in Ubuntu. Your post regarding root:root was yesterday. I see no post subsequent that states you changed that ownership, but if you have I guess I should have known. My apologizes for weighing and trying to assist.

anomeome wrote:
JW0914 wrote:
anomeome wrote:

Which is to be expected given that you state dir "files/etc" is owned by root:root, so permission 644 precludes anybody but the root user from being able to "ls" the dir. See post.

They're not owned by root, they're owned by my ubuntu user (which ironically I also informed you of yesterday)... please go back and read my prior posts if you insist on focusing only on what was said in my first few posts about this issue a few days back.  This is the second time you've incorrectly given advice which does not apply due to a failure to read subsequent posts.

By all means though, since you insist on being hubristic, please inform me of the correct way of getting 644 permissions within a compiled image for files and directories within the buildroot/files directory.  If you are personally able to compile an image and have files and directories within the buildroot/files directory end up with 644 permissions in OpenWRT, then you're doing something completely different to the steps given in this thread and within the build wikis.  If this is indeed the case,  please update the wiki with the correct information on how to obtain the proper permissions.

Hubris? I was simply offering an explanation as to why you are seeing what you are seeing. Certainly don't know how you take that as hubris, but whatever. You're right, the most likely explanation is a bug in permission rights in Ubuntu. Your post regarding root:root was yesterday. I see no post subsequent that states you changed that ownership, but if you have I guess I should have known. My apologizes for weighing and trying to assist.

The original post regarding this goes back a few days, and it was at another member's suggestion that I change the ownership of the files directory (recursively) from my ubuntu username to root (after the image was compiling everything within the files directory and saving them in the image with ownership belonging to my ubuntu username), which I did, and then changed back, which I mentioned yesterday.  We'll chalk it up to miscommunication, as well as frustration that I shouldn't have allowed to bleed through and apologize for.


To clear up any confusion
./openwrt/files  -  recursively owned by jw0914:jw0914, permissions recursively set to 755

If ./openwrt/files is recursively set to 644, image compile fails with access denied errors, of which I also receive if i give the command ls files/etc, and anything other than a minimum of 755 will cause the compile to fail.

Granted, OpenWRT will function with config files set to execute, however my major concern are files that need, or at least should be, 600 or 400, such as ssl keys and p12 files.  Currently, I've created a first run script that fixes the permissions on all files and directories contained within the files directory, and deletes itself once ran.

(Last edited by JW0914 on 16 Feb 2016, 01:29)

JW0914 wrote:
anomeome wrote:
JW0914 wrote:

They're not owned by root, they're owned by my ubuntu user (which ironically I also informed you of yesterday)... please go back and read my prior posts if you insist on focusing only on what was said in my first few posts about this issue a few days back.  This is the second time you've incorrectly given advice which does not apply due to a failure to read subsequent posts.

By all means though, since you insist on being hubristic, please inform me of the correct way of getting 644 permissions within a compiled image for files and directories within the buildroot/files directory.  If you are personally able to compile an image and have files and directories within the buildroot/files directory end up with 644 permissions in OpenWRT, then you're doing something completely different to the steps given in this thread and within the build wikis.  If this is indeed the case,  please update the wiki with the correct information on how to obtain the proper permissions.

Hubris? I was simply offering an explanation as to why you are seeing what you are seeing. Certainly don't know how you take that as hubris, but whatever. You're right, the most likely explanation is a bug in permission rights in Ubuntu. Your post regarding root:root was yesterday. I see no post subsequent that states you changed that ownership, but if you have I guess I should have known. My apologizes for weighing and trying to assist.

The original post regarding this goes back a few days, and it was at another member's suggestion that I change the ownership of the files directory (recursively) from my ubuntu username to root (after the image was compiling everything within the files directory and saving them in the image with ownership belonging to my ubuntu username), which I did, and then changed back, which I mentioned yesterday.  We'll chalk it up to miscommunication, as well as frustration that I shouldn't have allowed to bleed through and apologize for.


To clear up any confusion
./openwrt/files  -  recursively owned by jw0914:jw0914, permissions recursively set to 755

If ./openwrt/files is recursively set to 644, image compile fails with access denied errors, of which I also receive if i give the command ls files/etc, and anything other than a minimum of 755 will cause the compile to fail.

Granted, OpenWRT will function with config files set to execute, however my major concern are files that need, or at least should be, 600 or 400, such as ssl keys and p12 files.  Currently, I've created a first run script that fixes the permissions on all files and directories contained within the files directory, and deletes itself once ran.

It seems the issue was my lack of experience with linux directory permissions...

All directories within the buildroot/files directory must have a minimum of 755 permissions (albeit I ended up using 775), and permissions cannot be set recursively; instead, enter the individual directories and subdirectories, editing the permissions of only the files within that specific directory (chmod 644 * can be used to set all files within the folder recursively without using -R).  As long as file permissions are set in this manner, they will retain the proper permissions once the image is compiled.

On a side note, the uncompressed firmware image files can be found in buildroot/build_dir/<target>/root-mvebu/; can one simply add files to that directory, or will any additions be removed when a new make command is given?

(Last edited by JW0914 on 16 Feb 2016, 03:27)

JW0914 wrote:

On a side note, the uncompressed firmware image files can be found in buildroot/build_dir/<target>/root-mvebu/; can one simply add files to that directory, or will any additions be removed when a new make command is given?


https://wiki.openwrt.org/doc/howto/build#cleaning_up - "make clean" deletes contents of the directories /bin and /build_dir.

kirkgbr wrote:
JW0914 wrote:

On a side note, the uncompressed firmware image files can be found in buildroot/build_dir/<target>/root-mvebu/; can one simply add files to that directory, or will any additions be removed when a new make command is given?


https://wiki.openwrt.org/doc/howto/build#cleaning_up - "make clean" deletes contents of the directories /bin and /build_dir.

I don't think I articulated my question correctly... Once you've issued the make command, it creates the firmware within root-mvebu.  After the initial make command, can one simply add files directly into the root-mvebu folder, prior to issuing a second make command, and have those added files be incorporated into the new image?  Or does issuing a new make command remove anything within the root-mvebu folder that doesn't match the correct chksums?


Also, has anyone else who's compiled trunk after 2/7 (r48719) noticed /etc/uci-defaults/30_uboot-envtools is missing from the compiled image (the uci-defaults directory is empty, and since I've never looked in there, I'm not sure if there's supposed to be other files as well), thereby also causing /etc/fw_env.config to be missing?

  • If someone can verify, I'll submit a bug ticket, as it seems this was also an issue about three months ago, as discussed here, with that bug ticket here.

(Last edited by JW0914 on 16 Feb 2016, 15:21)

JW0914 wrote:

... noticed /etc/uci-defaults/30_uboot-envtools is missing from the compiled image (the uci-defaults directory is empty, and since I've never looked in there, I'm not sure if there's supposed to be other files as well)

Are you talking about the directory in the live router? Or the directory in the build system?

In case you looked for them in a live router: the uci-defaults scripts are deleted from /etc/uci-defaults in the router after being run successfully once. However, the original files can still be seen in /rom/etc/uci-defaults

https://wiki.openwrt.org/doc/uci#uci-defaults

This is not from mvebu, but I gues that this should similarly there:

root@OpenWrt:~# ls /etc/uci-defaults
root@OpenWrt:~#
root@OpenWrt:~# ls /rom/etc/uci-defaults
00_uhttpd_ubus                10-fstab                      30_luci-theme-material        luci-bcp38
03_network-switchX-migration  10_migrate-shadow             30_uboot-envtools             luci-sqm
03_network-vlan-migration     11_migrate-sysctl             40_luci-ddns                  odhcpd.defaults
04_led_migration              12_network-generate-ula       40_luci-statistics
09_fix-seama-header           20_migrate-feeds              99-miniupnpd
09_fix-trx-header             30_luci-theme-bootstrap       bcp38

(Last edited by hnyman on 16 Feb 2016, 15:33)

hnyman wrote:
JW0914 wrote:

... noticed /etc/uci-defaults/30_uboot-envtools is missing from the compiled image (the uci-defaults directory is empty, and since I've never looked in there, I'm not sure if there's supposed to be other files as well)

Are you talking about the directory in the live router? Or the directory in the build system?

In case you looked for them in a live router: the uci-defaults scripts are deleted from /etc/uci-defaults in the router after being run successfully once. However, the original files can still be seen in /rom/etc/uci-defaults

https://wiki.openwrt.org/doc/uci#uci-defaults

Thanks! =]  I didn't realize that.  I'm having the same issue as mentioned in that thread and bug ticket, where I'm unable to flash firmware via the webgui or sysupgrade, with the error being:

/tmp# /sbin/sysupgrade openwrt-mvebu-armada-xp-linksys-mamba-squashfs-factory.img
Saving config files...
killall: watchdog: no process killed
Sending TERM to remaining processes ... crond uhttpd ntpd udhcpc odhcp6c dnsmasq ubusd askfirst logd rpcd netifd odhcpd 
Sending KILL to remaining processes ... askfirst 
Switching to ramdisk...
Performing system upgrade...
Cannot parse config file: No such file or directory
Cannot parse config file: No such file or directory
Error: environment not initialized
cannot find target partition

Within makeconfig, I did edit Image Configuration - Version Configuration Options, and it made me wonder if the compiler uses values in there as variables, which my custom input wouldn't have matched correctly.  I've since re-compiled a new image with those values set back to default and the image configuration option unchecked, but am unable to flash it.

(Last edited by JW0914 on 16 Feb 2016, 15:41)

@JW0914

Please keep this (already long enough) thread clean. Your questions are not specific to the mvebu target, they are general build issues. Thanks for understanding.

nitroshift

matthew_eli wrote:

Firstly thanks for the reply. BTW, what I really want to know is if there is a syntax/set o rules behind the correct settings I have to use only for enabling the switch. At this stage I don't want to configure any VLAN but only enable the switch functions, maybe for doing that later

Is that possible? If so, what is the correct syntax to use in the /etc/config/netwotk file?

The base config on WRT1200AC, WRT1900ACv2 and WRT1900ACS is:

config switch                   
        option name 'switch0'   
        option reset '1'         
        option enable_vlan '1'    
                                
config switch_vlan              
        option device 'switch0'                
        option vlan '1'         
        option ports '0 1 2 3 6'
                               
config switch_vlan             
        option device 'switch0'
        option vlan '2'
        option ports '4 5'

Compared to the WRT1900ACv1 the LAN and WAN are flipped: interfaces eth1 and eth0, respectively. This means the switch needs to have CPU port 6 in VLAN 1 (LAN) and CPU port 5 in VLAN 2 (WAN).

If you are interested in building your own, you can add this patch:

http://patchwork.ozlabs.org/patch/560773/

this'll configure the switch on those models by default. It'll create this configuration automatically.

(Last edited by leitec on 16 Feb 2016, 22:31)

If you're doing your own mvebu build with custom feed for cerowrt this patch by hnyman may be of interest to you.

nitroshift wrote:

@JW0914

Please keep this (already long enough) thread clean. Your questions are not specific to the mvebu target, they are general build issues. Thanks for understanding.

nitroshift

sorry bout that, no problem.  When I get home, I'll copy all the relevant posts into a newly created thread about the issue and remove the off-topic build posts

Since buildbot is down, how do i compile all packages for mvebu ? I like to have all packages near me, especially since downloads.openwrt.org isn't stable lately.

trustno1foxm wrote:
drex wrote:

Hey everyone. Have a 1900acv1 using  (git-15.248.30277-3836b45) / OpenWrt Chaos Calmer 15.0 and the wifi issue (network with an inability to connect) and jammed or stuck router requiring a cold reboot keeps occurring. Uptime less than 24 hrs. Thought the build had addressed this particular issue. What gives?

Any advice on which build to use to prevent this?  Thanks

welcome! I have the same issue on my wrt1200ac, there is no solution so far hmm
I didn't try a trunk release so far, but did use different wifi drivers without success.

If you have a wrt1200, forget about 15.0, it just doesn't work.
Use https://downloads.openwrt.org/snapshots … u/generic/

Has worked wonders here for 4 days (power cut, otherwise, it would have been 10 days).

regadpellagru wrote:
trustno1foxm wrote:
drex wrote:

Hey everyone. Have a 1900acv1 using  (git-15.248.30277-3836b45) / OpenWrt Chaos Calmer 15.0 and the wifi issue (network with an inability to connect) and jammed or stuck router requiring a cold reboot keeps occurring. Uptime less than 24 hrs. Thought the build had addressed this particular issue. What gives?

Any advice on which build to use to prevent this?  Thanks

welcome! I have the same issue on my wrt1200ac, there is no solution so far hmm
I didn't try a trunk release so far, but did use different wifi drivers without success.

If you have a wrt1200, forget about 15.0, it just doesn't work.
Use https://downloads.openwrt.org/snapshots … u/generic/

Has worked wonders here for 4 days (power cut, otherwise, it would have been 10 days).

thx a lot! good to know! I want to wait for kaloz's image wink Otherwise I will use the trunk image.

leitec wrote:
matthew_eli wrote:

Firstly thanks for the reply. BTW, what I really want to know is if there is a syntax/set o rules behind the correct settings I have to use only for enabling the switch. At this stage I don't want to configure any VLAN but only enable the switch functions, maybe for doing that later

Is that possible? If so, what is the correct syntax to use in the /etc/config/netwotk file?

The base config on WRT1200AC, WRT1900ACv2 and WRT1900ACS is:

config switch                   
        option name 'switch0'   
        option reset '1'         
        option enable_vlan '1'    
                                
config switch_vlan              
        option device 'switch0'                
        option vlan '1'         
        option ports '0 1 2 3 6'
                               
config switch_vlan             
        option device 'switch0'
        option vlan '2'
        option ports '4 5'

Compared to the WRT1900ACv1 the LAN and WAN are flipped: interfaces eth1 and eth0, respectively. This means the switch needs to have CPU port 6 in VLAN 1 (LAN) and CPU port 5 in VLAN 2 (WAN).

If you are interested in building your own, you can add this patch:

http://patchwork.ozlabs.org/patch/560773/

this'll configure the switch on those models by default. It'll create this configuration automatically.

Many thanks: it works!!!

I'm trying to install the sqm QOS on Kaloz build, but I've a dependency problem related to the kernel version the firmware has.

OPKG gives me the following error:

Installing luci-app-sqm (1.0.3-1) to root...
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/mvebu/generic/packages/packages/luci-app-sqm_1.0.3-1_all.ipk.
Multiple packages (kmod-sched-core and kmod-sched-core) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ipt-core and kmod-ipt-core) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ifb and kmod-ifb) providing same name marked HOLD or PREFER. Using latest.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-app-sqm:
 *     kernel (= 3.18.20-1-d18786f7b70aa80793e6f77c59ad223e) * 
 * opkg_install_cmd: Cannot install package luci-app-sqm.

Is there a way to fix this or I have to wait for the next firmware release (upcoming as far as I heard)?

(Last edited by matthew_eli on 17 Feb 2016, 21:36)

leitec wrote:

The base config on WRT1200AC, WRT1900ACv2 and WRT1900ACS is:

This is really a funny coincidence... :-)

I just received my 1200 today, and I was just searching for exactly this piece of information... :-)

So, many thanks from me as well!

Chadster766 wrote:

Author: Kevin Yuan

This is the app you are talking about.

ralfbergs wrote:
Chadster766 wrote:

Author: Kevin Yuan

This is the app you are talking about.

Yes

matthew_eli wrote:

I'm trying to install the sqm QOS on Kaloz build, but I've a dependency problem related to the kernel version the firmware has.

OPKG gives me the following error:

Installing luci-app-sqm (1.0.3-1) to root...
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/mvebu/generic/packages/packages/luci-app-sqm_1.0.3-1_all.ipk.
Multiple packages (kmod-sched-core and kmod-sched-core) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ipt-core and kmod-ipt-core) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ifb and kmod-ifb) providing same name marked HOLD or PREFER. Using latest.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-app-sqm:
 *     kernel (= 3.18.20-1-d18786f7b70aa80793e6f77c59ad223e) * 
 * opkg_install_cmd: Cannot install package luci-app-sqm.

Is there a way to fix this or I have to wait for the next firmware release (upcoming as far as I heard)?

Ok, fixed by using opkg --force-depends

matthew_eli wrote:
matthew_eli wrote:

I'm trying to install the sqm QOS on Kaloz build, but I've a dependency problem related to the kernel version the firmware has.

OPKG gives me the following error:

Installing luci-app-sqm (1.0.3-1) to root...
Downloading http://downloads.openwrt.org/chaos_calmer/15.05/mvebu/generic/packages/packages/luci-app-sqm_1.0.3-1_all.ipk.
Multiple packages (kmod-sched-core and kmod-sched-core) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ipt-core and kmod-ipt-core) providing same name marked HOLD or PREFER. Using latest.
Multiple packages (kmod-ifb and kmod-ifb) providing same name marked HOLD or PREFER. Using latest.
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-app-sqm:
 *     kernel (= 3.18.20-1-d18786f7b70aa80793e6f77c59ad223e) * 
 * opkg_install_cmd: Cannot install package luci-app-sqm.

Is there a way to fix this or I have to wait for the next firmware release (upcoming as far as I heard)?

Ok, fixed by using opkg --force-depends

It's generally not a good idea to force install packages when you receive kernel dependency errors.  I could be wrong, but I believe doing so also installs the mismatching kernel mods, which will cause instability if that is the case

(Last edited by JW0914 on 18 Feb 2016, 17:38)

gsustek wrote:

Hi, what is the status of this router http://www.notebooksbilliger.de/linksys … c77be9f40a ?

Does he has hw nat support, opensourced wifi driver, is wifi stable?
First thread isn't so much positive:-)


Thnx.

please folks, do i really need to read 400+ pages of this thread? :-)