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.

SuperWRT is an alternative firmware for compatible wireless router equipment. The files are provided free of charge on the site and compiled from public sources of the LEDE project with adjustments in the kernel and system configurations.

Linksys wrt1900ac v2  Stable version r4479  Kernel Version 4.9.34 s.go.ro/4ce8yfnu  superwrt.download   superwrt.download/firmware/

(Last edited by magnum44 on 16 Jul 2017, 07:34)

magnum44 wrote:

SuperWRT is an alternative firmware for compatible wireless router equipment. The files are provided free of charge on the site and compiled from public sources of the LEDE project with adjustments in the kernel and system configurations.

Linksys wrt1900ac v2  Stable version r4479  Kernel Version 4.9.34 s.go.ro/4ce8yfnu  superwrt.download   superwrt.download/firmware/

No English no downloady!

tapper wrote:
magnum44 wrote:

SuperWRT is an alternative firmware for compatible wireless router equipment. The files are provided free of charge on the site and compiled from public sources of the LEDE project with adjustments in the kernel and system configurations.

Linksys wrt1900ac v2  Stable version r4479  Kernel Version 4.9.34 s.go.ro/4ce8yfnu  superwrt.download   superwrt.download/firmware/

No English no downloady!

Not only that:

  • SuperWRT has no credibility, as there's no repo, no forum, no source, no nothing, and should not be trusted.

  • it's a private, not public, site and essentially, for all intents and purposes, is nothing more than a personal project of Daniel Petre, who claims copyright protection

If one is going to install router firmware, of which is the literal gateway to one's digital life (and anyone else behind the router), one had better be 100% sure they can trust the firmware. 

  • For example, someone flashing DD-WRT, LEDE. or OpenWrt doesn't need to know how to read or write code, as there's thousands of others who do that review the source code and final files weekly, if not daily.

(Last edited by JW0914 on 16 Jul 2017, 15:41)

JW0914 wrote:
tapper wrote:
magnum44 wrote:

SuperWRT is an alternative firmware for compatible wireless router equipment. The files are provided free of charge on the site and compiled from public sources of the LEDE project with adjustments in the kernel and system configurations.

Linksys wrt1900ac v2  Stable version r4479  Kernel Version 4.9.34 s.go.ro/4ce8yfnu  superwrt.download   superwrt.download/firmware/

No English no downloady!

Not only that:

  • SuperWRT has no credibility, as there's no repo, no forum, no source, no nothing, and should not be trusted.

  • it's a private, not public, site and essentially, for all intents and purposes, is nothing more than a personal project of Daniel Petre, who claims copyright protection

If one is going to install router firmware, of which is the literal gateway to one's digital life (and anyone else behind the router), one had better be 100% sure they can trust the firmware. 

  • For example, someone flashing DD-WRT, LEDE. or OpenWrt doesn't need to know how to read or write code, as there's thousands of others who do that review the source code and final files weekly, if not daily.

Anyone claiming copyright protection on opensource code is NOT to be trusted.

nitroshift

Is anyone else having issues with WDS clients on the 3200ACM? I can't get my 1900AC or 1900AC v2 to connect to my 3200ACM and pass data. They connect but RX remains at 48Mbis and TX at 1300Mbits on the 1900's. The 3200ACM shows 6Mbits on each from each router. I am running davids current builds for each on all of my routers. I have installed bridge and nothing seems to be working. All my other devices remain stable and connected. Is there something I can do to fix this, or is this driver related (dealing with WDS)?

