Send connman mailing list submissions to
        connman@lists.01.org

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
        connman-requ...@lists.01.org

You can reach the person managing the list at
        connman-ow...@lists.01.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: [PATCH] service: signal when services are moved
      (Daniel Wagner)
   2. Re: Crash when running connmand along iwd (Daniel Wagner)
   3. Re: [Question] Gateway route in multi-home environment
      (Daniel Wagner)
   4. Re: Does not create resolv.conf parent directories (Daniel Wagner)
   5. Re: [PATCH] notifier: constify vtables (Daniel Wagner)


----------------------------------------------------------------------

Message: 1
Date: Sun, 28 Oct 2018 19:39:36 +0100
From: Daniel Wagner <w...@monom.org>
To: Beno?t Monin <benoit.mo...@gmx.fr>
Cc: connman@lists.01.org
Subject: Re: [PATCH] service: signal when services are moved
Message-ID: <b1d1380a-6c30-9b7d-5bb6-70a830e37...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Beno?t,

On 10/14/2018 06:33 PM, Beno?t Monin wrote:
> When calling MoveBefore or MoveAfter on a service, no signal is emitted
> by connman. This makes it impossible for a dbus client to maintain an
> ordered list of services in sync with connman.
> 
> This patch schedules the emission of the signal ServicesChanged from the
> function move_service, so the new list will get published over dbus.

Sorry for the long delay. Was traveling last week.

I moved the service_schedule_changed() code in front of move_service(). 
This avoids the static function declaration. After that I applied your 
patch.

Thanks,
Daniel


------------------------------

Message: 2
Date: Sun, 28 Oct 2018 19:42:41 +0100
From: Daniel Wagner <w...@monom.org>
To: Doron Behar <doron.be...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: Crash when running connmand along iwd
Message-ID: <a08edf7b-6801-6a73-c5b6-2cd90b1e9...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

On 10/26/2018 02:08 PM, Doron Behar wrote:
> I have connman version 1.36 and iwd version 0.10 installed and every
> time I run iwd along with connman it crashes.

[...]

> Oct 26 15:04:03 NUC connmand[2988]: ++++++++ backtrace ++++++++
> Oct 26 15:04:03 NUC connmand[2988]: #0  0x7fc7a3e01e00 in /usr/lib/libc.so.6
> Oct 26 15:04:03 NUC connmand[2988]: #1  0x561d85e16ea7 in /usr/bin/connmand
> Oct 26 15:04:03 NUC connmand[2988]: #2  0x561d85e1746b in /usr/bin/connmand
> Oct 26 15:04:03 NUC connmand[2988]: #3  0x561d85e810d4 in /usr/bin/connmand
> Oct 26 15:04:03 NUC connmand[2988]: #4  0x561d85e8235e in /usr/bin/connmand
> Oct 26 15:04:03 NUC connmand[2988]: #5  0x561d85e7cd04 in /usr/bin/connmand
> Oct 26 15:04:03 NUC connmand[2988]: #6  0x561d85e7cf08 in /usr/bin/connmand
> Oct 26 15:04:03 NUC connmand[2988]: #7  0x7fc7a414cd75 in 
> /usr/lib/libdbus-1.so.3
> Oct 26 15:04:03 NUC connmand[2988]: #8  0x561d85e7bed1 in /usr/bin/connmand
> Oct 26 15:04:03 NUC connmand[2988]: #9  0x7fc7a41f4271 in 
> /usr/lib/libglib-2.0.so.0
> Oct 26 15:04:03 NUC connmand[2988]: #10 0x7fc7a41f5f89 in 
> /usr/lib/libglib-2.0.so.0
> Oct 26 15:04:03 NUC connmand[2988]: #11 0x7fc7a41f6f62 in 
> /usr/lib/libglib-2.0.so.0
> Oct 26 15:04:03 NUC connmand[2988]: #12 0x561d85df6c8b in /usr/bin/connmand
> Oct 26 15:04:03 NUC connmand[2988]: #13 0x7fc7a3dee223 in /usr/lib/libc.so.6
> Oct 26 15:04:03 NUC connmand[2988]: +++++++++++++++++++++++++++

