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.

ValCher,

there is no space for a fan on Rango either, yet someone still managed to make room for it wink

---

Ansuel,

The clock is part of the SoC itself. And sort of usable for preserving time across a reboot. To make it fully functional you need access to the pins rtc_avss rtc_avdd rtc_xin rtc_xout, a 32768 kHz quartz and a 3V battery and some modding skills.

Hey there,

i am using a wrt1900acs (Linux openwrt 3.18.36 #8 SMP Thu Oct 13 11:43:34 CEST 2016 armv7l GNU/Linux) and have problems using some of the 5ghz channels:

my /etc/config/wireless looks like this:

  
        config wifi-device 'radio0'
        option type 'mac80211'
        option channel '140'
        option hwmode '11a'
        ...

root@openwrt:~# iwinfo wlan0 info
No such wireless device: wlan0

when i change the wireless config to channel 36:

  
config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'

 
reload with 'wifi' then the device apears:

iwinfo wlan0 freqlist
* 5.180 GHz (Channel 36)
  5.200 GHz (Channel 40)
  5.220 GHz (Channel 44)
  5.240 GHz (Channel 48)
  5.260 GHz (Channel 52)
  5.280 GHz (Channel 56)
  5.300 GHz (Channel 60)
  5.320 GHz (Channel 64)
  5.500 GHz (Channel 100)
  5.520 GHz (Channel 104)
  5.540 GHz (Channel 108)
  5.560 GHz (Channel 112)
  5.580 GHz (Channel 116)
  5.600 GHz (Channel 120)
  5.620 GHz (Channel 124)
  5.640 GHz (Channel 128)
  5.660 GHz (Channel 132)
  5.680 GHz (Channel 136)
  5.700 GHz (Channel 140)

 
Now, when i change it back and reload the conf it will work (listed correctly in iw freqlist) - until the next reboot.


Alternatively when i change it to channel 136, the frequency is set to channel 100 !?

Using the commandline i get:

root@openwrt:~# iw wlan0 set channel 136
command failed: Invalid argument (-22)

-- the listed frequencies from iw are not valid?

and

root@openwrt:~# iw wlan0 set channel 140
command failed: Invalid argument (-22)

which is really strange, because having this option in the conf and then reloading works

@sera,
@Ansuel.
On account of the fan, I had to install the fan due to compilation engines. The more that there is virtually nothing else to redo, but to give my friend a radiator on the milling machine.
At the RTC. To install it, you must choose a processor from the boards and build external connection to it, and then this whole "kitchen garden" solder back. No, I don't agree. wink

ValCher

Yeah, I don't think it's worth it either. You are probably right that one needs to solder the wires to the bottom side of the board, directly connect it to the SoC.

sera wrote:

ValCher

Yeah, I don't think it's worth it either. You are probably right that one needs to solder the wires to the bottom side of the board, directly connect it to the SoC.

well not worth it so much....
also i have problem with connecting the board with a serial adapter...

if i connect it, the esata led stay on but i don't get any output from the console..

Any idea?

Ansuel wrote:
sera wrote:

ValCher

Yeah, I don't think it's worth it either. You are probably right that one needs to solder the wires to the bottom side of the board, directly connect it to the SoC.

well not worth it so much....
also i have problem with connecting the board with a serial adapter...

if i connect it, the esata led stay on but i don't get any output from the console..

Any idea?

Did you connect the USB to TTL power lead? If so disconnect it because it's unused.

@sera
In principle it is possible to make and I am familiar with the technology of soldering BGA, but something could go wrong as you'd expect-overheating CPU, static discharge, etc

ValCher,

indeed there is the risk of damaging the unit. As most of the supported devices don't come with an RTC it needs to be solved in software anyway for them. Sure would be nice to have an RTC but it's far from a big deal to not have one.

Ansuel,

Might be just a bad usb2ttl adapter. The Prolific chips are only partial implementations. I recommend FTDI instead.

evilroach wrote:

The nginx inclued in 15.05 can not run normally in reverse-proxy mode.
I have re-compiled the nginx package, but it still can not fix the problem, Neither the nginx source version of 1.4.7 nor 1.10.3.
It looks like that the "status line" returned by the upstream has disappeared.
Only on a WRT1900ACv2, the problem always appears. the Devices else i tried include XiaoMi mini , HG255d, 843Nv1.
Is there a bug in another module, may be ?

If you, or anyone else, can access LuCI with nginx, please post your nginx config as no one on this forum has thus far known what cgi options must be added.

swrt-2017-04-19
---------------

The ubifs and the xhci regression are taken care of in today's linux-next. The
38x labels patch made it in as well.

Also bump openssl.

* linux-4.10: bump to 4.10.11
* linux-4.11: bump to 4.11-rc7
* linux-next: bump to next-20170419

* openssl: bump to 1.0.2k

* kernel: next: drop 38x labels patch, already in.
* kernel: next: drop regression patches, already fixed.

swrt-2017-04-19.tar.xz: https://gpldr.in/v/hDsvVEEjEF/roHogWwpVyh7ZwYt
sha256sum: 332c2147762e4b132683c53822f1049dee3f26529c0f7c572aee5982ae8970d9

davidc502 wrote:
Gazoo wrote:

Make sure you aren't running a stock firmware on your Linksys router.

10 vulnerabilities with 6 being remote - 25 models affected including the WRT series
http://blog.ioactive.com/2017/04/linksy … ities.html

Linksys Advisory
http://www.linksys.com/us/support-artic … Num=246427

Will do some searching, but are there any vulnerability or penetration tests done on OpenWrt/LEDE?

Not that IOActive or The Hacker News has reported.  A few of the 10 vulnerabilites are due to idiots not changing the default credentials for root and guest networks. 

  • I've come to the opinion if someone refuses to do something as simple as a google/bing/duckduckgo/etc. search for best router security practices, they deserve to be exploited.  There's simply no excuse in 2017 for users to still be refusing to employ basic IPsec measures, of which takes no more than 5 seconds to do a web search on.

    • This doesn't absolve an OEM of their responsibility to address vulnerabilities, however it's highly likely when the full details of the vulnerabilities are released most, if not all, will have a correlation back to a user not employing basic security practices on their router(s).

(Last edited by JW0914 on 21 Apr 2017, 16:23)

Getting to compile with the new wifi driver, and noticed something maybe new?

PKG_MIRROR_HASH:=a903d87cbd252019d2dee84ca331e3c865be611e989301aadaaee86ca4ce2435

This is in the mwlwifi Makefile

Usually I edit the PKG_VERSION AND THE PKG_SOURCE_VERSION, but what kind of hash do we have going on here with the Mirror Hash (Looks Long), and where can I get the correct value?  I'm assuming my build will fail without the correct value?

Thanks,

Not really that new, it's a sha256sum. You can leave it out for your own build if you want. It can be generated manually, or with an option on make script.

0util@util0:~/br/dl$ sha256sum mwlwifi-10.3.4.0-20170421.tar.xz
43e0c2c00929e4d50a3abfbf0348f21e77debc8f298ac2d0d699b981dd940799  mwlwifi-10.3.4.0-20170421.tar.xz

(Last edited by Villeneuve on 22 Apr 2017, 00:47)

Villeneuve wrote:

Not really that new, it's a sha256sum. You can leave it out for your own build if you want. It can be generated manually, or with an option on make script.

0util@util0:~/br/dl$ sha256sum mwlwifi-10.3.4.0-20170421.tar.xz
43e0c2c00929e4d50a3abfbf0348f21e77debc8f298ac2d0d699b981dd940799  mwlwifi-10.3.4.0-20170421.tar.xz

Thanks...

davidc502@ubuntu:~/Downloads$ sha256sum mwlwifi-4bcb55582df196e3b814e01adb9500591e69505a.tar.xz
00c123f452d287d182ccd3d694d9bb3c7982e3ec41c12323a1cedc3b2ca7f639  mwlwifi-4bcb55582df196e3b814e01adb9500591e69505a.tar.xz

Is there a reason you went one commit back from the most recent? Just curious due to the reboot/crash on rango in pulling the latest; i.e. did I miss anything?

Villeneuve wrote:

Is there a reason you went one commit back from the most recent? Just curious due to the reboot/crash on rango in pulling the latest; i.e. did I miss anything?

A bunch of people have already tested, and moved on to the next commit, so I wanted to test the first commit as well.

Hope that makes sense.

davidc502 wrote:
Villeneuve wrote:

Is there a reason you went one commit back from the most recent? Just curious due to the reboot/crash on rango in pulling the latest; i.e. did I miss anything?

A bunch of people have already tested, and moved on to the next commit, so I wanted to test the first commit as well.

Hope that makes sense.

It doesn't make a difference.
If you look at the Kaloz repo git history, it is straight development in mrvltest repo and one merge where new commits were pulled into the main Kaloz repo. The last commit 6ba335bb is just a clean merge commit with no code changes.
https://github.com/kaloz/mwlwifi/network
As there are no commits in the main master at the same time, the files should be identical in both 4bcb555 and 6ba335b.

(Last edited by hnyman on 22 Apr 2017, 08:08)

swrt-2017-04-22
---------------

A new version of mwlwifi with the new Rango firmware was pushed, so bump the
firmware and driver. This driver isn't to be expected to solve all issues but
should be a bigger step towards a good / stable driver. Works for Me (tm) at
first, both on Shelby and Rango, the same for me as with the old driver wink So I
only really tested Shelby for about a day without regressions, so far so good.
Rango was just a basic test.

I enabled rfkill in the kernel config instead of using black magic. So it's now
possible to have cfg80211 and mac80211 built in without further modifications
which makes it easy to build a "debug" version thereof just by using
kernel_menuconfig.

Also cleaned up the packages a bit, mainly adding packages to the default
package set instead of adding them as pseudo dependencies. There is nothing in
the way to use the wireless part of the SD8887 on Rango so add the driver to
the default packages as well.

Last but not least I added back cake support to tc. Dropped it with the
iproute2 bump, so it's currently broken with linux-next.

* linux-4.10: bump to 4.10.12
* linux-next: bump to next-20170421

* kmod-cfg80211: cleanup, drop pseudo dependencies
* kmod-mac80211: cleanup, drop pseudo dependencies
* mwlwifi-firmware-88W8964: bump to 9.1.2.5
* mwlwifi-nocompat: bump to 2017-04-21
* iproute2: tc: add back cake support.
* kmod-sched-cake: mark broken with next

* profile: add the pseudo dependencies to the default package set.
* profile: add kmod-net-mwifiex-sdio to default package set

* kernel: enable rfkill


swrt-2017-04-22.tar.xz: https://gpldr.in/v/4g1mvmQkRq/2fzJLDk7qMG2Ay5m
sha256sum: 5bf9bcd97e4407222041b3b102791e2729c5833c1833ef02fe7332977e3448b9

@sera Where I can download your recent build?

Has anyone else had issues with iotivity compiling in the new builds?  During compilation there is a request for a password. I left it blank and hit enter, and it moved past the request.

This is where it was hanging waiting for a password.

touch /home/davidc502/Desktop/lede-imagebuilder-mvebu.Linux-x86_64/source/staging_dir/target-arm_cortex-a9+vfpv3_musl_eabi/root-mvebu/stamp/.iotivity-example-simple_installed
make[3]: Leaving directory '/home/davidc502/Desktop/lede-imagebuilder-mvebu.Linux-x86_64/source/feeds/packages/net/iotivity'

(Last edited by davidc502 on 22 Apr 2017, 19:34)

S Pimenta,

Create a branch from openwrt/master and apply the patches, then build your own as you normally would.

---

davidc502

Interactive builds are a packaging bug, report it to the package maintainer.

For those testing 3200acm with the new driver...   Just my first observation.

Flash Kernel 4.9 r3988 this was using the USB/TTL method, so no settings were retained, and I got a copy of /etc/config/wireless before restoring.

After restoring configurations from the 1900acm, I couldn't connect any devices to Wifi though the SSID Broadcast was there... However, I could connect to the default "LEDE" on Radio #2. Okay, so what's the difference between the radios, so I compared the /etc/config/wireless, and noticed there was a difference.

config wifi-device 'radio0'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'
VS.

config wifi-device 'radio2'
         option path 'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'

I noticed the path "platform" on Radio 2 which was working... So, I edited the wireless config for Radio 0 and 1, and inserted platform, and all my clients can now connect.

*EDIT*

If memory serves me correctly we had gotten away from that path because of kernel requirements?

(Last edited by davidc502 on 23 Apr 2017, 16:21)

Sorry, posts 14351 to 14350 are missing from our archive.