Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #155720 > unrolled thread

Tablet refuses to connect to an AP that it knows

Back to article view | Back to comp.mobile.android

Contents

  Tablet refuses to connect to an AP that it knows "Carlos E.R." <robin_listas@es.invalid> - 2026-09-07 19:42 +0200
    Re: Tablet refuses to connect to an AP that it knows Maria Sophia <mariasophia@comprehension.com> - 2026-09-08 04:50 +0300
      Re: Tablet refuses to connect to an AP that it knows "Carlos E.R." <robin_listas@es.invalid> - 2026-09-08 09:41 +0200
        Re: Tablet refuses to connect to an AP that it knows Nuno Silva <nunojsilva@invalid.invalid> - 2026-09-08 09:51 +0100
          Re: Tablet refuses to connect to an AP that it knows "Carlos E.R." <robin_listas@es.invalid> - 2026-09-08 11:51 +0200
        Re: Tablet refuses to connect to an AP that it knows "Carlos E.R." <robin_listas@es.invalid> - 2026-09-08 12:45 +0200
        Re: Tablet refuses to connect to an AP that it knows Maria Sophia <mariasophia@comprehension.com> - 2026-09-08 19:02 +0300
          Re: Tablet refuses to connect to an AP that it knows "Carlos E.R." <robin_listas@es.invalid> - 2026-09-08 18:54 +0200
            Re: Tablet refuses to connect to an AP that it knows Maria Sophia <mariasophia@comprehension.com> - 2026-09-08 21:03 +0400
              Re: Tablet refuses to connect to an AP that it knows Maria Sophia <mariasophia@comprehension.com> - 2026-09-08 21:07 +0400
    Re: Tablet refuses to connect to an AP that it knows Andy Burns <usenet@andyburns.uk> - 2026-09-08 11:51 +0100
      Re: Tablet refuses to connect to an AP that it knows "Carlos E.R." <robin_listas@es.invalid> - 2026-09-08 13:35 +0200
        Re: Tablet refuses to connect to an AP that it knows Andy Burns <usenet@andyburns.uk> - 2026-09-08 13:41 +0100
          Re: Tablet refuses to connect to an AP that it knows Maria Sophia <mariasophia@comprehension.com> - 2026-09-09 20:52 +0430

#155720 — Tablet refuses to connect to an AP that it knows

Hi,