I think I have fixed this with bc97d6602f79 ("iwd: Remove device state 
property"). Can you try the current master or cherry pick the patch to 
verify?

Thanks,
Daniel


------------------------------

Message: 3
Date: Sun, 28 Oct 2018 19:53:28 +0100
From: Daniel Wagner <w...@monom.org>
To: Andrea Capirchio <andrea.capirc...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: [Question] Gateway route in multi-home environment
Message-ID: <fdb53beb-398f-4934-3f54-849906c7f...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Andrea,

On 10/23/2018 09:49 AM, Andrea Capirchio wrote:
>> Hi,
>>
>> I am developing an embedded system running connman 1.36 over linux.
>> My system is multi-home, so I have one network interface connected to
>> two subnets that cannot see each other.
>> Assuming that I have a gateway present on "subnet 2" (relative to 
>> "address 2"), and that the
>> primary address of the interface is? "address 1", that was assigned 
>> manually at boot time, I have the following routing table (from $ ip r):
>>
>> 1. <gateway addr> dev <interface>                                     
>> ??? ??? ??? ??? ??? ??? // added by connman
>> 2. <dns addr> via <gateway addr> dev <interface>                     
>> ??? ??? ??? ? // added by connman
>> 3. <local subnet2>/<netmask2> dev <interface> src <local address2>     
>> // added by connman
>> 4. <local subnet1>/<netmask1> dev <interface> src <local address1>     
>> // added manually
>> 5. default via <gateway addr> dev <interface>                         
>> ??? ??? ??? ??? ? // added by connman

While ConnMan monitors the changes no the routing table it wont react on 
it.

>> I think that the first rule is wrong.

I am not completely sure I understand your setup. Is <interface> always 
the same NIC? Is <interface> configured to use DHCP? If so what is the 
response of the server?

>> Explaination:
>>
>> With this configuration, PING from the device to the gateway is not
>> working.
>> This because linux chooses rule number 1 to route the packets to the
>> gateway, but this does not specify the source IP of the interface, so
>> the primary IP is chosen as source address.
>> The primary is the IP relative to "subnet 1" while the gateway can only
>> communicate with IPs from "subnet 2", so the gateway cannot answer to my
>> device.
>>
>> I am considering to patch this, but should the rule be erased?
>> Or if it is useful to some purpose, should I add the src IP to rule
>> number 1?

IIRC the first rule is added to make sure we can always reach the 
machine which acts as gateway for the default route. Not sure if this 
might be the source of your problem.

Thanks,
Daniel


------------------------------

Message: 4
Date: Sun, 28 Oct 2018 19:56:28 +0100
From: Daniel Wagner <w...@monom.org>
To: Roy Reese <waterbeare...@gmx.com>
Cc: connman@lists.01.org
Subject: Re: Does not create resolv.conf parent directories
Message-ID: <4c64d780-f8be-1a5d-e7e4-6d27b3410...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Roy,

> I would like to hear the answer to that. I use Enlightenment and like
> Connman, but have about had it with systemd. There are still good
> non-systemd distros (Gentoo, Slackware, MX Linux, and newer Artix)
> and I am increasingly inclined to switch out, especially to Artix
> which is Arch w/o systemd.
I think as long we don't explicit state that ConnMan depends on systemd, 
I am happy to accept such patches.

Thanks,
Daniel


------------------------------

Message: 5
Date: Sun, 28 Oct 2018 19:58:45 +0100
From: Daniel Wagner <w...@monom.org>
To: Slava Monich <slava.mon...@jolla.com>
Cc: connman@lists.01.org
Subject: Re: [PATCH] notifier: constify vtables
Message-ID: <1ba317e8-79b4-1d93-29b6-1741d7356...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Slava,

On 10/20/2018 01:05 AM, Slava Monich wrote:
> connman_notifier vtables are read-only structures. Declaring them const
> at compile time allows the compiler to actually make them read-only at
> runtime.

Patch applied.

Thanks,
Daniel


------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 36, Issue 23
***************************************

Reply via email to