[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[ColinTaylor]

Is it using STUN on 374 LTS now by default? I have static external IP behind the "private" address, wouldn't it be better if I supplied it somehow to miniupnpd?

Don't over-think this. It's working now so leave it at that.

 

[john9527]

Im connecting to my own vpnserver over internet. Merlin 384.18 build.
Do I need to load your test build?

No need for a test build....
I'm assuming that your server running Merlin is configured with compression disabled?

 

[octopus]

@octopus @ColinTaylor
OK....recreated it. I've never seen it not return fields for compression before, even with compression set to Disabled or None it would just return the headings and '0' for the data
The lack of any fields there broke my data reordering when creating the table. Simple fix for the next release.

Just tested -PASS2 build and same client display.

 

[octopus]

No need for a test build....
I'm assuming that your server running Merlin is configured with compression disabled?

Yes, and compression is disabled.

 

[keshavdaboss]

Can't do that...way too many changes between them. Need to factory reset and config manually when changing.

Got it, I reflashed your firmware and performed a nvram and factory reset. Script still does not work though, again all the traffic routes properly if I turn off the encryption for the network. Do you have any idea why this could be? I am also running in AP mode and the wl0.2 names referenced in the code snippet above correspond to the guest networks set in the webinterface. The setup looks like WAN-> Firewall (OPNsense... etc) (Trunks with VLANs) -> AP (AC68U) -> Wifi (Seperate networks for each VLAN tag (guest, lan, etc..))

 

[ekze]

I put up an Update-44D9-Pass2 folder which picks up the latest miniupnpc which supplies that message. (Also fixed the Description field overflow in your screenshot )
Let's see if that helps.

Just installed it!
I think the messages are gone now! I'll keep an eye out for them.
Description field is better now: https://nyazo.jp/W8oP0q4.png, though there's also Destination field that doesn't fit in the box at all, not really important ^^

 

[ekze]

Don't over-think this. It's working now so leave it at that.

Am I and is it? It has somewhat worked before as well, but only for qBt for me, now it also works for AceStream, but doesn't for any of crypto wallets I've tried - port stays closed, and there's no new entry in port forwarding table.
Is there a way to check miniupnpd debug logs to see why it is happening? Is there a way to start it in debug mode from ssh or something like that?
I also wanted to try pushing my external ip to see if it would fix it. It would be easier to try if only I knew appropriate nvram commands ^^. I tried to supply externalip to crypto wallets conf, but it didn't help.

 

[ColinTaylor]

Am I and is it? It has somewhat worked before as well, but only for qBt for me, now it also works for AceStream, but doesn't for any of crypto wallets I've tried - port stays closed, and there's no new entry in port forwarding table.

Unless you explicitly describe something that isn't working we're going to assume it is because miniupnpd is now working that way it was in the old 380 firmware. Any additional problems will be caused by you having double-NAT now when you didn't before.

Is there a way to check miniupnpd debug logs to see why it is happening? Is there a way to start it in debug mode from ssh or something like that?
I also wanted to try pushing my external ip to see if it would fix it. It would be easier to try if only I knew appropriate nvram commands ^^. I tried to supply externalip to crypto wallets conf, but it didn't help.

There are no simple nvram variables to change. You'll either have to create a custom config file or script, or edit the config file from the command line and manually restart miniupnpd. You could run miniupnpd in debug mode with "-d".

To read about STUN support look at this post.

EDIT: You could try this from the router's command line just to see if it makes a difference (look in the syslog for messages).

killall miniupnpd; sleep 5; miniupnpd -f /etc/upnp/config -o STUN:stun.stunprotocol.org

 

[ekze]

Unless you explicitly describe something that isn't working we're going to assume it is because miniupnpd is now working that way it was in the old 380 firmware. Any additional problems will be caused by you having double-NAT now when you didn't before.

OK, I've went through the logs of the program in question, that doesn't seem to use UPnP properly after the fix. Here's what I found:

2020-07-06T21:20:39Z upnp thread start
2020-07-06T21:20:41Z No valid UPnP IGDs found
2020-07-06T21:20:41Z upnp thread exit

It could be related to upnpc included in the app not finding ExternalIPAddress outside "private" range.
I've tried using Windows binary that is quite old - from 2015, and it doesn't mind 10/8 "external" ip - successfully found valid IGD:

Found valid IGD : http://192.168.1.1:34701/ctl/IPConn
Local LAN ip address : 192.168.1.2
ExternalIPAddress = 10.33.51.67
InternalIP:Port = 192.168.1.2:6666

And even redirected port to test:

external 10.33.51.67:6666 TCP is redirected to internal 192.168.1.2:6666 (duration=0)

And it worked.
My guess is the issue could be that some apps that use newer builds of upnpc will fail to work with that setup, unless I provide valid external ip.

You'll either have to create a custom config file or script, or edit the config file from the command line and manually restart miniupnpd. You could run miniupnpd in debug mode with "-d".

Can you please guide me a little how to do that properly on a router? I tried editing /etc/upnp/config but it's overwritten when I restart UPnP from web panel. I tried launching miniupnpd -d (also tried providing custom config custom config file via -f /path/to/conf or using -o ext_ip) it doesn't start - just printing usage help message. I'm certain I'm using correct variables, it just doesn't start. Is there some special way to start it up I'm missing?

Is it explicit enough?

 

[ColinTaylor]

OK, I've went through the logs of the program in question, that doesn't seem to use UPnP properly after the fix. Here's what I found:

2020-07-06T21:20:39Z upnp thread start
2020-07-06T21:20:41Z No valid UPnP IGDs found
2020-07-06T21:20:41Z upnp thread exit

If your application can't even find the IGD then it looks like you need to fix the application before going any further.

If you want to run it in debug mode try this:

killall miniupnpd; sleep 5; miniupnpd -f /etc/upnp/config -d

EDIT: Did you try the STUN command in my previous post?

 

[ekze]

YES! After adding ext_ip=myrealip in /etc/upnp/config it's working!
Log from the program that didn't work before:

Spoiler

2020-07-06T22:36:54Z upnp thread start
2020-07-06T22:36:56Z UPnP: ExternalIPAddress = (my real ip)
2020-07-06T22:36:56Z AddLocal(myrealip:8235,3)
2020-07-06T22:36:56Z UPnP Port Mapping successful.

Removing ext_ip from config. Trying STUN now.

Spoiler

miniupnpd[937]: STUN: Performing with host=stun.stunprotocol.org and port=0 ...
miniupnpd[937]: STUN: ext interface eth0 with IP address 10.33.51.67 is now behind restrictive NAT with public IP address myrealip: Port forwarding might not work properly
...
miniupnpd[937]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping
miniupnpd[937]: AddPortMapping: ext port 8767 to 192.168.1.2:8767 protocol TCP for: Raven v4.1.0.0-16480934a leaseduration=0 rhost=
miniupnpd[937]: UPnP permission rule 0 matched : port mapping accepted
miniupnpd[937]: Check protocol tcp for port 8767 on ext_if eth0 10.33.51.67, 4333210A
miniupnpd[937]: redirecting port 8767 to 192.168.1.2:8767 protocol TCP for: Raven v4.1.0.0-16480934a
miniupnpd[937]: Returning UPnPError 501: ActionFailed

Getting similar error in application log:
2020-07-06 22:50:16 upnp thread start
2020-07-06 22:50:18 UPnP: ExternalIPAddress = myrealip
2020-07-06 22:50:18 AddLocal(myrealip:8767,3)
2020-07-06 22:50:18 AddPortMapping(8767, 8767, 192.168.1.2) failed with code 501 (Action Failed)

TL;DR Applications that worked without stun now won't work at all: qBt (worked without ext_ip), crypto wallets (worked only with ext_ip)

Tried different STUN servers, removing rules - didn't help.

Switched back to using ext_ip in config:

Spoiler

miniupnpd[1032]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping
miniupnpd[1032]: AddPortMapping: ext port 8767 to 192.168.1.2:8767 protocol TCP for: Raven v4.1.0.0-16480934a leaseduration=0 rhost=
miniupnpd[1032]: UPnP permission rule 0 matched : port mapping accepted
miniupnpd[1032]: Check protocol tcp for port 8767 on ext_if eth0 10.33.51.67, 4333210A
miniupnpd[1032]: redirecting port 8767 to 192.168.1.2:8767 protocol TCP for: Raven v4.1.0.0-16480934a

Perfect there!

No idea why it's not working with stun, but hey, at least it's working perfectly with ext_ip! Also checked with external services if the port is indeed open and visible, and it was!

Add: let me know if you need more testing! Looks like issue with stun is described here: https://github.com/miniupnp/miniupnp/issues/433

 

[ColinTaylor]

@john9527 Looks like RMerlin just updated miniupnpd in his build. Mostly IPv6 stuff but there's a few change that might impact STUN. Do you think it's worth a development build at this time?

It might be useful to enable the syslog messages in the upnp_redirect_internal function to get a better understanding of where it's failing.

OTOH this has only impacted one user so far and he now has a workaround. So the STUN issue is really only for academic interest.

 

[john9527]

@john9527 Looks like RMerlin just updated miniupnpd in his build. Mostly IPv6 stuff but there's a few change that might impact STUN. Do you think it's worth a development build at this time?

It might be useful to enable the syslog messages in the upnp_redirect_internal function to get a better understanding of where it's failing.

I think I already figured it out.....really badly coded check in the code. Doing a build now to test a fix.

 

[jschu2]

Hello,
I have an RT-N66U and successfully installed 3.0.0.4.374.43_44E5j9527 firmware yesterday. When I first tried to change the default username and password and enter the SSID and usernames for 2.4G and 5G networks during the initial setup, the progress circle dots kept spinning and didn't seem like it was going to finish. I tried several times, but eventually skipped those steps and was able to change them from the main menu individually.

The main reason I wanted to try this firmware was so that I could use the VPN kill switch feature. It was impossible for me to even enter my VPN information today. Under the VPN settings, OpenVPN tab, every time I would upload my .ovpn file, the page refreshes itself a few seconds later and everything, including my username and password, are deleted. I tried 3 different browsers, 2 different computers, and even turned on NoScript to see if that would stop it, but it was impossible to save my VPN information. The page refreshes and deletes everything. The router has been rebooted multiple times and powered off completely, but I can't get it to work.

Has anyone else had this issue? Could it be software I'm running? I have Kaspersky Internet Security, Ublock Origin and NoScript. I'd appreciate any help, thank you!

 

[ColinTaylor]

@jschu2 Which firmware version were you using before installing this one? Have you performed a factory reset after installing this firmware?

 

[jschu2]

@jschu2 Which firmware version were you using before installing this one? Have you performed a factory reset after installing this firmware?

I was using the very latest firmware from Asus. I used the Asus firmware restoration tool in recovery mode and loaded John's firmware right away. I was under the impression that I could revert to the stock firmware, but couldn't find the option to do this (I couldn't even find the original firmware on Asus' website), so I hope this was done correctly. Yes, I did a factory reset after, by holding the reset button in for 20 seconds or so.

 

[ColinTaylor]

@jschu2 Well it sounds like you did everything correctly. Have a look at Tools - System Information page and see what you have for "NVRAM usage" and "JFFS".

 

[jschu2]

@jschu2 Well it sounds like you did everything correctly. Have a look at Tools - System Information page and see what you have for "NVRAM usage" and "JFFS".

Thank you for the quick replies.

NVRAM usage 47145 / 65536 bytes (71% utilized)
JFFS 0.52 / 10.00 MB

 

[ColinTaylor]

Thank you for the quick replies.

NVRAM usage 47145 / 65536 bytes (71% utilized)
JFFS 0.52 / 10.00 MB

Well that looks good so I'm at a loss for why you're having such strange issues. The fact that you had issues straight away during the initial setup is concerning.

If I were you I'd reinstall the firmware but do it through the GUI (Administration - Firmware Upgrade). After the firmware is uploaded the router will reboot and go into the initial setup again. At this point don't do anything, just leave it for a couple of minutes. Then press the reset button (not the WPS button) for 10 seconds and wait for it to boot up again. Now see if you have the same setup problems.

I know you've done this before, but it's worth trying it again just to be sure.

 

[john9527]

Could it be software I'm running? I have Kaspersky Internet Security, Ublock Origin and NoScript.

Yes, it could....I would try with each of these set to ignore the router address.