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.

@JW0914

wrt -> wrt

4. Select the OpenWRT Sysupgrade tarball [*.tar] downloaded from Stable or Trunk, tick Keep Settings, then Flash Image

As soon as you add a community build as you intended from stable or trunk will be wrong. Keeping the settings can lock you out. Chances aren't big but playing safe should be the documented way.

About the wifi security section, I feel it doesn't belong on this page and should be outsourced so other devices can profit as well wink

Hiding ssid doesn't improve security, same for mac filtering.

As for the key length, my take >= 16 acceptable, >= 24 good - but obviously opinions differ.

@dlang

I think you make a valid point.

@mefreeze

I did run it with the mentioned options and got that result (posted before)
I don't know what those error codes are or where I could look for what it is.

This happened now  on two PCs, one was my laptop and the other was a fresh install VPS server  with Ubuntu 16.04. I thought this will go fast with the xoen cpu's it have :-D
But there the same error.

Which profile is the right one? The wrt1900acs, the blablabla armada 385 rd ap or that one with armada 385 db?

What are the differences?


thx4wrt wrote:
SHELL= flock /wrt/openwrt/tmp/.attr-20150922.tar.gz.flock -c '   echo "Checking out files from the git repository..."; mkdir -p /wrt/openwrt/tmp/dl && cd /wrt/openwrt/tmp/dl && rm -rf attr-20150922 && [ \! -d attr-20150922 ] && git clone git://git.sv.gnu.org/attr.git attr-20150922 && (cd attr-20150922 && git checkout efa0b1ea982261861d64f6d6d620af83d82b02d3 && git submodule update --init --recursive) && echo "Packing checkout..." && rm -rf attr-20150922/.git &&   tar czf /wrt/openwrt/tmp/dl/attr-20150922.tar.gz attr-20150922 && mv /wrt/openwrt/tmp/dl/attr-20150922.tar.gz /wrt/openwrt/dl/ && rm -rf attr-20150922; '
Checking out files from the git repository...
Cloning into 'attr-20150922'...
fatal: read error: Connection reset by peer
Makefile:92: recipe for target '/wrt/openwrt/dl/attr-20150922.tar.gz' failed
make[3]: *** [/wrt/openwrt/dl/attr-20150922.tar.gz] Error 128
make[3]: Leaving directory '/wrt/openwrt/feeds/packages/utils/attr'
package/Makefile:196: recipe for target 'package/feeds/packages/attr/compile' failed
make[2]: *** [package/feeds/packages/attr/compile] Error 2
make[2]: Leaving directory '/wrt/openwrt'
package/Makefile:193: recipe for target '/wrt/openwrt/staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/stamp/.package_compile' failed
make[1]: *** [/wrt/openwrt/staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory '/wrt/openwrt'
/wrt/openwrt/include/toplevel.mk:192: die Regel für Ziel „world“ scheiterte
make: *** [world] Fehler 2

WHAT IS THAT?

dlang wrote:

On the hardware detail tables, are we getting to the point where it makes sense to rotate them so the hardware version is along the top with what are currently the headers down the left?

I tend to use portrait mode monitors so I notice wide tables sooner than most, but as mobile devices become more common so does that mode of viewing.

If we do this, would it make sense to add the links to the downloads to the table and have the table up near the top of the page?

A large part of this is what the expected uses of the pages are. For me, the most common thing I am looking for is 'what are the specs of this hardware, and what versions are supported'. It's only after I have purchased one that I then get into the details of flashing, configuring, etc.

You make several great points; I can move the hardware tables to right below the introduction, with the next section following it being firmware.  The only thing I'm not sure about, or at least I'm not sure how to do, would be to get the hardware version along the top.  Below is the code for the WRT1200ac hardware table:

== WRT1200AC ===
---- datatable ----
cols    : Model, Versions, Supported Since Rev_url, Supported Since Rel, Platform, CPU MHz, Flash MB, RAM MB, Switch, Power Supply, Device Techdata_pageid, Comments_
align   : c,c,c,c,c,c,c,c,c,c,c,c,c
filter  : Model=WRT1200AC
----


sera wrote:

About the wifi security section, I feel it doesn't belong on this page and should be outsourced so other devices can profit as well wink

That was my feeling as well after I got done moving things around.  I was trying to prevent redundantly saying the same thing under multiple headings, but now it seems quite out of place in the firmware section.

Should it be included within the wiki, but within it's own section, or should it be put into it's own doc and simply link to the doc?

Hiding ssid doesn't improve security, same for mac filtering.

Doesn't it make it more difficult if one doesn't know the SSID, as I've seen what you've said echoed on different forums with no one ever going into detail why it doesn't.  Would you also elaborate on the mac filtering as well please.

As for the key length, my take >= 16 acceptable, >= 24 good - but obviously opinions differ.

I don't feel comfortable unless my passwords are ~30 characters or longer for sensitive logins. 

  • Should I simply add what I quoted for this response, or should an arbitrary number be listed; and if so, should it be the bare minimum, or should it be ~25.

  • I've tried to edit this, and other wikis, with the lay user in mind, and I'm always asking myself "am I going too deep into into this", "am I making this more complex than it needs to be", "will what I just wrote be overwhelming to the user", etc.; So I struggle a lot with "this is how I would do it", but "this makes it inherently more complex for the lay user"

  • I personally believe root & wifi passwords should be no less than 25 characters; however, I also have my own system of generating complex passwords that are unique to every login, but are still easy to remember due to the system I utilize for substitution.

EDIT

Moved Hardware section to directly below Introduction

(Last edited by JW0914 on 13 May 2016, 12:39)

JW0914 wrote:

Hiding ssid doesn't improve security, same for mac filtering.

Doesn't it make it more difficult if one doesn't know the SSID, as I've seen what you've said echoed on different forums with no one ever going into detail why it doesn't.  Would you also elaborate on the mac filtering as well please.

As soon as there is a valid client connecting I'd heard all I need already. Maybe you can prevent your neighbour using windows wifi setup from connecting because he knows your birthday which you thoughtfully used as your key. Certainly the pain for users far exceeds that of a hacker.

JW0914 wrote:

As for the key length, my take >= 16 acceptable, >= 24 good - but obviously opinions differ.

I don't feel comfortable unless my passwords are ~30 characters or longer for sensitive logins.

  • Should I simply add what I quoted for this response, or should an arbitrary number be listed; and if so, should it be the bare minimum, or should it be ~25.

  • I've tried to edit this, and other, wikis with the lay user in mind, and I'm always asking myself "am I going too deep into into this", "am I making this more complex than it needs to be", "will what I just wrote be overwhelming to the user", etc.; So I struggle a lot with "this is how I would do it", but "this makes it inherently more complex for the lay user"

  • I personally believe root & wifi passwords should be no less than 25 characters; however, I also have my own system of generating complex passwords that are unique to every login, but are still easy to remember due to the system I utilize for substitution.

Depends what level of security you are after. Generally, unless you have something particular valuable, as long as there are plenty easier targets you are fine. 16 is maybe a year on consumer grade hardware, 24 a year of Hollywood's rendering farms. If concerned $(pwgen 63 1).

To ease my life password based logins are disabled all together and I use things like radius and ldap, the added security comes basically for free.

The best thing about wpa2 is it's straight forward, there is no need to learn the concepts behind all those technologies and is reasonably safe.

I think I said all the above so you have a bigger picture of what is available, not for it to be included. The original statement on the wiki was misleading. Basically claiming wpa2 is the best on can do and not mentioning the basic requirements of unique ssid and a reasonably long random password. Leaving out things is fine, wrong or misleading information should be avoided.

Edit: I can state here 16/24 as an opinion, on a wiki you can only have it as a fact.

(Last edited by sera on 12 May 2016, 23:46)

JW0914 wrote:

Hiding ssid doesn't improve security, same for mac filtering.

Doesn't it make it more difficult if one doesn't know the SSID, as I've seen what you've said echoed on different forums with no one ever going into detail why it doesn't.  Would you also elaborate on the mac filtering as well please.

hiding the SSID doesn't help much because if anyone is actually using the network, they are broadcasting the SSID quite frequently, so you will see it on the air.

Hiding the SSID does two things.

1. if nobody is using the network, it's not visible

2. it doesn't show up by default in pulldown menus.

As a result it's weak protection at best.

As for locking things down to a particular MAC address, the weakness is that you can trivially change your MAC address to an authorized one (and you can detect the MAC address by listening on the network)

both of these harden your system against weaker attackers, but they probably won't get through even the most trivial password. They are speedbumps against more sophisticated attackers, at the cost of being more effort to setup and maintain.

I will do the MAC filtering on my home network, but I have a household of 4 geeks, I would not implement it at my friends house because it would cause lots of problems.

As for the key length, my take >= 16 acceptable, >= 24 good - but obviously opinions differ.

I don't feel comfortable unless my passwords are ~30 characters or longer for sensitive logins.

if I am actually worried about security, I don't use passwords.

If the password is too long, people just write them down or tell their systems to remember them, neither of which really helps much.

I don't think either of these recommendations are good to put in a particular device's page. They are useful to have in a generic "things you can do to improve wireless security", but they should not be presented as absolutes.

JW0914 wrote:
dlang wrote:

On the hardware detail tables, are we getting to the point where it makes sense to rotate them so the hardware version is along the top with what are currently the headers down the left?

I tend to use portrait mode monitors so I notice wide tables sooner than most, but as mobile devices become more common so does that mode of viewing.

If we do this, would it make sense to add the links to the downloads to the table and have the table up near the top of the page?

A large part of this is what the expected uses of the pages are. For me, the most common thing I am looking for is 'what are the specs of this hardware, and what versions are supported'. It's only after I have purchased one that I then get into the details of flashing, configuring, etc.

You make several great points; I can move the hardware tables to right below the introduction, with the next section following it being firmware.  The only thing I'm not sure about, or at least I'm not sure how to do, would be to get the hardware version along the top.  Below is the code for the WRT1200ac hardware table:

== WRT1200AC ===
---- datatable ----
cols    : Model, Versions, Supported Since Rev_url, Supported Since Rel, Platform, CPU MHz, Flash MB, RAM MB, Switch, Power Supply, Device Techdata_pageid, Comments_
align   : c,c,c,c,c,c,c,c,c,c,c,c,c
filter  : Model=WRT1200AC
----

I don't know if there is an easy way to do it with the wiki code. but can you do a smarter filter to have them all as one table at least?

can you do the following? (I don't know if this will accept regexes here or not

filter : Model(WRT1200AC|WRT1900AC|WRT1900ACS)

Hi everybody,

I'm (almost) compiling custom image for 1900acs.
I have one question and i hope anybody can give me advise on this.

For 1900acs, Do I need to compile the kernel with Asynchronous IO support or not? (good or bad idea??)

Thanks in advance!

@Remco

Both should be fine, default is off and so obviously much better tested.

@Sera, thanks for your reply! much appreciated.

sera wrote:

@Remco

Both should be fine, default is off and so obviously much better tested.

@davidc502 @mrfrezee  Would either of you like your firmware listed under firmware in the WRT1X00AC/S Series wiki?

JW0914 wrote:

@davidc502 @mrfrezee  Would either of you like your firmware listed under firmware in the WRT1X00AC/S Series wiki?

Yeah why not, just wait a little bit, my WAN fiber is supposed to be up in 4-5 days and my repo is still offline.

It's usefull to get listed because more people would test "community made" firmware (for example, to have more feedback on marvell-cesa or anything that's not yet uncluded on the official trunk stream)

@thx4wrt

Seems like one your your selected packages failed to build because one of the repository needed for it isn't working correctly (reset by peer).

Try to build with:

-j1 IGNORE_ERRORS=m V=99 CONFIG_DEBUG_SECTION_MISMATCH=y
mrfrezee wrote:
JW0914 wrote:

@davidc502 @mrfrezee  Would either of you like your firmware listed under firmware in the WRT1X00AC/S Series wiki?

Yeah why not, just wait a little bit, my WAN fiber is supposed to be up in 4-5 days and my repo is still offline.

It's usefull to get listed because more people would test "community made" firmware (for example, to have more feedback on marvell-cesa or anything that's not yet included on the official trunk stream)