I recently did a factory reset to the main router of the house. I 
recreated the AP with the same credentials. My Linux computers connect 
fine to it. My Android phones (Motorola G52, G62) connect fine. But not 
the Lenovo Tablet (Lenovo Idea Tab 11" (8GB 128GB)).

It says (translated from Spanish):

   Saved / Not available with current security settings

If I tap on it, it says "your administrator has inhabilitated 'SSID'"

A friend has the same tablet, she came the other day here and it would 
not connect, same trouble. I thought "you have done something to it"™. I 
had to remove the connection and add it again.

Is this known? It has Android 16.

Your administrator? In Android?

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [next] | [standalone]

#155735

Carlos E.R. wrote:
> Hi,
> 
> I recently did a factory reset to the main router of the house. I 
> recreated the AP with the same credentials. My Linux computers connect 
> fine to it. My Android phones (Motorola G52, G62) connect fine. But not 
> the Lenovo Tablet (Lenovo Idea Tab 11" (8GB 128GB)).
> 
> It says (translated from Spanish):
> 
>    Saved / Not available with current security settings
> 
> If I tap on it, it says "your administrator has inhabilitated 'SSID'"
> 
> A friend has the same tablet, she came the other day here and it would 
> not connect, same trouble. I thought "you have done something to it"™. I 
> had to remove the connection and add it again.
> 
> Is this known? It has Android 16.
> 
> Your administrator? In Android?

Hi Carlos,

I have no idea what the problem might be, so these are only suggestions
made to be purposefully helpful, out of the goodness of my heart.

I have dozens of access points, and "something like this" happens to me
frequently. First, perhaps the "administrator" message is probably
misleading here. It does not necessarily mean that the tablet is managed by
an administrator or enrolled in some kind of MDM.

What you describe sounds more like Android rejecting the previously saved
WiFi configuration because the security settings of the newly recreated AP
are not quite the same as before.

The interesting clues are that the Linux machines and Motorola phones
connect normally, another identical Lenovo tablet has the same problem, and
forgetting the WiFi network and adding it again fixes the problem.

Since you just factory reset the router, I would check the WiFi security
settings. In particular, see whether it is now using WPA2/WPA3 mixed mode
instead of WPA2-Personal/AES, whether WPA3 is enabled, or whether
PMF/802.11w is set to required.

As a test, I would temporarily configure the AP as WPA2-Personal with AES
only, then forget and recreate the network on the Lenovo.

If that fixes it, then it is probably a compatibility issue between this
Lenovo/Android 16 build and the security configuration being advertised by
the router.

So I would not worry too much about the "your administrator has disabled
SSID" wording. In this context it sounds much more like Android's rather
confusing way of reporting that the saved WiFi configuration cannot
currently be used.

And the fact that forgetting the network fixes it is a pretty strong clue
that this is a stale or incompatible saved configuration rather than an
actual administrator restriction.

Lastly, by default, nowadays, all mobile phones (whether iOS or Android)
will randomize the BSSID on the device by access point, so that might also
be something to consider. I go into developer options to randomize the
BSSID not only by access point, but per connection, by the way, so that's
another level of complexity for you to consider as a possible culprit.

[toc] | [prev] | [next] | [standalone]

#155751

On 2026-09-08 03:50, Maria Sophia wrote:
> Carlos E.R. wrote:


> The interesting clues are that the Linux machines and Motorola phones
> connect normally, another identical Lenovo tablet has the same problem, and
> forgetting the WiFi network and adding it again fixes the problem.
> 
> Since you just factory reset the router, I would check the WiFi security
> settings. In particular, see whether it is now using WPA2/WPA3 mixed mode
> instead of WPA2-Personal/AES, whether WPA3 is enabled, or whether
> PMF/802.11w is set to required.

That's an interesting idea.

The security is at default settings, WPA2-PSK-AES, and is greyed out. To 
change it, I have to get into the advanced setting pages. The page in 
question is not familiar, I did not touch those settings previously.

Alternatives are

   Open/EnhancedOpen Open&OWE - warning: disables easy mesh
   EnhancedOpen Open&OWE - warning: disables easy mesh
   WPA2/WPA3 PSK&SAE - warning: not all repeaters/extender are compatible
   WPA3 SAE - Warning: make sure your devices support it.

The only one I might have been tempted to try of those is the third one. 
I enabled it now, the tablet is still complaining.


No, I don't worry about it at all, I'm just curious, because it is a 
nuisance to have to reenter the credentials.


My guess is that the BSSID changed, but the router config doesn't report 
it. It is mentioned somewhere as MAC, though

Ah, found it, for 2.4Ghz. It is not the same as reported by my Linux 
laptop in that room, there is one digit difference. Not configurable.

Ah, there is one for 2.4G and another for 5G, they differ in the last 
digit. It matches the laptop info for 5GHz, I did not know that old 
laptop had the 5Gh band.


Bingo! It changed. This command finds the change:

Legolas:~ # grep "wlan1: authenticate with" /var/log/messages


<0.6> 2026-09-07 12:05:12 Legolas kernel - - - [ T1159] wlan1: 
authenticate with 70:8b:... (local address=a0:d3:7a:...)
<0.6> 2026-09-07 12:26:22 Legolas kernel - - - [ T1159] wlan1: 
authenticate with 90:d3:... (local address=a0:d3:7a:...)


So, one more tidbit for you: my router changes the BSSID on factory 
reset, so it can not be tracked across different owners. :-)


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#155757

On 2026-09-08, Carlos E.R. wrote:

> On 2026-09-08 03:50, Maria Sophia wrote:
>> Carlos E.R. wrote:
>
>
>> The interesting clues are that the Linux machines and Motorola phones
>> connect normally, another identical Lenovo tablet has the same problem, and
>> forgetting the WiFi network and adding it again fixes the problem.
>>
>> Since you just factory reset the router, I would check the WiFi security
>> settings. In particular, see whether it is now using WPA2/WPA3 mixed mode
>> instead of WPA2-Personal/AES, whether WPA3 is enabled, or whether
>> PMF/802.11w is set to required.
>
> That's an interesting idea.
>
> The security is at default settings, WPA2-PSK-AES, and is greyed
> out. To change it, I have to get into the advanced setting pages. The
> page in question is not familiar, I did not touch those settings
> previously.
>
> Alternatives are
>
>   Open/EnhancedOpen Open&OWE - warning: disables easy mesh
>   EnhancedOpen Open&OWE - warning: disables easy mesh
>   WPA2/WPA3 PSK&SAE - warning: not all repeaters/extender are compatible
>   WPA3 SAE - Warning: make sure your devices support it.
>
> The only one I might have been tempted to try of those is the third
> one. I enabled it now, the tablet is still complaining.
>
>
> No, I don't worry about it at all, I'm just curious, because it is a
> nuisance to have to reenter the credentials.
>
>
> My guess is that the BSSID changed, but the router config doesn't
> report it. It is mentioned somewhere as MAC, though
>
> Ah, found it, for 2.4Ghz. It is not the same as reported by my Linux
> laptop in that room, there is one digit difference. Not configurable.
>
> Ah, there is one for 2.4G and another for 5G, they differ in the last
> digit. It matches the laptop info for 5GHz, I did not know that old
> laptop had the 5Gh band.
>
>
> Bingo! It changed. This command finds the change:
>
> Legolas:~ # grep "wlan1: authenticate with" /var/log/messages
>
>
> <0.6> 2026-09-07 12:05:12 Legolas kernel - - - [ T1159] wlan1:
> authenticate with 70:8b:... (local address=a0:d3:7a:...)
> <0.6> 2026-09-07 12:26:22 Legolas kernel - - - [ T1159] wlan1:
> authenticate with 90:d3:... (local address=a0:d3:7a:...)
>
>
> So, one more tidbit for you: my router changes the BSSID on factory
> reset, so it can not be tracked across different owners. :-)

