Using Connman for WiFi AP/tether...

Brian_Anderson · March 8, 2016, 6:59pm

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.

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).

Stop and disable dnsmasq service. dnsmasq is being used for DHCP on the usb gadget. dnsmasq apparently conflicts with Connman’s internal DHCP.
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
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

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 .local. So, maybe we don’t necessarily need a static IP to supporting “connecting” to the BBB from usb clients?

This all seems to be encouraging as a possible path to addressing the “requirements” that JasonK enumerated in this thread: https://groups.google.com/forum/#!category-topic/beagleboard/v4_A2x1I5gs

ba

RobertCNelson · March 8, 2016, 7:26pm

Hi Job Brian!

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
(multiple CapabilityBoundingSet= not merged? · Issue #1221 · systemd/systemd · GitHub). 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,

RobertCNelson · March 8, 2016, 8:27pm

Humm, not getting an ip over usb0 yet, (connman with 9e96310)
(systemd: 215 debian jessie)

dnsmasq/create_ap removed

$(dirname $0)/autoconfigure_usb0.sh disabled...

bone:

usb0 Link encap:Ethernet HWaddr ec:24:b8:d2:06:a0
          inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1968 (1.9 KiB) TX bytes:6180 (6.0 KiB)

root@beaglebone:~# journalctl | grep conn | grep usb0
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {create} index 3 type 1 <ETHER>
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {update} flags 4098 <DOWN>
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
operstate 2 <DOWN>
Mar 08 20:22:54 beaglebone connmand[322]: Adding interface usb0 [ gadget ]
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {update} flags 102467
<UP,RUNNING,LOWER_UP>
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
operstate 6 <UP>
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {add} route fe80:: gw
:: scope 0 <UNIVERSE>

root@beaglebone:~# cat /var/lib/connman/settings
[global]
OfflineMode=false

[Wired]
Enable=true
Tethering=false

[Gadget]
Enable=true
Tethering=true

Desktop:

enxec24b8d206af: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        ether ec:24:b8:d2:06:af txqueuelen 1000 (Ethernet)
        RX packets 20 bytes 5020 (4.9 KiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 7 bytes 2702 (2.6 KiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

sudo dhclient enxec24b8d206af not getting an ip...

Regards,

Brian_Anderson · March 8, 2016, 9:42pm

Humm, not getting an ip over usb0 yet, (connman with 9e96310)

Did you unplug/replug the USB cable from the desktop? When first enabling this with the cable plugged in, it seems to require a re-plug to get DHCP to issue an IP. But I suppose your dhclient request from the desktop side should have triggered this.

(systemd: 215 debian jessie)

dnsmasq/create_ap removed

$(dirname $0)/autoconfigure_usb0.sh disabled…

bone:

usb0 Link encap:Ethernet HWaddr ec:24:b8:d2:06:a0
inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1968 (1.9 KiB) TX bytes:6180 (6.0 KiB)

Do you see a tether interface (ip addr)? Attached log has output from ip on bone. And of course, if you have rebooted, you need to enable the tether again unless you have setup things for persistent tethering…some connman config parameter.

root@beaglebone:~# journalctl | grep conn | grep usb0
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {create} index 3 type 1
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {update} flags 4098
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
operstate 2
Mar 08 20:22:54 beaglebone connmand[322]: Adding interface usb0 [ gadget ]
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {update} flags 102467
<UP,RUNNING,LOWER_UP>
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
operstate 6
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {add} route fe80:: gw
:: scope 0

Hmmm. That’s it? I have lots more output (see attached file).

Note also, that I have a wired connection on eth0 as well as a powered hub with a TP-Link and BT dongle attached. Not that the TP-Link and BT dongle matter. But I am wondering about eth0.

root@beaglebone:~# cat /var/lib/connman/settings
[global]
OfflineMode=false

[Wired]
Enable=true
Tethering=false

[Gadget]
Enable=true
Tethering=true

Pretty much same as mine.

FWIW, I also have /etc/connman/main.conf:

Place this file in /etc/connman/main.conf

[General]

Don’t manage mesh point interfaces of the form “mpx”…

NetworkInterfaceBlacklist=mp

Ordered list of preferred technologies to connect to.

PreferredTechnologies=ethernet,wifi

Desktop:

enxec24b8d206af: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether ec:24:b8:d2:06:af txqueuelen 1000 (Ethernet)
RX packets 20 bytes 5020 (4.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7 bytes 2702 (2.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

sudo dhclient enxec24b8d206af not getting an ip…

Didn’t have to do that. Well, maybe that would have negated the need to re-plug the cable. I have an IP on the host side:

brian_anderson@htc-thinkpad1 ~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 54:ee:75:31:34:94 brd ff:ff:ff:ff:ff:ff
inet6 fe80::56ee:75ff:fe31:3494/64 scope link
valid_lft forever preferred_lft forever
4: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether e8:b1:fc:46:1d:ba brd ff:ff:ff:ff:ff:ff
inet6 fe80::eab1:fcff:fe46:1dba/64 scope link
valid_lft forever preferred_lft forever
39: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether d0:5f:b8:fd:1e:d6 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::d25f:b8ff:fefd:1ed6/64 scope link
valid_lft forever preferred_lft forever

I attached a log.txt file with a bunch of details.

ba

log.txt (12.4 KB)

Brian_Anderson · March 8, 2016, 9:46pm

sudo dhclient enxec24b8d206af not getting an ip…

Didn’t have to do that. Well, maybe that would have negated the need to re-plug the cable. I have an IP on the host side:

OK, I rebooted the Bone and enabled the tether from the Bone. IP didn’t show up on laptop. dhclient on the laptop hung (well, maybe it would timeout but I was impatient). Re-plugging the cable got me a shiny new IP on the laptop (eth1). Laptop is running Linux Mint and Network Manager.

ba

RobertCNelson · March 8, 2016, 10:00pm

PS, i'm also switched to 'git' on the build:

It's currently building, so i'll retest in a bit..

Did you unplug/replug the USB cable from the desktop? When first enabling
this with the cable plugged in, it seems to require a re-plug to get DHCP to
issue an IP. But I suppose your dhclient request from the desktop side
should have triggered this.

That's actually going to be a problem. On the BeagleBone Green, power
comes thru usb0... (and i've run out of BeagleBone Black's at
work...)

I've tried, restarting connman.service, that didn't help... We might
have to fake a hotplug event?

(systemd: 215 debian jessie)

dnsmasq/create_ap removed

$(dirname $0)/autoconfigure_usb0.sh disabled...

bone:

usb0 Link encap:Ethernet HWaddr ec:24:b8:d2:06:a0
          inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1968 (1.9 KiB) TX bytes:6180 (6.0 KiB)

Do you see a tether interface (ip addr)? Attached log has output from ip on
bone. And of course, if you have rebooted, you need to enable the tether
again unless you have setup things for persistent tethering...some connman
config parameter.

Nope, no tether, and i've enabled:

PersistentTetheringMode=true

err..

that seems like it was it!!

mkdir /etc/connman/
mv /etc/connman.conf /etc/connman/main.conf

reboot...

Mar 08 21:57:44 beaglebone connmand[307]: usb0 {RX} 0 packets 0 bytes
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {TX} 3 packets 390 bytes
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 <UP>
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {RX} 0 packets 0 bytes
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {TX} 3 packets 390 bytes
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 <UP>
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 <UP>
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 <UP>
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 <UP>
Mar 08 21:57:45 beaglebone kernel: device usb0 entered promiscuous mode
Mar 08 21:57:45 beaglebone kernel: tether: port 1(usb0) entered forwarding state
Mar 08 21:57:45 beaglebone kernel: tether: port 1(usb0) entered forwarding state

bone:

tether Link encap:Ethernet HWaddr ec:24:b8:d2:06:a0
          inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
          inet6 addr: fe80::38b0:4eff:feb4:9211/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
          RX packets:684 errors:0 dropped:0 overruns:0 frame:0
          TX packets:360 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:66369 (64.8 KiB) TX bytes:38011 (37.1 KiB)

usb0 Link encap:Ethernet HWaddr ec:24:b8:d2:06:a0
          inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
          RX packets:684 errors:0 dropped:0 overruns:0 frame:0
          TX packets:380 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:66369 (64.8 KiB) TX bytes:60067 (58.6 KiB)

desktop:

enxec24b8d206af: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255
        inet6 fe80::ee24:b8ff:fed2:6af prefixlen 64 scopeid 0x20<link>
        ether ec:24:b8:d2:06:af txqueuelen 1000 (Ethernet)
        RX packets 180 bytes 24507 (23.9 KiB)
        RX errors 3 dropped 0 overruns 0 frame 3
        TX packets 183 bytes 24716 (24.1 KiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Regards,

Brian_Anderson · March 8, 2016, 11:08pm

PS, i’m also switched to ‘git’ on the build:

https://github.com/rcn-ee/repos/commit/dd480e6dac1317eac1cc15b2a60740e7ba53128e

It’s currently building, so i’ll retest in a bit…

Did you unplug/replug the USB cable from the desktop? When first enabling
this with the cable plugged in, it seems to require a re-plug to get DHCP to
issue an IP. But I suppose your dhclient request from the desktop side
should have triggered this.

That’s actually going to be a problem. On the BeagleBone Green, power
comes thru usb0… (and i’ve run out of BeagleBone Black’s at
work…)

Ya. I have a couple of BBGs and didn’t read the fine print close enough to see that there is no barrel jack.
So, I have an Andice Labs Power Cape at the ready and/or build my own power supply as power over USB is obviously such a non-starter for real work.

I’ve tried, restarting connman.service, that didn’t help… We might
have to fake a hotplug event?

Sounds like the right thing, but I haven’t done that before. I suppose a hotplug event on boot iff a usb cable is plugged in?

(systemd: 215 debian jessie)

dnsmasq/create_ap removed

$(dirname $0)/autoconfigure_usb0.sh disabled…

bone:

usb0 Link encap:Ethernet HWaddr ec:24:b8:d2:06:a0
inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1968 (1.9 KiB) TX bytes:6180 (6.0 KiB)

Do you see a tether interface (ip addr)? Attached log has output from ip on
bone. And of course, if you have rebooted, you need to enable the tether
again unless you have setup things for persistent tethering…some connman
config parameter.

Nope, no tether, and i’ve enabled:

PersistentTetheringMode=true

err…

that seems like it was it!!

mkdir /etc/connman/
mv /etc/connman.conf /etc/connman/main.conf

reboot…

Mar 08 21:57:44 beaglebone connmand[307]: usb0 {RX} 0 packets 0 bytes
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {TX} 3 packets 390 bytes
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {RX} 0 packets 0 bytes
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {TX} 3 packets 390 bytes
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6
Mar 08 21:57:45 beaglebone kernel: device usb0 entered promiscuous mode
Mar 08 21:57:45 beaglebone kernel: tether: port 1(usb0) entered forwarding state
Mar 08 21:57:45 beaglebone kernel: tether: port 1(usb0) entered forwarding state

bone:

tether Link encap:Ethernet HWaddr ec:24:b8:d2:06:a0
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::38b0:4eff:feb4:9211/64 Scope:Link
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:684 errors:0 dropped:0 overruns:0 frame:0
TX packets:360 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:66369 (64.8 KiB) TX bytes:38011 (37.1 KiB)

usb0 Link encap:Ethernet HWaddr ec:24:b8:d2:06:a0
inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:684 errors:0 dropped:0 overruns:0 frame:0
TX packets:380 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:66369 (64.8 KiB) TX bytes:60067 (58.6 KiB)

desktop:

enxec24b8d206af: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::ee24:b8ff:fed2:6af prefixlen 64 scopeid 0x20
ether ec:24:b8:d2:06:af txqueuelen 1000 (Ethernet)
RX packets 180 bytes 24507 (23.9 KiB)
RX errors 3 dropped 0 overruns 0 frame 3
TX packets 183 bytes 24716 (24.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Excellent!

So one has to wonder if it would be wise to eliminate /etc/network/interfaces (or at least have everthing commented out with warnings) to help prevent the often occurring confusion when Connman overrides definitions in /etc/network/interfaces. And, of course, /etc/network/interfaces is supposed to be “legacy”.

When this is sorted, it would be cool to work towards an “on-boarding” solution (possibly using something like AllJoyn OnBoarding Service) to provision credentials on boards with on board wifi…sorta like what JasonK was pining about.

ba
ba

RobertCNelson · March 8, 2016, 11:25pm

Ya. I have a couple of BBGs and didn't read the fine print close enough to
see that there is no barrel jack.
So, I have an Andice Labs Power Cape at the ready and/or build my own power
supply as power over USB is obviously such a non-starter for real work.

I have that same power cape, just need to assemble it..

Excellent!

So one has to wonder if it would be wise to eliminate
/etc/network/interfaces (or at least have everthing commented out with
warnings) to help prevent the often occurring confusion when Connman
overrides definitions in /etc/network/interfaces. And, of course,
/etc/network/interfaces is supposed to be "legacy".

I think we will just blank it out, then users can add there own tweaks..

I think i figured out how to get the usb0 to start at 192.168.7.2

https://paste.debian.net/413402/

(so much stuff is hard-coded for 192.168.7.2)

When this is sorted, it would be cool to work towards an "on-boarding"
solution (possibly using something like AllJoyn OnBoarding Service) to
provision credentials on boards with on board wifi...sorta like what JasonK
was pining about.

I'd be up for anything unified..

Regards,

William_Hermans · March 9, 2016, 1:05am

(so much stuff is hard-coded for 192.168.7.2)

So, again. I’m wondering why you all need to have dhcp on this interface at all ? I mean with all the hassles I’m hearing about on the forums here, it would be easier to teach people how to set the interface manually to *7.1 on the host side. Then of course . . . *7.2 on the beaglebone. I’ve been doing this pretty much since day one, give or take a week or two shake down early on . . .and yeah have had no problems. Definately not the problems I’m seeing crop up on the forums here all the time . . .

William_Hermans · March 9, 2016, 1:09am

Also, I’m glad you all are working on getting this working. Truly. But is it or does it really have to be all this work, and all this difficult to get this sort of thing working ? Me, I really really hate, yes hate, with a passion → connman. So of course im sitting on the sidelines here thinking this should be doable with using connman. But again, of course, I’ve no hands on yet to date.

Brian_Anderson · March 9, 2016, 5:32am

So one has to wonder if it would be wise to eliminate
/etc/network/interfaces (or at least have everthing commented out with
warnings) to help prevent the often occurring confusion when Connman
overrides definitions in /etc/network/interfaces. And, of course,
/etc/network/interfaces is supposed to be “legacy”.

I think we will just blank it out, then users can add there own tweaks…

With a big fat warning about connman overriding certain settings!

I think i figured out how to get the usb0 to start at 192.168.7.2

https://paste.debian.net/413402/

Err, couldn’t figure out from the pastebin. Looked at your repo, and it appears you are trying to have some control over what the starting IP address that DHCP will hand out for tethering? If so, I don’t think you can necessarily assume that the USB gadget will be the first thing needing an address can you? What if one tethers WiFi then USB? What if there is an address conflict with the localhost or USB host? I’m assuming that connman deals with these use cases when allocating a new IP address via its internal DHCP. And you still won’t get the “static” address you desire.

(so much stuff is hard-coded for 192.168.7.2)

Ya, and therein lies the problem it seems. Maybe it would be best to bite the bullet here and go for .local discovery? OTOH, not sure if mDNS hostname discovery works on a Windoze machine?

ba

RobertCNelson · March 9, 2016, 4:09pm

I think i figured out how to get the usb0 to start at 192.168.7.2

Debian paste error

Err, couldn't figure out from the pastebin. Looked at your repo, and it
appears you are trying to have some control over what the starting IP
address that DHCP will hand out for tethering? If so, I don't think you can
necessarily assume that the USB gadget will be the first thing needing an
address can you? What if one tethers WiFi then USB? What if there is an
address conflict with the localhost or USB host? I'm assuming that connman
deals with these use cases when allocating a new IP address via its internal
DHCP. And you still won't get the "static" address you desire.

yeah, very racy, and a bad idea.

So i now have things working a littler closer to a connman only solution..

Drop dnsmasq/create_ap, add back udhcpd

usb0 : udhcpd (192.168.7.2)
wlan0: connman ap (192.168.0.1)

Windows 10 (usb0, beaglebone.local doesn't work)

I wonder Jason's thought on "shipping" this installer?

https://support.apple.com/kb/DL999?locale=en_US

Regards,

jkridner · March 9, 2016, 4:52pm

I think i figured out how to get the usb0 to start at 192.168.7.2

Debian paste error

Err, couldn't figure out from the pastebin. Looked at your repo, and it
appears you are trying to have some control over what the starting IP
address that DHCP will hand out for tethering? If so, I don't think you can
necessarily assume that the USB gadget will be the first thing needing an
address can you? What if one tethers WiFi then USB? What if there is an
address conflict with the localhost or USB host? I'm assuming that connman
deals with these use cases when allocating a new IP address via its internal
DHCP. And you still won't get the "static" address you desire.

yeah, very racy, and a bad idea.

So i now have things working a littler closer to a connman only solution..

Drop dnsmasq/create_ap, add back udhcpd

usb0 : udhcpd (192.168.7.2)
wlan0: connman ap (192.168.0.1)

Windows 10 (usb0, beaglebone.local doesn't work)

I wonder Jason's thought on "shipping" this installer?

Download Bonjour Print Services for Windows v2.0.2

Does it work? Do they provide a redistribution license?

RobertCNelson · March 9, 2016, 4:55pm

I think i figured out how to get the usb0 to start at 192.168.7.2

Debian paste error

Err, couldn't figure out from the pastebin. Looked at your repo, and it
appears you are trying to have some control over what the starting IP
address that DHCP will hand out for tethering? If so, I don't think you can
necessarily assume that the USB gadget will be the first thing needing an
address can you? What if one tethers WiFi then USB? What if there is an
address conflict with the localhost or USB host? I'm assuming that connman
deals with these use cases when allocating a new IP address via its internal
DHCP. And you still won't get the "static" address you desire.

yeah, very racy, and a bad idea.

So i now have things working a littler closer to a connman only solution..

Drop dnsmasq/create_ap, add back udhcpd

usb0 : udhcpd (192.168.7.2)
wlan0: connman ap (192.168.0.1)

Windows 10 (usb0, beaglebone.local doesn't work)

I wonder Jason's thought on "shipping" this installer?

Download Bonjour Print Services for Windows v2.0.2

Does it work?

It does work on Windows 10, "http://beaglebone.local" comes up over
usb0 just fine..

Do they provide a redistribution license?

I haven't found a clear license on that, everyone seems to link to it.
Or users are too cut it out of the itunes.exe binary.. yuck.

(maybe we can just link in the documentation for windows users)

Regards,

Brian_Anderson · March 9, 2016, 6:26pm

yeah, very racy, and a bad idea.

So i now have things working a littler closer to a connman only solution…

Drop dnsmasq/create_ap, add back udhcpd

usb0 : udhcpd (192.168.7.2)
wlan0: connman ap (192.168.0.1)

Assuming Connman manages wlanx (AP or STA) as well as ethx. I presume you have told Connman to ignore usbx interfaces in /etc/connman/main.conf?

Windows 10 (usb0, beaglebone.local doesn’t work)

Hmm. So, if udhcpd is managing the static address on usb0, then counting on mDNS hostname discovery in no longer a requirement, just a nice to have? For Windoze users, they call still access via static IP, other platforms can access via static IP via hostname.local. With that said, if we do include mDNS for Windoze users, and start advertising hostname.local as the preferred way of access, then eventually we could rid ourselves of the static IP access method.

Also, this Wikipedia article on “.local” is enlightening. The article suggests that counting on hostname.local resolution may not scale well to Windoze environments.

RobertCNelson · March 9, 2016, 6:41pm

>> yeah, very racy, and a bad idea.
>>
>> So i now have things working a littler closer to a connman only
>> solution..
>>
>> Drop dnsmasq/create_ap, add back udhcpd
>>
>> usb0 : udhcpd (192.168.7.2)
>> wlan0: connman ap (192.168.0.1)

Assuming Connman manages wlanx (AP or STA) as well as ethx.

Correct

I presume you
have told Connman to ignore usbx interfaces in /etc/connman/main.conf?

Here's the configuration i'm using at the moment, i'll test adding an
ignore for usbx

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-jessie.sh#L190-L220

>> Windows 10 (usb0, beaglebone.local doesn't work)

Hmm. So, if udhcpd is managing the _static_ address on usb0, then counting
on mDNS hostname discovery in no longer a requirement, just a nice to have?
For Windoze users, they call still access via static IP, other platforms can
access via static IP via hostname.local. With that said, if we do include
mDNS for Windoze users, and start advertising hostname.local as the
_preferred_ way of access, then _eventually_ we could rid ourselves of the
static IP access method.

Yeah, once we find a Windows "mDNS" discovery (like Bonjour but
distribtable) we can stick in that in the flash drive that pop's up,
and switch usb0 to connman..

Also, this Wikipedia article on ".local" is enlightening. The article
suggests that counting on hostname.local resolution may not scale well to
Windoze environments.

I think as long as it works on one, that's good enough for out of box.

Regards,

RobertCNelson · March 9, 2016, 6:50pm

Okay, that should solve a race:

root@beaglebone:~# journalctl | grep conn | grep usb0
Mar 09 18:48:52 beaglebone connmand[373]: usb0 {create} index 2 type 1 <ETHER>
Mar 09 18:48:52 beaglebone connmand[373]: usb0 {update} flags 4098 <DOWN>
Mar 09 18:48:52 beaglebone connmand[373]: usb0 {newlink} index 2
address 1C:BA:8C:D9:F8:A0 mtu 1500
Mar 09 18:48:52 beaglebone connmand[373]: usb0 {newlink} index 2
operstate 2 <DOWN>
Mar 09 18:48:52 beaglebone connmand[373]: Ignoring interface usb0 (filtered)
Mar 09 18:48:52 beaglebone connmand[373]: Adding interface usb0 [ gadget ]
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {add} address
192.168.7.2/24 label usb0 family 2
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {update} flags 69699
<UP,RUNNING,LOWER_UP>
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {newlink} index 2
address 1C:BA:8C:D9:F8:A0 mtu 1500
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {newlink} index 2
operstate 6 <UP>
Mar 09 18:48:55 beaglebone connmand[373]: Ignoring interface usb0 (filtered)
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {add} route 192.168.7.0
gw 0.0.0.0 scope 253 <LINK>
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {add} route fe80:: gw
:: scope 0 <UNIVERSE>
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {del} address
192.168.7.2/24 label usb0
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {del} route 192.168.7.0
gw 0.0.0.0 scope 253 <LINK>
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {add} address
192.168.7.2/30 label usb0 family 2
Mar 09 18:48:55 beaglebone connmand[373]: usb0 {add} route 192.168.7.0
gw 0.0.0.0 scope 253 <LINK>

Regards,

Brian_Anderson · March 9, 2016, 7:05pm

Drop dnsmasq/create_ap, add back udhcpd

Just curious, why udhcpd rather than dnsmasq? Isn’t dnsmasq supposed to be “light weight”? Err, lighter than udhcpd? What is the difference between the two?

I presume you
have told Connman to ignore usbx interfaces in /etc/connman/main.conf?

Here’s the configuration i’m using at the moment, i’ll test adding an
ignore for usbx

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-jessie.sh#L190-L220

Hmm, I see you are ignoring usb0 rather than all usb interfaces. I suppose that is the only possiblity on BBB. Not sure about other boards.

BTW, does it work to put a USB hub between the host and gadget and thus connect multiple hosts (laptop, desktop, etc.) to the usb ethernet and thus serve up many IP addresses from usb0 gadget?

Okay, that should solve a race:

Cool.

ba

Brian_Anderson · March 9, 2016, 7:10pm

Yeah, once we find a Windows “mDNS” discovery (like Bonjour but
distribtable) we can stick in that in the flash drive that pop’s up,
and switch usb0 to connman…

Yes, thats a good idea. Any while you are at it, maybe a “preconfigured” PuTTY or something like that so users can automagically and hassle free connect to their shiny new board via usb ethernet?

Also, this Wikipedia article on “.local” is enlightening. The article
suggests that counting on hostname.local resolution may not scale well to
Windoze environments.

I think as long as it works on one, that’s good enough for out of box.

Yes, I guess that’s correct! External networks not involved!

ba

jkridner · March 9, 2016, 8:03pm

Yeah, once we find a Windows “mDNS” discovery (like Bonjour but
distribtable) we can stick in that in the flash drive that pop’s up,
and switch usb0 to connman…

Yes, thats a good idea. Any while you are at it, maybe a “preconfigured” PuTTY or something like that so users can automagically and hassle free connect to their shiny new board via usb ethernet?

License is probably okay for that. Can you confirm, create the customization, and send a pull request against http://github.com/beagleboard/beaglebone-getting-started ?