No internet connection while screen share with Aethercast (BQ Aquaris M10)

Bug #1639630 reported by GT
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
aethercast
In Progress
High
Simon Fels

Bug Description

There is another issue with Aethercast on MD10 FHD with OTA-13:

When using aethercast, the internet connection can't be used. It only works after either manually removing the dafault route via the p2p connection each time or by adapting the dhclient config to request the router for wlan0 or for p2p* .

There already seems to be an issue fixing this for mii-box, but the fix does at least not work for MD10.

This issue was mentioned by Michael Sievers as additional info for this bug https://bugs.launchpad.net/aethercast/+bug/1590135/comments/17

I can also confirm this issue on my M10 tablet.

Related branches

Revision history for this message
Simon Fels (morphis) wrote :
Changed in aethercast:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Simon Fels (morphis)
Revision history for this message
Michael Sievers (mike+s) wrote :

Hello,

the short version: it works only after moving the enter-hook script one directory up.

The long version:

as my device is not set up for developer mode yet, I have tried replicating the changes by manually:

I left the line added to /etc/apparmor.d/sbin.dhclient in place:

phablet@ubuntu-phablet:/etc/apparmor.d$ diff -c /home/phablet/aether/sbin.dhclient.orig sbin.dhclient
*** /home/phablet/aether/sbin.dhclient.orig 2016-11-02 21:58:11.399360012 +0100
--- sbin.dhclient 2016-11-02 22:15:36.399360075 +0100
***************
*** 45,50 ****
--- 45,51 ----

    # aethercast
    /{,var/}run/aethercast/dhclient*.leases lrw,
+ /run/aethercast/dhclient*.leases lrw,

    # synce-hal
    /usr/share/synce-hal/dhclient.conf r,

I performed the following according to the merge diff:

* sudo mv /etc/dhcp/dhclient-enter-hooks.d/aethercast/dhclient-hook-p2p /etc/dhcp/dhclient-enter-hooks.d/aethercast
* sudo chmod 755 /etc/dhcp/dhclient-enter-hooks.d/aethercast/dhclient-hook-p2p

added the asterisk to leases:
mor.d/dhcpd.d/usr.sbin.aethercasphablet@ubuntu-phablet:/etc/apparmor.d/dhcpd.d$ diff -c /home/phablet/aether-silo/dhcpd.d/usr.sbin.aethercast.orig /etc/apparmor.d/dhcpd.d/usr.sbin.aethercast
*** /home/phablet/aether-silo/dhcpd.d/usr.sbin.aethercast.orig 2016-11-09 14:40:05.984798320 +0100
--- /etc/apparmor.d/dhcpd.d/usr.sbin.aethercast 2016-11-09 14:40:21.054798320 +0100
***************
*** 11,15 ****
  /etc/aethercast/dhcpd.conf r,
  # In addition aethercast will also point dhcpd to a private
  # lease/pid file
! /{,var/}run/aethercast/dhcpd*.leases lrw,
  /{,var/}run/aethercast/dhcpd*.pid lrw,
--- 11,15 ----
  /etc/aethercast/dhcpd.conf r,
  # In addition aethercast will also point dhcpd to a private
  # lease/pid file
! /{,var/}run/aethercast/dhcpd*.leases* lrw,
  /{,var/}run/aethercast/dhcpd*.pid lrw,

After reboot, the M10 FHD on so changed OTA-13 connects successfully to a Microsoft Wireless Display Adapter.

On the first connect, I see no new default route added (checked by "ip r l").

But, after disconnecting and reconnecting, a default route appears:

$ ip r l
default via 192.168.157.1 dev p2p0
default via 192.168.1.254 dev wlan0 proto static metric 600
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.33 metric 600
192.168.7.0/24 dev p2p0 proto kernel scope link src 192.168.7.1
192.168.157.0/24 dev p2p0 proto kernel scope link src 192.168.157.100

It works multiple times without new default route only after moving the enter hook one directory up:

$ sudo mv /etc/dhcp/dhclient-enter-hooks.d/aethercast/dhclient-hook-p2p /etc/dhcp/dhclient-enter-hooks.d/

Could there be a restriction that dhclient does not look at the enter-hooks directory recursively?

Revision history for this message
Michael Sievers (mike+s) wrote :

rereading that, I am not 100% sure I did replicated exactly what is in the silo.
@GT: are you having success with that?

if the dhclient entry hook is directly under the dhclient-enter-hooks.de directory, it should work, I believe.

Revision history for this message
Michael Sievers (mike+s) wrote :

sorry for the comment spam - is there a way to see where the enter hook lands other than setting up my M10 for silos? That is not something I can do quickly.

Revision history for this message
GT (gleppert) wrote :

@Simon: as mentioned on bug 1590135, I now tested the Silo 2162 and that bug bug 1590135 seems to be solved.

