[RT-AX86U] Merlin 386.1 - Unable to completely disable upnp

[podkaracz]

@RMerlin
Sounds like the default setting should maybe be changed to off?

Is this option only visible when using adaptive qos or its enabled by default ?

 

[DiscoSi]

Is this option only visible when using adaptive qos or its enabled by default ?

It's on by default and appears on the QOS tab even is QOS is actually off. It's not specific to Merlin's build either, it's the same in stock as well.

 

[podkaracz]

It's on by default and appears on the QOS tab even is QOS is actually off. It's not specific to Merlin's build either, it's the same in stock as well.

It has to be a new feature because im having ac86u and its not there. Probably only newer models have it.

 

[eclp]

I cannot find this setting on my device (AX88U). Does the GeForce setting only exist on certain model series and what exactly does it do? Sorry, two questions.

My AX88U does not have this setting either ...

 

[DiscoSi]

Yes you're correct, the AC86U doesn't have the "Enable GeForce NOW QoS UPnP control" option/feature. I've come from the AC86U to an AX86U.

 

[eclp]

I've come from the AC86U to an AX86U.

 

[DiscoSi]

I guess it'll be any that Asus advertise as having the GeForce NOW support, that's pure speculation though as I don't have other devices to test. Like I said though it isn't just Merlin's build as it's present in the stock firmware for the AX86U going back to the 384 branch too.

 

[RMerlin]

@RMerlin
Sounds like the default setting should maybe be changed to off?

Or the qos_type should be checked in addition to that setting, since I believe qos_type should be set to Geforce NOW for this to work.

Geforce Now used to be unique to GT models, and support for it was only recently added by Asus to my miniupnpd code. I haven't looked at the GeForce NOW code at all so far, aside from when dealing with the queue disciplines.

I will need to study how this feature works exactly.

 

[RMerlin]

Looks like I lost the GeForce NOW upnp patches at some point during 386 development, I will have to re-merge Asus's code.

After a first look at it, miniupnpd can be set to run in three different modes:

- Regular UPNP
- Regular UPNP and GeForce NOW
- GeForce NOW only

So, having the GeForce NOW default value be the same as the regular UPNP default value makes sense to me. And I would assume that if one were to disable UPNP on the WAN page, it would leave miniupnpd running only to handle GeForce NOW specific code. I cannot make miniupnpd just blindly stop running just by having regular UPNP disabled, as Asus relies on it for a few other functionalities, like GeForce NOW and Aura Sync.

Asus seems to consider GeForce NOW upnp and GeForce NOW QOS to be two separate things, nowhere in the code do I see one rely on the other being enabled/disabled, aside from when one sets a router button to become a GeForce NOW toggle, in which case it toggles both at the same time.

So unless I can see any good reason to make this become disabled by default after I've had a deeper look into the code, I will most likely leave it as it is, considering that miniupnpd is designed to be able to explicitly run in GFNOW-only mode.

 

[john9527]

Looks like I lost the GeForce NOW upnp patches at some point during 386 development, I will have to re-merge Asus's code.

At least some of it was there, since I could see the GeForce setting enabling miniupnpd. Be interesting to see what got lost.

 

[DiscoSi]

So with Regular upnp turned off, should it still be possible for ordinary upnp requests to open ports? That's what I observed just using upnpc command from a Ubuntu box?

 

[RMerlin]

At least some of it was there, since I could see the GeForce setting enabling miniupnpd. Be interesting to see what got lost.

The code inside miniupnpd itself is what's missing. They had sent me a patch with the GeForce NOW code during development, but I must have forgotten to reapply it at some point.

Fortunately it will be much easier to reapply now that we both keep our miniupnpd code mostly in sync.

So with Regular upnp turned off, should it still be possible for ordinary upnp requests to open ports? That's what I observed just using upnpc command from a Ubuntu box?

Right now you can't test this properly, as the GFNOW code is missing in 386.1's miniupnpd.

 

[DiscoSi]

The code inside miniupnpd itself is what's missing. They had sent me a patch with the GeForce NOW code during development, but I must have forgotten to reapply it at some point.

Fortunately it will be much easier to reapply now that we both keep our miniupnpd code mostly in sync.


Right now you can't test this properly, as the GFNOW code is missing in 386.1's miniupnpd.

I don't know if this helps you at all but I observed the same behaviour in the current latest stock firmware beta: Version 9.0.0.4.386.41994. The main regular uPnP setting off but still able to use upnpc client to set port forwarding, in fact several regular devices on my network did as well which is how I spotted the situation in the first place.

Maybe I don't understand the difference between the special GeForce NOW upnp and regular?

 

[Mutzli]

The new alpha released today should include the patch for GeForce NOW Merlin mentioned above and of course many other improvements and fixes. Thank you @RMerin for all the fixes.

 

[gattaca]

I was reading the logs and found the "miniupnp" running. Of course I went tearing thru the settings b/c I KNEW I'd disabled UPnP by default - ALWAYS! Since some of us never enable QOS, I had no idea it would be hiding there! This is another heads up that this 2nd place needed to fully disable that security nightmare...

AX86U > Adaptive QOS > QOS > Enable GeForce NOW UPnP control > No That's on 386.2_alpha1-gc52b410e89. I've not hopped to the Beta yet..

Before with default -> Mar 12 16:13:52 miniupnpd[19530]: shutting down MiniUPnPd
Mar 12 16:13:53 miniupnpd[26653]: HTTP listening on port 41937
Mar 12 16:13:53 miniupnpd[26653]: Listening for NAT-PMP/PCP traffic on port 5351
...
After flipping the setting-> Mar 12 16:38:03 miniupnpd[26653]: shutting down MiniUPnPd

 

[bortek]

On my AX86U-Pro there is no such setting for Geoforce. I ended up adding this script and manually stopping the service

/jffs/scripts/nat-start (dont forget to chmod +x)

Why nat-start and not some other scripts? Because all other script execute before miniupnp service is started. nat-start looks like executes after that.

nat-start contains these 2 rows

#!/bin/sh
service stop_upnp


which resulted in the following


...
Dec 22 10:49:15 miniupnpd[4209]: HTTP listening on port 37753
Dec 22 10:49:15 miniupnpd[4209]: Listening for NAT-PMP/PCP traffic on port 5351
...
Dec 22 10:49:21 custom_script: Running /jffs/scripts/nat-start
Dec 22 10:49:21 rc_service: service 4339:notify_rc stop_upnp
Dec 22 10:49:21 miniupnpd[4209]: shutting down MiniUPnPd

Yipiii