384.13 Upnp issue

[eastavin]

Intialized the RT-ac68u router erasing all files and settings. Went back in and turned off UPNP and set up the rest of my settings. Then I checked AI Protection router security assessement and it says UPNP is on. However the WAN page shows UPNP is off and the Port forwarding log shows an open port to a device that is actually disconnected. I have reboot the router several times over the last 3 days but it wont go away. I even left it for a day or so to see if it would time out. No dice.

Any thoughts on what to change next?

 

[ColinTaylor]

You reported the same thing with a previous firmware. Nobody else has reported this over the last year so I'd guess there's something unusual with your setup, or maybe everybody just leaves UPnP enabled.

https://www.snbforums.com/threads/384-7_2-bug-upnp-setting-ai-protection-disagree.49600/

 

[eastavin]

Yes I recall that. The problem went away with the next release. Now its back.

 

[ColinTaylor]

Are you using dual-WAN or some other kind of unusual WAN setup?

 

[eastavin]

I fiddled with it some more. It has something to do with Dual Wan. When its on Primary the ports forward log shows no upnp connections. When its on the secondary (Ethernet LAN port 2) it shows a log for upnp on port 52146 though best as I can determine the port is not open.

 

[ColinTaylor]

Can you SSH into the router and post the output of these commands.

ps w | grep upnp

nvram show | grep upnp | sort

 

[eastavin]

have to give that a go little later.

 

[eastavin]

Can you SSH into the router and post the output of these commands.

ps w | grep upnp

nvram show | grep upnp | sort

On second thought I had a moment...

17337 admin 912 S miniupnpd -f /etc/upnp/config
17385 admin 1428 S grep upnp

AND the second

size: 53550 bytes (11986 left)
none_wan_upnp_enable=1
upnp_clean=1
upnp_clean_interval=600
upnp_clean_threshold=20
upnp_enable=1
upnp_max_lifetime=86400
upnp_max_port_ext=65535
upnp_max_port_int=65535
upnp_min_lifetime=120
upnp_min_port_ext=1
upnp_min_port_int=1024
upnp_mnp=1
upnp_pinhole_enable=0
upnp_port=0
upnp_secure=0
upnp_ssdp_interval=60
vts_upnplist=
wan0_upnp_enable=0
wan1_upnp_enable=1
wan_upnp_enable=0
wan_wan_upnp_enable=1
wl0_wmf_ucast_upnp=0
wl1_wmf_ucast_upnp=0
wl_wmf_ucast_upnp=0

 

[eastavin]

I don't know much about the above parameters as I don't mess with these kind of setting since I sent dd-wrt to the bottom of the ocean .. sticking only to the GUI however... doesn't it say that wan0 upnp is off but it is on for wan1? So maybe the problem never went away from the time I first reported it but it only seemed to go away as the router switched wan along the way?

 

[ColinTaylor]

Looks like this:

https://www.snbforums.com/threads/384-6-enabling-dual-wan-enables-upnp-service.48569/#post-426798

 

[eastavin]

Looks like this:

https://www.snbforums.com/threads/384-6-enabling-dual-wan-enables-upnp-service.48569/#post-426798

Yes it does sound like that description.

I thought about my last comment some after reading this and need to expand ... one thing that does not make sense is why have there been no threat levels sensed by AI protection SCAN for the releases that came after 384.7_2? But suddenly there is? AI Protection is probably scanning the settings and not the current state of the dual wan. So maybe they have reused an older file of default settings for the factory reset/initialization? or older code for setting it on and off after fixing it assuming it had been fixed? Or AiProtection was not scanning properly?? Clearly a number of possible bugs exist simultaneously.

In any event it sounds like ai protection is doing the job its supposed to do to expose bad Asus code in this release 13. I will have to save your two notes here as I guess that Asus wont be fixing this anytime soon.

I followed Merlin's instructions in your note from 384.6 and now it shows UPNP is off in AiProtection. Rebooting cleared the Port forward log of a UPNP port.

Thank you.

Edward

 

[RMerlin]

wan0_upnp_enable=0
wan1_upnp_enable=1

You have it disabled on WAN0, but enabled on WAN1. If you are not using Dual WAN, then it's probably a bug in the check routine that fails to skip over the wan1 check when Dual WAN isn't enabled. I remember having to fix that at one point, maybe Asus broke it again with a recent merge.

In any case, you can safely ignore that if you don't use Dual WAN. The issue is in the check routine.

 

[eastavin]

wan0_upnp_enable=0
wan1_upnp_enable=1

You have it disabled on WAN0, but enabled on WAN1. If you are not using Dual WAN, then it's probably a bug in the check routine that fails to skip over the wan1 check when Dual WAN isn't enabled. I remember having to fix that at one point, maybe Asus broke it again with a recent merge.

In any case, you can safely ignore that if you don't use Dual WAN. The issue is in the check routine.

The point was that I did not consciously change wan1 by itself. I only use the GUI to adjust this particular router. up until my post the AI protection scan was reporting upnp was off since .8. I did a factory initialize and checked the box to erase all and on the next boot I went in turned on dual Wan, and then disabled upnp, all from the GUI, then I did an ai protection scan. At that point it reports the upnp problem.

It would be illogical to have an AI protection scan that skips over the state of a specific Wan port as it seems you suggested. That is not the fix. It would also be illogical to default set one port to on the other to off on initialization. It is illogical to make a GUI for upnp setting that only affects one Wan port without documenting that as an intended action. The conclusion from this is that an inexperienced coder at Asus did not think through how this is to work and messed it up on one of the recent releases maybe just by pulling in a wrong blob.

 

[RMerlin]

It would be illogical to have an AI protection scan that skips over the state of a specific Wan port as it seems you suggested. That is not the fix.

Why? The parameter is not used in any way unless you enable Dual WAN. And since there is no way to configure it without first enabling Dual WAN, then it makes perfect sense for the parameter not to be considered if it's not even used, otherwise it triggers the very exact problem you've encounterd: an apparent false positive report. The scan is about the router's current security state, not about the "what if"s.

It would also be illogical to default set one port to on the other to off on initialization.

The default is to be enabled for both ports, so it's consistent there.