Any chance it has a setting to offer separate WLANs on 5 GHz and 2.4
GHz, and that this setting now is set to show two "separate" APs?

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#155761

On 2026-09-08 10:51, Nuno Silva wrote:
> On 2026-09-08, Carlos E.R. wrote:
> 
>> On 2026-09-08 03:50, Maria Sophia wrote:
>>> Carlos E.R. wrote:
>>
>>
>>> The interesting clues are that the Linux machines and Motorola phones
>>> connect normally, another identical Lenovo tablet has the same problem, and
>>> forgetting the WiFi network and adding it again fixes the problem.
>>>
>>> Since you just factory reset the router, I would check the WiFi security
>>> settings. In particular, see whether it is now using WPA2/WPA3 mixed mode
>>> instead of WPA2-Personal/AES, whether WPA3 is enabled, or whether
>>> PMF/802.11w is set to required.
>>
>> That's an interesting idea.
>>
>> The security is at default settings, WPA2-PSK-AES, and is greyed
>> out. To change it, I have to get into the advanced setting pages. The
>> page in question is not familiar, I did not touch those settings
>> previously.
>>
>> Alternatives are
>>
>>    Open/EnhancedOpen Open&OWE - warning: disables easy mesh
>>    EnhancedOpen Open&OWE - warning: disables easy mesh
>>    WPA2/WPA3 PSK&SAE - warning: not all repeaters/extender are compatible
>>    WPA3 SAE - Warning: make sure your devices support it.
>>
>> The only one I might have been tempted to try of those is the third
>> one. I enabled it now, the tablet is still complaining.
>>
>>
>> No, I don't worry about it at all, I'm just curious, because it is a
>> nuisance to have to reenter the credentials.
>>
>>
>> My guess is that the BSSID changed, but the router config doesn't
>> report it. It is mentioned somewhere as MAC, though
>>
>> Ah, found it, for 2.4Ghz. It is not the same as reported by my Linux
>> laptop in that room, there is one digit difference. Not configurable.
>>
>> Ah, there is one for 2.4G and another for 5G, they differ in the last
>> digit. It matches the laptop info for 5GHz, I did not know that old
>> laptop had the 5Gh band.
>>
>>
>> Bingo! It changed. This command finds the change:
>>
>> Legolas:~ # grep "wlan1: authenticate with" /var/log/messages
>>
>>
>> <0.6> 2026-09-07 12:05:12 Legolas kernel - - - [ T1159] wlan1:
>> authenticate with 70:8b:... (local address=a0:d3:7a:...)
>> <0.6> 2026-09-07 12:26:22 Legolas kernel - - - [ T1159] wlan1:
>> authenticate with 90:d3:... (local address=a0:d3:7a:...)
>>
>>
>> So, one more tidbit for you: my router changes the BSSID on factory
>> reset, so it can not be tracked across different owners. :-)
> 
> Any chance it has a setting to offer separate WLANs on 5 GHz and 2.4
> GHz, and that this setting now is set to show two "separate" APs?

