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: Annoying 169.254.x.x settings casually disrupting my
connection :( (Daniel Wagner)
2. Re: Issues in vpn l2tp and pptp plugins (Daniel Wagner)
3. Re: Void Linux, dbus, connman, kills machines networking
(Daniel Wagner)
4. Re: [PATCH 2/2] unit: Add unit test for iptables.c longjmp()
use. (Daniel Wagner)
5. Re: Bluetooth services does not appear (Ferry Toth)
6. Re: Void Linux, dbus, connman, kills machines networking
(Ryan Rosemie)
7. Re: Void Linux, dbus, connman, kills machines networking
(Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Thu, 14 Feb 2019 21:03:08 +0100
From: Daniel Wagner <[email protected]>
To: Julien Massot <[email protected]>
Cc: Gabriele Zaverio <[email protected]>, [email protected]
Subject: Re: Annoying 169.254.x.x settings casually disrupting my
connection :(
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
> > > How can I FORBID this "Zeroconf / RFC3927 / apipa / whatever"
> > > abomination to disrupt my network settings?
> Ipv4 Local Link is used in case DHCP discover or request has failed,
> it may be on a renew or on startup/ plug event.
> Please make sure that there is no script running which can conflict
> with connman or avahi-autoipd running,
> also make sure that your dhcp server is always responding.
>
> Try to capture connman logs if possible with debug output (connmand
> -nd) so that we will be able to understand the situation.
Can you check if what kind of leases your DHCP server provides? It
sounds like that you get initally a lease but then it gets invalidated
(time?) and then ConnMan is not able to get another lease. If that
happens ConnMan will assign the interface a link local address. You
can also diable the fallback to libnk local by setting the IPv4
service configuration to 'dhcp' instead 'auto'.
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 14 Feb 2019 21:12:46 +0100
From: Daniel Wagner <[email protected]>
To: Artem Yamshanov <[email protected]>
Cc: [email protected]
Subject: Re: Issues in vpn l2tp and pptp plugins
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Artem,
On Sun, Feb 03, 2019 at 12:32:58PM +0700, Artem Yamshanov wrote:
> Hi!
>
> I have found some bug in vpn l2tp and pptp plugins: logfd is not append to
> connman-ppp-option.conf, it leads to extra output ("Plugin /usr/lib64/
> connman/scripts/libppp-plugin.so loaded.") to xl2tpd or pptp and it brakes
> PPP connection.
Thanks for your report and patch. I made a prober patch out of
it. Please check if I didn't screw it up.
>
> Patch is pretty simple:
> --- a/vpn/plugins/l2tp.c
> +++ b/vpn/plugins/l2tp.c
> @@ -382,6 +382,7 @@ static int write_pppd_option(struct vpn_provider
> *provider, int fd)
>
> l2tp_write_option(fd, "nodetach", NULL);
> l2tp_write_option(fd, "lock", NULL);
> + l2tp_write_option(fd, "logfd", "2");
> l2tp_write_option(fd, "usepeerdns", NULL);
> l2tp_write_option(fd, "noipdefault", NULL);
> l2tp_write_option(fd, "noauth", NULL);
> --- a/vpn/plugins/pptp.c
> +++ b/vpn/plugins/pptp.c
> @@ -453,6 +453,7 @@ static int run_connect(struct vpn_provider *provider,
>
> connman_task_add_argument(task, "nodetach", NULL);
> connman_task_add_argument(task, "lock", NULL);
> + connman_task_add_argument(task, "logfd", "2");
> connman_task_add_argument(task, "usepeerdns", NULL);
> connman_task_add_argument(task, "noipdefault", NULL);
> connman_task_add_argument(task, "noauth", NULL);
>
> I have tried to report about this bug on https://01.org/connman, but it
> looks like it does not provide public registration now.
Unfortuntly, no one cares a lot about the bug tracker anymore. Sorry
about that.
> I also tried to ask the question at #connman channel, but I was not able to
> get an answer (I do not use IRC bouncer and live in GMT+7, so it was
> predictable).
I can't spend a lot of time on the channel (work hours). So the
current only working channel is this mailing list. It's a bandwith
problem (read it's me).
Thanks,
Daniel
------------------------------
Message: 3
Date: Thu, 14 Feb 2019 21:22:39 +0100
From: Daniel Wagner <[email protected]>
To: Julien Massot <[email protected]>
Cc: Ryan Rosemie <[email protected]>, [email protected]
Subject: Re: Void Linux, dbus, connman, kills machines networking
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, Feb 08, 2019 at 09:39:02AM +0100, Julien Massot wrote:
> On Tue, Feb 5, 2019 at 1:41 AM Ryan Rosemie <[email protected]> wrote:
> > Firstly connman needs dbus, if I don't enable dbus I get:
> >
> > Error: failed to connect to socket /run/dbus/system_bus_socket: No such
> > file or directory
ConnMan won't work without D-Bus. So this is to be expected.
> > When dbus is enabled to my network shuts off, even my hardware network
> > light on my laptop for Ethernet goes off. Although connman shows that I'm
> > on a network, I cant access anything even by Ethernet. Any ideas?
I don't understand what you mean with 'When dbus is enabled to my
network shuts off'. Do you stop D-Bus and then the network connection
goes down? That would be the behavior I expect. ConnMan will terminate
if D-Bus goes away, it can't live without it.
> > I do have dchcp disabled, wpa_supplicant isn't on a fresh install of void
> > linux.
ConnMan will start wpa_supplicant itself. Obviously you need it to be
installed in order to get WiFi working.
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 14 Feb 2019 21:36:31 +0100
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 2/2] unit: Add unit test for iptables.c longjmp()
use.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Jussi,
On Tue, Feb 05, 2019 at 04:45:41PM +0200, Jussi Laakkonen wrote:
> This adds a unit test to run at build for testing longjmp() use in
> iptables.c. The tests test both cases to 1) handle longjmp() when
> setjmp() was properly called to save env and 2) exit() when longjmp() is
> called via xtables exit_err() from a location that normally does not
> call it.
Nice work! Both patches applied. I've tested the unit test and all
looks good.
Thanks,
Daniel
------------------------------
Message: 5
Date: Thu, 14 Feb 2019 23:01:55 +0100
From: Ferry Toth <[email protected]>
To: Daniel Wagner <[email protected]>, David Lechner
<[email protected]>
Cc: [email protected]
Subject: Re: Bluetooth services does not appear
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Op 14-02-19 om 20:51 schreef Daniel Wagner:
> On Tue, Jan 29, 2019 at 09:49:13PM -0600, David Lechner wrote:
>> On 1/29/19 2:22 PM, Ferry Toth wrote:
>>> Op 09-01-19 om 16:51 schreef Daniel Wagner:
>>>>> root@edison:~# connmanctl
>>>>> connmanctl> services
>>>>> *AR Wired??????????????? ethernet_00800f951d4d_cable
>>>>> ???? Ferry Toth (Galaxy Note3) bluetooth_43341B001FAC_C462EA01AF74
>>>>> connmanctl> connect bluetooth_43341B001FAC_C462EA01AF74
>>>>> Error /net/connman/service/bluetooth_43341B001FAC_C462EA01AF74:
>>>>> Input/output error
>>>>>
>>>>> Seems like 1 more thing is missing.
>>>> Something interesting in the logs?
>>> I posted debug logs. Did you have a look?
>> I had a look, but I didn't see anything helpful. Sorry.
> Me neither.
>
>> Maybe there is something in the BlueZ/bluetoothd logs?
>>
>> Maybe you are missing a kernel option that needs to be
>> enabled for ConnMan or BlueZ?
I have read the parts relating to the kernel config. I think I have
everything. But then again, it's not working.
> Hmm, good idea. If it would be oFono my tip would CONFIG_TUN. Almost :(
Could d-bus be blocking something? This my bluetooth.conf:
<!-- This configuration file specifies the required security policies
???? for Bluetooth core daemon to work. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration
1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
<busconfig>
? <!-- ../system.conf have denied everything, so we just punch some
holes -->
? <policy user="root">
??? <allow own="org.bluez"/>
??? <allow send_destination="org.bluez"/>
??? <allow send_interface="org.bluez.Agent1"/>
??? <allow send_interface="org.bluez.MediaEndpoint1"/>
??? <allow send_interface="org.bluez.MediaPlayer1"/>
??? <allow send_interface="org.bluez.Profile1"/>
??? <allow send_interface="org.bluez.GattCharacteristic1"/>
??? <allow send_interface="org.bluez.GattDescriptor1"/>
??? <allow send_interface="org.bluez.LEAdvertisement1"/>
??? <allow send_interface="org.freedesktop.DBus.ObjectManager"/>
??? <allow send_interface="org.freedesktop.DBus.Properties"/>
? </policy>
? <policy at_console="true">
??? <allow send_destination="org.bluez"/>
? </policy>
? <!-- allow users of lp group (printing subsystem) to
?????? communicate with bluetoothd -->
? <policy group="lp">
??? <allow send_destination="org.bluez"/>
? </policy>
? <policy context="default">
??? <deny send_destination="org.bluez"/>
? </policy>
</busconfig>
> Thanks,
> Daniel
------------------------------
Message: 6
Date: Thu, 14 Feb 2019 18:08:15 -0500
From: Ryan Rosemie <[email protected]>
To: Julien Massot <[email protected]>,
[email protected], [email protected]
Subject: Re: Void Linux, dbus, connman, kills machines networking
Message-ID:
<caongcvxdn2bvwcf1avau1feum9sd5k9fz6unfjlxyk0gqm2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
From: Julien Massot <[email protected]>
Date: Mon, Feb 11, 2019 at 8:00 AM
This is what the terminal outputs
hopefully I didn't miss anything
https://ghostbin.com/paste/s4jy9
From: Daniel Wagner <[email protected]>
Date: Thu, Feb 14, 2019 at 3:22 PM
>> I don't understand what you mean with 'When dbus is enabled to my
network shuts off Do you stop D-Bus and then the network connection
goes down? That would be the behavior I expect. ConnMan will terminate
if D-Bus goes away, it can't live without it.
When I enable dbus with runit the network shuts off. I can no longer
connect through ethernet or wifi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20190214/4e8a45e3/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 15 Feb 2019 09:15:16 +0100
From: Daniel Wagner <[email protected]>
To: Ryan Rosemie <[email protected]>, Julien Massot
<[email protected]>, [email protected]
Subject: Re: Void Linux, dbus, connman, kills machines networking
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 2/15/19 12:08 AM, Ryan Rosemie wrote:
> From: *Julien Massot* <[email protected]
> <mailto:[email protected]>>
> Date: Mon, Feb 11, 2019 at 8:00 AM
>
> This is what the terminal outputs
> hopefully I didn't miss anything
> https://ghostbin.com/paste/s4jy9
The wifi interface is setup, gets it IP address. ConnMan can't talk to
the NTP server on 192.168.0.1. I guess there is just none. So that looks
okay.
> From: Daniel Wagner <[email protected] <mailto:[email protected]>>
> Date: Thu, Feb 14, 2019 at 3:22 PM
>
> >> I don't understand what you mean with 'When dbus is enabled to my
> network shuts off Do you stop D-Bus and then the network connection
> goes down? That would be the behavior I expect. ConnMan will terminate
> if D-Bus goes away, it can't live without it.
>
> When I enable dbus with runit the network shuts off. I can no longer
> connect through ethernet or wifi
Ah, so starting dbus manually works but using runit to start dbus
triggers this problem. This sounds like a dbus policy (configuration)
issue. Check under which user runit runs dbus and ConnMan what the
policy settings (/etc/dbus.d/system.d/).
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 40, Issue 6
**************************************
