Hi Glenn, On ke, 2014-01-22 at 20:42 -0500, Glenn Schmottlach wrote: > > 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.
Yes, these are the relevant patches. Note that I implemented the USB tethering in v1.17, so some part of the from patches from April need not to be done. > > 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. Patches are welcome as usual. > > 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? I would say yes, please fix the name to be logical if you wish. > > 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? Note that ethernet and usb gadget ethernet work somewhat differently. When ethernet is plugged in we automatically power if on, for usb gadget ethernet, we should power the device only when there is a real connection. I saw this error when trying the patches in last April. > > 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. I would prefer separate "gadget" and "ethernet". This way it is easier to distinguish them in possible UI etc. > > 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. Sounds ok to me. > > 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? Probably this is not relevant anymore. > > 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 . . . Thank you, and we are waiting to see your patches. > > Glenn Cheers, Jukka _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
