Ubuntu-emulator no network on latest image

On the host system I see this * Starting virtual private network daemon(s)... [ 10.783889] systemd-logind[630]: Failed to start user service: Unknown unit: user@32011.service

What is the host system?

Host system is Xenial 64bit on xps13

Another NM 1.2 effect ?

We've never really had any kind of working mobile data support in the emulator. There was an effort a long time ago to try and make this work for CI testing of ofono, but as it was estimated to be a major under-taking, we abandoned it.

It should be possible to use the ofono phonesim package to do some testing of the telephony related components, however again this isn't something that would be configured by default either.

From what I understand at used to happen was the mock sim was in place and that linked to the standard emulator bridge connect meaning you had networking this is now not happening, I don't think it is network-manager itself but possibly that the mock sim isn't being activated as there is no sim shown in the system.

This maybe and api change issue on nm side that the mock sim needs updating to utilise.

Any chance you can fire up an old emulator image and prove this?

Again, although there is a modem emulation included in the emulator image ( it's part of qemu ), it's not sufficient for us to run a full ofono/rilmodem against.

AFAIK, there's no special trigger to configure ofono phonesim on the emulator either.

RC 19 which is the current stable image is working as expected, it shows no networking but actually connects.

Network manager version is:
ii network-manager 0.9.10.0-4ubuntu15.1.11 i386 network management framework (daemon and userspace tools)

rc 20 shows no scopes and if I open webbrowser app I have no connection.

ii network-manager 1.1.93-0ubuntu1~vivid3 i386 network management framework (daemon and userspace tools)

Is the version of network manager in image 20 and on.

I created an emulator instance using revision 19. I verified indeed that it's running NM , per comment #8. The indicator shows that airplane mode is active, although urfill isn't running ( /usr/share/urfkill/scripts/flight-mode throws an error ). When I run 'nmcli d', I see that ril_0 ( the modem ) is unavailable, and then I see a number of ethernet devices listed, all which are reported as "unmanaged". This means NM isn't managing the devices. In the case of the emulator, 'eth0' is configured in /etc/network/interfaces like this:

auto eth0
iface eth0 inet static
    address 10.0.2.15
    netmask 255.255.255.0
    gateway 10.0.2.2
    dns-nameservers 10.0.2.3

To confirm that NM really doesn't effect the default networking in the emulator, I dropped an upstart override containing "manual" into /etc/init, and re-started the emulator. I re-started, confirmed NM was longer running, and then used wget to pull down a webpage ( slashdot.org ).

Next I created an emulator using the latest rc image ( #23 ), and after swiping down in the OOB/How-To-Swipe app, I get a white screen, and the apps scope is never displayed, nor does the launcher appear when dragging from the left.

I re-created an emulator using revision 20, with the same effect. If I kill the instance, and restart, after entering the device PIN, I again just get a white screen. phablet-screenshot isn't able to grab an image either...

The last thing I see on the console is:

[ 4.994175] systemd-logind[606]: Failed to start user service: Unknown unit: user@0.service
 * Setting up X socket directories... [ OK ]
/lib/init/init-d-script: 12: /etc/rc2.d/S02whoopsie: -c: not found
basename: missing operand
Try 'basename --help' for more information.
 * Starting virtual private network daemon(s)... [ 10.583711] systemd-logind[606]: Failed to start user service: Unknown unit: user@32011.service
sdk/emulator/opengl/host/libs/Translator/GLES_V2/GLESv2Imp.cpp:glTexParameterf:1786 error 0x500
sdk/emulator/opengl/host/libs/Translator/GLES_V2/GLESv2Imp.cpp:glTexParameterf:1786 error 0x500

I see these same errors with revision 19, so they don't seem to be the cause of the networking and/or unity errors.

@Dave

Could you try to disable NM startup per my instructions above and see if you get the same results?

Confirmed the issues that Tony is seeing there are some serious issue with the rc image.

That is on top of the networking issue that isn't nm. (Thank you Tony for digging into that).

Scopes are not displaying just get the spinner and nothing happens.

If I open system setting from the launcher or an indicator it is just white it's like something is critically not well on the image.

There is no default route set

root@ubuntu-phablet:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.2.0 * 255.255.255.0 U 0 0 0 eth0

On a working emulator

Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.0.2.2 0.0.0.0 UG 0 0 0 eth0
10.0.2.0 * 255.255.255.0 U 0 0 0 eth0

Manually setting it provides a network connection
sudo route add default gw 10.0.2.2

By default, ubuntu-emulator creates an /etc/network/interfaces file with the following contents:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.2.15
    netmask 255.255.255.0
    gateway 10.0.2.2
    dns-nameservers 10.0.2.3

iface eth1 inet manual
iface eth2 inet manual
iface eth3 inet manual
iface eth4 inet manual
iface eth5 inet manual

These interfaces are processed individually by the init script network-interface, and as eth0 is the only 'auto' interface, ifupdown will attempt to configure it.

My guess is that some system-level change in r20 introduces a race condition which prevents ifupdown from properly configuring the default route for eth0.

If the network-interface jobs is restarted, the default route is properly configured, and the browser is able to access the network. That said, this doesn't resolve the problem with scopes not starting...

Here's the syntax for re-starting the interface:

# restart network-interface INTERFACE=eth0

Note, I've also tested the latest emulator rc ( #27 ) and confirmed that the restart works there as well. I also verified that I get the same system-settings failure ( eg. white screen after launching system-settings ) that @Dave described in comment #13.

@tony we already landed a fix for the white screen in the UITK

@Pat Is there a new rc available then?

The white-screen UITK bug is fixed in rc-proposed right now, but we can cherry-pick that to the snapshot and build an rc. But that would be earliest tomorrow.

@Dave

Did you ever confirm my results per my last request in comment #11? It's looking more and more like I was mistaken, and that NM 1.2 may indeed be the culprit.

I re-tested the emulator with the latest rc ( #27 ), and dropped a "manual" network-manager.override file in /etc/init. When I start the emulator, eth0 is properly configured as the default route, and networking is OK. If I then manually start network-manager, the default route disappears. It looks like there's code in NMDefaultRouteManager to remove pre-existing default routes, however the code does have logic to check if the route device is known, and only deletes it in certain circumstances. Unfortunately, there's little to no logging of this code path.

I'll add some debug logs to the version of NM in silo 005, and re-test tomorrow.

Will give it a try today

I confirmed that without NM running the network is up.
sudo mv /etc/init/network-manager.conf /etc/init/network-manager.conf-disabled
and restart

FWIW I see mentions of NM 1.2 having issues supporting interfaces within other types of containers like LXC

So... a long time ago, when Ubuntu Touch was first being developed, we hit a bug with certain rild implementations that would configure the routing table when a data call was established, and this caused problems with NM's routing logic.

The workaround was the creation of a NM dispatcher script called 02default_route_workaround, which runs the following command when triggered:

ip route flush proto boot

This clears any pre-existing routes, and let's NM be the master of the routing table. As you can imagine, this doesn't play well with externally managed devices which may have created default routes.

I confirmed that this script was the culprit by adding a logger statement to log when the script gets called to syslog. By dumping the script args ( $1 == interface, $2 == status ), I determined that the script was being called with 'interface=none' and 'status=hostname'.

I compared NM 0.9.10x to the 1.2.2, and turns out there's a difference in how the hostname is set. In 0.9.10x, setting the hostname is handled by one of the settings plugins. On an Ubuntu system this is either ifupdown or the keyfile settings plugins, neither of which trigger the dispatcher scripts.

In NM 1.2.2, setting the hostname is no longer handled by the settings plugins, and is now instead handled by the core NMPolicy class. The static function settings_set_hostname_cb additionally triggers a call to nm_dispatcher_call with action=hostname.

This fix is to modify 02default_route_workaround to prevent the route flush from occurring if 'status=hostname'.

The attached script prevents the route flush from occurring when the hostname is set.

This script is owned by lxc-android-config, so I'll add a new task to the bug.

Note, we may even want to make additional changes to that this script doesn't flush then routing table on VPN events. I made an attempt to do this ( ie. added an additional check for the prefix "vpn-" when checking $status ), but was having trouble getting it working. The attached change just prevents it from running when the hostname is set, which is what's causing the emulator regression.

This bug was fixed in the package lxc-android-config - 0.230+16.10.20160728-0ubuntu1

---------------
lxc-android-config (0.230+16.10.20160728-0ubuntu1) yakkety; urgency=medium

  * Update NM routing dispatcher script to fix emulator networking ( LP:
    #1587808). (LP: #1587808)

 -- Tony Espy <email address hidden> Thu, 28 Jul 2016 19:44:02 +0000