Perhaps we need to fully define the requirement such that experts can provide the lowest memory and least complex solution?
usb0 should act as a DHCP server to simplify connecting to a PC. It should generally not provide a gateway such that it doesn't interfere with the PC's network. Often, people will want to bridge the network on the PC such that the Beagle can get to the Internet. For this, we need a way to trigger the adding of a route to the usb0 interface as well as adding nameservers, since the route isn't coming from a DHCP request. Additionally, it might also make sense for the Beagle to provide a bridge to wlan0 or eth0 if those are known to provide good Internet connections and thus a gateway and nameserver might need to be provided. Unless the DHCP times out quickly, I don't know how you'd be able to add that to the PC connection. Further, I am not sure how we'd want to register the user's desire to enable or block this behavior. We should broadcast our mDNS on this interface. The static IP address for this interface should be 192.168.7.2/30, but if the PC provides a bridge, we should DHCP our address. eth0 should act as a DHCP client almost all the time. Occasionally people will want to add static configurations, but I don't think we need to do anything to make this easy. We should broadcast our mDNS on this interface. ap0 should come up by default using the "BeagleBone-XXXX" SSID and "BeagleBone" password if a compatible adapter is in the system. It should be possible to provide a persistent password change and to disable the AP as long as a wlan0 connection is made within a timeout period. If wlan0 is configured and times out, ap0 should come up unless more "expertly disabled", i.e., we don't need to make it easy to permanently disable ap0. We should provide DHCP, gateways and nameservers over ap0 and we should resolve everything to the bone101 server until wlan0 or eth0 is configured. We should NAT ap0 requests to the wlan0 or eth0 networks as long as our DHCP config provides a good gateway and nameservers on those interfaces. We should give preference to eth0 or whatever interface has a valid Internet connection. We can use https://BeagleBoard.org to validate our connection if desired. To be discovered when on an Internet connected network, we should broadcast our mDNS on this interface. Also, if we are proxying the DNS, we should resolve hostname.local ourselves to our static ap0 IP address. It is also desirable to support NAT to usb0 if the PC is configured as a bridge, but this would be a last resort. The static IP address for this interface should be 192.168.8.1/24. wlan0 should look for a "BeagleBone-XXXX" SSID by default and use the "BeagleBone" password, but should not connect to itself. This provides an immediate network of BeagleBones, though only the AP would actually be able to provide a route to the Internet on this network. In practice, you'd need to have a period where all non-Internet-connected-AP-capable BeagleBones have their ap0 disabled (i.e., powered off) to make the network of BeagleBones include a route to the Internet. More important than the network-of-Bones is simply providing an easy persistent configuration for getting on a user's existing WiFi network, including WPS. If a configuration is there, it should connect on boot. This should not take down ap0 unless there is an explicit configuration to do so. It could further be considered to bring in a wlan0 configuration from another BeagleBone found on the network, either if the Beagle host is acting as the AP or perhaps discovered via mDNS. The wlan0 interface should act as a DHCP client and we should broadcast our mDNS on this interface. Don't forget IP over Bluetooth or Bone variants with eth1. An Internet bridge over Bluetooth is especially interesting to make easy. My desire is to simply treat it generically to have an interface with an Internet connection configured outside our "plan" and triggering any desired NAT to the above mentioned interesting interfaces. Is this helpful? Accurate? On Tue, Feb 16, 2016 at 6:35 PM Brian Anderson <[email protected]> wrote: > > > >>> nah use connman, i have it installed by default on jessie images. ;) >>> >>> ~$ sudo connmanctl >>> connmanctl> enable wifi >>> >> >> If connected to BeagleBone with it acting as an access point (AP), this >> seems to result in immediately losing connection. Is there a way to keep >> the AP active? >> > > Ya. I don't think connman plays well with create_ap. You can probably > work around this by telling connman to not manage wlan0 by placing > something like the following in /etc/connman/main.conf > > NetworkInterfaceBlacklist=wlan > > This will prevent connman from attempting to manage _any_ wlan interface. > But of course, you won't later be able to use connman with that interface > to connect as a STA. > > It seems to be a point of confusion about how to setup and manage > persistent settings for networking. People often are tripped up by the > fact that connman may be interfering with their attempts to make changes > using /etc/network/interfaces and friends. It would be great if we could > come up with ways to prevent this confusion. > > I do know that connman will setup an AP (called tethering). > Unfortunately, the only way I could get this to work was by stopping > dnsmasq. For some reason, dnsmasq was preventing connman for establishing > the AP...my guess is that connman wants to do DHCP and conflicts with > dnsmasq. > > I wonder if it would be possible to have connman manage the USB link and > thus avoid all the hackery in /etc/network/interfaces and dnsmasq? > > Alternatively, I wonder if network manager might be a better all around > choice for one stop shopping for network management in lieu of connman? I > don't have any personal experience, but others (DeKay) have supposedly had > luck using nm. > > > > > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