No problem at all =]

Hi,

Sorry to bother you with a noob question. It has been atleast 5 years since I built openwrt (backfire)...
I would like to build davidc502 version of the tree, since it seems most stable and frequently updated.
I remember that there were a extensive howto for the Gateworks boards, like this: http://trac.gateworks.com/wiki/OpenWrt Is something similar available for the WRT1900ACS? Or could someone please write up a short howto config/build for WRT1900ACS?
I would like to add MBIM support into OpenWRT (if not already implemented)

/R

@JW0914

how about:

Firmware

    -There are several OpenWrt build sources for the WRT1X00AC/S Series
       - Some builds do not have the LuCI web GUI installed. To install LuCI, ssh/telnet to the router and follow the LuCI Essentials wiki
       - Wireless is disabled by default for security reasons. Follow <insert document fit for purpose>.

And be done with the wireless business on this page?

Also 802.11w isn't enterprise level, just enable it. Some old clients might not be able to connect anymore but recent ones should support it transparently while significantly increasing security.

Redferne wrote:

Hi,

Sorry to bother you with a noob question. It has been atleast 5 years since I built openwrt (backfire)...
I would like to build davidc502 version of the tree, since it seems most stable and frequently updated.
I remember that there were a extensive howto for the Gateworks boards, like this: http://trac.gateworks.com/wiki/OpenWrt Is something similar available for the WRT1900ACS? Or could someone please write up a short howto config/build for WRT1900ACS?
I would like to add MBIM support into OpenWRT (if not already implemented)

