[ 3004.388.7 alpha 1 Build(s) ] Testing available build(s)

[SteveyB]

Upgraded my GT-AX6000 with the alpha over the top of previous release build after 48 Hours everything seems absolutely fine. Running 30+ devices.

I would even go as far to say the UPNP aspects are much better. I used to get alot of Miniupnp messages in the log e.g. "miniupnpd unexpectedly closed the connection" and floods of "miniupnpd[3356]: accept(http): too many open files" in a random nature (even after disconnecting all devices). Log is completely clean so far.

What I have also noticed is port forwarding is working better. GTA V online used to have issues when two PS5s on same router could not connect to same game. I can see both devices in port forwarding log and all working fine. Previously I had to manually setup rules.

NAT seems same as always for all my devices where applicable. Happy to test specifics if it helps?

Only 48 hours but seems to be best firmware so far.

Thanks! @RMerlin

 

[RMerlin]

Upnp works with my son's PS5 specifically Call of Duty, I know it's not windows 10 but you can not generalize that it's not working with games. Although the usual IPv4 port forwrds/mapping doesn't show in the port forwarding system log in this build. Maybe now it's using IPv6 port mappings/forwards since @RMerlin enabled that feature.

The issue is application specific. AnyDesk on my work VM has no issue forwarding ports, same with the upnpc client, while Call of Duty on Windows does not work. It probably depends on the SDK the application developer used to manage UPnP ports, whatever the Windows version of CoD uses is broken.

The suggestion I posted earlier to start miniupnpd with the "-1" parameter (which lies to clients by pretending to be a V1 daemon) does work, but the client device needs to reconnect to the network to redetect the IGD version. In Windows this amounts to disable/enabling the network interface, for example.

 

[DiGz_Au]

The issue is application specific. AnyDesk on my work VM has no issue forwarding ports, same with the upnpc client, while Call of Duty on Windows does not work. It probably depends on the SDK the application developer used to manage UPnP ports, whatever the Windows version of CoD uses is broken.

The suggestion I posted earlier to start miniupnpd with the "-1" parameter (which lies to clients by pretending to be a V1 daemon) does work, but the client device needs to reconnect to the network to redetect the IGD version. In Windows this amounts to disable/enabling the network interface, for example.

Fiddly, I tested other games such as destiny 2 and it too also doesn't correctly open ports. So what would be the best thing going forwards? Because xbox consoles also would have this same issue as pc running w10/11.

 

[amigohd]

All running fine so far... no troubles at all.

Bootzeit	4 Tage 2 stunde 5 Minuten 4 Sekunden

 

[RMerlin]

Fiddly, I tested other games such as destiny 2 and it too also doesn't correctly open ports. So what would be the best thing going forwards? Because xbox consoles also would have this same issue as pc running w10/11.

It works if miniupnpd is started with the -1 switch, which tells it to lie and pretend to only support IGDv1. I've changed it so disabling pinhole support will now also force miniupnpd to report itself as being only IGDv1.

 

[Damit1]

It works if miniupnpd is started with the -1 switch, which tells it to lie and pretend to only support IGDv1. I've changed it so disabling pinhole support will now also force miniupnpd to report itself as being only IGDv1.

A question, if you disable pinole for V6 port forwarding, wouldn't it affect anything?
Or, can you "lie" with the report with pinole enabled as well?

Will you enable it and resolve whatever issue they showed here?
Just to understand the situation in its whole meaning.

 

[RMerlin]

A question, if you disable pinole for V6 port forwarding, wouldn't it affect anything?
Or, can you "lie" with the report with pinole enabled as well?

IPv6 pinhole is a feature of IGDv2. The two are therefore tied together.

 

[Damit1]

IPv6 pinhole is a feature of IGDv2. The two are therefore tied together.

Ok, in the case someone doesn't want the IGVD2 they disable the pinole?
I guess it would be up to user choise whether to disable or not?

 

[BlueiPhone]

I normally do not test alpha releases but I jumped in and I am very happy with this release.

Looking forward to the Beta.

I have a WireGuard VPN running always and it is working great.

I port forward IP4 addresses using the nat-start table and the firewall-start table with iptables rules

