Feature Request: Anti-Tethering, Native Hotspot Detection, and Random MAC Prevention for Multi-Tenant Environments

Feature Requests
1

Hi Alta Labs R&D Team,

I am writing to share a critical requirement and feature request based on real-world deployment challenges we face in the UAE market, specifically within High-Density Multi-Tenant environments such as Labor Camps and Staff Accommodations.

1. Background & Problem Statement

In these accommodation setups, Internet Service Providers or System Integrators deploy paid/tiered Wi-Fi models (e.g., monthly packages per user with bandwidth capping). Access is strictly managed per user via MAC binding / Captive Portal authentication.

However, major loopholes are actively being exploited by users:

Users activate the native Mobile Hotspot sharing features (on Android and iOS) or install third-party tethering apps, turning their phones into NAT devices.

Users frequently leverage Randomized/Private MAC address features on their mobile devices, bypassing MAC binding and complicating user identification and bandwidth management.

Impact: Network abuse, severe bandwidth degradation, and substantial revenue/control losses for administrators.

2. Requested Solution / Feature Implementation

To prevent these issues at the Gateway or Access Point level, we request Alta Labs to evaluate incorporating the following mechanisms into the Route10 (Gateway) / Alta Control / AP Firmware:

A. Native Hotspot & Tethering Prevention Mechanisms:

Implement detection of native Android/iOS hotspot configurations by inspecting DHCP fingerprints or TCP/IP signatures originating from a single associated MAC.

Provide an option to block clients that exhibit characteristics of acting as a NAT or DHCP server.

B. Random/Private MAC Address Prevention:

Implement features to detect and optionally block clients using randomized MAC addresses, enforcing the use of the device’s actual hardware MAC address for authentication and binding.

C. TTL (Time to Live) / Hop Count Inspection:

Inspect the IPv4 TTL or IPv6 Hop Limit. Packets routed through a phone’s internal NAT will have an incremented/decremented TTL.

Feature Request: Ability to enforce/reset TTL at the gateway level or drop packets with non-standard TTLs.

D. MAC/IP Connection Limits:

Implement configurable connection rate limits and maximum concurrent TCP/UDP session limits per authenticated MAC to make tethering unusable.

E. App / Protocol DPI Filtering:

Identify and block traffic patterns generated by popular Wi-Fi tethering/proxy applications.

2
  1. We have support for limiting the number of client devices per password, which can be used to accomplish this. Please let me know if you disagree!
  2. There’s no (easy) way to detect random/private MAC address prevention, but if you are using AltaPass, then there shouldn’t be a need, since you know what password is being used, and can apply policies based on that.

Please let me know if I am missing something.

3

Hi Jeff,

Thanks for the quick reply!

I wanted to clarify why limiting devices per password doesn’t solve this issue in our accommodation setups. When a user turns on their phone’s mobile hotspot, they connect to the Wi-Fi using a single password, but their phone acts as a NAT router. Downstream devices connect directly to the phone rather than the Alta AP, so to the network, it still appears as only one device—completely bypassing device limits and allowing one account to be shared across multiple users.

Since we have no control over the user sharing their internet connection via password on their phone, we need lower-level gateway checks on the Route10 to detect routed traffic:

1. TTL Inspection/Enforcement: Dropping or resetting packets with decremented TTLs caused by phone-level NAT.

2. Concurrent Session Limits per MAC or IP/Subnet: Capping TCP/UDP connections so a single phone cannot route traffic for multiple secondary users.

Please let us know if these mechanisms could be considered for future firmware updates.

4

OK, gotcha. We can definitely consider it, but I know many ISPs have tried to implement something similar, and it’s very easy to get false negatives.

5

Thanks, Jeff! You’re totally right—advanced users can manipulate TTL settings or use VPNs to bypass detection.

That said, given these limitations, what alternative methods or best practices would the Alta team recommend to effectively restrict or manage Wi-Fi hotspot sharing and unauthorized bandwidth consumption in high-density multi-tenant environments?

Appreciate your insights!

6

Enforcing lower instantaneous bandwidth limits (50 Mbps, etc) or monthly bandwidth caps are common solutions for this.

7

Thanks, Jeff! Lowering bandwidth limits helps manage total usage, but it doesn’t solve the core issue—users still pool their limits and share one connection among several people, which affects network performance and paid Wi-Fi revenue.
We are still looking for a native solution for these setups. As a reference, TP-Link Omada recently added a “Prohibit Wi-Fi Sharing” option in their AP settings (attached screenshot for reference).
I haven’t tested how they implemented it under the hood yet, but having a similar native toggle in Alta APs or the Route10 would stop the vast majority of standard hotspot sharing and be a huge advantage for multi-tenant projects.
Appreciate you passing this feedback to the team!

IMG_0011
IMG_00111290Ă—1562 419 KB

IMG_0010
IMG_00101290Ă—695 67.5 KB

8

I’d be curious to know how well that works, and how quickly it gets worked around :wink: