Re: NetworkManager for Ubuntu Touch
Hi, ok super, then we shall try to make a packaging repo for the current version and use our armhf builder to try if it can build it. One question ahead of this, if network and WiFi both have provided DNS via DHCP, how is NM updating the resolver so that not only the route to the active network is taken but also the DNS proxy knows what to do? BR Florian Am 05.12.2018 um 18:23 schrieb Lubomir Rintel: > It is supposed to. > > There were significant improvements to the connectivity checking > lately. The connectivity checks were previously rather rudimentary, > providing a simple connected/disconnected status, completely oblivious > to the device that's actually used for the check. > > With an up-to-date NetworkManager we try to make the connectivity check > use a particular device that has came up and then adjust the route > metric accordingly. We also expose the result on the D-Bus. For this to > work robustly you need to have systemd-resolved available (not > necessarily default), otherwise we're not able to resolve names via a > particular interface. > > I'm really really really not going to help you solve eventual problems > on a rather old version when we have a new one that is a drop-in > replacement. On the other hand I'm happy to help if something doesn't > work with an up-to-date version. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager for Ubuntu Touch
On Fri, 2018-11-23 at 23:28 +0100, Florian Leeber wrote: > Am 21.11.2018 um 19:18 schrieb Lubomir Rintel: > > NetworkManager is doing captive portal detection for ages, though it > > recently got somewhat better. The notification should be done in the > > desktop shell. > > Hey cool, I just configured it: > > root@ubuntu-phablet:~# tail /var/log/syslog -f | grep connectivity > Nov 23 22:58:03 ubuntu-phablet NetworkManager[1774]: > [1543010283.5003] connectivity: check: send periodic request to > 'http://connectivity-check.ubuntu.com/' > Nov 23 22:58:03 ubuntu-phablet NetworkManager[1774]: > [1543010283.8697] connectivity: check for uri > 'http://connectivity-check.ubuntu.com/' with Status header successful. > Nov 23 23:03:03 ubuntu-phablet NetworkManager[1774]: > [1543010583.4998] connectivity: check: send periodic request to > 'http://connectivity-check.ubuntu.com/' > Nov 23 23:03:03 ubuntu-phablet NetworkManager[1774]: > [1543010583.8536] connectivity: check for uri > 'http://connectivity-check.ubuntu.com/' with Status header successful. > > So we could work with this version already. But a question, can it also > be triggered on any connection going down / being changed? It is supposed to. > If I disable/reenable WiFi the connection check should take place > immediately... It is supposed to. There were significant improvements to the connectivity checking lately. The connectivity checks were previously rather rudimentary, providing a simple connected/disconnected status, completely oblivious to the device that's actually used for the check. With an up-to-date NetworkManager we try to make the connectivity check use a particular device that has came up and then adjust the route metric accordingly. We also expose the result on the D-Bus. For this to work robustly you need to have systemd-resolved available (not necessarily default), otherwise we're not able to resolve names via a particular interface. I'm really really really not going to help you solve eventual problems on a rather old version when we have a new one that is a drop-in replacement. On the other hand I'm happy to help if something doesn't work with an up-to-date version. > > BR Lubo ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager for Ubuntu Touch
Am 21.11.2018 um 19:18 schrieb Lubomir Rintel: > NetworkManager is doing captive portal detection for ages, though it > recently got somewhat better. The notification should be done in the > desktop shell. Hey cool, I just configured it: root@ubuntu-phablet:~# tail /var/log/syslog -f | grep connectivity Nov 23 22:58:03 ubuntu-phablet NetworkManager[1774]: [1543010283.5003] connectivity: check: send periodic request to 'http://connectivity-check.ubuntu.com/' Nov 23 22:58:03 ubuntu-phablet NetworkManager[1774]: [1543010283.8697] connectivity: check for uri 'http://connectivity-check.ubuntu.com/' with Status header successful. Nov 23 23:03:03 ubuntu-phablet NetworkManager[1774]: [1543010583.4998] connectivity: check: send periodic request to 'http://connectivity-check.ubuntu.com/' Nov 23 23:03:03 ubuntu-phablet NetworkManager[1774]: [1543010583.8536] connectivity: check for uri 'http://connectivity-check.ubuntu.com/' with Status header successful. So we could work with this version already. But a question, can it also be triggered on any connection going down / being changed? If I disable/reenable WiFi the connection check should take place immediately... BR ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager for Ubuntu Touch
Hello Lubomir, great to get you feedback so quickly! And we are happy that you have good news for us already in the first mail :) Let me summarize this quickly here, and I will come back and be more specific when I have more infos on your questions: - We are still using unity8 as shell, and there is indicator-network basically displaying that status of WiFi and radio network and allowing to operate the network connections, enable flight mode etc. Its a new development made specifically for unity8 if I remember right. And it should be able to talk to D-Bus. Debian wants to use them in the so-called Ayatana indicators package, too. - Regarding builds: The real issue is the rather tight coupling between the Ubuntu root fs and the Android container which is started at boot time. So far we are not able to just start Ubuntu Touch without it. A lot of scripts and magic wait for the successful bringup of the container. Moreover, some things just dont build correctly for amd64, but do for armhf. We are working form time to time to get it more sanitized, for example you could install unity8 shell with the indicators probably also on a normal PC already. Maybe thats enough? - The captive portal detection I tried to configure manually for my device, but since nothing is listening to that event, I cannot tell if it works properly or not. I might be able to hook up tcpdump or so on the device to see if he is querying on change of network. So if thats already in for ages, I hope we can use it right away ;) - What we currently see sometimes is a long switchover time between radio and WiFi. Is it NM trying to hold on for the WiFi connection for a longer time? What also can happen is that the DNS servers dont get updated, and when you come from WiFi you have a reall long interval without having DNS lookups. FYI here is our packaging for NM: https://github.com/ubports/network-manager-packaging/ I will talk with my guys how we can make a bit more Q&A with you guys, have a ncie weekend until then! BR Florian Am 21.11.2018 um 19:18 schrieb Lubomir Rintel: > Hello Florian, > > thanks for your message. > > We're dealing with exact same challenges on machines larger than phones > too. > > For quite some time I think the Canonical folks have done a good job at > upstreaming their changes. E.g. ofono support got in, which I figure > was one of the larger patches. > > Perhaps there wouldn't be too much stuff left if NM gets rebased to > something more recent (more on that below). > There's basically four regular contributors to NetworkManager at the > moment, all of us happy to improve its usefulness on phones, provided > we understand what the deficiencies are. > > A device could help, but I think even more useful would be an x86 > compose of your distribution that could be run in a VM. Do you have > such builds? I suppose that would help us understand what are the > specifics of the phone setup (I guess you run a different desktop > shell, have Android kernel beneath, ofono instead of ModemManager, > etc.). > > We don't break things, including API/ABI and do regularly test our > builds on Ubuntu 16.04. The version number in itself doesn't carry much > meaning -- an update to 1.14.x at this point should be staightforward > and safe. > > NetworkManager is doing captive portal detection for ages, though it > recently got somewhat better. The notification should be done in the > desktop shell. > > For the reference -- GNOME Shell deals with it and should provide a > good example. I guess KDE does too. nm-applet does not. > > Don't hesitate to ask more, especially when we do something that > doesn't make sense on a phone or miss something that would be useful. > The more technical context you provide the better. > > I'm quite certain it's not only me who appreciates that you decided to > keep the upstream project in the loop. > > Take care, > Lubo > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager for Ubuntu Touch
Hello Florian, thanks for your message. On Tue, 2018-11-20 at 11:23 +0100, Florian Leeber via networkmanager-list wrote: > Greetings, > > my name is Florian Leeber and I am in the BoD of the upcoming UBports > Foundation, which promotes Ubuntu Touch since Canonical has abandoned > it. We have so far achieved a continuation of the project, delivering an > upgrade to Ubuntu 16.04 and so forth. > > When it comes to networking, some things are crucial for a smooth user > experience on a mobile device. Unlike to a desktop or fixed server > device, a mobile device has to tackle a lot of challenges with changing > networks, WiFi connections, loosing contact, constantly changing IP > addresses etc. We're dealing with exact same challenges on machines larger than phones too. > NetworkManager has been patched for that by Canonical and others, but we > still think it could improve a lot. For quite some time I think the Canonical folks have done a good job at upstreaming their changes. E.g. ofono support got in, which I figure was one of the larger patches. Perhaps there wouldn't be too much stuff left if NM gets rebased to something more recent (more on that below). > But we are a small team, and we are > constantly looking for help. So in this context, I am currently looking > for an experienced dev that knows NetworkManager fairly well, in order > to help us test and improve it for the mobile experience we want to > achieve. If necessary he/she can receive a test device with Ubuntu Touch > and the necessary support. However, we cannot pay for the support at > them moment. There's basically four regular contributors to NetworkManager at the moment, all of us happy to improve its usefulness on phones, provided we understand what the deficiencies are. A device could help, but I think even more useful would be an x86 compose of your distribution that could be run in a VM. Do you have such builds? I suppose that would help us understand what are the specifics of the phone setup (I guess you run a different desktop shell, have Android kernel beneath, ofono instead of ModemManager, etc.). > The first goal will be to update/backport things if necessary for the > currently used 16.04 LTS version (1.2.2 I think). I know this is quite > old, but we are bound to what we get from usual Ubuntu sources for the > time being. Backporting can be done by our developers as well, if they > are guided which things to be aware of. We don't break things, including API/ABI and do regularly test our builds on Ubuntu 16.04. The version number in itself doesn't carry much meaning -- an update to 1.14.x at this point should be staightforward and safe. > Another very urgent task is to get connectivity / captive portal > recognition working, so that users can more easily connect to public > networks. This involves signalling from NM to the OS in some way so that > a popup notification with a link to the web browser is being shown. NetworkManager is doing captive portal detection for ages, though it recently got somewhat better. The notification should be done in the desktop shell. For the reference -- GNOME Shell deals with it and should provide a good example. I guess KDE does too. nm-applet does not. > I am looking forward to hearing from anyone who is interested, her eon > the ML or on my email addy. Don't hesitate to ask more, especially when we do something that doesn't make sense on a phone or miss something that would be useful. The more technical context you provide the better. I'm quite certain it's not only me who appreciates that you decided to keep the upstream project in the loop. Take care, Lubo > > BR Florian > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager for Ubuntu Touch
Greetings, my name is Florian Leeber and I am in the BoD of the upcoming UBports Foundation, which promotes Ubuntu Touch since Canonical has abandoned it. We have so far achieved a continuation of the project, delivering an upgrade to Ubuntu 16.04 and so forth. When it comes to networking, some things are crucial for a smooth user experience on a mobile device. Unlike to a desktop or fixed server device, a mobile device has to tackle a lot of challenges with changing networks, WiFi connections, loosing contact, constantly changing IP addresses etc. NetworkManager has been patched for that by Canonical and others, but we still think it could improve a lot. But we are a small team, and we are constantly looking for help. So in this context, I am currently looking for an experienced dev that knows NetworkManager fairly well, in order to help us test and improve it for the mobile experience we want to achieve. If necessary he/she can receive a test device with Ubuntu Touch and the necessary support. However, we cannot pay for the support at them moment. The first goal will be to update/backport things if necessary for the currently used 16.04 LTS version (1.2.2 I think). I know this is quite old, but we are bound to what we get from usual Ubuntu sources for the time being. Backporting can be done by our developers as well, if they are guided which things to be aware of. Another very urgent task is to get connectivity / captive portal recognition working, so that users can more easily connect to public networks. This involves signalling from NM to the OS in some way so that a popup notification with a link to the web browser is being shown. I am looking forward to hearing from anyone who is interested, her eon the ML or on my email addy. BR Florian ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
