Hi Lucas, > > > We can see on it that nothing occurs when I run the enable-tethering > > script and that the bridge is never created :( > > > > if the bridge does not get created, then no wonder that Tethering does > > not work. > > > > Can you check with brctl (part of bridge-utils) that bridge support is > > available. Also check /sys/modem/bridge/ or lsmod that the either the > > bridge support is compiled in or loaded as module. > > > > You might just have a kernel without bridge support by accident. I > > think > > we used to have a MeeGo bug open for that, but that got fixed. Same > > applies for having a kernel with proper set of netfilter modules for IP > > forwarding and masquerading. > > I've check and it's effectively the case. The build that I've used don't have > the bridge support. I will try to re-test with the latest MeeGo image or > build a kernel myself if it's again the case. > > However there is one thing that I don't understand. For me, don't having the > bridge support in the kernel will simply make a failure for the > src/tethering.c:create_bridge function. In the traces that I've taken there > is absolutely no call to this function. So there is not even a tentative to > create the bridge by connman. > > From the analysis that I've did the create_bridge function is called when we > run the enable-tethering script via the plugin/ethernet.c:enable_tethering() > function. But this is done only if the interface is in the cdc_interface_list. > > The adding of an interface to the cdc_interface_list is done by the > plugin/ethernet.c:tech_add_interface function. Here again, I don't find any > call to this function in my traces. If I continue in this way, the > tech_add_interface is probably not called because when we are in the > src/technology.c:__conman_technology_add_interface (we have trace line 146 > who confirms that this function is called) the technology_list do not > contains (yet?) the technology for the gadget type. > > Adding something to the technology_list is done by the > src/technology.c:technology_get function. In my traces we have a call to this > function for the cellular technology but never for the gadget. So this > confirms that the technology_list contains anything relative to gadget. I'm > not sure if my argument is right but I think there is something who is > missing for the USB gadget.
there is one bridge for all Tethering. So it could be that this already gets enabled for Bluetooth and then we don't create a second bridge for USB. The bridge is shared and Bluetooth clients can talk to USB clients. That is on purpose. The code looks just fine to me. However you also need to double check that /sys/class/net/usb0/uevent shows DEVTYPE=gadget. If not then we also have another problem. This of course does not mean that we did not screw up at some point. The Tethering feature is rather complex actually. Regards Marcel _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
