OpenWrt Forum Archive

Topic: davidc502 1900ac 3200acm builds

The content of this topic has been archived between 26 Feb 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

So hey guys, anyone have a Google Home running on this firmware?

I bought one at a black friday sale (50% off, w00t) but the thing refused to connect through wifi. Just said it couldn't connect. Had to revert back to my ISP provided router.

I did some google searches, but it really doesn't tell much aside from how it's incompatible with some routers.

farchord wrote:

So hey guys, anyone have a Google Home running on this firmware?

I bought one at a black friday sale (50% off, w00t) but the thing refused to connect through wifi. Just said it couldn't connect. Had to revert back to my ISP provided router.

I did some google searches, but it really doesn't tell much aside from how it's incompatible with some routers.

You've tried to have no password on your wifi?

farchord wrote:

So hey guys, anyone have a Google Home running on this firmware?

I bought one at a black friday sale (50% off, w00t) but the thing refused to connect through wifi. Just said it couldn't connect. Had to revert back to my ISP provided router.

I did some google searches, but it really doesn't tell much aside from how it's incompatible with some routers.

I actually just set up a Google Home Mini. During the setup it told me that the Home connected to the network successfully, but my phone could not connect to it over the network. I left the setup and a few minutes later the Home was connected and working just fine.

davidc502 wrote:

For 3200acm owners.  If your router needs to be up 24/7 and you don't want to test the latest firmware, feel free to download and install firmware version 9.3.0.7.

https://github.com/kaloz/mwlwifi/blob/2 … 8W8964.bin

All you have to do is copy 88W8964.bin over to /lib/firmware/mwlwifi/. Don't forget to rename the original to .old or something that makes sense to you.

Best Regards,

I have been running both 9.3.0.8 and 9.3.1.2, on a WRT3200ACM with LEDE 17.01.4, and it has been running for days without any trouble. However, by the comments here, and the bug reports at kaloz's repo, looks like I am very lucky.

I noticed this Pinned news from @davidc502:
*SECURITY PATCHES* for the wpa2 WIFI vulnerability are included in r5389. These patches close the wpa2 vulnerability that could allow hackers to successfully perform the "KRACK attack".

I'm curious, wasn't this previously addressed on r5113?  I remember seeing a previous pinned note about it but wasn't sure if this means that r5113 has a different issue?

I ask because I'm running a 1900acv1 with the REBOOTING builds.

eduperez wrote:
davidc502 wrote:

For 3200acm owners.  If your router needs to be up 24/7 and you don't want to test the latest firmware, feel free to download and install firmware version 9.3.0.7.

https://github.com/kaloz/mwlwifi/blob/2 … 8W8964.bin

All you have to do is copy 88W8964.bin over to /lib/firmware/mwlwifi/. Don't forget to rename the original to .old or something that makes sense to you.

Best Regards,

I have been running both 9.3.0.8 and 9.3.1.2, on a WRT3200ACM with LEDE 17.01.4, and it has been running for days without any trouble. However, by the comments here, and the bug reports at kaloz's repo, looks like I am very lucky.

you are.
I for one have experienced so much instability, i have just shut off my wireless 5ghz on the WRT3200 and am using my WRT1900acv2 as an AP. Running Davids image flawlessly other then that. Couldn't be happier.

(Last edited by mojolacerator on 24 Nov 2017, 20:14)

bcroteau wrote:

I noticed this Pinned news from @davidc502:
*SECURITY PATCHES* for the wpa2 WIFI vulnerability are included in r5389. These patches close the wpa2 vulnerability that could allow hackers to successfully perform the "KRACK attack".

I'm curious, wasn't this previously addressed on r5113?  I remember seeing a previous pinned note about it but wasn't sure if this means that r5113 has a different issue?

I ask because I'm running a 1900acv1 with the REBOOTING builds.

Yes, you are good with r5113.

davidc502 wrote:

For 3200acm owners.  If your router needs to be up 24/7 and you don't want to test the latest firmware, feel free to download and install firmware version 9.3.0.7.

