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

[agbommarito]

This morning, after more than four days without any errors, the rude awakening: all Tasmota sockets that were connected to the main router (2.4 GHz) are disconnected and cannot reconnect. In the log I can see that they are trying to reconnect, probably not getting an IP address and therefore giving up the connection.
If I turn the WiFi off and on, all tasmotas can connect again.

I will go back to set up stable 388.6_2 and see if this will happen after 4 days or more too.... BIG SIGH

This may be totally unrelated, but I had a somewhat similar problem with a non-Tasmota ESP8285 device. I found a number of discussions on the web about problems with the ESP device refusing a DHCP offer from the Asus router, which seems to be what is happening in your syslog file. The fix was to add a command to the ESP code to force 802.11g mode [WiFi.setPhyMode(WIFI_PHY_MODE_11G);] Look at https://github.com/esp8266/Arduino/issues/8412 for more details.

 

[Dedel66]

The fix was to add a command to the ESP code to force 802.11g mode [WiFi.setPhyMode(WIFI_PHY_MODE_11G)

Thanks for that hint! I will try that later. But the strange thing is the fact that after a restart of the wlan the tasmoras can reconnect.

From now I will disable the b/g Protection as next testing step. And I am back to 388.6_2 but that step didn´t solve the problem.

EDIT:
switched all tasmotas now to 11g

I will report here if that did the trick...

 

[maxbraketorque]

This morning, after more than four days without any errors, the rude awakening: all Tasmota sockets that were connected to the main router (2.4 GHz) are disconnected and cannot reconnect. In the log I can see that they are trying to reconnect, probably not getting an IP address and therefore giving up the connection.
If I turn the WiFi off and on, all tasmotas can connect again.

I will go back to set up stable 388.6_2 and see if this will happen after 4 days or more too.... BIG SIGH

What lease time are you using?

 

[Dedel66]

What lease time are you using?

86400 = 24h
I played around with leasetime and tried also fixed IPs for the tasmotas.... Nothing changed.
Now I am reading about the issues of tasmotas with wlan-n.

I switched them all to "wlan-g" and observe again (waiting for disconnects).
Painful but maybe a tasmota (ESP8266) related problem...

 

[Darek]

Hello everyone
My GT-AX6000 went from beta 388.6.2 to 388.7.1 alpha 1 and then after a few days to alpha 2.

My configuration is LAN 2.5G, several devices on 5GHz WiFi, only this range enabled and WPA3. DHCP disabled, everything on static.

After a few days of testing, I went back to alpha 1 because there are fewer bugs. On Alpha 2, the IPv6 page displays incorrectly, and the list of devices on the network map-view list stops. Alpha 1 is stable, the only error I see (although Alpha 2 also has it) is that it incorrectly shows the range of Wi-Fi devices in the wireless log tab. It shows a much worse range of devices in dBm than it actually is. I don't remember what version 388.6.2 showed, but I won't go back to it to check.

Well done Merlin, I'm looking forward to the next stable release.

 

[robinjoo1]

Hello everyone
My GT-AX6000 went from beta 388.6.2 to 388.7.1 alpha 1 and then after a few days to alpha 2.

My configuration is LAN 2.5G, several devices on 5GHz WiFi, only this range enabled and WPA3. DHCP disabled, everything on static.

After a few days of testing, I went back to alpha 1 because there are fewer bugs. On Alpha 2, the IPv6 page displays incorrectly, and the list of devices on the network map-view list stops. Alpha 1 is stable, the only error I see (although Alpha 2 also has it) is that it incorrectly shows the range of Wi-Fi devices in the wireless log tab. It shows a much worse range of devices in dBm than it actually is. I don't remember what version 388.6.2 showed, but I won't go back to it to check.

Well done Merlin, I'm looking forward to the next stable release.

where do you see alpha2???? i have a gt-ax11000pro

 

[visortgw]

where do you see alpha2???? i have a gt-ax11000pro

Most likely referring to second iteration of alpha1 as alpha2...

 

[Darek]

Of course, it was a shortcut maind. Alpha 1 is the g83... version and "alpha 2" is actually g4c... also alpha 1, so I'm sorry if I misled anyone.

 

[robinjoo1]

so sorry for misinterpreting your post

 

[colossus]

After eight days, on the second alpha, no issues to report.

 

[ika]

Thank you for g4c689dffeb. Everything works as expected, no issues to report.

I noticed a phenomenon on some of the devices I have this alpha deployed (GT-AX6000 and RT-AX58U).
After boot, on the "Network Map" page, the display of the WAN IP address alternates between the actual WAN IP and 0.0.0.0 for quite a while until it settles on the actual WAN IP.
I do not recall seeing this before, but I wasn't really looking either.

Is this a known thing?

ps.: I did not experience any problems, so this is more like FYI post at this moment.

 

[Damit1]

2 days with latest Alpha on AX56U, no issues whatsoever.

Where should we "enable" the IGMD ver?
Didnot see anything special under Webui

 

[ColinTaylor]

2 days with latest Alpha on AX56U, no issues whatsoever.

Where should we "enable" the IGMD ver?
Didnot see anything special under Webui

WAN - Internet Connection > Enable IGDv2 (IPv6 pinhole support)

 

[bluepoint]

@RMerlin
It looks like iPhone will not give up easily when preventing client auto DoH is enabled. This notification keeps on going up when iCloud Private Relay is suppressed, this will be annoying.

 

[L&LD]

As is everything apple-related.

 

[Damit1]

IGVD2 is enalbled, IPv6 (native) is enabled, both on AX56U.
NO ISSUES observed.

It seems so far that my buddy with the AX56U does not have any IoT or such thing that enabled IPv6 , so pinhole does not relevant.

Waiting for Beta for my own network.

 

[bluepoint]

As is everything apple-related.

And to add, it seems the DoH prevention in apple products, in my case iPhone, it doesn't work even there's notification about private relay unavailable, safari still tunnels through iCloud. I know it does because it still serves ads.

iOS 17.4.1
GT-AX6000 Alpha 1 g4c689dffeb

 

[bluepoint]

Private Relay is VPN like function that is useful for users that wish that their internet activity private, more useful when they are on the road. It's opt-in and is not on by default and only available for iCloud paid users. In my opinion we should just leave it alone, users who opt-in knows what they are into.

What we are preventing from DoH:
Private Relay = Security
Others = Data mining

 

[L&LD]

No. No security. No privacy.

Both are fallacies of a VPN that you don't control. As you contradict yourself, in post 157.

And (most) Apple users knowing what they're getting into? That is infinitely debatable too.

 

[RMerlin]

@RMerlin
It looks like iPhone will not give up easily when preventing client auto DoH is enabled. This notification keeps on going up when iCloud Private Relay is suppressed, this will be annoying.
View attachment 57709

Disable the Private Relay feature then. The router is doing what it's intended to do when that router setting is enabled: ensure that client devices cannot work around the router-provided DNS server. You have to decide if you want to continue blocking that DNS bypass (in which case disable the feature on your phone), or to allow it (in which case disable the setting on the router).

Private Relay is VPN like function

It's also a DNS encryption technology that uses a DNS server that is NOT your router's. That`s why it`s part of the DoH block feature of the router.

What we are preventing from DoH:

The reason behind the existence of the router setting is not to prevent DoH itself, it`s to prevent a device from bypassing what you configure on the router. If you configure a parental control DNS server on your router, you would obviously not want your kid's iPhone to just bypass it by using either a DoH server or some Apple-approved DoQ server (Private Relay uses QUIC, which also introduce its own set of potential issues). That's when you`ll need to also enable the Prevent DoH setting on the router.

If that does not fit your personal scenario, then just disable the router setting. The option is entirely yours.