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: [PATCH] dhcp: Bind to interface when sending (Daniel Wagner)
2. Re: [PATCH] tethering: fix use after free. (Daniel Wagner)
3. Re: Set up wifi.config (Daniel Wagner)
4. Re: [PATCH] gresolv: fix ASAN runtime error. (Daniel Wagner)
5. Re: [PATCH 0/6] Re: Propose patch for perpetual online check
for connected services (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Sep 2019 08:48:07 +0200
From: Daniel Wagner <[email protected]>
To: Joakim Lotseng?rd <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [PATCH] dhcp: Bind to interface when sending
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Joakim,
On 8/26/19 4:41 PM, Joakim Lotseng?rd wrote:
> Having two interfaces and one goes down, ConnMan previously sent a
> DHCP-release only bound to srcIP (via bind), and dstIP, (via connect).
> If an interface goes down, the Linux kernel will try to route the
> packet any means possible. Effect was that it routed it out on the
> other available interface. It might even SNAT the srcIP due to connman
> NATing setup.
>
> The result was a very strange DHCP-release. A dstIP of an DHCP-server
> that the incorect interface probably could not reach. A srcIP that
> seemed correct (due to SNAT rule). An included address to release
> inside the DHCP-release that was not the same as the srcIP, but rather
> the actual IP to release.
>
> This fixes this via setsockopt(.., SO_BINDTODEVICE, ...) which binds
> the socket to the specific interface name, and packets are not seen on
> the incorrect interface anymore.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 2
Date: Mon, 2 Sep 2019 08:51:58 +0200
From: Daniel Wagner <[email protected]>
To: Mickael GARDET <[email protected]>, connman
<[email protected]>
Subject: Re: [PATCH] tethering: fix use after free.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Mckael,
On 8/26/19 9:53 AM, Mickael GARDET wrote:
> enclosed new patch without set remove to NULL .
Patch applied.
Thanks,
Daniel
------------------------------
Message: 3
Date: Mon, 2 Sep 2019 08:56:42 +0200
From: Daniel Wagner <[email protected]>
To: JH <[email protected]>, connman <[email protected]>
Subject: Re: Set up wifi.config
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi JH,
On 8/23/19 1:06 AM, JH wrote:
> Hi,
>
> In wifi.config set up, how can the WiFi name with white space, using
> quotes? Also, the Passphrase is clear text, can the connman accepts
> Passphrase be hashed or some encypted method?
>
> Name = My Home Wifi
This should work. Spaces between the words is no issue. IIRC, it get's
more tricky if you wifi name starts or ends in whitespaces. ConnMan uses
g_key_file_get_string to parse the config files. So we are limited what
this function is able to provide:
https://developer.gnome.org/glib/stable/glib-Key-value-file-parser.html#g-key-file-get-string
Thanks,
Daniel
------------------------------
Message: 4
Date: Mon, 2 Sep 2019 09:09:59 +0200
From: Daniel Wagner <[email protected]>
To: Mickael GARDET <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [PATCH] gresolv: fix ASAN runtime error.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Mickael,
On Wed, Aug 28, 2019 at 10:45:16AM +0200, Mickael GARDET wrote:
> ../git/gweb/gresolv.c:331:7: runtime error: left shift of 169 by 24
> places cannot be represented in type 'int'
> connmand2[3417]: eth0 {add} route 192.168.2.0 gw 0.0.0.0 scope 253 <LINK>
Since ntohl returns the uint32_t type, I changed your patch to this:
-#define DQUAD(_a,_b,_c,_d) ( ((_a)<<24) | ((_b)<<16) | ((_c)<<8) | (_d) )
+#define DQUAD(_a,_b,_c,_d) ( (((uint32_t)_a)<<24) | (((uint32_t)_b)<<16) | \
+ (((uint32_t)_c)<<8) | ((uint32_t)_d) )
#define V4MATCH(addr, a,b,c,d, m) ( ((addr) ^ DQUAD(a,b,c,d)) >> (32 - (m)) )
#define RFC3484_SCOPE_LINK 2
@@ -326,7 +327,7 @@ static int addr_scope(struct sockaddr *sa)
{
if (sa->sa_family == AF_INET) {
struct sockaddr_in *sin = (void *)sa;
- guint32 addr = ntohl(sin->sin_addr.s_addr);
+ uint32_t addr = ntohl(sin->sin_addr.s_addr);
if (V4MATCH(addr, 169,254,0,0, 16) ||
V4MATCH(addr, 127,0,0,0, 8))
Hope that's okay with you. It should fix at least the problem you reported.
Thanks,
Daniel
------------------------------
Message: 5
Date: Mon, 2 Sep 2019 09:21:42 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: [email protected], Aleksandar Mitev <[email protected]>
Subject: Re: [PATCH 0/6] Re: Propose patch for perpetual online check
for connected services
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Aleksandar,
On Tue, Aug 27, 2019 at 03:30:40PM +0300, [email protected] wrote:
> Ok, let me describe our use case that led me to come up with the proposed
> change:
> We have a setup with Ethernet, Wifi and Cellular and want to have Internet
> access
> in any case. This would mean that if an interface fails or doesn't have
> Internet
> reachability, a switchover should be made to the next one. Of course, Ethernet
> is the most preferred, falling back to Wifi, and if Wifi is not reliable
> source
> of Internet, then go to the last resort of Cellular.
>
> Everything is running fine with the current version of connman, except that,
> if,
> for example, Ethernet is the current default source of Internet, and the
> router
> we are connected to, stops routing packets for some reason, then we lose
> Internet
> connectivity and our connection the device is no longer active.
> But connman would not react and continue using the Ethernet connecion. I have
> seen
> this on my Android phone as well: when I am connected with Wifi and the ISP
> decides to cut my router's Internet access, then the phone would not switch
> to cellular
> and no application would recieve notifications for indefinite time.
>
> So my proposed change is to monitor the internet reachability at regular
> intervals,
> using the same technique that connman uses now at the connecting phase.
> However,
> since this checking will eat some data inevitably, we would not want to run it
> on the cellular connection, at least (which is last resort anyway and no
> fallback
> can be made). That is why the config option I added is based on network
> interfaces,
> allowing you to choose only those devices that would make sence to
> continuously
> check for Internet reachability.
Thanks for the more verbose explenation on what you want to
achieve. This sounds like a reasonable thing to expect from
ConnMan. Overall, I think we don't need to add a new config
options. Instead just depend on the default OnlineCheck option. If
that is set ConnMan should continuously do the check. Would you mind
to respin your patches withtout the InterfacesPerpetualOnlineCheck
config option?
> >[1] https://git.merproject.org/mer-core/connman
>
> I was not familiar with this fork of connman. Did not test it but looked
> at the code and I did not find the continuous check after the service goes to
> ONLINE state. I may be missing smth here, though.
I just might have remembered it wrong.
> As for the config option - sure, it could be removed (meaning that all
> interfaces would be treated as enabled for checks) or reduces to a
> simple global switch that would enable continuous online check after
> going to the ONLINE state. However, please consider the usefulness of
> our use case here.
>
> >> Attached is the proposed patch (based on tag 1.37).
> >
> >The patches were attached to this mail. Did you use git send-email to
> >send out the patches?
>
> No, I just used my email client. Now using the git send mail. Hope this
> is the right way to send patch proposals along.
Looks good now :)
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 47, Issue 1
**************************************