No, they are paired by default, same settings on both, if the setting 
exists. They can be separated, but I prefer paired.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#155765

On 2026-09-08 09:41, Carlos E.R. wrote:
> On 2026-09-08 03:50, Maria Sophia wrote:
>> Carlos E.R. wrote:
> 
> 
>> The interesting clues are that the Linux machines and Motorola phones
>> connect normally, another identical Lenovo tablet has the same 
>> problem, and
>> forgetting the WiFi network and adding it again fixes the problem.
>>
>> Since you just factory reset the router, I would check the WiFi security
>> settings. In particular, see whether it is now using WPA2/WPA3 mixed mode
>> instead of WPA2-Personal/AES, whether WPA3 is enabled, or whether
>> PMF/802.11w is set to required.
> 
> That's an interesting idea.
> 
> The security is at default settings, WPA2-PSK-AES, and is greyed out. To 
> change it, I have to get into the advanced setting pages. The page in 
> question is not familiar, I did not touch those settings previously.
> 
> Alternatives are
> 
>    Open/EnhancedOpen Open&OWE - warning: disables easy mesh
>    EnhancedOpen Open&OWE - warning: disables easy mesh
>    WPA2/WPA3 PSK&SAE - warning: not all repeaters/extender are compatible
>    WPA3 SAE - Warning: make sure your devices support it.
> 
> The only one I might have been tempted to try of those is the third one. 
> I enabled it now, the tablet is still complaining.

But tapping on it, it does connect silently, not as before. So it was 
using WPA3.

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#155773

Carlos E.R. wrote:
> My guess is that the BSSID changed, but the router config doesn't report 
> it. It is mentioned somewhere as MAC, though

Hi Carlos,

As we said, I don't see your router configuration in front of me, so I can
only purposefully helpfully offer kind advice as to what's going on there.

Regarding terminology, on Usenet, we're colloquial, so we don't write our
articles after having legal teams and documentation teams review every
nuance, so, often we casually use MAC address and BSSID interchangeably.

But they're not exactly the same thing, where a simple summary may be:
   "Every BSSID is a MAC address, but not every MAC address is a BSSID."

These are copypasted actual definitions, which we gloss over on Usenet.
 MAC Address (Media Access Control): 
   A broad, general term for the unique 48-bit hardware identifier
   assigned to any network interface card, whether it is an Ethernet 
   port, a Bluetooth chip, or a Wi-Fi adapter.

 BSSID (Basic Service Set Identifier): 
   A specific type of MAC address used exclusively in wireless networking. 
   It is the actual MAC address of the specific Wi-Fi radio interface 
   (or virtual access point) broadcasting a wireless network.

Note some sources explain the MAC address doesn't need to be a hardware ID.
 MAC Address: 
  A broad, general term for a link-layer address, commonly 48 bits in 
  Ethernet and Wi-Fi, that may be factory-assigned, locally administered, 
  virtual, or software-generated.

  Or... 

  A link-layer address used to identify a network interface.
  Ethernet/Wi-Fi commonly use 48-bit MAC addresses, but a MAC address 
  need not be permanently assigned or burned into hardware.
  In addition, software can assign locally administered addresses.

> Ah, found it, for 2.4Ghz. It is not the same as reported by my Linux 
> laptop in that room, there is one digit difference. Not configurable.
> 
> Ah, there is one for 2.4G and another for 5G, they differ in the last 
> digit. It matches the laptop info for 5GHz, I did not know that old 
> laptop had the 5Gh band.

Each physical chip (2.4GHz, 5GHz) possesses a single, permanent, burned-in
MAC address assigned by the manufacturer at the factory. But a single
physical network chip can host multiple virtual interfaces simultaneously.

