Client Isolation for AP Mode (IDFGH-12805)

[SmartAppsML]

Is your feature request related to a problem?

I would like to implement a Client Isolation when the ESP is acting as Wireless Access Point, meaning that clients cannot send packets to each other, only to the AP.

As far as I know, there is no option to do so. I am able to read the raw Ethernet Frames by registering a custom callback in the internal wifi driver and that works flawlessly. But the problem is, I can only "listen" to the packets, but I cannot "intercept" them.

Describe the solution you'd like.

I would like to be able to intercept a packet if it is addressed to another WiFi client. So, all Raw Frames would go through my function, which checks the destination address in the IP header. If another WiFi client is addressed, drop the packet.

Is there an option to intercept the package? I can only "sniff" it, unfortunately.

Thank you!

Describe alternatives you've considered.

No response

Additional context.

No response

[MaxwellAlan]

Hi @SmartAppsML

Thanks for the feature request.

This is not a normal case for Wi-Fi communication. Could you share some more details about this feat request, such as working scene, request api params etc.

Thanks.

[SmartAppsML]

This is quite relevant for high security environments. It should be able to activate on startup / reboot, so no runtime change is required. Do you know if there is a way to intercept the packets? Or is it done in the closed source WiFi 802.11 library?

alanmaxwell @.***> schrieb am Mo., 13. Mai 2024, 04:53:

Hi @SmartAppsML https://github.com/SmartAppsML

Thanks for the feature request.

This is not a normal case for Wi-Fi communication. Could you share some more details about this feat request, such as working scene, request api params etc.

Thanks.

— Reply to this email directly, view it on GitHub https://github.com/espressif/esp-idf/issues/13781#issuecomment-2106542053, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6FE5ZAYQ2JGA274LUR36DZCATMFAVCNFSM6AAAAABHSB3R2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGU2DEMBVGM . You are receiving this because you were mentioned.Message ID: @.***>

[SmartAppsML]

Could you please explain what exactly happens on incoming WiFi packets? Say, we got two WiFi Clients 192.168.4.2 and 192.168.4.3 (the AP has 192.168.14.1). What happens if 192.168.14.2 sends a TCP request to 192.168.4.3. If I enable Verbose Logging and full LWIP logging, I cannot really trace that package. So, doesn't it go through the LWIP layer? Is the WiFi module directly forwarding the packet to the client without feeding it through LWIP because it is not addressed to the access point?

[MaxwellAlan]

Hi @SmartAppsML

Sorry for reply late.

This is quite relevant for high security environments. It should be able to activate on startup / reboot, so no runtime change is required. Do you know if there is a way to intercept the packets? Or is it done in the closed source WiFi 802.11 library? alanmaxwell @.***> schrieb am Mo., 13. Mai 2024, 04:53:

No, it is only can do in the closed source WiFi lib.

Could you please explain what exactly happens on incoming WiFi packets? Say, we got two WiFi Clients 192.168.4.2 and 192.168.4.3 (the AP has 192.168.14.1). What happens if 192.168.14.2 sends a TCP request to 192.168.4.3. If I enable Verbose Logging and full LWIP logging, I cannot really trace that package. So, doesn't it go through the LWIP layer? Is the WiFi module directly forwarding the packet to the client without feeding it through LWIP because it is not addressed to the access point?

Yes, not go through LWIP (IP layer), since 802.11 pkts have 4 address, which can be forwarded in MAC layer.

[Sherry616]

Thanks for reporting, will close due to short of feedback, feel free to reopen with more updates. Thanks for using our Espressif product!