However, the issue with this bug 1639630 concerning the internet connection is not yet solved. There is no internet connection while screen sharing and also not after having disconnected the screen. Even then, the tablet cannot access the internet. In order to re-establish the internet connection, I have to manually disable Wifi and enable it again, and wait a few seconds.

Please let me know if there is anything else I can test.

Revision history for this message
GT (gleppert) wrote :

@Simon: In fact, this bug seems to be partially fixed: As described, internet connection does not work after activating screen sharing, although the tablet is always connected to my wifi network.

Workaround: After screen sharing is activated, in fact, I can establish an internet connection when I try to connect to another secured wifi network but enter a wrong password. Of course, the tablet cannot connect to that other network, but the tablet remains connected with my wifi network. Then, suddenly, internet is starting to work.

I have no idea, why the workaround works, but it does.

Revision history for this message
Michael Sievers (mike+s) wrote :
Download full text (4.4 KiB)

Hello, the silo 2162 installed nicely, but the update to aethercast did not
install. What has been changed is:

 The following packages will be upgraded:
   isc-dhcp-client isc-dhcp-common isc-dhcp-server

I see the changed /etc/apparmor.d/sbin.dhclient, so that landed.

But I still see
/etc/dhcp/dhclient-enter-hooks.d/aethercast-p2p/dhclient-hook-p2p and I assume
this will only work when pushed a directory higher, as explored below.

In the current state, I can connect once to the Wireless Display Adapter while
conserving internet access. By the second time, internet access is dropped.
The behavior I'm seeing is that at the first time, a new network is added,
albeit without a default route. By the second connection, a new network is
added, this time with a default route.

=== network routes with silo 2162 installed:

$ dpkg -l | egrep '(aethercast|isc-dhcp)' # lines are shortened manually
ii aethercast 0.1+15.04.20160808-0ubuntu1
ii aethercast-tools 0.1+15.04.20160808-0ubuntu1
ii isc-dhcp-client 4.3.1-5ubuntu2.4~overlay2
ii isc-dhcp-common 4.3.1-5ubuntu2.4~overlay2
ii isc-dhcp-server 4.3.1-5ubuntu2.4~overlay2

before aethercast:

 $ ip r l
 default via 192.168.1.254 dev wlan0 proto static metric 600
 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.33 metric 600

after first aethercast connection, it being active:

 $ ip r l
 default via 192.168.1.254 dev wlan0 proto static metric 600
 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.33 metric 600
 192.168.7.0/24 dev p2p0 proto kernel scope link src 192.168.7.1

after second aethercast connection, it being active:

 default via 192.168.157.1 dev p2p0
 default via 192.168.1.254 dev wlan0 proto static metric 600
 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.33 metric 600
 192.168.7.0/24 dev p2p0 proto kernel scope link src 192.168.7.1
 192.168.157.0/24 dev p2p0 proto kernel scope link src 192.168.157.100

This stays the same from here on, even after disabling external display via
menu. Disabling and reenabling wireless network completely re-empties the
routes, eliminating the default route via the p2p0 device, thus restoring
internet connectivity. Until aethercast is activated again.

It seems that p2p0 connections are not torn down on terminating aethercast
connection, at least after the first time - when using it multiple times, I
always end up with two networks routed via p2p0, at the second time coming with
a default route. I do not know what is the desired behavior, if networks are
supposed to be torn down after ending an aethercast connection.

==== network state after moving the aethercast dhclient-enter-hook up by one
directory and rebooting:

 $ sudo mount -o rw,remount /
 $ sudo mv /etc/dhcp/dhclient-enter-hooks.d/aethercast-p2p/dhclient-hook-p2p /etc/dhcp/dhclient-enter-hooks.d/
 $ sudo shutdown -r now

before first connection:

 $ ip r l
 default via 192.168.1.254 dev wlan0 proto static metric 600
 192.168.1.0...

Read more...

Revision history for this message
Michael Sievers (mike+s) wrote :

FYI - because /var/log/syslog is receiving about 390 messages per second when aethercast is active, I added an issue for that as well: https://bugs.launchpad.net/aethercast/+bug/1641301 .

Best regards,
Michael

Revision history for this message
Simon Fels (morphis) wrote :

@Michael: Thanks for the writeup. Actually the problem with moving the hook into the right directory (/etc/dhcp/dhclient-enter-hooks.d/) is what I am fixing with https://code.launchpad.net/~morphis/aethercast/+git/aethercast/+merge/310189 Really wondering what went wrong here.

When I download the vivid package from the silo and look at its content the file is at the right place:

