Beta Asuswrt-Merlin 386.2 Beta is now available

[dave14305]

Nope, not really
wl1_chlist=36 40 44 48 149 153 157 161 165
But yeah, if I'll not find a root cause of that error message - as last resort, I will do factory reset, just to be sure

You’re really stubborn for someone asking for help.

 

[goodwin_c]

You’re really stubborn for someone asking for help.

I think its because i'm not asking for help, but trying to help everybody finding a truth about a root cause may help others and developers

 

[Jack Yaz]

I think its because i'm not asking for help, but trying to help everybody finding a truth about a root cause may help others and developers

The original numbers in the firewall rules look bad (57 161 165).

This looks like the end of the wl1_chlist nvram content.

wl1_chlist=36 40 44 48 149 153 157 161 165

Notice anything about the last 8 numbers?

 

[goodwin_c]

Notice anything about the last 8 numbers?

Ah, crap... 57 is trimmed 157... Yes, then it is chlist still, question is - wtf? :-D

 

[Deleted member 22229]

Right now on my router with 384.19

Unfortunately 384.19 has security issues.

 

[RMerlin]

Or invoke qos-start with the “rules” parameter already used with t.QoS.

Could be an idea, I didn't remember this one.

 

[goodwin_c]

Ok, a little bit moree info:
- it is NOT nvram - i've made a full factory reset - firewall still fails with two wrong rules, that are containing part of wan0_chlist instead of wan0_ifname
- internet connectivity is affected by failing firewall - I've copied one of the files from /tmp/err_rules, corrected two wrong lines, restored it with iptables-restore - and my internet came back immediatelly
So, I have to assume that there is definitely something wrong with Beta 1 related to firewall.c (still not sure if it is directly there, or issue comes from other place)
P.S. Tried with both dual-wan and without dual-wan - no difference (that setting triggers little different logic in firewall.c)

 

[goodwin_c]

@RMerlin is get_wan_ifname method implemented somewhere inside of binary blobs? i can't find it in the open sources. looks like this method is failing firewall rules generation, as it is responsible to return proper interface name used by firewall.c

 

[octopus]

@RMerlin is get_wan_ifname method implemented somewhere inside of binary blobs? i can't find it in the open sources. looks like this method is failing firewall rules generation, as it is responsible to return proper interface name used by firewall.c

Try: nvram get wan0_ifname

 

[goodwin_c]

Try: nvram get wan0_ifname

haha, very funny. before giving such advice - read the last few pages of investigations

 

[dave14305]

@RMerlin is get_wan_ifname method implemented somewhere inside of binary blobs? i can't find it in the open sources. looks like this method is failing firewall rules generation, as it is responsible to return proper interface name used by firewall.c

See here. not sure if this is the only function, but it is a start:

asuswrt-merlin.ng/release/src/router/shared/rtstate.c at c514f9f0b3f279dc1ea91ede4c92ab3e02beb8fa · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[goodwin_c]

See here. not sure if this is the only function, but it is a start:

asuswrt-merlin.ng/release/src/router/shared/rtstate.c at c514f9f0b3f279dc1ea91ede4c92ab3e02beb8fa · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

Tnx a lot. Will dig a little tomorrow. Will let you know if I'll find something useful

 

[octopus]

haha, very funny. before giving such advice - read the last few pages of investigations

Sure TL: DR

 

[dave14305]

Tnx a lot. Will dig a little tomorrow. Will let you know if I'll find something useful

If it’s a compile issue, other users with the same router should see the same behavior, and it should be easy to spot.

 

[jerry6]

thanks merlin 386beta 2 working well on my rt5300 for the last 3 days

 

[mromero]

Unfortunately 384.19 has security issues.

Always use commercial grade router in front.

 

[bbunge]

OpenVPN Android client fails authentication to server in AX86U. Using the Arne Schawbe Android client. User authentication set in server. 1024 bit, changed default port.

 

[kernol]

I think its because i'm not asking for help, but trying to help everybody finding a truth about a root cause may help others and developers

In your quest to help others [laudable], I would find it really useful if you included your router model and add-ons in your signature. I had to dig back to your very first post to see that your issues are with the RT-AC3100 [or as it is also known RT-AC88U].

A search of this thread reveals that there are at least 4 other members having similar problems ...
https://www.snbforums.com/search/147549/?q=ac88u&t=post&c[thread]=71038&o=date

Probably find that @dave14305 has nailed it with a compile hiccup relevant to this model only?
http://www.snbforums.com/threads/asuswrt-merlin-386-2-beta-is-now-available.71038/post-672455

 

[Xentrk]

BTW, the same issue with no internet (AC3100 in my case). Unfortunately, I have to revert back right now, so here is all information that I can provide atm:
- internet connection through PPPoE
- internet connection is available immediately after router reboot. but drops after some time (and there was no internet on the first boot just after firmware update). when issue occurs - internet is available from router itself, but not for clients (tested both from wired machine and wifi) - so looks like routing/firewall issue
- I have Skynet installed - who knows, maybe it's related...

I experienced the same thing on RT-AC88U. Router is able to establish WAN and VPN routes/connections. But clients have no internet. RPDB rules are getting wiped. I see they are getting created in the System Log. Bouncing the VPN Clients restores the RPDB rules. No clues that I can spot in the System Log at the moment. Restoring to 386.1_2 restores internet access for clients and no issues with RPDB rules.

 

[Xentrk]

RT-AC86U updated to 386.2_beta1 successful. No issues identified so far.