That's how it can 
 a. Broadcast a primary home network
 b. Plus, a concurrent isolated guest network 
 c. and a concurrent IoT device network 

It has been my experience, and perhaps that of others, that dual-band
wireless chipsets typically assign sequential MAC addresses (often
differing by 1 or 2 in the final digits) to separate the 2.4 GHz and 5 GHz
virtual interfaces.
 a. One for for 2.4 GHz (70:8b:...)
 b. A similar one for 5 GHz (90:d3:...)

There's usually more virtualization with the 2.4GHz chip due to the many
older/cheaper devices which can connect to it, but just like the 5 GHz
radio, a 2.4 GHz physical radio slices its hardware block into multiple
virtual interfaces, assigning each one a unique BSSID, often derived
sequentially from the chip's base address pool (but they can be random).

> So, one more tidbit for you: my router changes the BSSID on factory 
> reset, so it can not be tracked across different owners. :-)

One can often identify a randomized BSSID by the U/L (universal/local) bit,
which is the second-least-significant bit of the first octet. 
second hex character is not 0, 4, 8, or C for a randomized BSSID, but
instead, it's 2, 6, A, or E. However, that tells us only that the address
is locally administered but it does not prove that it was generated by a
randomization mechanism.
<https://help.elevensoftware.com/hc/en-us/articles/47366137023629-Identifying-a-Randomized-MAC-Address>

Besides, relying on an accidental firmware re-indexing events in some
routers may not be an easily usable workaround unless people are willing to
frequently factory reset their routers (if the router has that feature).

I said from the start that some routers can change the outward-facing
BSSID, and the paper explicitly says that some APs already randomize their
BSSIDs and the authors recommend making that behavior much more widespread.
   *Surveilling the Masses with Wi-Fi-Based Positioning Systems*
    <https://par.nsf.gov/servlets/purl/10540853>

If I can afford it, my next router will be the kind that changes the BSSID.
BTW, apparently OpenWrt added that feature for certain compatible routers.

This is more viable than relying on accidental changes in a factory reset.

 <https://forum.archive.openwrt.org/viewtopic.php?id=62768>
 option macaddr Overrides the MAC address used for the Wi-Fi interface.
 when set to random, OpenWrt generates a new locally administered
 unicast MAC address every time the interface is (re-)configured.
 /etc/config/wireless
   config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'MyWiFi'
    option encryption 'sae-mixed'
    option key 'your-password'
    option macaddr 'random'

However, there's a catch (there always is, as the devil is in details).

When we manually set a custom MAC address, network standards require us to
flip a specific bit in the first byte (making the second hexadecimal digit
a 2, 6, A, or E). This tells networking equipment that the address is
locally defined software rather than a permanent factory hardware ID.

Note: 2, 6, A, or E in the second hex digit tells us the address is a
locally administered unicast address (assuming ordinary left-to-right MAC
notation). That can result from randomization but can also be a fixed
manually configured address	in routers that allow changes.

Pop quiz!

Which three of the following are factory burned BSSIDs, vs randomized?
 a. 00:1A:2B:3C:4D:50 
 b. 40:1A:2B:3C:4D:50 
 c. 80:1A:2B:3C:4D:50
 d. 02:1A:2B:3C:4D:50 
 e. 46:1A:2B:3C:4D:50 
 f. 8A:1A:2B:3C:4D:50 

HINT: Look at the binary representation of the second character 
      (check the second-to-last bit, i.e., the Universal/Local flag).
-- 
Usenet is where kind-hearted people gather to voluntarily help others.	

[toc] | [prev] | [next] | [standalone]

#155777

On 2026-09-08 18:02, Maria Sophia wrote:
> Carlos E.R. wrote:

> Pop quiz!
> 
> Which three of the following are factory burned BSSIDs, vs randomized?
>   a. 00:1A:2B:3C:4D:50
>   b. 40:1A:2B:3C:4D:50
>   c. 80:1A:2B:3C:4D:50
>   d. 02:1A:2B:3C:4D:50
>   e. 46:1A:2B:3C:4D:50
>   f. 8A:1A:2B:3C:4D:50
> 
> HINT: Look at the binary representation of the second character
>        (check the second-to-last bit, i.e., the Universal/Local flag).


