Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: IPv6 privacy extensions with connman (Daniel Wagner)
2. Re: Tethering Ethernet (Daniel Wagner)
3. Re: Interface change callback (Daniel Wagner)
4. Re: "P2P" not available in connman technologies (Daniel Wagner)
5. Re: Problem connecting to WISPr access point (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Sat, 11 May 2019 18:22:27 +0200
From: Daniel Wagner <[email protected]>
To: Christian <[email protected]>, [email protected]
Subject: Re: IPv6 privacy extensions with connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Christian,
On 4/30/19 4:42 PM, Christian wrote:
> Were you able to investigate why a "scope global secondary dynamic"
> address is created instead of a "scope global temporary dynamic".
I have enabled IPv6 in my network to reproduce your problem. I get a
'scope global temporary dynamic' and no 'secondary dynamic' address with
privacy enabled. Is the secondary dynamic address really assigned by
ConnMan? Is something else running on your system fiddling with IPv6
addresses?
Thanks,
Daniel
------------------------------
Message: 2
Date: Sat, 11 May 2019 18:28:36 +0200
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: Tethering Ethernet
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 5/2/19 11:24 PM, [email protected] wrote:
> I'm looking for some reference on a embedded project I'm working on.
> I'm the hardware guy, not the software guy, but I'm trying to point
> someone in the right direction.
> I think the short question is, Can you disable DHCP on the ethernet
> interface?
Yes, you can tell ConnMan either to ignore an interface complete,
configure it statically or dynamically (e.g DHCP)
> This is what I'm trying to accomplish
> I have 1 Ethernet interface, 1 wifi interface, and 1 MC7354 external modem.
> I would like to support two scenarios:
> 1:
> MC7354 as WAN
> Wifi as AP and Ethernet bridged as LAN, DHCP enabled, (but will static
> IP addresses work)
ConnMan's tethering supports only dynamic addresses, no static address.
> 2:
> No WAN
> Ethernet and WIFI as AP? bridged.? Bridge obtains IP address via DHCP
> via Ethernet connected external router.
ConnMan setups the device as router when tethering, so no L2 bridge to
external device.
> DHCP disabled on device itself.? DHCP requests made on WIFI as AP are
> serviced by the external router.
> Any help on whether this is supported and what to search would be
> appreciated.
If I understand your use case correctly, ConnMan wont fit your
requirements.
Thanks,
Daniel
------------------------------
Message: 3
Date: Sat, 11 May 2019 18:38:42 +0200
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Interface change callback
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi JH,
On 5/9/19 4:13 AM, JH wrote:
> Will the net.connman.Manager provide network type like wifi or
> cellular for callback for the services changed event? What will be
> message format in the callback?
Please see our API documentation. It should be correct and up to date. A
good idea is to run test/monitor-connman script (if you want not raw
D-Bus message dump or alternative use dbus-monitor) and you see what the
D-Bus signals contain.
Thanks,
Daniel
------------------------------
Message: 4
Date: Sat, 11 May 2019 19:19:03 +0200
From: Daniel Wagner <[email protected]>
To: vishal bs <[email protected]>
Cc: [email protected]
Subject: Re: "P2P" not available in connman technologies
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 5/9/19 6:53 AM, vishal bs wrote:
> there is no p2p in the "technologies" list in the connman ,
> I did follow one of the other mail lists which was on the same issue.
> Link : https://lists.01.org/pipermail/connman/2017-August/022040.html
> I gave the commands specified in the link to get the capabilities and
> was able to get P2P in both "all global" capabilities of
> wpa_supplicant(i.e I am running wpa_supplicant using the parameter -u)
> as well as in "Interface" capabilities, further when i enabled the log
> I came across this,
>
> connmand[4569]:gsupplicant/suppicannt.c:debug_strvalmap() mode
> capability: infrastructure
> connmand[4569]:gsupplicant/suppicannt.c:debug_strvalmap() mode
> capability: ad-hoc
> connmand[4569]:gsupplicant/suppicannt.c:debug_strvalmap() mode capability: ap
> connmand[4569]:gsupplicant/suppicannt.c:callback_interface_added()
>
> which is confusing!
wpa_supplicant reports that the interface support p2p. So far so good.
> It would be great if anybody steps up to solve this problem.
After looking at your trace and the gsupplicant code I'd say
callback_p2p_support() is never called which means some lower level
stuff doesn't work as expected.
> I hope someone will help me regarding this.
Not sure if I can help a lot. First, check if you are using up to date
versions of ConnMan and wpa_supplicant first. Then verify the
interaction between the ConnMan wpa_supplicant. For this start
wpa_supplicant by hand adding -ddd to the command line. Maybe there is
more info what is happening.
Thanks,
Daniel
------------------------------
Message: 5
Date: Sat, 11 May 2019 20:27:09 +0200
From: Daniel Wagner <[email protected]>
To: Thomas Green <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Problem connecting to WISPr access point
Message-ID: <20190511182708.xodmwdp4wpnbeuo2@beryllium>
Content-Type: text/plain; charset=us-ascii
Hi Thomas,
> > 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
http://ipv4.connman.net/online/status.html is answered with a rederect
to https://n195.network-auth.com/[...].
ConnMan does the DNS lookup for n195.network-auth.com which works.
After the DNS resolve a new TCP with TLSv1 session is initiated for
209.206.52.180 which is aborted. I would bet that TLSv1 is the
problem.
Can you try following patch with your changes?
Thanks,
Daniel
diff --git a/gweb/giognutls.c b/gweb/giognutls.c
index b5c476cbe670..8c97413a3bdd 100644
--- a/gweb/giognutls.c
+++ b/gweb/giognutls.c
@@ -456,7 +456,7 @@ GIOChannel *g_io_channel_gnutls_new(int fd)
"NORMAL:%COMPAT", NULL);
#else
gnutls_priority_set_direct(gnutls_channel->session,
- "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT", NULL);
+ "NORMAL:%COMPAT", NULL);
#endif
gnutls_certificate_allocate_credentials(&gnutls_channel->cred);
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 43, Issue 12
***************************************
