Beta Asuswrt-Merlin 386.3 beta is now available

[dave14305]

For @shabbs's problem where all clients going through the Pi-hole will show up as his router, not the actual client, wouldn't the add-mac and add-subnet dnsmasq flags help there as well?

This is only helpful if dnsmasq is forwarding to the Pi-Hole (i.e. Pi-Hole IPs in WAN DNS). When DNSFilter is redirecting to the Pi-Hole, dnsmasq has no chance to add the mac and IP to the upstream request.

 

[zenmota]

The reason it used to work before is that your provider was pushing the option to redirect the gateway. With 386.3, now the "Redirect Internet" truly follows what the user desires, rather than being blindly overridden by the provider.

As for the invalid option, that option only works with Windows clients, not Linux routers.

As for the invalid option, I take it you mean the pull-filter ignore "block-outside-dns" I put in the VPN custom config? Are you saying I shouldn't have to put that in the config (since I guess the Ac86u is running Linux)? All I know is that if I don't put that in there it does not work, even with the Redirect Internet traffic through tunnel set to Yes. Thanks for explaining it though.

 

[RMerlin]

As for the invalid option, I take it you mean the pull-filter ignore "block-outside-dns" I put in the VPN custom config? Are you saying I shouldn't have to put that in the config (since I guess the Ac86u is running Linux)? All I know is that if I don't put that in there it does not work, even with the Redirect Internet traffic through tunnel set to Yes. Thanks for explaining it though.

No, I`m referring to the block-outside-dns parameter that they are pushing. Filtering it out will suppress the log warning.

 

[RMerlin]

with "all" over VPN had a dns leak.

Make sure you have DNS mode set to Exclusive, and that your clients are using your router as their DNS server.

 

[shabbs]

For @shabbs's problem where all clients going through the Pi-hole will show up as his router, not the actual client, wouldn't the add-mac and add-subnet dnsmasq flags help there as well?

FYI - update on what I've settled on, and hat tip to @dave14305 for the recommendation. I've gone ahead and put all my settings back to the way they were before (Quad9 on the WAN DNS, my dual Pi-hole IPs handed out via LAN DHCP) and then simply updated the desired Manually Assigned devices info to have their DNS set as the Router when they get their IP. That listing of devices is essentially my media streaming boxes (Nvidia Shield's, Apple TV 4K's etc...) so that I can easily toggle VPN on/off as needed for those. Outside of that need, I'd just run the ExpressVPN Client on my Windows device should the need arise.

My Pi-hole Query Logs are back to having individual devices showing up (~100 of them), the media boxes etc... will show up as the source being the router, which is a small price to pay for the sweet sweet convenience of being able to use @RMerlin 's VPN Director toggle.

Big thanks to everyone for their help and patience with this adventure today. Hopefully this was also educational to others looking to make use of the VPN Director functionality.

 

[dave14305]

and hat tip to @dave14305 for the recommendation

Yet you wear no hat anymore...

Glad it worked.

 

[shabbs]

Yet you wear no hat anymore...

Glad it worked.

LOL! Next avatar update will have a hat... oddly enough, wearing a hat right now. So... it's legit.

Did a quick test on my Nvidia Shield Pro in the basement with ExpressVPN set to Chicago and ran a DNS Leak Test - all good.

NOICE!

 

[albinoman887]

Wifi related. No idea what the message means, and outside of my control.

dang, okay thanks for replying. A follow up, Everything seems to still work fine even with those errors i just was snooping around when i came accross those errors,i started using the workaround where you blacklist the mac address of the offending device from 5ghtz and it gets rid of the log spam but i swear the connection is LESS stable. on 5ghtz i have the rolling error but connection seems fine, Since ive forced it to 2.4ghtz twice over the last week my nest mini has been disconnected from wifi when i went to use it. My initial thoughts were its cuz i still have smart connect on and so its trying to steer it to 5ghtz every once in awhile and it cant so then it drops. Just a guess. SO ...If you were me, how would you approach it? Would you just go the "it ain't broken dont fix it" approach or blacklist the mac from 5ghtz. its all google assistant devices.

PS: im sure you know this already but in my searching i found out that Broadcom/ASUS updated the wifi driver version for the 386 base from whatever was being used in 384 , idk if that gets the gears going in your head at all but figured id mention it. Also all google devices that i have that are doing this also overrride the DNS ip from the oines supplied by router DHCP... idk how that could have anything to do with it but figured id mention that...

 

[raion969]

is this normal to you ? Or are there any tips that i can improve it ?

 

[albinoman887]

Wifi related. No idea what the message means, and outside of my control.

sorry for the multiple posts but i didnt want this to get lost in the ether. I guess asus released a update for ax86u fw on like jun28th so i dirty flashed that back on top of my working 386.2_6 build and the errors are now gone (so far) this is the fw version i flashed...

FW_RT_AX86U_AX86S_300438644130

do they have their shirt up on github so i can look at the commit history?

 

[RMerlin]

do they have their shirt up on github so i can look at the commit history?

No, and GPL building has been temporarily suspended while they address issues with these tarballs.

 

[albinoman887]

No, and GPL building has been temporarily suspended while they address issues with these tarballs.

43684b0-ram/config_pcie_fdap_release Version: 17.10.121.37 (r789389) CRC: afffde35 Date: Fri 2021-06-18 17:53:58 CST Ucode Ver: 1570.159 FWID: 01-89d445e2

so my gut thought was that they updated the drivers but now i'm not so sure. the revision hash is the same as 386.2 but the build date is newer. could they have just dirty patched the source code but not bump the rev since its not from upstream?

theres nothing in merlin fw that adds more verbose logging or something by default is there? thats my only other unknown, is it just not logging the error cuz its actually fixed or cuz the log level is higher in stock?

 

[zenmota]

No, I`m referring to the block-outside-dns parameter that they are pushing. Filtering it out will suppress the log warning.