/R

Actually, you should build from Trunk and not my snapshots. The reason? Davidc502 builds are derived trunk snapshots.

There's actually a good openwrt Wiki about how to build your own snapshots from trunk. https://wiki.openwrt.org/doc/howto/build

JW0914 wrote:

@davidc502 @mrfrezee  Would either of you like your firmware listed under firmware in the WRT1X00AC/S Series wiki?

Sure, feel free to list.

Best Regards,

@JW0914 is there a url where we can find 1900ac(s) patches? mrfreeze's, davidc502's even nitroshift which we apply to the trunk source during the build?

@Bogey
are you satisfied with WiFi stability?

gsustek wrote:

@Bogey
are you satisfied with WiFi stability?

Nope, still getting slow after a while. 5GHz has been stable since last post, but 2.4GHz slowed down two times.

Yesterday I set
option txpower '20'
but today 2.4GHz was slow again.
Now added this even though my devices does not support it.
option htmode 'HT40'

After changing the settings I have only run 'wifi' command to reload the config, next time maybe I'll reboot.

Btw I'm running vnstat and system statistic, maybe try to disable those next time.
I have also usb plugged in where I store the stats and syslog.


Edit: while writing 2.4GHz was slow again. Maybe I'll just schedule daily reboot and wait for updated release / wifi driver.

