[Preview] Asuswrt-Merlin 384.3 pre-release test builds

[Wolfschiesst]

Here's the link to Asus' latest bios 382-Update for the RT-AC87U for Bugfix-Information (incl. Krack-Fix,...) dated from January 25th:
https://www.asus.com/de/Networking/RTAC87U/HelpDesk_BIOS/

Looks like 384 is far away as expected.

 

[Treadler]

I suppose it’s a good thing you are getting some malicious sites trapped by AI Protection.
I’ve verified my counts haven’t changed since I updated firmwares & no trend micro test links throw up a warning page so I’m assuming AI Protection simply isn’t working for me at the moment. Not sure what else to try other than a clean wipe. I’ve turned AI Protection on off multiple times, rebooted ( via router’s GUI ).

Im not currently using Merlin, am seeing 15 - 20 hits a day in 2 way IPS.
Just lucky I guess. :-(

 

[hoang51]

I uploaded a new RT-AC56U test builds. This one contains CTF/PPPoE as well as multicast fixes from 382_50010. Please give it a shot.

If you still get non-working QoS with it, make sure you reconfigure your rules. My RT-AC56U reproduced the issue until I reconfigured my preferred priorities, then rebooted. After that rules were always properly configured (tested both DHCP and PPPoE).

Thanks. I flashed it the first time over Wi-Fi (RT-AC68U [wireless router] -> RT-AC56U [repeater]) and it semi-bricked the router. Never happened with all the flashing done over Wi-Fi with both routers. I powered down the RT-AC56U and powered it back up (via power button in the back of the router). It booted up just fine and it was still on the previous firmware (382.2 beta 3). I rebooted the router once more and then flashed the firmware again by the same method - over Wi-Fi. Success. Now both RT-AC68U and RT-AC56U are running the same firmware revision: 384.3 alpha 2.

Potential bug: One thing I noticed is with my configuration (RT-AC68U [wireless router] -> RT-AC56U [repeater]), the RT-AC68U shows the wrong IP address (i.e., 192.168.1.66) of RT-AC56U under Network Map->Clients->View List. If I'm not mistaken, it should show 192.168.1.2 (statically assigned to RT-AC56U) instead of one of the clients on the RT-AC56U (i.e., 192.168.1.66).

 

[Jack Yaz]

Thanks. I flashed it the first time over Wi-Fi (RT-AC68U [wireless router] -> RT-AC56U [repeater]) and it semi-bricked the router. Never happened with all the flashing done over Wi-Fi with both routers. I powered down the RT-AC56U and powered it back up (via power button in the back of the router). It booted up just fine and it was still on the previous firmware (382.2 beta 3). I rebooted the router once more and then flashed the firmware again by the same method - over Wi-Fi. Success. Now both RT-AC68U and RT-AC56U are running the same firmware revision: 384.3 alpha 2.

Potential bug: One thing I noticed is with my configuration (RT-AC68U [wireless router] -> RT-AC56U [repeater]), the RT-AC68U shows the wrong IP address (i.e., 192.168.1.66) of RT-AC56U under Network Map->Clients->View List. If I'm not mistaken, it should show 192.168.1.2 (statically assigned to RT-AC56U) instead of one of the clients on the RT-AC56U (i.e., 192.168.1.66).

Networkmap is now closed source so Asus have to patch

 

[rdallen]

I've been testing the latest alpha with an RT-AC68U. One issue I've found is that the policy based routing doesn't work for VPN. I specify some subnets to send data through the VPN. However this seems to be ignored: all traffic seems to be going through the standard WAN interface.

Edit: after deleting and re-entering all settings, it seems to be working.

 

[Gingernut]

Does anybody have an idea as to why, since yesterday, my router log is plagued with this:

Jan 31 14:05:46 kernel: DROP IN=br1 OUT= MAC=b0:6e:bf:63:a6:e8:00:1a:f0:ab:d4:4b:08:00 SRC=141.136.195.189 DST=90.71.78.189 LEN=48 TOS=0x00 PREC=0x00 TTL=111 ID=28202 PROTO=UDP SPT=6881 DPT=6881 LEN=28 MARK=0x8000000

Someone pinging ports?

After 24h or so of this constant output lost internet and had to reboot to get it backup and running.

 

[M@rco]

Does anybody have an idea as to why, since yesterday, my router log is plagued with this:

Jan 31 14:05:46 kernel: DROP IN=br1 OUT= MAC=b0:6e:bf:63:a6:e8:00:1a:f0:ab:d4:4b:08:00 SRC=141.136.195.189 DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=111 ID=28202 PROTO=UDP SPT=6881 DPT=6881 LEN=28 MARK=0x8000000

Someone pinging ports?

Not sure how this is related to the latest alpha in the 384 branch, but if the source ip is the same for all entries and the destination port varies, someone in Croatia is bored to death and most likely trying to find a weak spot. BTW, if you have a static ip, you might want to mask the part after DST IP in the log line you posted.

 

[DonnyJohnny]

Does anybody have an idea as to why, since yesterday, my router log is plagued with this:

Jan 31 14:05:46 kernel: DROP IN=br1 OUT= MAC=b0:6e:bf:63:a6:e8:00:1a:f0:ab:d4:4b:08:00 SRC=141.136.195.189 DST=90.71.78.189 LEN=48 TOS=0x00 PREC=0x00 TTL=111 ID=28202 PROTO=UDP SPT=6881 DPT=6881 LEN=28 MARK=0x8000000

Someone pinging ports?

After 24h or so of this constant output lost internet and had to reboot to get it backup and running.

Let’s ddos him!!!

6881 is common bittorrent port or World of Warcraft

Internet world is very noisy. I have like avg 50-200 drop per hour using Skynet. So if u know your port/service is closed. Should be fine.

Regarding disconnection, if this is a real ddos flooding u at very high frequency like hundreds or thousands per Sec, maybe? But I doubt this would happen in home router as there is no meaning in doing that.

If u want, u can try to install Skynet to block common malicious ip from knocking at your door. They will be stop at fence (raw table).

Alternative if u see the incoming ip is the same, u can set your own iptables rule and block the ip at raw table.

 

[Gingernut]

Thanks for the info M@rco.

Instead of creating a new thread, and as I'm running this alpha, I thought I'd ask here.

Don't really see much harm if I don't go too far off topic.

 

[DanTheMan]

Does anybody have an idea as to why, since yesterday, my router log is plagued with this:

Jan 31 14:05:46 kernel: DROP IN=br1 OUT= MAC=b0:6e:bf:63:a6:e8:00:1a:f0:ab:d4:4b:08:00 SRC=141.136.195.189 DST=90.71.78.189 LEN=48 TOS=0x00 PREC=0x00 TTL=111 ID=28202 PROTO=UDP SPT=6881 DPT=6881 LEN=28 MARK=0x8000000

Someone pinging ports?

After 24h or so of this constant output lost internet and had to reboot to get it backup and running.

I had the exact same thing happen yesterday, it started after I uninstalled Skynet ( thinking it was interfering with AI Protection, see my previous posts ). I gave up trying to figure out what was going on and I flashed to the most recent AC3100 FW and no more kernel errors. For all I know those source IPs are still hitting my router but not being logged, either way I’m back on stock firmware and things are smooth. I’ll hold off for a beta or final release firmware for now.

 

[DonnyJohnny]

I had the exact same thing happen yesterday, it started after I uninstalled Skynet ( thinking it was interfering with AI Protection, see my previous posts ). I gave up trying to figure out what was going on and I flashed to the most recent AC3100 FW and no more kernel errors. For all I know those source IPs are still hitting my router but not being logged, either way I’m back on stock firmware and things are smooth. I’ll hold off for a beta or final release firmware for now.

Likely because the firewall logging setting is set to off after the reflash of the new firmware. When installing Skynet, it will auto on the drop log in the firewall setting.

 

[Adamm]

I had the exact same thing happen yesterday, it started after I uninstalled Skynet ( thinking it was interfering with AI Protection, see my previous posts ). I gave up trying to figure out what was going on and I flashed to the most recent AC3100 FW and no more kernel errors. For all I know those source IPs are still hitting my router but not being logged, either way I’m back on stock firmware and things are smooth. I’ll hold off for a beta or final release firmware for now.

This is a setting that Skynet requires to be enabled (but modify's its functionality). Upon uninstallation it is disabled.

As for your previous posts about the Trend Micro blocking page, it seems AB-Solution is the reason it doesn't appear (although it still functions correctly otherwise). Maybe @thelonelycoder can share some insight.

 

[king006]

last night our internet (modem) was out. it occurred to me tonight after work that the internet speed was only 10/10 (normal 100/60)

After the restart of the asus, the problem was solved. we have not had this before? anyone have an idea? unfortunately we can not yet use our own modem.

I had done a WAN IP renew via SSH but that did not help.

 

[charlie2alpha]

@RMerlin I tried compiling the latest git for the RT-AC56U. It compiled and installed fine but again Adaptive QoS wouldn't start. Went back to the latest 384.x beta you provided and it started fine. I don't know if there's some change you didn't commit yet or subsequent commits broke it again.

 

[TheOldMan]

Is the openvpn server supposed to log that many lines? Check enclosed text file. RT-AC3200 with Merlin's 384-3_A2

 

[RMerlin]

@RMerlin I tried compiling the latest git for the RT-AC56U. It compiled and installed fine but again Adaptive QoS wouldn't start. Went back to the latest 384.x beta you provided and it started fine. I don't know if there's some change you didn't commit yet or subsequent commits broke it again.

I haven't done any change specific to the RT-AC56U since that last test build, changes were for other platform kernels.

 

[RMerlin]

Is the openvpn server supposed to log that many lines? Check enclosed text file. RT-AC3200 with Merlin's 384-3_A2

Logging verbosity is configurable on the OpenVPN settings page.

 

[Martineau]

Is the openvpn server supposed to log that many lines?

I would say 10 secs between disconnects isn't normal nor indeed is 30-60 secs?

I would check compatibility with your IOS Client.

Jan 30 15:44:55 ovpn-server1[2132]: rt-ac3200-ran/166.171.120.33 SIGTERM[soft,remote-exit] received, client-instance exiting
Jan 30 15:45:15 ovpn-server1[2132]: rt-ac3200-ran/166.171.120.33 SIGTERM[soft,remote-exit] received, client-instance exiting
Jan 30 15:46:05 ovpn-server1[2132]: rt-ac3200-ran/166.171.120.33 SIGTERM[soft,remote-exit] received, client-instance exiting
Jan 30 15:46:25 ovpn-server1[2132]: rt-ac3200-ran/166.171.120.33 SIGTERM[soft,remote-exit] received, client-instance exiting
Jan 30 15:46:32 ovpn-server1[2132]: rt-ac3200-ran/166.171.120.33 SIGTERM[soft,remote-exit] received, client-instance exiting
Jan 30 15:47:10 ovpn-server1[2132]: rt-ac3200-ran/166.171.120.33 SIGTERM[soft,remote-exit] received, client-instance exiting

P.S.Your IOS device has 'push-peer-info' enabled which can be removed to suppress those 7 lines of noise lines each time the client connects.

 

[drboss]

With my AC68U I have still problem with WAN balancing. It's not work when the second WAN is USB modem.
Two problem:
1. the modem is not recognized by system, I need use: insmod usbserial vendor=0x12d1 product=0x1506
2. but after this, when modem is accessible locally by gcom and it's connected to network, all routing form LAN is stopped. Only I have possibility to ping, trace internet from AC68U shell

 

[eastavin]

Did a 'factory settings -restore' operation this morning. Upon logging back in was surprised to find AI protection screens showing what could be wonky stuff.

For example before 'restoring' I had ai protection enabled for all 4 switches on the Network protection screen, plus 12 malicious site hits, and 7 2-way IPS hits, 0 infected computer. After the restore the top switch showed Enabled AI protection OFF, but the 3 detailed switches below show ON. plus the 12-7-0 hits report had changed to 45-23-0. In addition the boxes on the SCAN screen disagree with the 3 detailed switches on the Network protection screen so its hard to figure out if the Network protection is On or Off. (I was figuring all 7 would have shown OFF after the factory restore.)

Think next time I will try initialize instead.