Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

The thought of doing a complete reset did cross my mind.... However I've been using these builds for a long time with no problems, so I'm really reluctant to hit a reset button at this point. Tough choice! I'd hate to be stuck on r11266 forever.

Hi All,

Sorry this is a bit OT, but maybe someone here can point me in the right direction. I have couple of commercial wifi cameras (I was using motioneye previously), and I'd like to create a separate AP for them and not allow them to access my LAN at all. They could get out to the internet to 'call home', and upload their recordings, but that would be it. Could anyone point me at a good article for how to do this? I've read some about configuring VLANs, but what about the wifi part?

Thanks again for all the great work.

Hmm...
When using https with uhttpd/luci the webinterface is slow.
But when using own certificates and the certificates got installed on the client machine
(so the browser doesn't throw a certificate error), luci web interface access is way faster.

And for last releases in trunk (not related to david's builds), IPv6 prefix delegation is again not working for me. After reboot I have to restart wan and wan6 to get the prefix delegation working.
Only restarting wan6 doesn't work, doesn't even get a IPv6 address.

Maybe something to do with flowoffload? I'm running master/trunk as well but the only switch I flipped is changing target/linux/mvebu/Makefile to KERNEL_PATCHVER:=4.14.

I still think kernel 4.19 is not fully stable yet. I do know there are fixes to mvneta, though I ended up just backporting some of them to 4.14.

mvneta_backport_patches_4.14.zip
https://www19.zippyshare.com/v/0T97UzkT/file.html

I've got an OpenVPN tunnel setup to a provider, and want all internet traffic for all devices to go over this tunnel except for my Roku (video streaming services often won't work properly over the VPN). It looks like mwan3 is what I need to do this, but when I try to install, I get:

root@LEDE:/etc/openvpn# opkg install mwan3 luci-app-mwan3
Installing mwan3 (2.8.0-2) to root...
Downloading https://dc502wrt.org/snapshots/r11398/packages/arm_cortex-a9_vfpv3/packages/mwan3_2.8.0-2_all.ipk
Installing ip-tiny (5.3.0-1) to root...
Downloading https://dc502wrt.org/snapshots/r11398/packages/arm_cortex-a9_vfpv3/base/ip-tiny_5.3.0-1_arm_cortex-a9_vfpv3.ipk
Installing luci-app-mwan3 (git-19.307.79135-4e9f2d3-1) to root...
Downloading https://dc502wrt.org/snapshots/r11398/packages/arm_cortex-a9_vfpv3/luci/luci-app-mwan3_git-19.307.79135-4e9f2d3-1_all.ipk
Configuring ip-tiny.
Configuring mwan3.
uci: Entry not found
uci: Entry not found
grep: /var/etc/miniupnpd.conf: No such file or directory
uci: Entry not found
uci: Entry not found
grep: /var/etc/miniupnpd.conf: No such file or directory
Configuring luci-app-mwan3.
root@LEDE:/etc/openvpn#  120948  WARN : Service section disabled! - TERMINATE

I'm unsure how to resolve this, can someone point me in the right direction?

Thanks!

Maybe this option, mwan3 is is more for load balance/failover if you have multiple pipes.

1 Like

That looks promising, thanks!

Edit: vpn-policy-routing isn't in the official repo yet... but vpnbypass is, also by strangi, and I think it will do what I want also.

Edit2: vpnbypass did the trick with no hassle or fuss at all :slight_smile:

I'm also seeing weird 5ghz performance differences between stock OpenWrt (18.06.4) and the latest David build on a 3200acm. With stock I get occasional dropouts, but a consistent router ping of around 6ms with minimal variance, but with the latest David build, pings are averaging around 200ms with significant variance.

As far as I can tell the configurations are identical (channels etc). If the wireless drivers are the same it must be something else - any thoughts on how to diagnose possible causes @davidc502?

I had this issue as well after an upgrade - think it was due to the fact I had DNSSEC enabled and was using dnsmasq-full (which is downgraded to normal dnsmasq during the upgrade). Turning off DNSSEC while I installed dnsmasq-full solved the issue for me.

Yeah, same everything wifi, so no difference there. Even though 18.06.4 is much older the drivers haven't changed much in a year. Hard to say, but are you having the same issue across the board or with 1 device? For starters you might "forget" everything about that wifi SID and re-enter the PSK, and see if that changes anything.

hi Mr. David again
Today i fixed DNSMASQ problem by remove Dnsmasq and reinstall dnsmasq full

please add dnsmasq full instead of standard in your next build

Thank You Mr. David For your very best work
Regards,
Tarek Herik

4 Likes

Dear Dave,
Hello and I hope that you are doing well. I have not written you in a while and in the interim I have been enjoying your excellent Builds as always. Now - I have a question / request for you. I run Stubby ( DNS OVER TLS ) along with Unbound. Your recent Builds have OpenSSL 1.1.1d 10 Sep 2019 and since OpenSSL 1.1.1 there is included support for TLSv1.3 - with that being said - Is it possible to configure your next Build so that TLSv1.3 is enabled in the kernel or whatever needs to be done to put TLSv1.3 in effect. See here : https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ and here : https://wiki.openssl.org/index.php/TLS1.3 - no rush or pressure - it is just that I am trying to be as safe and secure as possible.
Stubby supports TLSv1.3 as do many of the DNS PRIVACY SERVERS.

The most salient point from these articles is this point of reference
 " In order to compile OpenSSL with TLSv1.3 support 
you must use the “enable-tls1_3” option to “config” or “Configure”

Anyway - thanks for all you do for all of us in what I fondly refer to as " The Community "
Peace and I am OUT !

2 Likes

I had these drivers recommended to me in a separate thread for my WRT32X:

I was experiencing an issue with stock 18.06.4 with my 2.4GHz dying and requiring a restart after a couple weeks and someone recommended I tried this release.

Is anyone here up to date with the current state of the drivers, I was understanding not much has changed - what would be different/fixed if I were to use this in place of what's running in stock? In addition, is the Davidc502 builds using these? I guess I'm mostly curious with what's different/fixed comparing Stock OpenWRT 18.06.4, Latest Davidc502, and these Drivers I linked above?

Those packages are built from the same sources as @davidc502's builds and latest official releases, too.

Hmm, so possibly misinformation or someone misinformed recommending those to me, if stock 18.06.4 and Davidc502 builds are no different than those drivers?

Thank you for the reply!

When these drivers were still being developed, stable releases (and even snapshots) where usually not up to date with development, and using my packages or @davidc502's builds would make a difference.

There have literately been no commits to mwlwifi in 8-9 months, and no useful commits in a year. The open source project has been abandoned by Marvel. In other words, Wi-Fi is not going to improve for these devices moving forward.

Right, now this is a bit unrelated and offtopic from the thread (although semi-related due to Driver related talks and what it's using) but I had opened up a threat on the forums here: WRT32X with 18.06.4 - 2.4GHz dies after a few weeks

And was told to try these drivers, but it was my understanding that they haven't really changed so I was curious and what may or may not be different between those drivers, Davidc502's builds, as well as Stock OpenWRT.

Now based on what @eduperez said above, it seems possible that Stock OpenWRT 18.06.4 may not be using these latest drivers or in the past haven't always been fully up-to-date, although that doesn't say for sure if 18.06.4 is using the latest.

The master gitlog version, the 19.x version, the 18,x version; check that against what you see in the image you are running.

Don't run 18.06 it's just too old. At this point if you are going to run an official OpenWrt then run 19.07 RC1: OpenWrt 19.07.0 first release candidate

Davidc502 is built off Master which is more update to date but potentially less stable.