Z uses two IP addresses on eth0

Using Zynthian
1

I had issues with rtpMIDI and the root cause seems to be that Z allocates two ip addresses via eth0.

ifconfig doesn’t reveal it:

(venv) root@zynthian:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.20.152  netmask 255.255.255.0  broadcast 192.168.20.255
        inet6 xxxx::xxx:xxxx:xxx:xxxx prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx txqueuelen 1000  (Ethernet)
        RX packets 7614  bytes 720816 (703.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 708  bytes 88157 (86.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 104

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 25  bytes 5060 (4.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25  bytes 5060 (4.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

But ip a shows the second one

(venv) root@zynthian:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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 noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.152/24 brd 192.168.20.255 scope global dynamic noprefixroute eth0
       valid_lft 5964sec preferred_lft 5964sec
    inet 192.168.20.100/24 brd 192.168.20.255 scope global secondary dynamic noprefixroute eth0
       valid_lft 5969sec preferred_lft 5075sec
    inet6 xxxx::xxx:xxxx:xxx:xxxx/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

The issue is that rtpMIDI announces itself via both IPs, the x.152 being the primary, but rtpMIDI only accepts connection on secondary IP x.100

Is there a reason for having two different IP addresses and can rtpMIDI be fixed to listen for incoming connections on both?

2

Ups! You probably found the cause of the network issues that a bunch of users are having with oram.
In previous versions the dhcpcd service was active. I didn’t disabled it when building the oram image but it collides with the network manager and produce several issues, being the “double” IP one of them.
I just pushed a patch to disable the dhcpcd service. Please update, reboot and the issue should be solved.

Thanks!

2 Likes
3

glad to have helped :+1:

Stupid question, I am on the stable branch, is there any way to switch/update? If I do apt update there is only zynaddsubfx.

I guess being on testing might make more sense in the future just in case you do something that dsp emus might benefit from

I assume editing /etc/apt/sources.list.d/zynthian.list might do? What do I have to enter for testing?

4

I am not sure that my answer fulfills your question, but there is an on-screen switch in Webconf, under Software > Repositories, that allows you to switch your current OS distribution to testing (Vangelis).

1 Like
5

You should not do apt upgrade, it could break things.
Update with this command:

update_zynthian.sh

Or from the zynthian-ui’s admin menu. You will see the green recycle symbol at top-right when an update is available.

Or from webconf :wink:

Regards!

1 Like
6

Stick with Oram branch until we notify. We are currently working on the version management and will inform everyone when that is done.

7

ifconfig, route, arp, bridge commands were written for the linux network stack pre to kernel 2.2 and was obsoleted by the iproute2 command ip, please tell as many people as you can!

2 Likes
8

thanks, update worked and the issue is fixed, rtpMIDI working normally now

3 Likes
9

@wyleu could this be the cause of the issue you were having with network MIDI? (I don’t remember what flavour you were using.)

10

I was using qmidinet but it was a fingers problem at my end hence I chose not to mention it because of the incredible embarrassment it would have brought on me, my family, my friends, my various lovers and exes, and the many, many simple native villagers that worship the very ground I walk on…

5 Likes
11

I am glad I made that as public as possible!

12

Presumably I will have to stand up at a forthcoming zynthclub meeting and declare my failings to the world? and presumably we should organise just such a moot to make me mock myself and chew over the recent zynthian happenings…?

Any suggestions as to when?

13

See Zynth club. .. There's just one rule in Zynth club - #1236 by riban

14

Pin the comment!