Re: Feature roadmap
Hi, On Wed, 2015-03-04 at 12:47 +0200, Mihai Neagu wrote: So the presence of the carrier (cable plugged in) to all ethernet interfaces should trigger auto-connect. Autoconnect is already triggered when carrier is present. Autoconnect considers everything to be fine when at least one service has been connected (by some means, be it autoconnect itself or something the user did) and won't connect any more services after that. So the solution is to trigger an immediate connect when the cable is plugged in. Is there a tracker where I can create an entry for this issue (like bugzilla)? There is https://01.org/jira/browse/CM, but at the moment the mailing list is followed by more people. Will the fix also include auto-connect to gadget interfaces which have the cable plugged in to a computer? Gadgets, while being USB client end devices, have the nasty property of not properly reporting a carrier signal, and they usually show off as being connected immediately without a physical cable inserted. This most likely due to the USB gadget driver/hw implementation details which does not properly take into account and/or report a carrier detect signal. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Feature roadmap
Patrik, So the presence of the carrier (cable plugged in) to all ethernet interfaces should trigger auto-connect. Is there a tracker where I can create an entry for this issue (like bugzilla)? Will the fix also include auto-connect to gadget interfaces which have the cable plugged in to a computer? Cheers, Mihai On 02/27/2015 09:19 AM, Patrik Flykt wrote: Hi, On Tue, 2015-02-24 at 17:59 +0200, Mihai Neagu wrote: 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. After re-reading ConnMan documentation, not connecting an ethernet network that was plugged in is to be considered a bug. The action of a cable plug-in is documented in the description of the Connect() method call in doc/service-api.txt as ...the plugging of a cable will trigger connecting automatically This on the initial cable plug-in, it is possible to disconnect and connect ethernet services via D-Bus later on. I'll fix this in the near future. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Feature roadmap
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
Re: Feature roadmap
Hi Mihai, 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. 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. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Feature roadmap
Hi Mihai, We're looking into using connman as the network manager for our programmable embedded systems. It currently has most of the desired features, but we would still need the following functionality: 1. DHCP-only method - to not fall back to link-local if no DHCP lease is issued propose a /etc/connman/main.conf option for this. Should be pretty trivial to add, but you also need to contribute the patches for it. 2. Set link-local method on an interface, without trying DHCP first You are asking for a link-local only method? If so, then same as 1) and propose an option and patches for it. 3. Be able to auto connect to all interfaces that have AutoConnect=true, not just the first successful connection You need to check on how this fits with SingleConnectedTechnology option we already have. 4. Be able to set the link speed for an interface (10/100/1000, Half/Full Duplex) I am not really convinced with this one. That seems out of the scope of ConnMan. Just do that via udev. This sounds like a pretty static configuration to me. Not something that you should be configuring via ConnMan. 5. Be able to specify packet detection (Polling or Interrupt) I have no idea what this means. You need to explain it to me in much more detail. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Feature roadmap
Hi guys, We're looking into using connman as the network manager for our programmable embedded systems. It currently has most of the desired features, but we would still need the following functionality: 1. DHCP-only method - to not fall back to link-local if no DHCP lease is issued 2. Set link-local method on an interface, without trying DHCP first 3. Be able to auto connect to all interfaces that have AutoConnect=true, not just the first successful connection 4. Be able to set the link speed for an interface (10/100/1000, Half/Full Duplex) 5. Be able to specify packet detection (Polling or Interrupt) Are any of these features on the roadmap? If not, would they be accepted from contributors? Thanks, Mihai ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
