Beagleboard Black static IPv4 connman difficulties
 

Background

I'm using the BBB with the provided Angstrom Linux.

Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l GNU/Linux

Supplied with that is connman, which for me is new over the /etc/network/interfaces method.

Further, I find is that the connman I have does not include connmanctl and there's a few email threads from about a year ago noting that the connman in Angstrom is very old.

I'm assigning a static IP address, using one of the connman scripts to do this; the intention is to make a distributable embedded product - by which I mean that the static IP will always be the same because it's internal to a larger architecture, I'll be making copies of the disk to establish the base disk and then have upgrade-able application code.

Using the script to set a static IP, the flow goes as following:

1. Determine the cabled Ethernet resource by inspecting /var/lib/connman directory - there should be a sub-directory under there using the name convention: ethernet_<mac-addr-digits>_cable
2. Invoke /usr/lib/connman/test/set-ipv4-method script with the arguments "manual 192.168.2.7 255.255.255.0" to select the address I desire for this and all similar systems.

My Problem(s)

My first tact was in my startup script to invoke the connman set-ipv4-method script with the correct arguments. Further, my script obtained the correct resource name by looking at the /var/lib/connman directory to see what resource was there, expecting only the one wired Ethernet.

The first problem came upon making my disk copy and placing it on another board. The fault was that the disk copy included the sub-directory with a matching MAC resource from the original board and also the discovered MAC resource directory from the new board it was now booting off of. Therefore the process failed.

I don't like things that are close to hacks; wasn't liking this whole connman script concept in the first place; I'd rather have a network configuration file. However to move ahead, a minor pain would be "erase the resource directory from /var/lib/connman and let the connman daemon create a new one for the first boot". Well, it does work, but something is not perfect, it pretty much always fails the first boot and even via the use of a sleep-retry once step I incorporated in my script. It works the second boot, telling me that the search and resolve resources has not fully been completed.

My Questions

Based on this, I find it hard to believe that connman is this great embedded board network utility. I haven't grown to like it at all, except that it does work, when it works. The problem is establishing a method to cause identical configuration for all systems, regardless of the physical resource. In short, when I had /etc/network/interfaces, I could configure eth0 to be static and that worked no matter what CPU board I plugged my flash card into. So I'm wondering if there are any suggestions to the tunes of:

1. Give it up and here's an Angstrom way to go back to /etc/network conventions
2. Here's a way to upgrade to the most recent connman and here are some connman suggestions to streamline the complicated way you're doing this
3. Use another Linux distribution

Final Note

Sorry for the length. I just realized that we did a Raspberry Pi project, recently; we stayed with DHCP, but I just checked one of those systems, arm v6, Linux is 3.6, and it uses the /etc/network convention.

Anyways, if there are suggestions, I'm happy to hear them.

Short answer: Use another distro.

Preferably one that have a larger community and is well mainteined. Also one that doesn't need anything like connman, but just use what works, why have the hasle of such tools that works when they want(is it some sort of AI with own will)?

How about this, Debian Arm ?
Debian is rock solid and works! What else you need ?

Regards

Thanks for the opinion ukiuki. When I see the whole underpinnings replaced, not just the top level app/daemon; I do wonder if I'm missing a core Linux trend. Somehow I suspected I hadn't. I'll give the debian arm a try once we move beyond our first proto stage, thanks for the suggestion.