Hi Job Brian! On Tue, Mar 8, 2016 at 12:59 PM, Brian Anderson <b...@nwlink.com> wrote: > I wanted to document some steps that I took to get Connman working for > setting up a WiFI AP. Connman terminology for this is "tethering". All of > this was done on a recent (Feb2016) Debian Jessie distro with the 4.1.x TI > kernel. > > 1. There is an issue with the systemd connman.service unit file. Connman > needs to be able to dynamically load kernel modules in order for tethering > to work. The systemd unit file lacks the CAP_SYS_MODULE capability in the > CapabilityBoundingSet property. The proper setting should be: > > CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE > CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE > > I first attempted to add a systemd drop-in to merge this into the distros > connman.service, but alas, also ran into systemd issue 1221 > (https://github.com/systemd/systemd/issues/1221). Apparently this systemd > issue was fixed after release 226. Currently, RCN Debian images run systemd > 215. So, you will have to directly modify > /lib/systemd/system/connman.service to correct this capability deficiency. > > I have posted a bug report to the Connman mail list, and a patch has been > committed to Connman mainline to fix this missing capability (commit > 9e96310).
I'll add that commit to our connman patchset.. > > 2. Stop and disable dnsmasq service. dnsmasq is being used for DHCP on the > usb gadget. dnsmasq apparently conflicts with Connman's internal DHCP. > > 3. I renamed /etc/dnsmasq.d/usb0-dhcp to /etc/dnsmasq.d/usb0-dhcp~ to > disable boot time setup being performed by > /opt/scripts/boot/autoconfigure_usb0.sh > > 4. I renamed /etc/network/interfaces to /etc/network/interfaces.org to > avoid any conflicts and confusion between Connman and legacy ifup/ifdown and > test that Connman can truely deal with all network setup without having to > resort to any legacy tools. > > After these fixes, I can now successfully setup a WiFI AP using > `connmanctl`. Traffic on the AP will have internet traffic routed to the > ethernet interface. Client STAs connected to the AP will have DHCP > allocated IP addresses (typically on the 192.168.0.1/24 network). > > connmanctl enable wifi > connmanctl tether wifi on <my-ssid> <my-ssid-passphrase> > > Note that I can also setup a usb gadget tether using similar `connmanctl` > commands: > > connmanctl enable gadget > connmanctl tether gadget on > > A client connected to the usb gadget will also have a DHCP allocated IP > address (again typically on the 192.168.0.1/24 network). You may need to > re-plug the USB cable in order to have an IP address allocated after you > turn on the tether. > > So, all of this avoids the `create_ap` hackery and the necessity to run > dnsmasq for the usb ethernet gadget. Unfortunately, I see no way to use > this method to allocate a static IP address on the usb gadget. Reading the > Connman mail list, I doubt defining a static IP for the usb gadget would > ever be supported as in general there is no way to guarantee that wouldn't > be a conflict with the static IP...or at least that's the way I read the > discussion. But, the BBB _does_ show up via mDNS on the client (in this > case, my Linux laptop). Both the BBB web site and the "workstation" show up > via Avahi Discovery browser. And I can ssh to the BBB via <hostname>.local. > So, maybe we don't necessarily need a static IP to supporting "connecting" > to the BBB from usb clients? Sweet i like it! As long as "hostname.local" works i don't mind losing 192.168.7.2 Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