Thanks for the info. Whenever I enable the VPN this info appears in my log file. What is it and is it something to worry about?

Jul 5 18:14:27 ovpn-client1[3930]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Jul 5 18:14:27 ovpn-client1[3930]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 5 18:14:27 ovpn-client1[3930]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581'
Jul 5 18:14:27 ovpn-client1[3930]: WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]'
Jul 5 18:14:28 ovpn-client1[3930]: WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results
Jul 5 18:14:30 ovpn-client1[3930]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

Then when I exit the VPN I get this in log file. Anything to worry about?

Jul 5 18:17:46 ovpn-client1[3930]: event_wait : Interrupted system call (code=4)


Thanks again for the info and help....

 

[RMerlin]

Thanks for the info. Whenever I enable the VPN this info appears in my log file. What is it and is it something to worry about?

Jul 5 18:14:27 ovpn-client1[3930]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Jul 5 18:14:27 ovpn-client1[3930]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 5 18:14:27 ovpn-client1[3930]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1581'
Jul 5 18:14:27 ovpn-client1[3930]: WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]'
Jul 5 18:14:28 ovpn-client1[3930]: WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results
Jul 5 18:14:30 ovpn-client1[3930]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

Then when I exit the VPN I get this in log file. Anything to worry about?

Jul 5 18:17:46 ovpn-client1[3930]: event_wait : Interrupted system call (code=4)


Thanks again for the info and help....

Nothing abnormal there.

 

[RMerlin]

so my gut thought was that they updated the drivers but now i'm not so sure. the revision hash is the same as 386.2 but the build date is newer. could they have just dirty patched the source code but not bump the rev since its not from upstream?

Nothing dirty about it. They applied the Fragattack patch on top of the existing code.

386.3 driver is 100% identical to 386.2_6.

 

[FTC]

Hi, this is to report a successfull update from 386.2_4 (which had ran flawlessly for 53 days) to 386.3.b1 on my rt-ax88u server and also on the rt-ax56u that is configured as a wired imesh client. So far and after 15 hours all seems like running fine. My WAN connection is PPPoE over FTTH 1Gb/1Gb speeds, and I actively use DHCP w/around 30 dynamic clients and 10 static ones, and the following features : Aiprotection, Samba, Transmission, Diversion, media server, ipTV (Movistar profile), OpenVPN server, time scheduled Wifi (2.4Ghz band with 20mhz channel width and 5Ghz band with 80mhz width, AX mode deactivated), NO guest networks, NO ipV6.

Thanks again to Merlin & all of the involved team for another nice build!

 

[albinoman887]

Nothing dirty about it. They applied the Fragattack patch on top of the existing code.

386.3 driver is 100% identical to 386.2_6.

Ok. Is it identical to the one included in latest sto k fw released a few days ago ? I tried running md5sum on the kernel modules but every single one comes up as different and iirc the md5sum changes just from a quick recompile so that's out. I tried greping strings related to build dates and revision numbers but couldn't find anything useful

EDIT: i pulled the files and just did a basic size comparision and they are different. i would of checked in a hex editor but i had no internet at the time from messing with things lol i'll do that in the morning... is there a way to symlink the updated module to the destination of the existing?

 

[albinoman887]

Ok. Is it identical to the one included in latest sto k fw released a few days ago ? I tried running md5sum on the kernel modules but every single one comes up as different and iirc the md5sum changes just from a quick recompile so that's out. I tried greping strings related to build dates and revision numbers but couldn't find anything useful

EDIT: i pulled the files and just did a basic size comparision and they are different. i would of checked in a hex editor but i had no internet at the time from messing with things lol i'll do that in the morning... is there a way to symlink the updated module to the destination of the existing?

i just diffed it now and its completely different

 

[RMerlin]

Is it identical to the one included in latest sto k fw released a few days ago ? I

I don't know, the latest GPL code that I have is 386_42095. No idea what was changed since then.

is there a way to symlink the updated module to the destination of the existing?

No, as you most likely need the rest of the SDK updates as well.

 

[albinoman887]

I don't know, the latest GPL code that I have is 386_42095. No idea what was changed since then.


No, as you most likely need the rest of the SDK updates as well.

How good Are they at keeping their GPL releases in line with binary release ? Are they as bad as Samsung use to be with Android kernel source back in the hayday of custom roms or just slightly staggered . I was looking at your source and correct me if I'm wrong but it seems like All I'd have to do is overwrite some precompiled binaries and headers . I'd be more then willing to do that and submit a PR once the source is available or is there more to it then that ?