d e f


-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#155780

Carlos E.R. wrote:
>> Which three of the following are factory burned BSSIDs, vs randomized?
>>   a. 00:1A:2B:3C:4D:50
>>   b. 40:1A:2B:3C:4D:50
>>   c. 80:1A:2B:3C:4D:50
>>   d. 02:1A:2B:3C:4D:50
>>   e. 46:1A:2B:3C:4D:50
>>   f. 8A:1A:2B:3C:4D:50
>> 
>> HINT: Look at the binary representation of the second character
>>        (check the second-to-last bit, i.e., the Universal/Local flag).
> 
> 
> d e f

Thank you for being the one out of 100 who understands the concepts!

[toc] | [prev] | [next] | [standalone]

#155781

Maria Sophia wrote:
>> d e f
> 
> Thank you for being the one out of 100 who understands the concepts!

Carlos got the point that the first half are different from the second
half, but we should clarify which half is which in this specific case.

The key to factory-vs-administered is the U/L (Universal/Local) bit, which
is the 2nd-least-significant bit of the first octet (not the 2nd hex char).

a. 00 -> binary 00000000 -> U/L = 0 -> factory/universally administered
b. 40 -> 01000000 -> U/L = 0 -> factory/universally administered
c. 80 -> 10000000 -> U/L = 0 -> factory/universally administered
d. 02 -> 00000010 -> U/L = 1 -> locally administered/randomized
e. 46 -> 01000110 -> U/L = 1 -> locally administered/randomized
f. 8A -> 10001010 -> U/L = 1 -> locally administered/randomized

Factory burned:  a, b, c
Locally administered/randomized:  d, e, f

[toc] | [prev] | [next] | [standalone]

#155766

Carlos E.R. wrote:

> I recently did a factory reset to the main router of the house. I 
> recreated the AP with the same credentials. My Linux computers connect 
> fine to it. My Android phones (Motorola G52, G62) connect fine. But not 
> the Lenovo Tablet (Lenovo Idea Tab 11" (8GB 128GB)).
Has the factory reset changed the to a high wifi channel number that 
some devices don't support? (e.g. 13 or 14)

[toc] | [prev] | [next] | [standalone]

#155768

On 2026-09-08 12:51, Andy Burns wrote:
> Carlos E.R. wrote:
> 
>> I recently did a factory reset to the main router of the house. I 
>> recreated the AP with the same credentials. My Linux computers connect 
>> fine to it. My Android phones (Motorola G52, G62) connect fine. But 
>> not the Lenovo Tablet (Lenovo Idea Tab 11" (8GB 128GB)).
> Has the factory reset changed the to a high wifi channel number that 
> some devices don't support? (e.g. 13 or 14)

No, that is defined by the default country (Spain).

-- 
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#155770

Carlos E.R. wrote:

> Andy Burns wrote:
> >> Carlos E.R. wrote:
>>
>>> I recently did a factory reset to the main router of the house. I 
>>> recreated the AP with the same credentials. My Linux computers 
>>> connect fine to it. My Android phones (Motorola G52, G62) connect 
>>> fine. But not the Lenovo Tablet (Lenovo Idea Tab 11" (8GB 128GB)).
>> >> Has the factory reset changed the to a high wifi channel number that
>> some devices don't support? (e.g. 13 or 14)
> 
> No, that is defined by the default country (Spain).
ch13 is allowed in the UK (ch14 is not allowed) but I have owned devices 
which refused to work on ch13 ...

[toc] | [prev] | [next] | [standalone]

#155819

Andy Burns wrote:
>> No, that is defined by the default country (Spain).
> ch13 is allowed in the UK (ch14 is not allowed) but I have owned devices 
> which refused to work on ch13 ...

I envy that you guys across the pond get more 2.4GHz channels than we do!

I think we get choices of higher transmit power though, at least in the
Ubiquiti radios that I manually administer for my community WISP project.

2.4 GHz:
 USA  36 dBm (4 W EIRP)
 UK   20 dBm (0.1 W EIRP)

5 GHz:
 USA  up to 36 dBm (4 W EIRP), depending on sub-band
 UK   up to 30 dBm (1 W EIRP), depending on sub-band

Dunno about the rest of Europe.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.mobile.android

csiph-web