Please no top posting and dropping the mailing list.
On 5/13/19 10:25 PM, Thomas Green wrote:
After getting this patch to work the code seems to be that the
gnutls_priority_set_direct takes the same arguments in both the cases of the #ifdef, and
that it only doesn't set the low watermark. Am I understanding this correctly?
According the gnutls documentation, the priority setting
will take the defaults and removes ALL TLS version and enables only
TLSv1 and SSL3.0. Furthermore, the documentation says "NORMAL:%COMPAT"
is the most compatible mode. But I am no expert here. Just guessing.
The current setting was added by 14030eaee370 ("gweb: Fix
gnutls_priority_set_direct() for various GnuTLS versions") in 2011, this
is 8 years ago and things have changed. At least TLSv1 is considered as
broken and is being removed from many web servers.
The gnutls version check could probably also be removed 2.12.x ended in
2011 and the API breakage was with 3.x.
The log for using this patch is attached. It doesn't even seem
to attempt to do anything WISPr related. Thanks for looking into this.
The logs don't include the gweb subsystem. Add CONNMAN_WEB_DEBUG to your
environment to enable it.
CONNMAN_WEB_DEBUG=1 src/connmand -n -d
And also check if you see something in the network trace.
From: Daniel Wagner [mailto:email@example.com]
Sent: Saturday, May 11, 2019 12:27 PM
To: Thomas Green <TGreen2(a)Sorenson.com>
Subject: Re: Problem connecting to WISPr access point
>> it never prompts for the wispr credentials. Turning on logging I
>> see that the access point returns a 307 error when trying to attach.
>> In wispr.c (line 735) it only checks for error 302. I added a case
>> to that for 307 to handle the redirect, and tried it again. As you
>> can see from the attached log, it now tries to handle the redirect,
>> but fails to do so. As you can see in the log, it immediately
>> returns a
>> 400 (Bad Request) error. Trying to determine what is happening I
>> then took a tcpdump of the connection process to see what happened then.
>> When examining the pcap file that is attached, It doesn't look as if
>> the attempt to actually perform the redirect actually happens. If
>> you could help me determine what is happening, and fix this, I would
>> surely appreciate it. Connecting to this access point works as
>> expected on my android and apple devices, so I'm guessing that
>> connman is doing something different.
Thanks for the log and pcap trace. From them I can see that GET
is answered with a rederect to
ConnMan does the DNS lookup for n195.network-auth.com
After the DNS resolve a new TCP with TLSv1 session is initiated for
184.108.40.206 which is aborted. I would bet that TLSv1 is the problem.
Can you try following patch with your changes?
diff --git a/gweb/giognutls.c b/gweb/giognutls.c index b5c476cbe670..8c97413a3bdd 100644
@@ -456,7 +456,7 @@ GIOChannel *g_io_channel_gnutls_new(int fd)
+ "NORMAL:%COMPAT", NULL);