How to sign into an open Wireless Network?

Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
I'm running Arch Linux on my netbook. My school have an open Access Point and we must sign into the network via a page which we are redirected to when we try to open whatever website if we are not connected.
It works on my Android Smartphone. It works on Windows. It should also works on Linux since my teacher is able to connect to it (he's running Ubuntu).
I connect to the access point with wifi-menu to generate a netctl profile. I am connected but I am not redirected to the login page, and when I type the address (taken from my phone) it don't find the server... I tried disabling IPv6, but nothing change...
linux arch-linux wifi authentication
add a comment |Â
up vote
6
down vote
favorite
I'm running Arch Linux on my netbook. My school have an open Access Point and we must sign into the network via a page which we are redirected to when we try to open whatever website if we are not connected.
It works on my Android Smartphone. It works on Windows. It should also works on Linux since my teacher is able to connect to it (he's running Ubuntu).
I connect to the access point with wifi-menu to generate a netctl profile. I am connected but I am not redirected to the login page, and when I type the address (taken from my phone) it don't find the server... I tried disabling IPv6, but nothing change...
linux arch-linux wifi authentication
It's running a service like networkmanager on your system?
â mavillan
Sep 6 '13 at 6:47
I don't think so... I have netctl which use wpa_supplicant... I discovered that there's also another network, which is securised by WPA. I can put login using my credentials that I should put in the login page for the open network, but I still can't access the web... Tried with my phone : it works...
â Matthieu Harlé
Sep 6 '13 at 7:28
It sounds like this could be an DNS issue. Can you confirm if you can access a remote host directly via an IP address?
â Thomas Nyman
Sep 6 '13 at 19:14
add a comment |Â
up vote
6
down vote
favorite
up vote
6
down vote
favorite
I'm running Arch Linux on my netbook. My school have an open Access Point and we must sign into the network via a page which we are redirected to when we try to open whatever website if we are not connected.
It works on my Android Smartphone. It works on Windows. It should also works on Linux since my teacher is able to connect to it (he's running Ubuntu).
I connect to the access point with wifi-menu to generate a netctl profile. I am connected but I am not redirected to the login page, and when I type the address (taken from my phone) it don't find the server... I tried disabling IPv6, but nothing change...
linux arch-linux wifi authentication
I'm running Arch Linux on my netbook. My school have an open Access Point and we must sign into the network via a page which we are redirected to when we try to open whatever website if we are not connected.
It works on my Android Smartphone. It works on Windows. It should also works on Linux since my teacher is able to connect to it (he's running Ubuntu).
I connect to the access point with wifi-menu to generate a netctl profile. I am connected but I am not redirected to the login page, and when I type the address (taken from my phone) it don't find the server... I tried disabling IPv6, but nothing change...
linux arch-linux wifi authentication
linux arch-linux wifi authentication
edited Sep 6 '13 at 22:14
Gilles
516k12210281557
516k12210281557
asked Sep 6 '13 at 6:24
Matthieu Harlé
133115
133115
It's running a service like networkmanager on your system?
â mavillan
Sep 6 '13 at 6:47
I don't think so... I have netctl which use wpa_supplicant... I discovered that there's also another network, which is securised by WPA. I can put login using my credentials that I should put in the login page for the open network, but I still can't access the web... Tried with my phone : it works...
â Matthieu Harlé
Sep 6 '13 at 7:28
It sounds like this could be an DNS issue. Can you confirm if you can access a remote host directly via an IP address?
â Thomas Nyman
Sep 6 '13 at 19:14
add a comment |Â
It's running a service like networkmanager on your system?
â mavillan
Sep 6 '13 at 6:47
I don't think so... I have netctl which use wpa_supplicant... I discovered that there's also another network, which is securised by WPA. I can put login using my credentials that I should put in the login page for the open network, but I still can't access the web... Tried with my phone : it works...
â Matthieu Harlé
Sep 6 '13 at 7:28
It sounds like this could be an DNS issue. Can you confirm if you can access a remote host directly via an IP address?
â Thomas Nyman
Sep 6 '13 at 19:14
It's running a service like networkmanager on your system?
â mavillan
Sep 6 '13 at 6:47
It's running a service like networkmanager on your system?
â mavillan
Sep 6 '13 at 6:47
I don't think so... I have netctl which use wpa_supplicant... I discovered that there's also another network, which is securised by WPA. I can put login using my credentials that I should put in the login page for the open network, but I still can't access the web... Tried with my phone : it works...
â Matthieu Harlé
Sep 6 '13 at 7:28
I don't think so... I have netctl which use wpa_supplicant... I discovered that there's also another network, which is securised by WPA. I can put login using my credentials that I should put in the login page for the open network, but I still can't access the web... Tried with my phone : it works...
â Matthieu Harlé
Sep 6 '13 at 7:28
It sounds like this could be an DNS issue. Can you confirm if you can access a remote host directly via an IP address?
â Thomas Nyman
Sep 6 '13 at 19:14
It sounds like this could be an DNS issue. Can you confirm if you can access a remote host directly via an IP address?
â Thomas Nyman
Sep 6 '13 at 19:14
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
6
down vote
accepted
What you describe is called a captive portal. They are typically used for authentication on Wi-Fi hotspots, but can be used to control wired network access as well.
There are several ways to implement a captive portal:
HTTP Redirection
In this case, DNS queries from unauthenticated clients are resolved as normal. However, when the browser makes a HTTP request to the resolved IP address, the request is intercepted by a firewall acting as a transparent proxy. The client HTTP request is forwarded to a server in the local network which issues a server-side redirect with a HTTP 302 Found status code, which will redirect the client to the captive portal.
DNS Redirection
In DNS based redirection the firewall ensures that only the DNS server(s) provided by DHCP may be used by authenticated clients. The firewall could also redirect any DNS queries from unauthenticated clients to the local DNS server. This DNS server will in turn return the IP address of the captive portal as a response to all DNS lookups made by unauthenticated clients.
IP Redirection
In redirection working on the IP layer a router performs Destination Network Address Translation (DNAT) to reroute packets originating from an captive hosts to the captive portal. In cases where the captive portal software runs on the router itself, the packets are directed to an internal interface instead. Packets headed from the captive portal to the host get in turn their source address rewritten so that they would appear to originate from the original destination.
When troubleshooting captive portal issues, the first step would be to identify what type of redirection is in use and at which point the redirection fails. The right tool for this job is a packet analyzer, such as Wireshark. Keep in mind though, that your school's IT policy might prohibit the use of packet sniffers on the local network as such tools could easily be used to invade the privacy of others on an unencrypted network.
You could also consult the tech support at your school. They would be aware of the captive portal configuration on the local Wi-Fi network, and especially if faculty members are using Linux they probably could help in pinpointing the source of the problem.
@Shywim My post is not much of an answer, but it's hard to give specific advice without knowing more about the specific captive portal solution used at your school.
â Thomas Nyman
Sep 6 '13 at 19:02
That's fine, it is very instructive. My problem seems to be different (I have the same problem with other networks), but I'll leave this question and accept your answer. :)
â Matthieu Harlé
Sep 9 '13 at 9:43
I would find it useful if this answer were edited to include information about what to look for in the packet traffic and how to respond accordingly.
â inquiryqueue
Dec 11 '14 at 19:11
add a comment |Â
up vote
12
down vote
If redirect page does not load, and reconnecting does not fix the issue, then the easiest next step is to address the router directly.
Try 192.168.1.1. That is the most common default address, and is often not changed.
Addressing the router should send you to the redirect page.
1
Or 10.10.1.1, which worked in my case.
â Ray
Jul 1 '17 at 21:55
add a comment |Â
up vote
1
down vote
In my case being signed in to Chrome was getting in the way. When I opened up an incognito window and went to a random webpage the redirection worked. I got this idea from a post on an Arch Linux thread.
add a comment |Â
up vote
0
down vote
Enter http://nmcheck.gnome.org in your browser.
(I added the "hotspot login" of Ubuntu 18 to my favorites and it showed that address, every time I clicked on it.)
It worked for me.
New contributor
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
What you describe is called a captive portal. They are typically used for authentication on Wi-Fi hotspots, but can be used to control wired network access as well.
There are several ways to implement a captive portal:
HTTP Redirection
In this case, DNS queries from unauthenticated clients are resolved as normal. However, when the browser makes a HTTP request to the resolved IP address, the request is intercepted by a firewall acting as a transparent proxy. The client HTTP request is forwarded to a server in the local network which issues a server-side redirect with a HTTP 302 Found status code, which will redirect the client to the captive portal.
DNS Redirection
In DNS based redirection the firewall ensures that only the DNS server(s) provided by DHCP may be used by authenticated clients. The firewall could also redirect any DNS queries from unauthenticated clients to the local DNS server. This DNS server will in turn return the IP address of the captive portal as a response to all DNS lookups made by unauthenticated clients.
IP Redirection
In redirection working on the IP layer a router performs Destination Network Address Translation (DNAT) to reroute packets originating from an captive hosts to the captive portal. In cases where the captive portal software runs on the router itself, the packets are directed to an internal interface instead. Packets headed from the captive portal to the host get in turn their source address rewritten so that they would appear to originate from the original destination.
When troubleshooting captive portal issues, the first step would be to identify what type of redirection is in use and at which point the redirection fails. The right tool for this job is a packet analyzer, such as Wireshark. Keep in mind though, that your school's IT policy might prohibit the use of packet sniffers on the local network as such tools could easily be used to invade the privacy of others on an unencrypted network.
You could also consult the tech support at your school. They would be aware of the captive portal configuration on the local Wi-Fi network, and especially if faculty members are using Linux they probably could help in pinpointing the source of the problem.
@Shywim My post is not much of an answer, but it's hard to give specific advice without knowing more about the specific captive portal solution used at your school.
â Thomas Nyman
Sep 6 '13 at 19:02
That's fine, it is very instructive. My problem seems to be different (I have the same problem with other networks), but I'll leave this question and accept your answer. :)
â Matthieu Harlé
Sep 9 '13 at 9:43
I would find it useful if this answer were edited to include information about what to look for in the packet traffic and how to respond accordingly.
â inquiryqueue
Dec 11 '14 at 19:11
add a comment |Â
up vote
6
down vote
accepted
What you describe is called a captive portal. They are typically used for authentication on Wi-Fi hotspots, but can be used to control wired network access as well.
There are several ways to implement a captive portal:
HTTP Redirection
In this case, DNS queries from unauthenticated clients are resolved as normal. However, when the browser makes a HTTP request to the resolved IP address, the request is intercepted by a firewall acting as a transparent proxy. The client HTTP request is forwarded to a server in the local network which issues a server-side redirect with a HTTP 302 Found status code, which will redirect the client to the captive portal.
DNS Redirection
In DNS based redirection the firewall ensures that only the DNS server(s) provided by DHCP may be used by authenticated clients. The firewall could also redirect any DNS queries from unauthenticated clients to the local DNS server. This DNS server will in turn return the IP address of the captive portal as a response to all DNS lookups made by unauthenticated clients.
IP Redirection
In redirection working on the IP layer a router performs Destination Network Address Translation (DNAT) to reroute packets originating from an captive hosts to the captive portal. In cases where the captive portal software runs on the router itself, the packets are directed to an internal interface instead. Packets headed from the captive portal to the host get in turn their source address rewritten so that they would appear to originate from the original destination.
When troubleshooting captive portal issues, the first step would be to identify what type of redirection is in use and at which point the redirection fails. The right tool for this job is a packet analyzer, such as Wireshark. Keep in mind though, that your school's IT policy might prohibit the use of packet sniffers on the local network as such tools could easily be used to invade the privacy of others on an unencrypted network.
You could also consult the tech support at your school. They would be aware of the captive portal configuration on the local Wi-Fi network, and especially if faculty members are using Linux they probably could help in pinpointing the source of the problem.
@Shywim My post is not much of an answer, but it's hard to give specific advice without knowing more about the specific captive portal solution used at your school.
â Thomas Nyman
Sep 6 '13 at 19:02
That's fine, it is very instructive. My problem seems to be different (I have the same problem with other networks), but I'll leave this question and accept your answer. :)
â Matthieu Harlé
Sep 9 '13 at 9:43
I would find it useful if this answer were edited to include information about what to look for in the packet traffic and how to respond accordingly.
â inquiryqueue
Dec 11 '14 at 19:11
add a comment |Â
up vote
6
down vote
accepted
up vote
6
down vote
accepted
What you describe is called a captive portal. They are typically used for authentication on Wi-Fi hotspots, but can be used to control wired network access as well.
There are several ways to implement a captive portal:
HTTP Redirection
In this case, DNS queries from unauthenticated clients are resolved as normal. However, when the browser makes a HTTP request to the resolved IP address, the request is intercepted by a firewall acting as a transparent proxy. The client HTTP request is forwarded to a server in the local network which issues a server-side redirect with a HTTP 302 Found status code, which will redirect the client to the captive portal.
DNS Redirection
In DNS based redirection the firewall ensures that only the DNS server(s) provided by DHCP may be used by authenticated clients. The firewall could also redirect any DNS queries from unauthenticated clients to the local DNS server. This DNS server will in turn return the IP address of the captive portal as a response to all DNS lookups made by unauthenticated clients.
IP Redirection
In redirection working on the IP layer a router performs Destination Network Address Translation (DNAT) to reroute packets originating from an captive hosts to the captive portal. In cases where the captive portal software runs on the router itself, the packets are directed to an internal interface instead. Packets headed from the captive portal to the host get in turn their source address rewritten so that they would appear to originate from the original destination.
When troubleshooting captive portal issues, the first step would be to identify what type of redirection is in use and at which point the redirection fails. The right tool for this job is a packet analyzer, such as Wireshark. Keep in mind though, that your school's IT policy might prohibit the use of packet sniffers on the local network as such tools could easily be used to invade the privacy of others on an unencrypted network.
You could also consult the tech support at your school. They would be aware of the captive portal configuration on the local Wi-Fi network, and especially if faculty members are using Linux they probably could help in pinpointing the source of the problem.
What you describe is called a captive portal. They are typically used for authentication on Wi-Fi hotspots, but can be used to control wired network access as well.
There are several ways to implement a captive portal:
HTTP Redirection
In this case, DNS queries from unauthenticated clients are resolved as normal. However, when the browser makes a HTTP request to the resolved IP address, the request is intercepted by a firewall acting as a transparent proxy. The client HTTP request is forwarded to a server in the local network which issues a server-side redirect with a HTTP 302 Found status code, which will redirect the client to the captive portal.
DNS Redirection
In DNS based redirection the firewall ensures that only the DNS server(s) provided by DHCP may be used by authenticated clients. The firewall could also redirect any DNS queries from unauthenticated clients to the local DNS server. This DNS server will in turn return the IP address of the captive portal as a response to all DNS lookups made by unauthenticated clients.
IP Redirection
In redirection working on the IP layer a router performs Destination Network Address Translation (DNAT) to reroute packets originating from an captive hosts to the captive portal. In cases where the captive portal software runs on the router itself, the packets are directed to an internal interface instead. Packets headed from the captive portal to the host get in turn their source address rewritten so that they would appear to originate from the original destination.
When troubleshooting captive portal issues, the first step would be to identify what type of redirection is in use and at which point the redirection fails. The right tool for this job is a packet analyzer, such as Wireshark. Keep in mind though, that your school's IT policy might prohibit the use of packet sniffers on the local network as such tools could easily be used to invade the privacy of others on an unencrypted network.
You could also consult the tech support at your school. They would be aware of the captive portal configuration on the local Wi-Fi network, and especially if faculty members are using Linux they probably could help in pinpointing the source of the problem.
answered Sep 6 '13 at 18:55
Thomas Nyman
19.5k74868
19.5k74868
@Shywim My post is not much of an answer, but it's hard to give specific advice without knowing more about the specific captive portal solution used at your school.
â Thomas Nyman
Sep 6 '13 at 19:02
That's fine, it is very instructive. My problem seems to be different (I have the same problem with other networks), but I'll leave this question and accept your answer. :)
â Matthieu Harlé
Sep 9 '13 at 9:43
I would find it useful if this answer were edited to include information about what to look for in the packet traffic and how to respond accordingly.
â inquiryqueue
Dec 11 '14 at 19:11
add a comment |Â
@Shywim My post is not much of an answer, but it's hard to give specific advice without knowing more about the specific captive portal solution used at your school.
â Thomas Nyman
Sep 6 '13 at 19:02
That's fine, it is very instructive. My problem seems to be different (I have the same problem with other networks), but I'll leave this question and accept your answer. :)
â Matthieu Harlé
Sep 9 '13 at 9:43
I would find it useful if this answer were edited to include information about what to look for in the packet traffic and how to respond accordingly.
â inquiryqueue
Dec 11 '14 at 19:11
@Shywim My post is not much of an answer, but it's hard to give specific advice without knowing more about the specific captive portal solution used at your school.
â Thomas Nyman
Sep 6 '13 at 19:02
@Shywim My post is not much of an answer, but it's hard to give specific advice without knowing more about the specific captive portal solution used at your school.
â Thomas Nyman
Sep 6 '13 at 19:02
That's fine, it is very instructive. My problem seems to be different (I have the same problem with other networks), but I'll leave this question and accept your answer. :)
â Matthieu Harlé
Sep 9 '13 at 9:43
That's fine, it is very instructive. My problem seems to be different (I have the same problem with other networks), but I'll leave this question and accept your answer. :)
â Matthieu Harlé
Sep 9 '13 at 9:43
I would find it useful if this answer were edited to include information about what to look for in the packet traffic and how to respond accordingly.
â inquiryqueue
Dec 11 '14 at 19:11
I would find it useful if this answer were edited to include information about what to look for in the packet traffic and how to respond accordingly.
â inquiryqueue
Dec 11 '14 at 19:11
add a comment |Â
up vote
12
down vote
If redirect page does not load, and reconnecting does not fix the issue, then the easiest next step is to address the router directly.
Try 192.168.1.1. That is the most common default address, and is often not changed.
Addressing the router should send you to the redirect page.
1
Or 10.10.1.1, which worked in my case.
â Ray
Jul 1 '17 at 21:55
add a comment |Â
up vote
12
down vote
If redirect page does not load, and reconnecting does not fix the issue, then the easiest next step is to address the router directly.
Try 192.168.1.1. That is the most common default address, and is often not changed.
Addressing the router should send you to the redirect page.
1
Or 10.10.1.1, which worked in my case.
â Ray
Jul 1 '17 at 21:55
add a comment |Â
up vote
12
down vote
up vote
12
down vote
If redirect page does not load, and reconnecting does not fix the issue, then the easiest next step is to address the router directly.
Try 192.168.1.1. That is the most common default address, and is often not changed.
Addressing the router should send you to the redirect page.
If redirect page does not load, and reconnecting does not fix the issue, then the easiest next step is to address the router directly.
Try 192.168.1.1. That is the most common default address, and is often not changed.
Addressing the router should send you to the redirect page.
edited Feb 9 '17 at 5:02
Stephen Rauch
3,278101328
3,278101328
answered Feb 9 '17 at 2:21
Matt
12112
12112
1
Or 10.10.1.1, which worked in my case.
â Ray
Jul 1 '17 at 21:55
add a comment |Â
1
Or 10.10.1.1, which worked in my case.
â Ray
Jul 1 '17 at 21:55
1
1
Or 10.10.1.1, which worked in my case.
â Ray
Jul 1 '17 at 21:55
Or 10.10.1.1, which worked in my case.
â Ray
Jul 1 '17 at 21:55
add a comment |Â
up vote
1
down vote
In my case being signed in to Chrome was getting in the way. When I opened up an incognito window and went to a random webpage the redirection worked. I got this idea from a post on an Arch Linux thread.
add a comment |Â
up vote
1
down vote
In my case being signed in to Chrome was getting in the way. When I opened up an incognito window and went to a random webpage the redirection worked. I got this idea from a post on an Arch Linux thread.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
In my case being signed in to Chrome was getting in the way. When I opened up an incognito window and went to a random webpage the redirection worked. I got this idea from a post on an Arch Linux thread.
In my case being signed in to Chrome was getting in the way. When I opened up an incognito window and went to a random webpage the redirection worked. I got this idea from a post on an Arch Linux thread.
answered Feb 13 '15 at 23:38
Geoff
1135
1135
add a comment |Â
add a comment |Â
up vote
0
down vote
Enter http://nmcheck.gnome.org in your browser.
(I added the "hotspot login" of Ubuntu 18 to my favorites and it showed that address, every time I clicked on it.)
It worked for me.
New contributor
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
0
down vote
Enter http://nmcheck.gnome.org in your browser.
(I added the "hotspot login" of Ubuntu 18 to my favorites and it showed that address, every time I clicked on it.)
It worked for me.
New contributor
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Enter http://nmcheck.gnome.org in your browser.
(I added the "hotspot login" of Ubuntu 18 to my favorites and it showed that address, every time I clicked on it.)
It worked for me.
New contributor
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Enter http://nmcheck.gnome.org in your browser.
(I added the "hotspot login" of Ubuntu 18 to my favorites and it showed that address, every time I clicked on it.)
It worked for me.
New contributor
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 6 mins ago
Kyrill
1
1
New contributor
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Kyrill is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f89630%2fhow-to-sign-into-an-open-wireless-network%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
It's running a service like networkmanager on your system?
â mavillan
Sep 6 '13 at 6:47
I don't think so... I have netctl which use wpa_supplicant... I discovered that there's also another network, which is securised by WPA. I can put login using my credentials that I should put in the login page for the open network, but I still can't access the web... Tried with my phone : it works...
â Matthieu Harlé
Sep 6 '13 at 7:28
It sounds like this could be an DNS issue. Can you confirm if you can access a remote host directly via an IP address?
â Thomas Nyman
Sep 6 '13 at 19:14