ConnMan, need to add secondary and third IPv4 addresses

Help and Support Raspberry Pi
1

OSMC 2017.07-1, Pi 2 Model B

I need a way to assign a secondary and third ipv4 to the interface eth0 which is robust against reboots.

Background: I want to use both SAT>IP DVB-C tuners of a DVB-C cable repeater (AVM DVB-C) with tvheadend. For this I have to bind two separate IPs of the OSMC device to the tuner adapter since the AVM DVB-C restricts the assignement of a DVB-C tuner to one external IP, only.

Unfortunately the old network manager solution which simply creates an appropriate file /etc/network/interfaces does not work anymore with the connman solution in place.
I’m successful to manually add the IPs using i.e.

/sbin/ifconfig eth0 add 192.168.178.18
/sbin/ifconfig eth0 add 192.168.178.19

but adding this to /etc/rc.local has worked very very seldom after a reboot.

Any ideas how to configure this so it is permanent and robust against network failures?
Current eth0 connman config is the default namely DHCP.

With thx in advance,

2

You should be able to do this using connmanctl. It
will then be persistent

3

Thx for your quick answer but I cannot figure out how to do that with connmanctl. Using

connmanctl config ... --ipv4 dhcp
or
connmanctl config ... --ipv4 manual ...

I’m only able to specify DHCP or bind one manual ip + netmask + gateway to the interface.

Any idea is welcome.

4

I also tried connmanctl but ran into the same problem.

Unless Sam can spell out the exact connmanctl syntax, I’d suggest you do it via systemd, Create a service unit:

osmc@osmc:~$ cat /etc/systemd/system/ip-alias.service 
[Unit]
Description=Creates alias IP addresses
After=network-online.target
Requires=network-online.target

[Service]
Type=oneshot
ExecStartPre=/bin/sleep 2
ExecStart=/sbin/ifconfig eth0 add 192.168.178.18
ExecStart=/sbin/ifconfig eth0 add 192.168.178.19

[Install]
WantedBy=multi-user.target

then enable it with sudo systemctl enable ip-alias.service and reboot. The sleep 2 is unfortunately a bit arbitrary but some delay was required before it would reliably work at system startup.

1 Like
5

That will work but:

  • Use connman-wait-for-network.service (and enable it) as your dependency
  • Keep in mind post Jessie ifconfig is dead.

Sam

1 Like
6

That overcame the need for the sleep.

not necessary if Requires=connman-wait-for-network.service is used.

So what’s the connmanctl syntax? :wink:

@JimKnopf Just for the record, here’s my revised ip-alias.service file:

osmc@osmc:~$ cat /etc/systemd/system/ip-alias.service 
[Unit]
Description=Create alias IP addresses
After=connman-wait-for-network.service
Requires=connman-wait-for-network.service

[Service]
Type=oneshot
ExecStart=/sbin/ifconfig eth0 add 192.168.178.18
ExecStart=/sbin/ifconfig eth0 add 192.168.178.19

[Install]
WantedBy=multi-user.target
1 Like
8

Hi @dillthedog and @sam_nazarko,

many thanks! This works excellent, here.

So, if connman is to be seen as the replacement for net-tools (and perhaps even route2) how should this work after Jessie?

9

I assume that the iproute2 package will be installed during the upgrade to stretch (though you can do it now, if you want) and instead of using ifconfig you’d run something like:

/bin/ip addr add 192.168.178.18/24 dev eth0
/bin/ip addr add 192.168.178.19/24 dev eth0

Running ip addr will show you if it worked, though interestingly I see that ifconfig won’t show the new addresses that were added using ip.

1 Like
10

Will try in the evening timezone MEST.

11

Can confirm that both methods ifconfig and ip of the iproute2 package works fine in this ip-alias service.

Thx for all your help!

Best would be to find an easy way with the connman stack but it looks to me that ‘additional ip addresses on same interface’ is something the connman developer(s) are not aware of or neglect since the Connection Manager’s target systems/users do not need such feature.

13

Not quite. We’ll still keep using ConnMan, but some tools such as ifconfig are deprecated, and being replaced by the ip command. You can get ifconfig back; but the output of the commands on Debian Stretch are a little different than what you might be used to. It seems to just behave as a wrapper to ip -a.

ConnMan indeed seems to be designed with a ‘one technology at a time’ concept. For example, it’s not possible to boot with WiFi and Ethernet connected if there’s an Ethernet connection at the time when ConnMan is started.

Sam

1 Like