That is completely right what you just wrote! Actually is my english not so bad, i was in a hurry and hit several keys wrong. How ever...

I am German living in Norway, speak and write every day Norwegian, German and English. How you build up the sentences in all three languages is different.

I am working at an US company in the support, so I guess usually English is not so bad.

Those comment's can sometimes destroy the hole day. Just because somebody is writing something what is completely out of range.

I am in this forum now over years... This is the first time that I have to read such stuff.

Again, how ever...

What is now the reason for that the R7000 is not supported by default from the dev's? There must be a reason..

What is it about with these FOSS driver support?

I did preface by saying "assume that English is not your native language and don’t realize the demanding tone you are conveying"

Apparently my initial assumption was correct.   And I was going to let this go until read "stupid" in your reply.

I am not "frustrated" at all and now think I understand what you are asking...

But,

How else are we to understand this sentence?

or this one?

Sounds pretty demanding to me. 

Fortunately, I don't have to speak you other languages but only the one being used here.  No doubt I would fall short.

I am sorry you cannot take constructive criticism and wish you well.

The R7000 cannot be supported because we have no access to suitable, kernel version agnostic wireless drivers.

Gentlemen,
Do we have an ETA for the new driver streamlined for the masses (assuming 15.05.1 will be the defacto for WRT 1900AC V1/2 )? BTW, my birthday is coming up so, I'm patiently awaiting for the new firmware

Regards,
-JM

(Last edited by Juni0rM1nt on 10 Mar 2016, 18:42)

@Thank you jow! The Linksys WRT1900ACS, is designed for wrt if I got it right. Will I be save with that one, I mean that all what is possible with openwrt will work?

@kirkgbr
You still have not enough oxygen? I am from now not reacting any more about your comments, have better thinks to do! I guess people are starting to laugh about your comments. jow simply answered the have of my post. For me such an answer is stupid! You didn't know what I wanted to say (others do) but commented it. And you are frustrated... I don't care...

;-)

I'm looking forward to trying it out when it does go public. Currently downloading upwards of 1 Gbps through the WAN interface using NAT uses around 80% CPU (Average of both processors), so I'll be happy if that can be brought down significantly to 20-25%.

So, is this implementing hardware acceleration? because I wouldn't think anything short of that would bring the CPU down so drastically?

Best Regards,

(Last edited by davidc502 on 10 Mar 2016, 19:17)

The wrt1900 has the same issue with wifi dirver, it contains a blob that is under manufacturer control.

To answer your question 1) yes openwrt is supported on the wrt1900acs 2) wireless is unstable https://github.com/kaloz/mwlwifi 3) new firmware promised and should be released soon which should solve some problems.