(Last edited by Bogey on 13 May 2016, 18:55)

@davidc502 I am using your compilation, works very well with config switch in luci. The only and detected a bug in the Internet LED does not work directly and the wifi is a bit slower than the original firmware. Thank you

roberto_MCF wrote:

@davidc502 I am using your compilation, works very well with config switch in luci. The only and detected a bug in the Internet LED does not work directly and the wifi is a bit slower than the original firmware. Thank you

A new image will be uploaded this weekend, so be sure to flash. The reason being that hardware acceleration is working better now smile

tapper wrote:

Linksys WRT routers won’t block open source firmware, despite new US rules
But come June 2, a lot of other routers in the US will block third-party firmware.
http://arstechnica.co.uk/information-te … e-details/

I've been telling people for a long time that this is coming...  As someone who is FCC licensed, I know how serious the FCC takes RF in general, and it's pretty much zero tolerance when it comes to tuning anything out of spec. People outside of the US will be affected by this as well. It's going to affect open source firmware, but how much remains to be seen. It will really depend on how "locked" down these new routers are I.E. Wifi verses the OS in general, and if people can still get in them. Many are claiming they can still get in and flash, but time will tell how much damage this ruling does.

@sera I went with:

Wireless is disabled by default for security reasons.  Please take a minute to briefly read the short Wireless Security section of Wireless Overview prior to enabling wireless.


@davidc502 Sounds great, I'll get your firmware added to the Wiki tomorrow.


davidc502 wrote:
tapper wrote:

Linksys WRT routers won’t block open source firmware, despite new US rules
But come June 2, a lot of other routers in the US will block third-party firmware.
http://arstechnica.co.uk/information-te … e-details/

I've been telling people for a long time that this is coming...  As someone who is FCC licensed, I know how serious the FCC takes RF in general, and it's pretty much zero tolerance when it comes to tuning anything out of spec. People outside of the US will be affected by this as well. It's going to affect open source firmware, but how much remains to be seen. It will really depend on how "locked" down these new routers are I.E. Wifi verses the OS in general, and if people can still get in them. Many are claiming they can still get in and flash, but time will tell how much damage this ruling does.

After building my own router to run Sophos UTM, I've come to the conclusion one is better off doing so, especially if looking at consumer routers in the $200 - $300 (USD) range. For ~$450, I bought a SuperMicro A1SRi-2758F (8 core 2.4gHz 24W), mini-ITX box, 16GB ECC DDR3L RAM, and 128GB 850 Pro SSD. 

It's definitely a larger out of pocket expense upfront, but it's guaranteed to not become obsolete, thereby making it far cheaper than a consumer grade router over the long term.  Granted, Sophos changed their free licenses for home users that restricts those switching from UTM to XG to 6 cores and 8GB of RAM, but still, it blows any consumer grade router out of the water.

(Last edited by JW0914 on 14 May 2016, 00:31)

JW0914 wrote:

 

It's definitely a larger out of pocket expense upfront, but it's guaranteed to not become obsolete, thereby making it far cheaper than a consumer grade router over the long term.  Granted, Sophos changed their free licenses for home users that restricts those switching from UTM to XG to 6 cores and 8GB of RAM, but still, it blows any consumer grade router out of the water.

This may be the direction OpenWrt goes.

Do you have the URL to the webpage?