Marcel, Patrik,
Yes. I'm thinking about two new values for "IPv4.method", called
"dhcp-only" and "linklocal-only". Using main.conf would not be the
appropriate place because we are interested in interface specific
settings where, for instance, one interface can be dhcp-only and
another linklocal-only.
I have no objections in adding a "link-local" method. However
something like only doing DHCP on a per service interface seems a bit
odd. What is wrong with providing link-local if DHCP temporary or
permanently fails?
This is similar to IPv6, where you always get a link-local address. I
have no idea what harm would it do for IPv4 to fallback to a
link-local address.
What is the ultimate reason for adding a "dhcp-only" or "linklocal-only"
option? Is it that ConnMan currently behaves badly? Or is there a
particular reason why sending DHCP packets on a link that doesn't
support the protocol is considered harmful - and if so, why? Same goes
for creating a link-local IPv4 address, why is that a problem? I do know
that currently everything is not as optimal as could be, but that can be
fixed eventually.
Some of our customers use dhcp-only because they need devices to either
receive full configuration (including gateway, dns, mask) or nothing at
all. For them, having link-local on dhcp failure would mean having an
incompletely configured network interface, which would create problems.
Other customers need link-local only because they use a network without
a dhcp server, and their devices need to communicate with one another,
without the need of setting static addresses individually, or waiting
for lease request time-outs. Our devices may need to be available on the
network as quickly as possible upon booting.
We'd like to adopt connman into our products in an effort to have a
standard network stack, and we need to continue supporting these
functionalities. By discussing which of these features the connman
community finds appropriate to integrate, we can identify which ones we
will need to focus on supporting on our own.
If you are using Ethernet, then both interfaces should be configured.
In general, the plugged in cable aka carrier for Ethernet was support
to indicate that it gets used. Of course only one can have the default
route of course.
The current feature is that all ethernet interfaces are treated in the
very same manner as every other service; if there already is another
service connected, the newly connected ethernet will not be connected
either. This is a matter of defining a detailed expectation of ethernet
network behavior plus a small amount of fixing.
Currently we support auto-connection to all interfaces (wired, wifi and
gadget) that have carrier, and connecting to just one at a time would
mean a regression in the network stack abilities. Our devices may need
to be connected to several networks at the same time, each one having a
different purpose.In this case,the metric would have various values for
different entries in the routing table.
Cheers,
Mihai
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