@GillyMoMo Did you read the WDS Client wiki?  If so, please post your system log within [ code ] brackets, as well as the wireless config for all three devices (/etc/config/wireless - please remove passwords, and ensure correct options are set [search "wds" on LEDE's wireless config]).

  • Copy log to file: logread > /tmp/sys.log

    • Please ensure you perform a find & replace for your WAN IP and DDNS (if you use one)

  • Copy and paste the output from the file

(Last edited by JW0914 on 18 Jul 2017, 13:27)

WDS doesn't work (yet) with recent WRT3200 drivers.  You can go back a few months and get WDS but then all the other issues with the driver that have been fixed over the past few months will be present.  The addition of WDS is being tracked here:

https://github.com/kaloz/mwlwifi/issues/182

JW0914 wrote:

@GillyMoMo Did you read the WDS Client wiki?  If so, please post your system log within [ code ] brackets, as well as the wireless config for all three devices (/etc/config/wireless - please remove passwords, and ensure correct options are set [search "wds" on LEDE's wireless config]).

  • Copy log to file: logread > /tmp/sys.log

    • Please ensure you perform a find & replace for your WAN IP and DDNS (if you use one)

  • Copy and paste the output from the file

Yes I did read it, many times over. I reverted back to stock firmware on the 3200 and 1900v2. I have been using openwrt/lede for a number of years now. I can send you the log file for the one that still has lede installed. What's odd in stock firmware they bridge just fine, lede they do not. I can update more when I get home.

GillyMoMo wrote:
JW0914 wrote:

@GillyMoMo Did you read the WDS Client wiki?  If so, please post your system log within [ code ] brackets, as well as the wireless config for all three devices (/etc/config/wireless - please remove passwords, and ensure correct options are set [search "wds" on LEDE's wireless config]).

  • Copy log to file: logread > /tmp/sys.log

    • Please ensure you perform a find & replace for your WAN IP and DDNS (if you use one)

  • Copy and paste the output from the file

Yes I did read it, many times over. I reverted back to stock firmware on the 3200 and 1900v2. I have been using openwrt/lede for a number of years now. I can send you the log file for the one that still has lede installed. What's odd in stock firmware they bridge just fine, lede they do not. I can update more when I get home.

None of that is necessary now, per @InkblotAdmirer's reply

Everyone should know the following for Security's sake.

AES-256bit has been broken, and with ease.... sigh.  With just some cheap parts.

Read more about it below.
https://www.digitaltrends.com/computing … on-decode/

*EDIT*

Currently looks like you have to be pretty close.... but don't expect distance to be a limitation for long.

@davidc502, don't be a fear-monger.  AES256 isn't broken, the technique described requires wireless access to radiated unencrypted data from the device.  Good luck with that attack vector, in general.

What you should be more worried about is that Marvell binary blob in the wifi driver.

Additionally, a similar method exists for smartphones IIRC, but like the method in the article, its only viable when the attacker has direct physical access to a chunk of the unencrypted data, as well as that exact same chunk of data after it's been encrypted. 

To be clear. 256bit encryption is physically impossible to crack, and will remain so until quantum computers are a viable option for computing.  Even nation states can't crack AES256 (and IIRC from the last D.o.D memo, only TS/SCI data must be encrypted with AES192, or AES256, can't recall which), as even with the most advanced supercomputers, it would take longer than a human life to crack.

InkblotAdmirer wrote:

WDS doesn't work (yet) with recent WRT3200 drivers.  You can go back a few months and get WDS but then all the other issues with the driver that have been fixed over the past few months will be present.  The addition of WDS is being tracked here:

https://github.com/kaloz/mwlwifi/issues/182


That's what I was thinking. Since it happened to work on the other two models without fail. So I shall be keeping an eye on this! Thank you!

JW0914 wrote:

To be clear. 256bit encryption is physically impossible to crack, and will remain so until quantum computers are a viable option for computing.  Even nation states can't crack AES256 (and IIRC from the last D.o.D memo, only TS/SCI data must be encrypted with AES192, or AES256, can't recall which), as even with the most advanced supercomputers, it would take longer than a human life to crack.

This is overstating the security of 256 bit encryption. If there are problems found in the algorithm, that can drastically reduce the number of attempts needed to break the encryption. Even 128 bit encryption is impractical to attack via brute force methods. It's only ancient DES that is able to be attacked via brute force in a practical way. Every 'broken' encryption method has required that some sort of 'shortcut' (i.e. algorithm bug) be found.

AES is not known to have any such bugs in it, but there may be ones found sometime in the future.

dlang wrote:
JW0914 wrote:

To be clear. 256bit encryption is physically impossible to crack, and will remain so until quantum computers are a viable option for computing.  Even nation states can't crack AES256 (and IIRC from the last D.o.D memo, only TS/SCI data must be encrypted with AES192, or AES256, can't recall which), as even with the most advanced supercomputers, it would take longer than a human life to crack.

This is overstating the security of 256 bit encryption. If there are problems found in the algorithm, that can drastically reduce the number of attempts needed to break the encryption. Even 128 bit encryption is impractical to attack via brute force methods. It's only ancient DES that is able to be attacked via brute force in a practical way. Every 'broken' encryption method has required that some sort of 'shortcut' (i.e. algorithm bug) be found.

AES is not known to have any such bugs in it, but there may be ones found sometime in the future.

One could say that about anything, literally anything, and as such is not a reasonable position to take... currently, AES256 will remain physically impossible to crack until quantum computing becomes viable. 

  • One could take a position with Moore's law in mind, however Moore's law will cease to exist within the coming years due to physics. 

    • Currently, the smallest dies available for CPUs are 10nm, however 6nm is the limit (IIRC, as it might be 4), since it becomes impractical & inefficient to pass electrons through electrical pathways smaller than 6nm (might be 4).

(Last edited by JW0914 on 19 Jul 2017, 13:52)

Hi all, I've been away from this forum for like a year. Around the time when LEDE was new.im still running an old custom CC release on my v1 1900ac.
Just wondering whats the latest stable build that is best to use. Has everyone moved off openwrt and gone to LEDE.
Could someone please provide a link to latest public releases that I can use.thanks.

(Last edited by alirz on 21 Jul 2017, 04:16)

@alirz Everyone should be running LEDE, as it's the only currently maintained repo [17.01.2 or snapshot]... OpenWrt hasn't seen a commit in quite sometime.

  • LEDE runs vLANs by default, and several configs are slightly different than OpenWrt's

    • If you're building your own image, it's recommended to make your image intially with no custom files, then flash and boot the router so the first run script generates the network config (lan is eth0.1, wan is eth1.2)

(Last edited by JW0914 on 21 Jul 2017, 15:28)

Is there a way to test an image prior to flashing it, specifically is there a way to test custom files to ensure there's no critical typos in them?  I have 3 routers at remote sites and was onsite flashing one of them yesterday, only to realize I had a typo in the network config.

JW0914 wrote:

Is there a way to test an image prior to flashing it, specifically is there a way to test custom files to ensure there's no critical typos in them?  I have 3 routers at remote sites and was onsite flashing one of them yesterday, only to realize I had a typo in the network config.

you need a serial interface and load the image via tftp... or modify the openwrt sysupgrade script to run the image in ram at the next boot

@Ansuel  Thanks! =]


@all I want to update the Firmware Images section of the Wiki to show the below... please let me know if the three below changes are not acceptable or should be tweaked:

  1. Update Firmware section to show LEDE as the recommended image for new members to install, annotating that CC should not be used due to the lack of commits and development in OpenWrt.

  2. I also want to add LEDE to it's own section, removing it from Third Party Builds and listing it first, above OpenWrt Branches

    • This will mimic the OpenWrt layout, with nested TOC listing for Stable and Development

  3. I want to annotate the LEDE repo for development builds should be used over OpenWrt's buildroot.

    • LEDE links to the WRT AC Series wiki on their site, and combined with the fact OpenWrt is no longer an updated source for images, I'd like to eliminate any confusion as to the best, and most stable, firmware to utilize for new members.

(Last edited by JW0914 on 25 Jul 2017, 13:01)

JW0914 wrote:

@Ansuel  Thanks! =]


@all I want to update the Firmware Images section of the Wiki to show the below... please let me know if the three below changes are not acceptable or should be tweaked:

  1. Update Firmware section to show LEDE as the recommended image for new members to install, annotating that CC should not be used due to the lack of commits and development in OpenWrt.

  2. I also want to add LEDE to it's own section, removing it from third party builds and listing it first, above OpenWrt Branches,

    • This will mimic the OpenWrt layout, with nested TOC listing for Stable and Development

  3. I want to annotate that the LEDE repo for development builds should also be used over OpenWrt's buildroot.

    • LEDE links to the WRT AC Series wiki on their site, and combined with the fact OpenWrt is no longer an updated source for images, I'd like to eliminate any confusion as to the best, and most stable, firmware to utilize for new members.

it's good for now as lede and openwrt are merging... lede develop are searching who own legal name of openwrt and this type of things, then openwrt code will be lede code with a different name (again openwrt)...

@all want to improve wifi range of wrt3200acm (so bad range...). How can i do that? change antenna?

Ansuel wrote:

@all want to improve wifi range of wrt3200acm (so bad range...). How can i do that? change antenna?

I do know there's issues specific to the 3200 with the WiFi driver, however I'm not sure what problems those issues cause.

In general, the following would be recommended:

  • Using WireShark, or an equivalent, to analyze WiFi channel usage around you to determine the best channels to use for 2.4gHz, whereas the 5.8gHz radio operates best with channels in the 150s.  Also ensure the 2.4gHz network is set to VHT40 (this matters for N, as without it, your mbit/s will be halved) and the 5.8gHz network set to VHT80.

    • This goes hand in hand with tweaking your wireless card settings on the PC.  If using an Intel WiFi card, download and install the Intel PROSet Wireless software, ensuring you install it with the Admin profiles (paraphrasing) box checked.  If not an Intel WiFi card, tweak settings under adapter properties -> configure.

      • Once PROSet is installed, create an admin profile, which then allows you to tweak applicable settings, save and apply the profile.  You should be able to change the same settings under the adapter properties -> Configure, however PROSet will create a profile executable which can simply be ran to auto set the values.

    • If you only see a handful of settings (there should be 15 - 20) under adapter properties -> configure, ensure you're running the latest driver package from your OEM.  If this does not show all settings, you'll need to install the drivers directly from the WiFi card's manufacturer's website

  • Changing the transmit distance and power parameters via LuCI or /etc/config/wireless

  • With LuCI on the Network -> Wireless page, change the position and angles of your antennas while watching the signal and noise dB levels

  • Ensure the router is as close to the center as possible of the area you want covered (in the center of a house for instance).

(Last edited by JW0914 on 25 Jul 2017, 13:36)

What is wrong with intel 7260 and mwlwifi? The connection works fine then slows to a crawl, google becomes unresponsive because of such a slow connection. a manual disconnect and reconnect is required to fix the speed for a short time until it happens again. I have not seen this before as i had moved to a wired only set up but now that im back in wireless I've notice this problem...

WRT 3200ACM
K4.9.37
Latest mwlwifi
nothing but the basics built
tftp flashed on both partitions then reset the config partition
latest intel wireless drivers.

(Last edited by lifehacksback on 25 Jul 2017, 13:55)

@lifehacksback  If you haven't installed Intel PROSet, do so, then import this profile.  Once imported, you can verify the options, however for troubleshooting, I'd recommend leaving them as is since it's the same config I use minus 2 options regarding WiFi network profiles.

  • Please note, all PROSet admin profiles are saved as an exe file in order to be applied without loading it into PROSet

    • Even so, I still recommend doing a virus scan of it, as all EXEs should have a virus scan performed prior to opening.

  • SHA256:

    • ---------------------------
      Checksum information
      ---------------------------
      Name: 7260ac-General-Profile.exe
      Size: 501658 bytes (0 MB)

      SHA256: 02A7961176799E65F28C760268170049463E6921A3A3A1B5BDC5E63C8C04F063

      ---------------------------
      OK   
      ---------------------------

      • This is for the 7260ac, so if you have the 7260n, you'll likely need to build a new profile

(Last edited by JW0914 on 25 Jul 2017, 14:23)

Sorry, posts 14701 to 14700 are missing from our archive.