https://github.com/kaloz/mwlwifi/blob/2 … 8W8964.bin

All you have to do is copy 88W8964.bin over to /lib/firmware/mwlwifi/. Don't forget to rename the original to .old or something that makes sense to you.

Best Regards,

Apologize if I sounded disrespectful
But not quite the opposite
Very appreciate and even admire people like you
I am working with your firmware from version 29.07.17
And installs every new version that comes out without hesitation
Keep up your work faithfully
With lots of appreciation
Waiting for the next firmware

thekodiwiz wrote:
davidc502 wrote:

For 3200acm owners.  If your router needs to be up 24/7 and you don't want to test the latest firmware, feel free to download and install firmware version 9.3.0.7.

https://github.com/kaloz/mwlwifi/blob/2 … 8W8964.bin

All you have to do is copy 88W8964.bin over to /lib/firmware/mwlwifi/. Don't forget to rename the original to .old or something that makes sense to you.

Best Regards,

Apologize if I sounded disrespectful
But not quite the opposite
Very appreciate and even admire people like you
I am working with your firmware from version 29.07.17
And installs every new version that comes out without hesitation
Keep up your work faithfully
With lots of appreciation
Waiting for the next firmware

No, not at all.  I have a wife that works from home, and has to have internet, so I made sure to swap the firmware out first thing.  So, I completely understand the need to have a reliable router.

In fact on this build I'm working on, I'm just going to put in the other firmware, and if someone wants to test the new firmware they can swap it out.

Hey guys.
So i've just spend the evenning trying to understand why they advise the device to be open source having proprietary wifi drivers.
I would like to have at least some documentation so we can do a GitHub project for a good and reliable driver.
I did contact marvell and linksys, one at the time.
I would really believe that if a lot of their costumers complain that they're not happy with this situation they will do something about it. Its been years since the product is out and the wifi never worked good. start making some noise, it will not hurt.
I know that there's a guy responsible for the project hired by linksys or whatever in github, but it's not enought, at least some documentation so we can make this device reliable and work along with him, or make another project.
Mail to marvell:
"So, as you might be aware, linksys WRT3200ACM uses your 88W8964 chipset, which is a good thing. But Linksys advertise that the WRT3200ACM is opensource with all the big letters everywhere they sell it. Although i can't seem to find firmware source for the 88W8964 to build a good openWRT driver(the one active at the moment doesn't work and crashes all the time).
I'm not sure what license is your firmware under, but if linksys is selling this product embedded in their routers i hope it is really opensource.
Would you mind sendind the sources file to me?
If the source files arent possible, i would like at least the documentation of the firmware so i'm able to at least make the driver work in opensource software. If none of the above is possible i would like to know why. Thanks."
Btw the 2.4Ghz should give 600mbs, why am i only getting 50mbs out of it?
Is there a limitation somwhere in the software?

(Last edited by pirretub on 25 Nov 2017, 01:09)

pirretub wrote:

opensource with all the big letters everywhere they sell it

Linksys did this with the 1900ACS as well. My attempt at voicing was to call and complain, but it was clear I was speaking with someone at an offshore call center who wasn't equipped to document the point of my call. I think it was exceedingly misleading to tout 'open source ready' when the wi-fi drivers used in open source firmware were not fully functional until quite a while after the router was released. If nothing else, those who are frustrated by it should remember this next time they are looking to upgrade I suppose, as our wallets are probably the most impactful noise we can make.

Hi will there be a new build with kernel 4.9.65?

tapper wrote:

Hi will there be a new build with kernel 4.9.65?

The build finished yesterday afternoon, and I just uploaded to the server.

@starcms

Please test to see if AMSDU is disabled now on the 1200.

David,

So this build is with  9.3.0.7 firmware and should be stable without reboots?

davidc502 wrote:
tapper wrote:

Hi will there be a new build with kernel 4.9.65?

The build finished yesterday afternoon, and I just uploaded to the server.

@starcms

Please test to see if AMSDU is disabled now on the 1200.

vadimtk wrote:

