Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

In the .toml configuration, you can choose one service, like cloudflare which is 1.1.1.1 and 1.0.0.1.

In tcpdump just do something like this.. "tcpdump -nni eth0 host 1.1.1.1 and 1.0.0.1"

Do some manual nslookups from a pc, and see if you get any hits. Yes, it isn't just one IP but you get the idea.

This is actually shocking Linksys updated the firmware for the first time in 2 years. Newer wifi drivers and firmware, security fixes certainly about time. I hope they do one for the WRT32X too so I can test it out. Still running davidc502 OpenWrt as my daily though.

1 Like

The new wifi firmware seems to work with OpenWrt so this could be good news for us... If it works with the WRT3200ACM so it will also work with the WRT32X @OpenWrt. I could never switch to an official Linksys FW after using david's builds for such a long time but any change regarding the Wifi is welcome for sure! :slight_smile:

3 Likes

This could actually be huge for us. Someone on that mwlwifi link has already applied it to OpenWrt and said he got wifi performance and stability improvements on the WRT32X. BrainSlayer said he added it to DD-WRT too. Now if we can get someone to officially integrate it into OpenWrt...

2 Likes

Doesn't take much to extract the BLOB, put it onto your device, and set up a soft link so that you can switch between what is there now and the latest OEM firmware.

But it doesn't seem to work flawless out of the box every time... For example @hnyman had some trouble with the new firmware: New official firmware wrt3200 acm
Anyway I can't wait to try the new wifi firmware with a build from davidc! :slight_smile:

2 Likes

Yes, working with a black box is problematic at best, ergo using the above method so you can back out of the change with little hassle. Not sure why you would want to see the firmware baked into an image without an updated driver, especially if there may be a problem working with the current OpenWrt components. I would guess this will not find its way into the upstream mwlwifi repository, and if not there even less likely in OpenWrt; and yess I saw the comment from kaloz.

Yes, I'm waiting to hear more information about what the testers find before integrating it into the build.

Thanks for your patience.

EDIT * Did someone make the firmware they extracted from OEM available on a website? I would like to drop it on a current working build and do some testing myself.

1 Like

Yes, in the mwlwifi issue 378 there is a link to a git

The link is to a patch. My make will have different values. I just need a link to the firmware, and I can calculate values for this build.

Just building my internal build now with the patch file, will let you know results. I have DM'd you @davidc502.

1 Like

Yes, but if you go the the git as given in the patch you can grab the firmware.

Just as a datapoint, I have been playing with this off and on for the last 8 or 9 days, at least in my environs there is nothing to see here.

I didn't think so, but I usually just give these things time to work themselves out.

Edit Just did 10 speed tests, dropped in the new firmware (reboot), and did 10 more.. Zero speed difference on the download, and upload speeds slower. This isn't definitive as more testing would need to be done.
Really, I'm just interested in security updates.

3 Likes

Could stability improvement be possible? The person that tested his WRT32X on the mwlwifi thread showed he was getting 1Gbit on 5GHz/160MHz consistently with more stability which is OEM firmware speeds.

PR for the new firmware submitted. I'm on the side of getting it tested by a wider audience and just do a simple git revert if it negatively affects performance, common use-cases, or causes configuration errors.

It's best to check:

  • Throughput,
  • Latency,
  • No. of Interrupts by mwlwifi by running cat /proc/interrupts,
  • SIRQ values from top -d 1, Configuration (e.g. wifi up && wifi down),
  • Effects on WiFi-N 20/40 MHz or Wifi-AC 20/40/80/160/80+80
  • AMSDU and if enabling/disabling still affects latency
  • Changes to android or ESP8266 client behaviour
2 Likes

I generally take what "individual" people say, when it comes to increased speeds, with a grain of salt. You should take my results with a grain of salt as well. We should all wait until a larger body of people have tested to get an over-all Idea on performance.

As for stability, there have been 2 or 3 people I recall talking about it. So far, this looks like a positive, but will will continue to monitor on my end.

1 Like

Currently running on channel 108 and 160hz which seems stable thus far. Speed boost as discribed I haven't got but the connection is stable thus far. Will do latency tests later.

Edit: I just had to jinx it I am on channel 36 10 seconds after posting the reply before edit lol

1 Like

Yea, the good old radar detection. The thing is once the driver switches you off a DSF channel it will never switch you back to one. It's kinda broken on the WRT3200/32x (at least with OpenWrt). For example my DIR860L-B1 stays on channel 100 all day long without any problems.
Imho things like DFS aren't truly open source ready as it doesn't function properly and It's a shame that Linksys kinda abdoned the mwlwifi project on github and don't work on these problems. But who knows maybe there will be some development in the near future...

Is port forwarding working now? Would like to upgrade to test to see if I still see "Connection reset by peer" for my WRT1900ACSV1, as previously reported, and perform a tcpdump, but this is a deal-breaker for me.

I'm getting reports from several people saying it is working though I personally haven't been able to. I figure it must be the way my router is configured or just plain ole "operator error" on my side :slight_smile: