3:13 p.m.
Hello,
I'm using connman 1.37 on embedded ARM device running Linux 4.9.146.
When Ethernet cable is connected to the board, everything works as
expected and I can see the service (and all its properties):
# connmanctl services
*AO Wired ethernet_0018d7677f91_cable
#
However, once I disconnect the cable, the service disappears, and I get:
# connmanctl services
# connmanctl services ethernet_0018d7677f91_cable
Error ethernet_0018d7677f91_cable: Method "GetProperties" with signature
"" on interface "net.connman.Service" doesn't exist
#
The question is: how do I get Ethernet service configuration and/or
re-configure it when there is no cable connected; for example, how do I
change configuration so that at the next connect of the cable the
service would use static IPv4 instead of DHCP?
-- Sergey
3:43 p.m.
Hi Sergey,
On Thu, Jan 30, 2020 at 05:13:04PM +0300, Sergey Organov wrote:
The question is: how do I get Ethernet service configuration and/or
re-configure it when there is no cable connected; for example, how do I
change configuration so that at the next connect of the cable the
service would use static IPv4 instead of DHCP?
For configuering non-existing networks you need to provision it. This
means you need to write a provisiong file for this. There is no D-Bus
interface for this. See the config-format.txt documentation:
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/doc/confi...
Thanks,
Daniel
2:53 p.m.
Hi Daniel,
Daniel Wagner <wagi(a)monom.org> writes:
Hi Sergey,
On Thu, Jan 30, 2020 at 05:13:04PM +0300, Sergey Organov wrote:
> The question is: how do I get Ethernet service configuration and/or
> re-configure it when there is no cable connected; for example, how do I
> change configuration so that at the next connect of the cable the
> service would use static IPv4 instead of DHCP?
For configuering non-existing networks you need to provision it.
This means you need to write a provisiong file for this. There is no
D-Bus interface for this. See the config-format.txt documentation:
https://git.kernel.org/pub/scm/network/connman/connman.git/tree/doc/confi...
Thanks! I've read it already, but it seemed unnatural to me to be forced
to parse/edit configuration file(s) directly, effectively duplicating
what connmand does anyway, especially as my actual aim is to do it from
an application.
I'll obviously do it, as it happens to be the only available way, but
it's still unclear how does provisioning interoperate with configuration
through D-Bus/connmanctl? My quick test shows that "connmanctl
configure" starts to give (rather undescriptive) errors on provisioned
service:
# connmanctl config ethernet_0018d7677f91_cable ipv4 dhcp
Error ethernet_0018d7677f91_cable: Not supported
#
effectively making provisioning and "connmanctl configure" mutually
exclusive. Is it how it's designed to behave indeed?
Thanks,
Sergey
3:21 p.m.
On Mon, Feb 03, 2020 at 04:53:50PM +0300, Sergey Organov wrote:
Thanks! I've read it already, but it seemed unnatural to me to be
forced
to parse/edit configuration file(s) directly, effectively duplicating
what connmand does anyway, especially as my actual aim is to do it from
an application.
The reason why the provisioning is done only by file is that the D-Bus
API lacks a way to create non existing services. You can only modify
currently available services via D-Bus.
I'll obviously do it, as it happens to be the only available way,
but
it's still unclear how does provisioning interoperate with configuration
through D-Bus/connmanctl? My quick test shows that "connmanctl
configure" starts to give (rather undescriptive) errors on provisioned
service:
# connmanctl config ethernet_0018d7677f91_cable ipv4 dhcp
Error ethernet_0018d7677f91_cable: Not supported
try
connmanctl config ethernet_0018d7677f91_cable --ipv4 dhcp
effectively making provisioning and "connmanctl configure"
mutually
exclusive. Is it how it's designed to behave indeed?
Yes indeed, they are mutually exclusive due it's original use case.
Thanks,
Daniel
4:39 p.m.
Daniel Wagner <wagi(a)monom.org> writes:
On Mon, Feb 03, 2020 at 04:53:50PM +0300, Sergey Organov wrote:
> Thanks! I've read it already, but it seemed unnatural to me to be forced
> to parse/edit configuration file(s) directly, effectively duplicating
> what connmand does anyway, especially as my actual aim is to do it from
> an application.
The reason why the provisioning is done only by file is that the D-Bus
API lacks a way to create non existing services. You can only modify
currently available services via D-Bus.
I meant that I'd expected I could configure Ethernet without
provisioning. In other words, I don't see why Ethernet with disconnected
cable is to be considered "non-existing" rather than, say,
"disconnected", or something else, keeping the ability to handle it
through D-Bus/connmanctl rather than forcing to use provision config
files.
> I'll obviously do it, as it happens to be the only available way, but
> it's still unclear how does provisioning interoperate with configuration
> through D-Bus/connmanctl? My quick test shows that "connmanctl
> configure" starts to give (rather undescriptive) errors on provisioned
> service:
>
> # connmanctl config ethernet_0018d7677f91_cable ipv4 dhcp
> Error ethernet_0018d7677f91_cable: Not supported
try
connmanctl config ethernet_0018d7677f91_cable --ipv4 dhcp
It doesn't seem to matter, both give the same error when interface is
provisioned, and both work silently when not, that seems to be perfectly
inline with the design of mutual exclusion of the features. The only woe
here is that error message could have been more informative.
> effectively making provisioning and "connmanctl configure" mutually
> exclusive. Is it how it's designed to behave indeed?
Yes indeed, they are mutually exclusive due it's original use case.
OK, got it, thanks!
-- Sergey
839
days inactive
843
days old
4 comments
2 participants
participants (2)
-
Daniel Wagner -
Sergey Organov