David,

So this build is with  9.3.0.7 firmware and should be stable without reboots?

davidc502 wrote:
tapper wrote:

Hi will there be a new build with kernel 4.9.65?

The build finished yesterday afternoon, and I just uploaded to the server.

@starcms

Please test to see if AMSDU is disabled now on the 1200.

Yes, and as we like to say..... "should" smile

David,

Ok, I want to make sure clarify.

My current partition (stable) is (2) and alternative partition (crashing) (1)

I want to flash from the current partition, but I want to keep it in case I need to go back...
If I flash from the current, will be it be automatically flashed into alternative partition ?

davidc502 wrote:
vadimtk wrote:

David,

So this build is with  9.3.0.7 firmware and should be stable without reboots?

davidc502 wrote:

The build finished yesterday afternoon, and I just uploaded to the server.

@starcms

Please test to see if AMSDU is disabled now on the 1200.

Yes, and as we like to say..... "should" smile

vadimtk wrote:

David,

Ok, I want to make sure clarify.

My current partition (stable) is (2) and alternative partition (crashing) (1)

I want to flash from the current partition, but I want to keep it in case I need to go back...
If I flash from the current, will be it be automatically flashed into alternative partition ?

davidc502 wrote:
vadimtk wrote:

David,

So this build is with  9.3.0.7 firmware and should be stable without reboots?

Yes, and as we like to say..... "should" smile

correct, it will flash the alternative partition, so you can go back to the primary partition at any time.

davidc502 wrote:

The build finished yesterday afternoon, and I just uploaded to the server.

Thanks David wink

I am going nuts here with the connectivity issues I have with the router. Nothing worked so far I have tried. I actually now have found maybe a clue, but I am not really sure what this means. When I do this on the router:

ping -s 1480 8.8.8.8 -I tun0

then after some short random time, the ping command just stops. No response anymore and all connections break down on all clients. I thought maybe this could be related to the option 'Enable SYN-flood protection' which was enabled by default, but deactivating it didnt change anything actually. A normal small package ping wouldnt cause this issue (ping 8.8.8.8 -I tun0).

(Last edited by makedir on 25 Nov 2017, 22:02)

makedir wrote:

I am going nuts here with the connectivity issues I have with the router. Nothing worked so far I have tried. I actually now have found maybe a clue, but I am not really sure what this means. When I do this on the router:

ping -s 1480 8.8.8.8 -I tun0

then after some short random time, the ping command just stops. No response anymore and all connections break down on all clients. I thought maybe this could be related to the option 'Enable SYN-flood protection' which was enabled by default, but deactivating it didnt change anything actually. A normal small package ping wouldnt cause this issue (ping 8.8.8.8 -I tun0).

Had the same issues with VPN. Iptables mods are messing things arround.
There are 3 iptables packages, just leave the stock iptables and it will work.
I've tried everything, but even well configured it wouldn't go, after i've only left iptables it did work 5*
Btw just uninstall the packages before configuring anything.
So uninstall those two iptables mods, the tqops or something and the other one. Leave the stock one and configure the firewall proprely. Make a iptables script so it wount leak if the tun0 is down. NordVPN has a good explaination on their site, with leak protections and everything and it will work with any OVPN.
Add "log /tmp/ovpn.log" to your config file and just cat it to debug aftewards. You'll be able to know, TLS handshake usually fails with the Iptables mods on there. Not sure why.  Other than tha some options don't work, like block-outside-dns and a lot of people try it in OpenWRT lol.
Btw feel free to add a line to the config:"engine cryptodev" you'll be happy with it wink
Good luck smile

(Last edited by pirretub on 25 Nov 2017, 22:31)

anymouse617 wrote:
pirretub wrote:

opensource with all the big letters everywhere they sell it

Linksys did this with the 1900ACS as well. My attempt at voicing was to call and complain, but it was clear I was speaking with someone at an offshore call center who wasn't equipped to document the point of my call. I think it was exceedingly misleading to tout 'open source ready' when the wi-fi drivers used in open source firmware were not fully functional until quite a while after the router was released. If nothing else, those who are frustrated by it should remember this next time they are looking to upgrade I suppose, as our wallets are probably the most impactful noise we can make.

