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.

Did you compile your own image, and if not, where did you grab Material from (I've looked in all CC repo directories and can't find it)?  I'd like to add an annotation to the wiki about where to find it if one is running CC, since I know if I'm having difficulty finding it, a new user is going to have an even worse time.

No, just stock CC with the latest .ipk from the Material github and installed normally (scp/opkg) - https://github.com/LuttyYang/luci-theme … l/releases

This is the thread i ran across that led me to the github page - https://forum.openwrt.org/viewtopic.php?id=59696

mikemccartney wrote:

Did you compile your own image, and if not, where did you grab Material from (I've looked in all CC repo directories and can't find it)?  I'd like to add an annotation to the wiki about where to find it if one is running CC, since I know if I'm having difficulty finding it, a new user is going to have an even worse time.

No, just stock CC with the latest .ipk from the Material github and installed normally (scp/opkg) - https://github.com/LuttyYang/luci-theme … l/releases

This is the thread i ran across that led me to the github page - https://forum.openwrt.org/viewtopic.php?id=59696

This is the repo URL that has the material theme. I installed it from here in my self built CC build several months ago

src/gz designated_driver_luci http://downloads.openwrt.org/snapshots/ … kages/luci

(Last edited by alirz on 31 Aug 2016, 15:42)

does anyone know why the "ip neigh" command doesnt work/exist in my latest build?

i do have the "ip" package installed. hower the 'neigh' option doesnt seem to be there anymore.

@sera, a note on your last patch-set. Did a build and flashed both the ubi and squash images on my v1 to the same outcome I previously reported; random reboot, cause unknown, as of yet no single discernible cause. Have not been able to collect any relevant log data as it has never flushed at an opportune time to my remote linux box. I suppose instrumenting the build is an option but then observer effect ...

Might take a shot at the 4.8 kernel this weekend.

Edit: On another note, regarding my previous observation about the jump in cpu utilization on my mamba. About the same time as the last mwlwifi release, I was modifying my build and had changed from dnsmasq to dnsmasq-full, as I wanted to possibly put dnssec into play. Right now that is looking like the likely suspect, but why an order of magnitude uptick, especially since it is not yet actually doing ipsec? Might try backing that out to prove one way or ta'other.

Edit2: Doesn't look like that was the issue. An interesting aside, where both cpu's have been ~20% from when I first noticed the change, one is now ~18%, one ~16%. So I'm guessing the hard float pushes from a day or two back had a discernible impact.

(Last edited by Villeneuve on 31 Aug 2016, 21:12)

JW0914 wrote:
Comitizer wrote:
thelakesclub wrote:

What model WRT19/200ac do you have? Mrfrezee builds is quite out of date I can build you a image that's identical and more upto date if you like?

I have the WRT1900ACv2.  I'm comfortable building my own build from trunk or the CC branch (been doing it for a few years on my WNDR3700) but I'm not clear if all the patches are in place.