As to your comments, I understand English is your third language and sentence structure can vary widely between the different languages you speak, however (it's spelled together not separate) kirkgbr has been a great contributor to our device and has given a lot of his time so please stop criticizing him and calling his comments "stupid" he was just pointing out how your messages conveyed a demanding tone (I got the same impression when i first read it until i noticed this was your third language).

Stay civil,
lifehacksback

Wifi driver is open https://github.com/kaloz/mwlwifi but it relies on a firmware blob to correctly initialize and use the hardware.

Which makes it less than "open", as OpenWrt is dependent upon the blob(s) for correct operation of the radio. If/when there are bugs there is a dependency on the manufacturer for resolution. Not my definition of Open Source.

Edit: At any rate my point was to the first post by NeuerLinuxfan where his concern, apparently, was to the stability/availability of wifi drivers for gear that mostly had nothing to do with the topic at hand. And whether he should consider a wrt1900ac. And as anyone who has spent any time with these devices knows, mwlwifi is the major hurdle. The very reason being the aforementioned blobs.

(Last edited by anomeome on 10 Mar 2016, 20:24)

Many devices are dependent on these blobs to function correctly. Intel's processors have blobs to initialize them yet all their source code is upstream in the linux kernel. It is less than optimal but it is what we have right now, unless someone takes the time to reverse-engineer the firmware blob or use open-hardware then we are going to always depend on blobs since manufacturers don't want to give away their "competitive advantage" tho open sourcing the firmware would have yielded stable and fast wireless long ago.

What do you mean?  There is a perfectly open driver for the wrt1900ac(s).  It still requires closed fimrware for the wifi cpus of course, but the driver is still open source.

First off I never used the word open, nor was it implied, appears some like to add content to posts by others. But if a philosophical debate is to be made of something I did not actually say, fine. By my definition of what constitutes open I would not include what amounts to a wrapper around a blob protected by a NDA to the owner of that blob. To me that flies in the very face of the meaning of open.

But one more time. My comment was in reference to this post, where the gist of the post appears to be regarding the stability/availability of wifi drivers for a couple of Netgear devices, and ends with an inquiry regarding wifi(implied) on the wrt1900ac. I simply stated that the same issue that exists on other devices also exists with the wifi driver mwlwifi; i.e. it is not free and clear of blobs. I stated absolutely nothing as to whether I considered it open or otherwise, a simple statement of fact that I assume a potential purchaser of the device would like to be made cognizant. Were I to go further I would add that anyone considering such a device might do well to add a mediatek device to their potential buy list ahead of the wrt1900ac for that very reason.

I can has 15.05.1 please?

Hello is now compile the firmware stages?

It's not available yet. Check back daily on OpenWrt downloads page.

Apparently it may be further off than had been anticipated.

Ouch. What does "further off," mean? Using a Kaloz and holding off on doing a custom build for my 1200AC. However, the pain with the radios is bad. I have a multitude of devices (and, children) and we've had to turn off the 5GHz radio, entirely. Now, the 2.4GHz is flaky and "kicks," you at what seems to be random intervals.

Saw the mwlwifi patch, but I'll not do it if we're going to have something better?

No. It's being done with one offload module enabled in mvneta driver.

nitroshift

(Last edited by nitroshift on 11 Mar 2016, 21:00)

It's not perfectly open at all; heck, it's not even open! But I don't fault you for buying into Marvell's marketing speak; after all, that's what they're paying their marketing department for. In fact, that blob you're pointing at pretty much is the driver. And the firmware.

Compare it to AMD's and nVidia's binary drivers for Linux. It's pretty much the same: a closed blob, and a wrapper to interface with the kernel and such. At least AMD and nVidia don't pretend it's open. They tell you up front it's closed.

And before you think otherwise, ath10k doesn't seem to be a lot better. For 802.11ac mt76 looks way more interesting if you want an open driver. See this talk by one of the OpenWrt developers.

I was eyeing a WRT1200, but unsure about the wireless driver; now, I'm waiting for th WiTi Board 2 and if I'm upgrading to 802.11AC, that will be what I'll be getting, unless in the meantime some big manufacturer has a good Mediatek AC wireless product by that time.

(Last edited by Borromini on 11 Mar 2016, 22:56)

@grovesp
I would suggest that if you have the means you should proceed with a custom build for your device. If not so inclined, than use a trunk snapshot or community build.

(Last edited by anomeome on 11 Mar 2016, 23:35)

Then we disagree on what a driver is.  That's OK

In my view, a "driver" is what runs on the host CPU.  It usually talks to a device CPU over some bus.  I consider the software running on the device CPU "firmware", and not part of the driver.  Many devices store their firmware on the host and need help from the driver to load it over the bus.  mwlwifi does this.  It still does not make the firmware part of the driver.

No, those are quite different.  Those blobs contain most of the drivers, are linked into the final driver, and will end up running on the host CPU.  Still talking to firmware on the device side.

Try building one of those drivers for another host CPU, and you will see one reason why the distinction is important.

Yes, sure, I would very much like open source firmware too.  But I am trying to be pragmatically realistic.

Hi all. I’m in a bit of a panic. I was running and nightly of DD on my wrt1900ac v2 and was having stability issues. I decided to flash back to DD RC3, but forgot I had configured a root overlay on usb. After flashing, the router wouldn’t come back up.

I tried using the reset button trick, but couldn’t get it to flash. Now, the only lights which turn on when I boot are Power, eSATA, and one of the interface lights if I have a ethernet cable plugged in. I ordered the following cp2102 from Amazon: http://www.amazon.com/CP2102-Module-Ser … ds=cp2102. However, when I connect it via minicom, screen, or picocom (for example, using “pico com -b 115200 /dev/ttyUSB0”), I get no output on the terminal when booting, even though I’ve verified via dmesg that ttyUSB0 is the device getting assigned to the cp2102. I’ve tried wired two ways, one with the TX on the wrt to RXD on the cp2102, and RX on the wrt to TXD on cp2102, and vice versa (RX->RXD, TX->TXD). However, neither seems to work. Still, just power light, esata, and physical link light if ethernet cable is plugged in. Note, I do get activity on the physical link (flashing) if something is occurring over the wire, but that’s it.

I’m concerned I’ve corrupted the boot loader somehow. Again, reset button seems to do nothing, even after holding down for one minute. I’ve found the following instructions for fixing a corrupt boot loader (https://github.com/Chadster766/McWRT/wi … r-recovery) and would try them, but I’m not certain if, since mine is hardware version V2, if they are appropriate.

Here are pics of my setup:

https://drive.google.com/folderview?id= … sp=sharing

Can anyone help? I’m completely out of ideas. Should I try the corrupt boot loader recovery? Should I try something else?

Thanks!

(Last edited by redwolf on 12 Mar 2016, 15:35)

Looking forward to checking it out ---

Thanks,

David

You only need RX, TX, and possibly GND. 

Here is the cable I ordered and it works great on both the WRT1900AC v1 and WRT1200AC.
JBtek® WINDOWS 8 Supported Debug Cable for Raspberry Pi USB Programming USB to TTL Serial Cable

Even though the description says Windows 8, I have used it successfully with Windows 10 and OS X.

EDIT:  Another suggestion before you try flashing anything else get that console connection working.  It is a plethora of information when it starts spitting things out.

Hope that helps and good luck.

(Last edited by kirkgbr on 12 Mar 2016, 16:44)