this has been going on since they released the wrt1900acv1, 3.5 years ago.
done with stinksys routers.

pirretub wrote:
makedir wrote:

I am going nuts here with the connectivity issues I have with the router. Nothing worked so far I have tried. I actually now have found maybe a clue, but I am not really sure what this means. When I do this on the router:

ping -s 1480 8.8.8.8 -I tun0

then after some short random time, the ping command just stops. No response anymore and all connections break down on all clients. I thought maybe this could be related to the option 'Enable SYN-flood protection' which was enabled by default, but deactivating it didnt change anything actually. A normal small package ping wouldnt cause this issue (ping 8.8.8.8 -I tun0).

Had the same issues with VPN. Iptables mods are messing things arround.
There are 3 iptables packages, just leave the stock iptables and it will work.
I've tried everything, but even well configured it wouldn't go, after i've only left iptables it did work 5*
Btw just uninstall the packages before configuring anything.
So uninstall those two iptables mods, the tqops or something and the other one. Leave the stock one and configure the firewall proprely. Make a iptables script so it wount leak if the tun0 is down. NordVPN has a good explaination on their site, with leak protections and everything and it will work with any OVPN.
Add "log /tmp/ovpn.log" to your config file and just cat it to debug aftewards. You'll be able to know, TLS handshake usually fails with the Iptables mods on there. Not sure why.  Other than tha some options don't work, like block-outside-dns and a lot of people try it in OpenWRT lol.
Btw feel free to add a line to the config:"engine cryptodev" you'll be happy with it wink
Good luck smile

1. I tried engine cryptodev before, it does nothing, the badnwidth is about 70mbit/s with or without it
2. I need iptables-mod-ipopt, because I am using mangle to filter stuff, and it worked before in the past, also kmod-ipt-conntrack-extra for owner flag.
3. to stop vpn leaks you just have to add a lan -> wan reject rule in Luci in the end thats all.
4. nope. I have no problems no TLS handshake issues, no disconnects. So this problem totally is not related to your problem. I am running OpenVPN in a screen window, and I can easily monitor the output there. The VPN connection never drops nor reconnects or has TLS handshake issues.

Is there a way to test to deactivate the modules without removing them first?

(Last edited by makedir on 26 Nov 2017, 01:10)

makedir wrote:
pirretub wrote:
makedir wrote:

I am going nuts here with the connectivity issues I have with the router. Nothing worked so far I have tried. I actually now have found maybe a clue, but I am not really sure what this means. When I do this on the router:

ping -s 1480 8.8.8.8 -I tun0

then after some short random time, the ping command just stops. No response anymore and all connections break down on all clients. I thought maybe this could be related to the option 'Enable SYN-flood protection' which was enabled by default, but deactivating it didnt change anything actually. A normal small package ping wouldnt cause this issue (ping 8.8.8.8 -I tun0).

Had the same issues with VPN. Iptables mods are messing things arround.
There are 3 iptables packages, just leave the stock iptables and it will work.
I've tried everything, but even well configured it wouldn't go, after i've only left iptables it did work 5*
Btw just uninstall the packages before configuring anything.
So uninstall those two iptables mods, the tqops or something and the other one. Leave the stock one and configure the firewall proprely. Make a iptables script so it wount leak if the tun0 is down. NordVPN has a good explaination on their site, with leak protections and everything and it will work with any OVPN.
Add "log /tmp/ovpn.log" to your config file and just cat it to debug aftewards. You'll be able to know, TLS handshake usually fails with the Iptables mods on there. Not sure why.  Other than tha some options don't work, like block-outside-dns and a lot of people try it in OpenWRT lol.
Btw feel free to add a line to the config:"engine cryptodev" you'll be happy with it wink
Good luck smile