I Have 6 Logitech cameras around the house and Logitech doorbell too. I was having disconnects from the cameras quite often. I use Apple’s Homekit and now with iOS 17.4.1 and this firmware. I am not seeing these disconnects. I am not having any other problems with Homekit devices.

I does seem to perform very well with T-Mobile Home Internet. Thank you, Merlin.

 

[RMerlin]

Ok, in the case someone doesn't want the IGVD2 they disable the pinole?
I guess it would be up to user choise whether to disable or not?

The other way around. It defaults to Disabled.

 

[Interfreak]

No issue for me to report on this alpha so far, very stable.

 

[ika]

Thank you for the update. No problem to report, very stable so far. We also had lots of guests all using the wireless network, so it was a good test (more than 20 new STAs at the same time additionally to the devices we use every day).

ps.: I had to reset like six times again (also install stock and Merlin back), because I had the usual crash from torrents, but doing the nuclear carpet-bombing resets sorted it out as usual. I still do not know why that is happening, but I accepted my fate and got used to it by now tbh, it is how it is.
I got a very good test now at least, to tell if everything is ok or not. If I launch VLC on my PC and it cannot see the DLNA server unless I also enable ipv6, then it will crash from the torrents (no ipv6 is enabled in the router), so if I see that happening, then I know I have to keep reseting.

 

[MDM]

The other way around. It defaults to Disabled.

Then will you make a toggle switch in the GUI to change from IGDv1 to IGDv2 (et vice versa), or will we need to do it manually via a SSH command...?

 

[jgrove]

@RMerlin Thank you for the 56U support, I thought my router had long since been placed in a museum.

 

[capncybo]

With my RT-AX86U on 3004.388.7 alpha 1... I just noticed some OpenVPN issues.
I'll admit... I almost always "dirty flash" these upgrades. (Don't throw things, please...)
(But this is the first time [in ages]) I've had issues.
I did have to reload DDNS, as that was OFF.
And my "client_file.ovpn" (which I've been using since 2022) uses the DDNS (hostname) for access.
In the RT-AX86U WebGUI, VPN>VPN Server (Page), things look normal...
I can see (Google Pixel 7) Connected @ 10.0.8.2 when Testing via Rogers(Canada)
HOWEVER...
When Trying to connect to various internal LAN devices (no-luck)
Yet when testing via Wireguard...
SUCCESS.

I've noted via the first post, OpenVPN was updated & I scanned this thread but didn't see any OpenVPN issues or complaints.

Any (ideas/help) would be appreciated.
Perhaps enough changes were made to OpenVPN that my older "client_file.ovpn" no-longer works?

But as I said... in the RT-AX86U WebGUI things look normal & my cellphone is CONNECTED.
???

 

[FLA_NL]

Dirty update over 388.6_2, no noticeable issues.

 

[RMerlin]

Then will you make a toggle switch in the GUI to change from IGDv1 to IGDv2 (et vice versa), or will we need to do it manually via a SSH command...?

The webui switch is already there, it was only controlling pinhole support, and will now also control the advertised version.

 

[Dedel66]

Perhaps enough changes were made to OpenVPN that my older "client_file.ovpn" no-longer works?

Maybe create a new *****.ovpn configuration file and compare with the old one. So you can see what's different.

 

[capncybo]

Maybe create a new *****.ovpn configuration file and compare with the old one. So you can see what's different.

Thanks, I was thinking the same thing. But before doing a RENEW... I did an export & saved the file as 2024_client1.ovpn & compared it to my... 2022_client1.ovpn file.
As expected (those two were identical).
I was reluctant to do a REFRESH as I would prefer to use the same OLD file (If possible).
But I suppose I should be able to perform an IMPORT (Afterward) if desired.

However, I was thinking of taking a closer look at the log files because...
IMO (I think OpenVPN is connecting properly),
This problem is behaving as if something changed with my (ROUTING/IP-Table)
But I'll admit (I'm a little weak in that knowledge base).
However...
In the WebGUI (under VPN>VPN Server Tab)... I have selected
Client will use VPN to access = Both (LAN & Internet)

Hence I would have thought, that should be sufficient to handle the routing properly.

 

[Dedel66]

Hence I would have thought, that should be sufficient to handle the routing properly.

Your thoughts are correct. This works perfectly for me. However, there is a difference: my VPN connection only works with IPv6 as I am behind a cgnat on IPv4.