> PPP links have not really ever been considered and nobody has any > current plans to support them either.
I saw what (might) appear to be the start of a PPP plugin in the Connman repo in the "scripts" folder under libppp-plugin.c. Do you know the intention/purpose of that plug-in? It appears to use the PPPD library to implement some features related to PPP. > The working assumption once upon a time was to use the device running > ConnMan as the one tethering its connection to a laptop nearby, thus the > implementation where ConnMan shares its connection to others. I understand this use case and assume you realize my use-case is the polar-opposite. In my scenario the Connman device is in fact tethered to another device (via Gadget Ethernet-USB) that provides WAN connectivity. Specially, I'm working on an IVI platform attached to a telematics module which serves as a brigde to the WAN. I imagine this could be an equally compelling use-case for Connman given GENIVI's interest in using it as a network manager for the car. > struct connman_service to everybody else. There were some patches > floating around last autumn, but the author of those patches disappeared > soon afterwards. > I discovered this discussion from April 2013 here: https://lists.connman.net/pipermail/connman/2013-April/013957.html and patches offered here: https://lists.connman.net/pipermail/connman/2013-April/013965.html Can I assume this is the topic you were referring to? I contacted the author of the patches and it seems increased workload prevented him from properly submit all the necessary patches. With that said, I would like to pick up where he left off and try to formulate a series of patches that the Connman maintainers would consider merging into the base-line. Unfortunately, I need some feedback on several questions regarding such an implementation. I ask only to minimize the number of changes necessary to get these changes submitted and accepted by you. Here are my questions: 1) Some of the structure/function names in ethernet.c are a bit mis-leading with the introduction of partial Gadget support. As in the earlier patch (above) I'm inclined to slightly modify some of these private names so the intent is clearer. Would you accept such changes? 2) It appears the functions for the Gadget "device" driver are effectively empty. My intention is to substitute the gadget_XXXX functions with their ethernet_driver equivalents since that appears to be the behavior I want. One approach is to use the ethernet driver functions directly in the Gadget device driver structure. Another is to call these ethernet driver functions from the Gadget driver function implementations. The third is to copy the content of the ethernet driver functions into the corresponding Gadget driver functions (effectively making copies). Which approach would you prefer and likely accept? 3) There is a static "eth_tethering" flag in ethernet.c. This seems to imply that all ethernet devices are either supporting tethering or not. Is this the intention? It's not clear how this flag would impact Gadget devices? Can you elaborate on the intent/purpose of this private global variable. It might seem this should be included in the ethernet device data (per instance) rather than globally applying to all ethernet devices. I'm likely mis-understanding the intent. 4) I'd argue the service name generated for a Gadget service should in fact include "ethernet" rather than "gadget" as was suggested in the earlier thread above. Truly, the Gadget device is providing an ethernet "service" instead of a "gadget" service which seems more akin to a particular bearer (like USB perhaps). Perhaps you could clarify your reasoning? I am inclined to maintain the current behavior. 5) Do you have any suggestions on the service "weight" that should be assigned to a gadget service type? I'm inclined to list it just below Ethernet since it is a hard-wired connection. 6) For the "service2bearer()" function in session.c, would CONNMAN_SERVICE_TYPE_GADGET be something like "usb"? Likewise for bearer2service()? 7) There was mention in the above threads about adding a global configuration item to main.conf. What is not clear is the intent/purpose of that variable. Can you elaborate? Sorry for bombarding you with so many questions. I am trying to understand the design approach so any patches I produce are easier to accept and integrate. Likely, I may have more questions as I begin the implementation. Thanks for your insights and understanding . . . Glenn _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
