Hi Martin,
I personally
would go straight for handling WISPr support and then the rest falls out
of it for free.
I must confess, that I didn't know about WISPr before you mentioned
it earlier in this thread. The Wikipedia article[1] suggests, that
it has almost nothing to do with the
Quoting Marcel Holtmann mar...@holtmann.org:
the first step is exactly the same. You need to get a well known website
and then continue your decision making from there. It needs to become
part of your connection state machine.
I see, thanks!
___
Hi Thomas,
However if your long term goal is WISPr support, then you have to look
at the whole page anyway. There is no guarantee that the WISPr XML is at
the beginning. Some providers actually just attach it to the end.
personally i don't care about WISPr. I just want to know if i have
Quoting Marcel Holtmann mar...@holtmann.org:
I personally
would go straight for handling WISPr support and then the rest falls out
of it for free.
I must confess, that I didn't know about WISPr before you mentioned
it earlier in this thread. The Wikipedia article[1] suggests, that
it has
Hi Marcel,
On 22/11/11 08:55, Marcel Holtmann wrote:
Hi Thomas,
i just want to summarize the discussion about the response handling so
we can decide which solution we want to use.
mentioned solutions are:
1) check http status-response 204 (or any other) (chromiumos method)
2) check content
Hi Thomas,
i just want to summarize the discussion about the response handling so
we can decide which solution we want to use.
mentioned solutions are:
1) check http status-response 204 (or any other) (chromiumos method)
2) check content for a specific http header (connman method)
Hi Marcel,
On 22/11/11 12:21, Marcel Holtmann wrote:
Hi Thomas,
i just want to summarize the discussion about the response handling so
we can decide which solution we want to use.
mentioned solutions are:
1) check http status-response 204 (or any other) (chromiumos method)
2) check content
On Tue, 2011-11-22 at 12:21 +0100, Marcel Holtmann wrote:
Actually the HTTP header makes a lot more sense since once you
received
the valid one, you can just terminate the HTTP request and do not have
to deal with downloading the whole file.
You can possibly do just a HTTP HEAD request,
Hi Thomas,
i just want to summarize the discussion about the response handling so
we can decide which solution we want to use.
mentioned solutions are:
1) check http status-response 204 (or any other) (chromiumos method)
2) check content for a specific http header (connman method)
Hi Marcel,
On 23/11/11 07:33, Marcel Holtmann wrote:
However if your long term goal is WISPr support, then you have to look
at the whole page anyway. There is no guarantee that the WISPr XML is at
the beginning. Some providers actually just attach it to the end.
personally i don't care about
Hi,
i just want to summarize the discussion about the response handling so
we can decide which solution we want to use.
mentioned solutions are:
1) check http status-response 204 (or any other) (chromiumos method)
2) check content for a specific http header (connman method)
3) check start of
Hi Thomas,
i just want to summarize the discussion about the response handling so
we can decide which solution we want to use.
mentioned solutions are:
1) check http status-response 204 (or any other) (chromiumos method)
2) check content for a specific http header (connman method)
3)
Hi Thomas,
within ConnMan we decided to go for a vendor-header with a specific
value within the HTTP response. That way we are keeping the HTTP
response code and don't have to define a magic one.
I don't understand this. Has connman a database with vendor-headers and
should every vendor
Hi Marcel,
On Fri, 2011-11-18 at 06:52 +0100, Marcel Holtmann wrote:
within ConnMan we decided to go for a vendor-header with a specific
value within the HTTP response. That way we are keeping the HTTP
response code and don't have to define a magic one.
I don't understand this. Has
On 16/11/11 07:19, Dan Williams wrote:
to test the connectivity check, do eg:
./NetworkManager --no-daemon --log-level=DEBUG --log-domains=CORE
--connectivity-uri=http://toabctl.de
--connectivity-response=titletoabctl.de/title
Pretty much what I was thinking about, but I wonder what we should
On 11/16/2011 01:19 AM, Dan Williams wrote:
./NetworkManager --no-daemon --log-level=DEBUG --log-domains=CORE
--connectivity-uri=http://toabctl.de
--connectivity-response=titletoabctl.de/title
Pretty much what I was thinking about, but I wonder what we should do
for the expected response.
Chromium OS hits a URL that is expected to give a 204 response; if we get
anything else, we assume we're being portalled.
This seems to be working well. HTTPS would be the next step if we start
to see portals returning 204s.
+0200
Subject: [PATCH] core: add internet connectivity check
* use libsoup to compare a http response from a given
uri with a given response (use g_str_has_prefix () to compare)
* do periodically check the connectivity. Check interval is configurable
* check connectivity when device state change
Hi David,
Chromium OS hits a URL that is expected to give a 204 response; if we get
anything else, we assume we're being portalled.
This seems to be working well. HTTPS would be the next step if we start
to see portals returning 204s.
within ConnMan we decided to go for a vendor-header
Hi Marcel,
On Thu, 2011-11-17 at 10:07 +0900, Marcel Holtmann wrote:
within ConnMan we decided to go for a vendor-header with a specific
value within the HTTP response. That way we are keeping the HTTP
response code and don't have to define a magic one.
I don't understand this. Has connman a
Hi,
here's the patch again. Forgot some code.
Cheers,
Tom
* use libsoup to check internet connectivity with
a http request to a configurable uri and check
the response code for 200
* do periodically check the connectivity. Check interval
is configurable
* check connectivity when device
Hi Tom,
* use libsoup to check internet connectivity with
a http request to a configurable uri and check
the response code for 200
just checking for result code 200 will not be enough. A bunch of
hotspots return result code 200 actually. You need to also check that
the content of your
-uri=http://toabctl.de
--connectivity-response=titletoabctl.de/title
Tom
From c5e05b7181b74db80525f49eb2224b81adc190a7 Mon Sep 17 00:00:00 2001
From: Thomas Bechtold thomasbecht...@jpberlin.de
Date: Fri, 21 Oct 2011 21:21:30 +0200
Subject: [PATCH] core: add internet connectivity check
* use
23 matches
Mail list logo
