Hi  @axute 

Thanks for posting here.

This is the first feedback we recieved this kind of feedback. To know more details, please give us the following info:

1. What's the SSID settings of the ESP deivces?

2. Apart from the EAP660 HD, do you have other EAP units in the network? Please send a screenshot of the controller's device page;

Please disable the following options of the SSID and see if it helps:

  @Vincent-TP 

for 1. I have the following SSID-Settings:

I also tried WPA/WPA2 PSK/AES, but nothing changed.

Configuration on ESP32 (all devices have the same. There are two stored, the closest access point is selected automatically)
 

wifi:
  ap:
    ssid: "XXXXXXXXXXX${device_name}"
    password: !secret wifi_password_fallback
  networks:
    - ssid: !secret wifi_ssid
      password: !secret wifi_password
      priority: 0.0
      bssid: CA:06:C3:XX:XX:XX
    - ssid: !secret wifi_ssid
      password: !secret wifi_password
      priority: 0.0
      bssid: 66:E9:31:XX:XX:XX

(X = anonymized)
 

for 2. I have also one EAP615-Wall configured but offline (not in use, replaced months ago by the second EAP660 HD).

The 802.11r is usefull for some other smarthome devices.

for 3. I'll try updating your configuration using just one device, as otherwise my entire smart home won't be usable.

I'll give you feedback when I find a solution to update just one device. I can't find an easy way to do this at the moment.

  @Vincent-TP 

If I try your configuration without a firmware update (1.3.2):

• Some Tasmota devices are not accessible via HTTP/MQTT (but are connected and have an IP address).
• Some Shelly products with the latest original firmware are also unavailable: Shelly 2 Plus
• ESPHome devices are online 

Hi  @axute 

Thanks for the reply.

IoT devices typically neither require roaming capabilities nor advanced features. In fact, enabling these unnecessary functions may sometimes lead to compatibility issues.

Please disable 802.11r and all options under Multicast/Broadcast Management, and let those IOT devices connect to the SSID only.

For other devices, you can create a separate SSID and enable advanced features as you want.

I recommend testing with the latest firmware.

  @Vincent-TP 

Start situation: 
 

14 ESPHome flashed Devices (Shelly v1/ESP8266, ESP32 - different manufacturers)
5 Shelly Devices with Original Firmware - latest
10 Tasmota Firmware Devices via MQTT
 

AP-1: Firmware 1.3.2, AP-2: Firmware 1.3.2

802.11r: on, ARP-to-Unicast Conversion: on, Multicast-to-Unicast Conversion: IPv4: on - IPv6 on - 100%

Steps I did:

1. First I tried to disable 802.11r, everthing works fine
   All devices are online (connected to AP-1 and AP-2).
    
2. Upgrade AP-2 with Firmware 1.4.2.
   Only 4 other devices connect to the AP-1 - connected to another SSID: Desktop-PCs and Google Chrome Cast Devices)
   Wait for 5 Minutes - none of the 3 device types will connect to AP-2.
    
3. Disabled ARP-to-Unicast Conversion ( = off).
   One Shelly wit ESPHome (ESP8266) and Tasmota devices are connected to AP-2.
   ESP32 devices will not connect to AP-2, they take the longer way to AP-1 with old Fimware.
    
4. Disable Multicast-to-Unicast Conversion: IPv4
   Same as 3. - ESP32 devices will not connect to AP-2, they take the longer way to AP-1 with old Fimware.
   That's now the configuration that you suggested, right?
    
5. Rolling back AP-2 to Firmware 1.3.2
   Same as 3. - ESP32 devices will not connect to AP-2, they take the longer way to AP-1 with old Fimware.
    
6. Enable ARP-to-Unicast Conversion (= on) and Enable Multicast-to-Unicast Conversion
   All 3 Device types connect to AP-2.

Is there anything else I could test for you?

PS: it is a IPv4 only network, disable Multicast conversion for IPv6 make no sense.

Hi  @axute 

Thank you for sharing the test results.

Currently, the compatibility between the advanced features and third-party IoT devices is unclear, and the above are just some recommended tests.

Based on your test results, does Test 6 work properly with the latest firmware? If so, please keep this configuration.

Enable ARP-to-Unicast Conversion (= on) and Enable Multicast-to-Unicast Conversion
All 3 Device types connect to AP-2.

  @Vincent-TP 

Unfortunately not.

After the rollback in point 5, firmware 1.3.2 is running, which works with all devices with ARP/Multicast enabled.

The latest firmware doesn't work with my current configuration, nor does it work with your recommendation.

PS: The only thing that works is: romaing with 802.11r disabled.

Hi  @axute 

PS: The only thing that works is: romaing with 802.11r disabled.

>>>Does the 1.4.2 work when the 802.11r disabled?

axute wrote

  @Vincent-TP 

Unfortunately not.

After the rollback in point 5, firmware 1.3.2 is running, which works with all devices with ARP/Multicast enabled.

The latest firmware doesn't work with my current configuration, nor does it work with your recommendation.

 

PS: The only thing that works is: romaing with 802.11r disabled.

  @Vincent-TP 

Nope it was disabled when the AP was running with Firmware 1.4.2.

It was disabled with point 1., and also now after the rollback to 1.3.2 (point) - but everything works, and it also look like some devices are roaming (saw it in the event log).

Hi  @axute 

When using 1.4.2, clients won't connect to the EAP, regardless of any configuration, correct?

To better assist you, I've created a support ticket via your registered email address and escalated it to our support engineer to look into the issue. The ticket ID is TKID250651667. Please check your email box and ensure the support email is well received. Thanks!