Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

Yea curious what the Wi-Fi tweak is but glad @davidc502 fixed it, seems like this would be obvious to include with OpenWrt so everyone can benefit, especially with this supposed 19.07 looming.

I believe it’s that AMSDU is disabled. @davidc502 is there any other tweaks you’ve made to improve performance?

Awesome, I have two of these devices but with OpenWRT :slight_smile:

2 Likes

@davidc502 it should be no surprise this vulnerability is still showing up, (oddly WRT32X isn't listed as a vulnerability which runs an old custom version of OpenWrt from the factory) because Linksys business practices should be illegal. Linksys has not provided any firmware update for their routers including the WRT3200ACM and WRT32X in 1 1/2 years. It's fair to say that their own flagship routers are abandoned at this point as if the company went out of business.

Running your builds of OpenWrt is really our only option, and it's a good one, but of course that has the issue of abandoned mwlwifi drivers.

Hi @davidc502
i deployed the release 4.19.52 as tester . Is there a significant change, meaning i need to deploy nowthe 4.19.53? thanks in advance

4.19.52 refers to the Linux kernel version. That version fixed the SACK issues that Netflix reported a week ago. The changelog for 4.19.53 is at
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.53
if you want to see it. I haven't noticed any one saying anything special about it. I just expect it was the current version at the time David did the build of OpenWRT.
FYI, 4.19.55 fixes an issue (with Steam) that 4.19.52 introduced, in case that is an issue with anyone here.

1 Like

What was the issue with steam on 4.19.52 Kernel?

Please see this report regarding problems (and a workaround) for some users with Steam because of the changes in 4.19.52
https://linuxreviews.org/The_Linux_Kernel_fix_for_SACK_vulnerabilities_broke_Steam

2 Likes

new here installed the latest build on my 1900ACS and 1900AC v2.

does the latest come with the latest wifi drivers/kernels or do I have to update those separately? I have noticed some lag in the luci interface when adjusting wifi settings on the 1900AC v2 vs on the ACS where the change in settings is almost instant.

Welcome to the forums, the Wifi driver is the latest in DC502 builds, as the Wireless driver is no longer maintained by Marvell anymore. So the last driver that was released is the last driver any of the WRT series is getting for openwrt.

2 Likes

Is their driver the same as the one in 18.06.2?
(Minus the AMSDU tweak)

Only one that will know that is @davidc502 as he is the one that builds the firmware.

Hi, I've just installed David's FW and have problems with PPPoE connection.
On regular Linksys FW (2.0.2.188405) I'm able to connect to my ISP (which is local provider that requires to authenticate via PPPoE - this is not a xDSL connection).
With when I've installed David or regular OpenWrt FW - with the same settings for connection I get:

Thu Jun 27 16:26:42 2019 daemon.err insmod: module is already loaded - slhc
Thu Jun 27 16:26:42 2019 daemon.err insmod: module is already loaded - ppp_generic
Thu Jun 27 16:26:42 2019 daemon.err insmod: module is already loaded - pppox
Thu Jun 27 16:26:42 2019 daemon.err insmod: module is already loaded - pppoe
Thu Jun 27 16:26:42 2019 daemon.info pppd[5963]: Plugin rp-pppoe.so loaded.
Thu Jun 27 16:26:42 2019 daemon.info pppd[5963]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Thu Jun 27 16:26:42 2019 daemon.notice pppd[5963]: pppd 2.4.7 started by root, uid 0
Thu Jun 27 16:26:43 2019 user.err wsdd2[5063]: error: wsdd-mcast-v4: wsd_send_soap_msg: send
Thu Jun 27 16:26:43 2019 daemon.info avahi-daemon[3980]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::26f5:a2ff:feba:e897.
Thu Jun 27 16:26:43 2019 daemon.info avahi-daemon[3980]: New relevant interface eth1.IPv6 for mDNS.
Thu Jun 27 16:26:43 2019 daemon.info avahi-daemon[3980]: Registering new address record for fe80::26f5:a2ff:feba:e897 on eth1.*.
Thu Jun 27 16:26:44 2019 user.info : dnscrypt-proxy - [fvz-anyone] does not support DNS Security Extensions
Thu Jun 27 16:26:44 2019 user.info : dnscrypt-proxy + Provider supposedly doesn't keep logs
Thu Jun 27 16:26:44 2019 daemon.notice dnscrypt-proxy[6120]: dnscrypt-proxy Starting dnscrypt-proxy 1.9.5
Thu Jun 27 16:26:44 2019 daemon.info dnscrypt-proxy[6120]: dnscrypt-proxy Generating a new session key pair
Thu Jun 27 16:26:44 2019 daemon.info dnscrypt-proxy[6120]: dnscrypt-proxy Done
Thu Jun 27 16:26:57 2019 daemon.warn pppd[5963]: Timeout waiting for PADO packets
Thu Jun 27 16:26:57 2019 daemon.err pppd[5963]: Unable to complete PPPoE Discovery

The problem is that my ISP uses ethernet cable to share Internet and the IPTV box, so each one is using only 4 wires.
Is there any solution that my PPPoE will work here?
Thank's for any help.

Is there a plan to upgrade to 4.19.55 or is that more on the OpenWrt team to upgrade to that version? Working Steam is fairly important to me.

OpenWrt team already updated to kernel 4.19.56 on master with the fixes. It just needs to be updated on Davidc502's build. Probably no reason to leave 4.14 anyway just yet, until 4.19 is thoroughly tested of course.

1 Like

:wave::wave::wave::wave::wave:

That's what I am doing as we speak. So far no issues at all.

Is anyone here using the 160Mhz channels by chance?

I've tried 160 a few times, but gave up. Because 160Mhz over-laps DFS on any channel chosen, usually within a few hours radar is detected and wifi goes down. After it goes down it just doesn't recover.

160MHz works fine here on a wrt32x, but I think mostly because mwlwifi wasn't designed to handle my device properly so it's running in some undefined state.

It picks up radar every now and then and drops back to 80MHz, and seems to change back to 160 about an hour or so later.

I'm a Newbie here, Thanks to David for all your hard work! I am using your latest build on a WRT3200. I wanted comment on the 160. I have tried the 160mhz , What i noticed, if I set it to a specific channel it would change channels automatically no matter what I set it for. And would drop when it changed channels. It usually comes back up within 5 minutes. I set it to to 80 and has been rock solid and didn't want to deal with the drops. It would be great if the 160mhz was usable. Because when It was working it's very Fast!! Again thanks David, enjoying tweaking your build and learning a lot!

1 Like