1. I tried engine cryptodev before, it does nothing, the badnwidth is about 70mbit/s with or without it
2. I need iptables-mod-ipopt, because I am using mangle to filter stuff, and it worked before in the past, also kmod-ipt-conntrack-extra for owner flag.
3. to stop vpn leaks you just have to add a lan -> wan reject rule in Luci in the end thats all.
4. nope. I have no problems no TLS handshake issues, no disconnects. So this problem totally is not related to your problem. I am running OpenVPN in a screen window, and I can easily monitor the output there. The VPN connection never drops nor reconnects or has TLS handshake issues.

Is there a way to test to deactivate the modules without removing them first?

1-Sure Bandwith will be the same as the dual core cpu ensures it, but the load on the cpu is lower. At least in mine.
2-Well if you need them give them a try one at the time.
3-You're totally right.
4-then its not indeed what i understood.
Not sure if there is a init.d for stop, just check for it. If there isnt, i would clean the image(the two extra modules mentioned in 2)and configure the vpn without the iptables extras make sure that was working, then backup those configs. After that if you want to test with the modules everything in place, just load the backup onto a new flashed complete image with all the modules. Otherwise you might just do the same and get the same .ipks somewhere and install them aftewards one at the time, so you can debug the problem.It might not even be the modules(but i would start here personally), route configs might be messed up or something, i guess you'll have to try it and check for the problem or provide additional info so somebody can help.
Hope it helps something.

(Last edited by pirretub on 26 Nov 2017, 01:39)

No. The 70mbit is already the cap, by the CPU. OpenVPN has cpu0 or 1 capped at 100% at around 70mbit/s, regardless if you put cryptodev in the config or not on this model. I am wondering whats causing this behavior: https://i.imgur.com/SIy1SOH.png not sure if it is related, but it looks like it. The connection with the VPN server stays, but the routing doesnt work anymore (randomly) and leads to timeout on the clients. I have looked on the OpenVPN output with a debug value of 7. It reads/writes to the socket, but it's somehow blocked by the router so the problem seems to be with the NAT (iptables) of this rom. Already open connections also will work on the clients, but no new connections anymore after this happens. Eventually it will timeout though and work again, but this seems to be the TCP timeout value.

(Last edited by makedir on 26 Nov 2017, 01:42)

makedir wrote:

No. The 70mbit is already the cap, by the CPU. OpenVPN has cpu0 or 1 capped at 100% at around 70mbit/s, regardless if you put cryptodev in the config or not on this model. I am wondering whats causing this behavior: https://i.imgur.com/SIy1SOH.png not sure if it is related, but it looks like it. The connection with the VPN server stays, but the routing doesnt work anymore (randomly) and leads to timeout on the clients. I have looked on the OpenVPN output with a debug value of 7. It reads/writes to the socket, but it's somehow blocked by the router so the problem seems to be with the NAT (iptables) of this rom. Already open connections also will work on the clients, but no new connections anymore after this happens. Eventually it will timeout though and work again, but this seems to be the TCP timeout value.

Sorry i need to understand this now, first off, are we talking about a WRT3200ACM here or which do you have? I migh have missed that.
What are you saying? That one of the CPU's is always at 100 and the other is whatever is needed to top the connection?
cipher AES-256-CBC, auth SHA512, using cryptodev, without it goes up, but not by much - I'm topping my connection at 93mbit/s (and my connection is 100) and not even using 30%(at least that's what "top" says, 27percent load at full blast) of the CPU here... Without cryptodev i do get 7percent difference. Unless i'm not getting some information. I'm not sure but that's what i'm getting here.
Yes, as i refered i did have exactly the same problem untill i removed those modules and made the iptables rules...
Not sure why, but removing it helped.
Just cat the firewall file and let me take a look maybe i can help? Also cat rt_tables or route and maybe trace a packet? Also cat the OVPN log. First we gotta check that the router traffic is going really throught the VPN. Then think about the rules for the clients to use it over lan.
Maybe this is a little offtopic here in the builds thread, if that's the case i'm sorry.
Thanks

(Last edited by pirretub on 26 Nov 2017, 02:19)