Hi,
On Wed, 2014-01-22 at 20:42 -0500, Glenn Schmottlach wrote:
> 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.
PPP is used for l2tp and pptp VPNs, that's where the code comes from.
We're not very enthusiastic in using PPP for anything else.
> I understand this use case and assume you realize my use-case is the
> polar-opposite.
Indeed it is.
> 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
Jukka can clarify which part already got applied.
> 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.
Yes, go ahead.
> 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?
The functions in 'struct connman_technology_driver eth_driver' should
all be prefixed with 'eth_tech_'. The functions in 'struct
connman_network_driver cable_driver' should be prefixed with
'eth_network_'. Both of them have .probe and .remove functions, so they
need different prefixes. Do notice that both soldered on ethernet chips
and USB ethernet dongle connected to an USB host both (automatically)
belong to this category. These use a *_TYPE_ETHERNET.
For the gadget functions, use 'gadget_tech_' and 'gadget_network_' as
prefixes. This part will use *_TYPE_GADGET.
Please have individual naming cleanup patches for each one, it would
also be good to move all the ethernet code after each other. So ehternet
handling first, then gadget and last the module init and close parts.
These ones you could send pretty much immediately.
> 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?
The difference between these two is the type, which then leads to
differently named services. Quickly looking at the code seems to
indicate that struct ethernet_data could be used for both regular
ethernet and gadget as the internal data should be very much the same.
Start e.g. by initially copying the functions, then see what the
difference is and factor out the common parts before sending the
implementation to the list?
> 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.
The eth_tethering flag is just data needed internally. When tethering is
enabled, it's enabled per technology, i.e. all devices belonging to the
technology are then tethering. This comes from technology handling in
ConnMan, it's not specific to plugins/ethernet.c.
> 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.
'Gadget' is already used in /var/lib/connman/settings, so it cannot
really be changed unless we want to create extra code for maintaining
compatibility with the old spelling. For now this is just a bunch of
unnecessary work.
> 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 fine.
> 6) For the "service2bearer()" function in session.c, would
> CONNMAN_SERVICE_TYPE_GADGET be something like "usb"? Likewise for
> bearer2service()?
As above.
> 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?
IIRC there was a discussiong of what the default should be, should we
present gadget as a tethering only technology as before or should
service(s) appear after enabling the technology itself but before
enabling tethering.
Another thing that seems to be different is the "auto-enabling" regular
ethernet has. With regular ethernet when plugging in a cable, a carrier
is detected and that's enough to enable the Wired technology at once.
With USB gadget this behavior seems to be opposite, merely loading the
gadget side kernel support indicates that a connection is present, this
even without a cable attached. Thus we can not do the same kind of
auto-enabling that ethernet has.
HTH,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