Provided you build with kernel 4.4.14+, many patches were merged (marvell-cesa hasn't been included yet).  If you'd like to build with a lower 4.4 kernel, @sera's done quite a bit of work on 4.7 & 4.8 patches.  If interested in building with versions below 4.4.14, it'd be more convenient to utilize the advanced search functions of google to search this thread.

  • For example, perform two separate searches by pasting all of the next two bullets [separately] into google search:

    • site:forum.openwrt.org daterange:2457388.5-2457631.99999 "WRT1900AC" AND kernel AND patch AND 4.4.

    • site:forum.openwrt.org daterange:2457388.5-2457631.99999 "WRT1900AC" AND kernel OR patch AND 4.4.

    • Date Range must be in Julian format, with the range currently set from 2016.01.01 @ 00:00:00 to 2016.08.31 @ 23:59:59

    • There's quite a few different search operators which can be employed via Google's search box, so I always recommend those not familiar with search operators to google "google advanced search operators"



    mikemccartney wrote:
    JW0914 wrote:

    Do you by chance know if Material is only compatible with k4.1+ (as it's not in the CC repo)?  If it isn't, how do I go about making the OpenWrt dev team aware it's missing from the CC repo?

    I've been using Material with CC and it seems to work fine, been up for a couple of weeks or so with no problems.

    Did you compile your own image, and if not, where did you grab Material from (I've looked in all CC repo directories and can't find it)?  I'd like to add an annotation to the wiki about where to find it if one is running CC, since I know if I'm having difficulty finding it, a new user is going to have an even worse time.

    I'm not well versed in html or javascript, only briefly glancing at the css coding in order to modify a few colors in the Material theme, so I'm not sure if it must be compiled specifically for CC or if a CC user can simply install the DD pkg. 

    • My assumption is theme pkgs only contain files that go in the webroot, however this could be a wrong assumption

    OK, this seems a LOT more complicated than my WNDR3700.  I read the portion of the wiki on the crypto modules and I'm not totally clear on what's needed to get them included.  I've kicked off a trunk build (just for fun) to see what happens but I feel like there's still too much going on with this router to be sure that I have an optimal build.

    I'd like to have all the requisite patches and a relatively stable build but I don't even know where to begin.

    @Comitizer
    Not really more complicated, but may seem that way. If you want/require all the bits, I would say your best jumping off place right now is on the other side of the fence; it's just where the greatest development effort is right now (could change).

    For an easy start:

    • git clone that

    • take the configdiff from my link

    • do this

    • make it yours with make menuconfig

    • build it

    All the currently available HW units will be in your build i.e. CESA,MVNETA

    Edit: Should add, don't forget the feeds:

    ./scripts/feeds update -a
    ./scripts/feeds install -a

    (Last edited by Villeneuve on 31 Aug 2016, 22:52)

    Villeneuve wrote:

    ... snip ...

    [*]do this[/*]

    ... snip ...

    ./scripts/feeds update -a
    ./scripts/feeds install -a

    This is somewhat off-topic from this router but I believe the typical stated methods for porting a config are a bit confusing and may lead to problems when someone doesn't understand the build system (which is likely if they're asking the question in the first place).

    I believe that you MUST do the ./scripts/feeds install -a prior to your "do this" step, or any packages that aren't in the baseline config will be ignored (and thus you'll end up with a different build than intended).

    The problem I have with doing the install -a is that going through menuconfig is painful and laborious due to the sheer number of packages.  It's worth spending the time going through the diffconfig and after executing a feeds update, manually installing the new required packages.

    I's more time consuming and prone to error, but it keeps menuconfig bloat to a minimum. YMMV and correct me if I'm wrong!

    Yes, the correct order, if starting from scratch, would be as you stated; that was simply an oversight and I edited in a reminder.

    The OP's question really was not about how to do a build, but what to build. I simply gave a quick get going on lede recipe, rather than trying to round up the requisite patches to do a owrt build, given the OP's desired outcome. Since my belief is that the OP is somewhat familiar with the process, and I had posted a link to the owrt build wiki, that any further relevant information was readily at hand.

    Villeneuve wrote:

    Yes, the correct order, if starting from scratch, would be as you stated; that was simply an oversight and I edited in a reminder.

    The OP's question really was not about how to do a build, but what to build. I simply gave a quick get going on lede recipe, rather than trying to round up the requisite patches to do a owrt build, given the OP's desired outcome. Since my belief is that the OP is somewhat familiar with the process, and I had posted a link to the owrt build wiki, that any further relevant information was readily at hand.

    It's true, I'm familiar with the build process so everything makes sense here. Thank you for your help.

    @alirz
    you can try to disable the build in ip command from busybox maybe it starts working again.


    What about the "enable neon support" commit?
    neon will be used as default now?
    Or do we have to specify it by mfpu=neon?
    Actually i dont think this is an good idea. Because neon is quite inaccurate?

    //edit
    okay i think it enables only the support for it...

    (Last edited by shm0 on 1 Sep 2016, 04:54)

    Villeneuve wrote:

    @sera, a note on your last patch-set. Did a build and flashed both the ubi and squash images on my v1 to the same outcome I previously reported; random reboot, cause unknown, as of yet no single discernible cause. Have not been able to collect any relevant log data as it has never flushed at an opportune time to my remote linux box. I suppose instrumenting the build is an option but then observer effect ...

    In case the kernel panics there is little hope that you will find the cause in the syslog. Logging the serial console has much better chance of revealing the issue. Always a great help is to know which change caused the issue. From what I understand the issue is very recent, right?


    Villeneuve wrote:

    Might take a shot at the 4.8 kernel this weekend.

    Haven't done much testing of 4.8 myself and given that the final release is only about a month away it can't hurt for more people to start testing. Though the Mamba issue needs probably taken care of regardless.


    Villeneuve wrote:

    Edit: On another note, regarding my previous observation about the jump in cpu utilization on my mamba. About the same time as the last mwlwifi release, I was modifying my build and had changed from dnsmasq to dnsmasq-full, as I wanted to possibly put dnssec into play. Right now that is looking like the likely suspect, but why an order of magnitude uptick, especially since it is not yet actually doing ipsec? Might try backing that out to prove one way or ta'other.

    I use dnsmasq-full without issues. What does for example htop say is eating the cpu?

    @sera
    As it looked like things were back to good I put the mamba back in it's usual place, so currently do not have serial connected. Probably pull it again to hook serial up if I get to trying out 4.8. It occurred first on patch-set dated Aug.24 (so one back from current/last).

    I backed out dnsmasq-full to see if that was the cause, but it was not. The next likely suspect is ubus. There was a version push in the same time-frame, about 8 days back, but everyone should be noticing that, and with no one else reporting same, well... Nothing leaps out at me as "that's it", there is just this very different @ idle before-after(1-2%,2-4% on each cpu - 18%,16% on each cpu) graph on the stats screen.

    @shm0
    I thought this was a non-neon device?

    (Last edited by Villeneuve on 1 Sep 2016, 12:03)

    @Villeneuve

    So 2016-08-24 is the first know bad, if the last know good is 2016-08-22 then only mwlwifi was bumped. The other changes were non functional changes like improving commit messages and the like going by my notes.

    PS: Indeed no neon for us.

    shm0 wrote:

    @alirz
    you can try to disable the build in ip command from busybox maybe it starts working again.

    @shm0

    Well as far as i know "ip" command is only available via busybox. So if i disable it, then it'll be unavailable altogether.
    I did some research and it seems that "ip neigh" might be missing from the busy box version 1.24.2 and probably will be added in 1.25 as per:

    https://busybox.net/

    (Last edited by alirz on 1 Sep 2016, 15:05)

    alirz wrote:

    does anyone know why the "ip neigh" command doesnt work/exist in my latest build?

    i do have the "ip" package installed. hower the 'neigh' option doesnt seem to be there anymore.


    this command works for me:

    root@1900acs:~# ip neighbor show
    192.1xx.168.xxx dev br-lan lladdr xx:xx:xx:xx STALE

    gsustek wrote:
    alirz wrote:

    does anyone know why the "ip neigh" command doesnt work/exist in my latest build?

    i do have the "ip" package installed. hower the 'neigh' option doesnt seem to be there anymore.


    this command works for me:

    root@1900acs:~# ip neighbor show
    192.1xx.168.xxx dev br-lan lladdr xx:xx:xx:xx STALE

    What is the version of your busybox? Also how old is your openwrt build?

    alirz wrote:

    does anyone know why the "ip neigh" command doesnt work/exist in my latest build?

    i do have the "ip" package installed. hower the 'neigh' option doesnt seem to be there anymore.

    you have likely sysupgraded with preserved settings from an old build. Your /etc/profile contains an outdated old PATH and with your new build the busybox ip gets found before the iproute2 ip (which you actually want).

    See:
    Default PATH modification: http://git.openwrt.org/?p=openwrt.git;a … 0827b94c92

    PATH in /etc/profile should be: "/usr/sbin:/usr/bin:/sbin:/bin"

    Currently /usr/bin/ip is iproute2 ip and it should be found first before the busybox ip in /sbin/ip

    root@xxx:~# /usr/bin/ip
    Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
           ip [ -force ] -batch filename
    where  OBJECT := { link | address | addrlabel | route | rule | neighbor | ntable                              |
    ...
    
    root@xxx:~# /sbin/ip
    BusyBox v1.24.2 () multi-call binary.

    (Last edited by hnyman on 1 Sep 2016, 15:38)

    Its a full flash not a sysupgrade.

    root@OpenWrt:~# which ip
    /sbin/ip
    root@OpenWrt:~# 
    
    root@OpenWrt:~# /sbin/ip 
    BusyBox v1.24.2 () multi-call binary.
    
    Usage: ip [OPTIONS] {address | route | link | rule} {COMMAND}
    
    ip [OPTIONS] OBJECT {COMMAND}
    where OBJECT := {address | route | link | rule}
    OPTIONS := { -f[amily] { inet | inet6 | link } | -o[neline] }
    
    
    root@OpenWrt:~# /usr/bin/
    [              cut            groups         lua            printf         sudo           unix2dos
    [[             diff           head           luci-bwc       readlink       tail           updatedb
    arping         dirname        hexdump        mailsend       reset          tee            uptime
    awk            dos2unix       id             md5sum         scp            telnet         usign
    basename       du             jshn           mkfifo         seq            test           wc
    bunzip2        env            jsonfilter     nc             signify        time           wget
    bzcat          etherwake      killall        nslookup       sort           top            which
    chage          expr           ldd            ntfs-3g        ssh            tr             xargs
    clear          find           less           ntfs-3g.probe  ssh-keygen     traceroute     yes
    cmp            free           locate         passwd         strings        traceroute6
    crontab        getrandom      logger         pgrep          su             uniq
    
    
    root@OpenWrt:~# /usr/sbin/
    add-shell          deluser            ip6tables-restore  lsmod              odhcpd-update      tcpdump
    addgroup           dnsmasq            ip6tables-save     modinfo            opkg-key           uhttpd
    adduser            groupadd           ipset              modprobe           pppd               useradd
    brctl              groupdel           iptables           ntpd               rmmod              userdel
    bridge             groupmod           iptables-restore   ntpd-hotplug       sshd               usermod
    chroot             insmod             iptables-save      odhcp6c            swapoff            visudo
    crond              ip6tables   
    
    PATH=/usr/bin:/usr/sbin:/bin:/sbin

    Could someone clarify something for me please.
    Im testing builds and flashing them in virtual openwrt enviroment on my PC.
    When the build process completes it genetes the following 4 files.

    -rw-r--r--  1 root root 9.7M Aug 31 09:40 openwrt-x86-generic-combined-ext4.img.gz
    -rw-r--r--  1 root root 9.3M Aug 31 09:40 openwrt-x86-generic-combined-squashfs.img
    -rw-r--r--  1 root root 5.8M Aug 31 09:40 openwrt-x86-generic-generic-rootfs.tar.gz
    -rw-r--r--  1 root root 5.9M Aug 31 09:40 openwrt-x86-generic-rootfs-ext4.img.gz
    -rw-r--r--  1 root root 4.8M Aug 31 09:40 openwrt-x86-generic-rootfs-squashfs.img


    However "openwrt-x86-generic-combined-ext4.img.gz" is the onyl one that can be flashed for some reason.The lucii interface doesnt accept the other files for flashing... Does anyone know which the proper format of the files, are the actual flashable files supposed to be .img or .gz ?

    @Villeneuve
    http://infocenter.arm.com/help/index.js … index.html

    It seems cortex-a9 has VFPv3-D16 (half precision) fpu with neon support?

    But neon is only useful for multimedia purposes i think. Like video playback/transcoding and so on.

    (Last edited by shm0 on 1 Sep 2016, 18:30)

    @all

    Does anyone know how to change the default kernel from 4.4.19 to 4.7.2 ?

    I would be greatly appreciated. smile

    thelakesclub wrote:

    @all

    Does anyone know how to change the default kernel from 4.4.19 to 4.7.2 ?

    I would be greatly appreciated. smile

    /source/include/kernel-version.mk
    But there is more than just changing the kernel. Read sera's posts.
    EDIT: /source/target/Linux/mvebu/makefile
    I think that is a start but I could be wrong. smile

    (Last edited by northbound on 2 Sep 2016, 00:06)

    @alirz:

    alirz wrote:

    i do have the "ip" package installed. hower the 'neigh' option doesnt seem to be there anymore.

    Based on you not having the "iproute2 ip" in /usr/bin, I think that you do not have the "ip" package installed, instead only the busybox app is there.

    You can easily verify if you have the "ip" package installed:
      root@xxx:~# opkg list-installed | grep "^ip "
      ip - 4.4.0-3

    Install the actual "ip" package to get the full ip functionality instead of the crippled-down busybox app.
    opkg install ip

    @sera Good call. I did a 4.8-rc4 build and flashed the UBI image. From your last post I decided I would leave wireless down to see how it behaved. It ran for a few hours with no issues, so I setup the /etc/config/wireless file and brought wireless up. Started connecting wireless devices and all went well until the one fruit device in the house, and it all came tumbling down. I can't say for sure it was the ipad2 on ac, it's the only ac device I have, but that is when things went South. When I get a chance I will pull the mamba and connect it to serial to see if I can get anything of value from the console. Another point of interest, @idle cpu numbers are in the 1-4% range with this image, of course sans wireless. Now, where did I put that snake hook.

    The 4.4-rc4 images are available if anyone wants to test behaviour on a different device.

    hnyman wrote:

    @alirz:

    alirz wrote:

    i do have the "ip" package installed. hower the 'neigh' option doesnt seem to be there anymore.

    Based on you not having the "iproute2 ip" in /usr/bin, I think that you do not have the "ip" package installed, instead only the busybox app is there.

    You can easily verify if you have the "ip" package installed:
      root@xxx:~# opkg list-installed | grep "^ip "
      ip - 4.4.0-3

    Install the actual "ip" package to get the full ip functionality instead of the crippled-down busybox app.
    opkg install ip

    Thanks. That was it.

    Now im wondering under which  section i can find this "ip" package when in the build enviroment so that i can select it to be inlucded in my customer built.
    I've search through all sections and all are pointing to the busybox version....

    Does the package have a different name that i should be looking for?
    thanks