$ dpkg-deb -c ~/Downloads/ _armhf.deb
drwxr-xr-x root/root 0 2016-11-08 09:42 ./
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/init/
-rw-r--r-- root/root 957 2016-11-08 09:36 ./etc/init/aethercast.conf
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/aethercast/
-rw-r--r-- root/root 163 2016-11-08 09:33 ./etc/aethercast/dhcpd.conf
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/apparmor.d/
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/apparmor.d/dhcpd.d/
-rw-r--r-- root/root 577 2016-11-08 09:33 ./etc/apparmor.d/dhcpd.d/usr.sbin.aethercast
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/dhcp/
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/dhcp/dhclient-enter-hooks.d/
-rw-r--r-- root/root 272 2016-11-08 09:33 ./etc/dhcp/dhclient-enter-hooks.d/aethercast
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/dbus-1/
drwxr-xr-x root/root 0 2016-11-08 09:42 ./etc/dbus-1/system.d/
-rw-r--r-- root/root 489 2016-11-08 09:33 ./etc/dbus-1/system.d/aethercast-dbus.conf
drwxr-xr-x root/root 0 2016-11-08 09:42 ./usr/
drwxr-xr-x root/root 0 2016-11-08 09:42 ./usr/bin/
-rwxr-xr-x root/root 92940 2016-11-08 09:42 ./usr/bin/aethercastctl
drwxr-xr-x root/root 0 2016-11-08 09:42 ./usr/share/
drwxr-xr-x root/root 0 2016-11-08 09:42 ./usr/share/doc/
drwxr-xr-x root/root 0 2016-11-08 09:44 ./usr/share/doc/aethercast/
-rw-r--r-- root/root 2441 2016-11-08 09:33 ./usr/share/doc/aethercast/copyright
drwxr-xr-x root/root 0 2016-11-08 09:42 ./usr/sbin/
-rwxr-xr-x root/root 1128400 2016-11-08 09:42 ./usr/sbin/aethercast
drwxr-xr-x root/root 0 2016-11-08 09:42 ./var/
drwxr-xr-x root/root 0 2016-11-08 09:42 ./var/lib/
drwxr-xr-x root/root 0 2016-11-08 09:42 ./var/lib/aethercast/
lrwxrwxrwx root/root 0 2016-11-08 09:44 ./usr/share/doc/aethercast/changelog.Debian.gz -> ../aethercast-tools/changelog.Debian.gz

Your dpkg output shows you have still aethercast 0.1+15.04.20160808-0ubuntu1 installed instead of 0.1+15.04.20161108-0ubuntu1. Can you reinstall the silo (just execute bileto again) or install the package manually from the ppa? That should remove the old file and give you the new /etc/dhcp/dhclient-enter-hooks.d/aethercast

Revision history for this message
Michael Sievers (mike+s) wrote :

Hello,

tried this again. Short version: it works, after forcing aethercast with dpkg
 and renaming a file to lose the .dpkg-new suffix.

bileto upgrade changed nothing:

 bileto device-upgrade 2162

installation by hand:

 wget http://ppa.launchpad.net/ci-train-ppa-service/2162/ubuntu/pool/main/a/aethercast/aethercast_0.1+15.04.20161108-0ubuntu1_armhf.deb

 sudo dpkg -i aethercast_0.1+15.04.20161108-0ubuntu1_armhf.deb

installs but gives errors (this might be why the package hasn't installed with bileto?)

  dpkg: dependency problems prevent configuration of aethercast:
 aethercast depends on libmirclient9 (>= 0.24.1+15.04.20160928); however:
    Version of libmirclient9:armhf on system is 0.24.0+15.04.20160815.3-0ubuntu1.

  dpkg: error processing package aethercast (--install):
   dependency problems - leaving unconfigured
  Processing triggers for ureadahead (0.100.0-19) ...
  Processing triggers for dbus (1.8.12-1ubuntu5) ...
  Errors were encountered while processing:
   aethercast

I can see the new file:
 /etc/dhcp/dhclient-enter-hooks.d/aethercast.dpkg-new

I assume it has not been renamed in order to lose the dpkg-new because auf the missing dependencies.

I did the renaming:

 sudo mv /etc/dhcp/dhclient-enter-hooks.d/aethercast.dpkg-new /etc/dhcp/dhclient-enter-hooks.d/aethercast

Reboot:
 sudo shutdown -r now

After reboot, even on the third, there is still only the normale default route:
  $ ip r l | grep default
  default via 192.168.1.254 dev wlan0 proto static metric 600

Which is expected behavior, great :-)

Not every connection attempt is successfull, but I can live with that.

In summary: the silo works for me, assuming that package installation of
aethercast has failed due to the missing libmir dependency and that the
missing rename was a consequence of that.

So - good news from my side :-)

Please let me know if there is anything else you'd like me to look at.

Best regards,
Michael

Revision history for this message
Simon Fels (morphis) wrote :

Actually this was my in ability of doing correct debian packages :-)

However I have a fix for this now and doing a rebuild in the silo. Will give it a quick test later today and then submit it to QA for inclusion.

Revision history for this message
Michael Sievers (mike+s) wrote :

Hello Simon,

just wondering, I tried bileto again the last few days but aethercast still does not surface due to a libmirclient9 dependency that is not satisfied.

Should this already work, is there something to test again?

Best regards,
Michael

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.