Skip to main content
added 5 characters in body; deleted 13 characters in body; deleted 14 characters in body
Source Link
Rui F Ribeiro
  • 58k
  • 28
  • 156
  • 238

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers of your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow the login to proceed.

PS. For instance, FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the gateway /wifi AP address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

PPS for future visitors, using either Mac or Linux, bear in mind: Firefox is capable of dealing with captive portals in it's own. However, some older captive portals will force you to get the DNS servers from their DHCP e.g. won't work with fixed DNS servers/DNS over TLS on your configuration.

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers of your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow the login to proceed.

PS. For instance, FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the gateway /wifi AP address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

PPS for future visitors, either Mac or Linux, bear in mind Firefox is capable of dealing with captive portals in it's own. However, some older captive portals will force you to get the DNS servers from their DHCP e.g. won't work with fixed DNS servers/DNS over TLS on your configuration.

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers of your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow the login to proceed.

PS. FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the gateway /wifi AP address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

PPS for future visitors using either Mac or Linux: Firefox is capable of dealing with captive portals in it's own. However, some older captive portals will force you to get the DNS servers from their DHCP e.g. won't work with fixed DNS servers/DNS over TLS on your configuration.

added 12 characters in body; added 5 characters in body; added 8 characters in body; deleted 9 characters in body; deleted 9 characters in body
Source Link
Rui F Ribeiro
  • 58k
  • 28
  • 156
  • 238

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will make you lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers you have onof your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow you tothe login to proceed.

PS. For instance, FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the gateway /wifi AP address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

PPS for future visitors, either Mac or Linux, bear in mind Firefox is capable of dealing with captive portals in it's own. However, some older captive portals will force you to get the DNS servers from their DHCP e.g. won't work with fixed DNS servers/DNS over TLS on your configuration.

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will make you lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers you have on your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow you to login.

PS. For instance, FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

PPS for future visitors, either Mac or Linux, bear in mind Firefox is capable of dealing with captive portals in it's own. However, some older captive portals will force you to get the DNS servers from their DHCP e.g. won't work with fixed DNS servers/DNS over TLS on your configuration.

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers of your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow the login to proceed.

PS. For instance, FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the gateway /wifi AP address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

PPS for future visitors, either Mac or Linux, bear in mind Firefox is capable of dealing with captive portals in it's own. However, some older captive portals will force you to get the DNS servers from their DHCP e.g. won't work with fixed DNS servers/DNS over TLS on your configuration.

added 291 characters in body
Source Link
Rui F Ribeiro
  • 58k
  • 28
  • 156
  • 238

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will make you lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers you have on your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow you to login.

PS. For instance, FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

PPS for future visitors, either Mac or Linux, bear in mind Firefox is capable of dealing with captive portals in it's own. However, some older captive portals will force you to get the DNS servers from their DHCP e.g. won't work with fixed DNS servers/DNS over TLS on your configuration.

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will make you lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers you have on your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow you to login.

PS. For instance, FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

The point on the Wifi connectivity issue in the captive portal Mac login process is that if the process is not successful, either by lack of login, or some other technical problem in the Apple Captive Network Assistant (CNA), it will make you lose Wifi connectivity.

So, the lack of ping connectivity is a symptom and not a cause.

As it is a fairly common problem with some captive portals, depending on their configuration, I would venture to say you need to take out the hardcoded DNS servers you have on your DNS configuration.

After you taking them out, it will allow the DHCP request to get Starbuck's own captive DNS portal servers, which will allow you to login.

PS. For instance, FON captive portals from at least of our Telecom operators (NÓS) used to have the very same problem - and behaviour - for years, now they seem to have catch on and just probably inserted firewall rules in the new firmware versions to intercept any non-encrypted DNS requests coming from clients connected via Wifi.

PS2. If you disable the CNA, you will be able to get away at least with pinging the address.

However for opening the authentication portal before authenticating, you will still need to take out your hardcoded DNS addresses first.

See Disabling CNA in MacOS

PPS for future visitors, either Mac or Linux, bear in mind Firefox is capable of dealing with captive portals in it's own. However, some older captive portals will force you to get the DNS servers from their DHCP e.g. won't work with fixed DNS servers/DNS over TLS on your configuration.

added 30 characters in body
Source Link
Rui F Ribeiro
  • 58k
  • 28
  • 156
  • 238
Loading
added 248 characters in body
Source Link
Rui F Ribeiro
  • 58k
  • 28
  • 156
  • 238
Loading
added 227 characters in body
Source Link
Rui F Ribeiro
  • 58k
  • 28
  • 156
  • 238
Loading
added 227 characters in body
Source Link
Rui F Ribeiro
  • 58k
  • 28
  • 156
  • 238
Loading
Source Link
Rui F Ribeiro
  • 58k
  • 28
  • 156
  • 238
Loading