The WebRTC test passes (no IP info given out) for certain servers with PIA VPN. There have been no connection issues. I used the VPN Editor app on Open Store and edited the system-connections file in Terminal as described elsewhere. The VPN still will not work with wifi, but I'm happy it works with the cell data part of the phone.

Magically both, the old Canonical tg app and tg-cli, started working again downloading files and photos. Don't know why, but they do work again. Fine.

Glad it worked out in the end

@nobhobbor they are in the ubports installer, so it should be just as easy or hard to install on the OP3 as the OP1. Though after the install, it is harder to use with the fact that there aren't to many arm64 apps available, there's no openstore, hopefully we'll get it in the not to distant future, but that's not got anything to do with installing the OS, but installing applications on the OS. I'm assuming that's the miscommunication, however if I'm wrong then please correct me!

@AppLee said in Google sheets: developped to work with chrome, I'm not sure it's W3C compliant. Morph uses QtWebEngine which is a fork of Chromium, so this is basically irrelevant. Though indeed it is not clear what @wdnp2 is trying to say here. It seems there is no webapp in the store for Google Sheets (or Docs), but they should all be accessible from the Drive, Mail, or Calendar webapps (since Google has links directly to such places on those web sites).

@Ingo Thanks a lot, I managed to get it into recovery and then install an update with the installer software to resolve the issue!

@banderson5586 Hi! A few of us are having similar problems with the installer and the issues are being looked at in the Porting category: https://forums.ubports.com/topic/3253/oneplus-3-3t/28

Different operating systems store simple text files differently. If you are using linux, it will automatically create text files with "LF" (line feed). If you are on windows, it will create "CRLF" (carriage return + line feed). On Mac OS it will create "CR" (carriage return). So, on linux, you don't have to worry. On windows and mac you have to explicitly convert the text file to "LF". On windows for example, notepad cannot do that but notepad++ for example. In case you want to know more: https://en.wikipedia.org/wiki/CRLF

[image: 1572986948161-log-resized.jpg] According to this recovery log. There is no disk space left, despite having wiped/formatted cache and data prior to installation.

@utouchuser as @guru said it is provider specific. so something can be figured out, but will require a config file to update missing providers or specific needs. It can be tricky but probably doable.

@nobhobbor Thanks, I'll give that a try. I've been using a nano-sim adapter and further research is showing that the adapters can often damage the pins. I might end up trying to push them up a bit to see if they contact better. @Lakotaubp Did that twice already. Was really hoping it would do the trick.

@Giiba Yeah it seems so I guess it's a problem with Morph.Web since Demo Browser doesn't use it and uses the vanilla QtWebEngine.

The deb version has the same errors for me.

@guru Glad you are getting somewhere still not sure what the change may have been though.

jEzEk, thanks for undertaking the tests. They show two things: the RT values are as high as mine, up 100++ ms in one test (the first) they went down to a normal value of 2-3ms I think the problem in general is reverse DNS or ARP related. When I ping from my laptop my AP 192.168.178.1 I see constant values of 2-3 ms. When I ping some other laptop (an Ubuntu 18.04) I see this: guru@c720-r342378 ~]$ ping 192.168.178.36 PING 192.168.178.36 (192.168.178.36): 56 data bytes 64 bytes from 192.168.178.36: icmp_seq=0 ttl=64 time=2.897 ms 64 bytes from 192.168.178.36: icmp_seq=1 ttl=64 time=2.993 ms 64 bytes from 192.168.178.36: icmp_seq=2 ttl=64 time=3.610 ms 64 bytes from 192.168.178.36: icmp_seq=3 ttl=64 time=2.852 ms 64 bytes from 192.168.178.36: icmp_seq=4 ttl=64 time=3.022 ms 64 bytes from 192.168.178.36: icmp_seq=5 ttl=64 time=3.024 ms 64 bytes from 192.168.178.36: icmp_seq=6 ttl=64 time=5.926 ms 64 bytes from 192.168.178.36: icmp_seq=7 ttl=64 time=3.230 ms 64 bytes from 192.168.178.36: icmp_seq=8 ttl=64 time=3.015 ms 64 bytes from 192.168.178.36: icmp_seq=9 ttl=64 time=343.706 ms 64 bytes from 192.168.178.36: icmp_seq=10 ttl=64 time=2.999 ms 64 bytes from 192.168.178.36: icmp_seq=11 ttl=64 time=3.006 ms 64 bytes from 192.168.178.36: icmp_seq=12 ttl=64 time=2.923 ms 64 bytes from 192.168.178.36: icmp_seq=13 ttl=64 time=5.357 ms 64 bytes from 192.168.178.36: icmp_seq=14 ttl=64 time=12.376 ms 64 bytes from 192.168.178.36: icmp_seq=15 ttl=64 time=2.988 ms 64 bytes from 192.168.178.36: icmp_seq=16 ttl=64 time=3.066 ms 64 bytes from 192.168.178.36: icmp_seq=17 ttl=64 time=3.007 ms 64 bytes from 192.168.178.36: icmp_seq=18 ttl=64 time=2.986 ms 64 bytes from 192.168.178.36: icmp_seq=19 ttl=64 time=317.896 ms 64 bytes from 192.168.178.36: icmp_seq=20 ttl=64 time=634.518 ms i.e. only a few peeks up to 600 ms. Now I went to the other laptop in question and inserted a line for my source IP 192.168.178.22 and for the laptop itself 192.168.178.36 in the /etc/hosts file as: guru@m4400:~$ cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 m4400 192.168.178.1 fritz 192.168.178.22 ubguru 192.168.178.36 ubuntu and magically, the RT goes down to normal: [guru@c720-r342378 ~]$ ping 192.168.178.36 PING 192.168.178.36 (192.168.178.36): 56 data bytes 64 bytes from 192.168.178.36: icmp_seq=0 ttl=64 time=3.010 ms 64 bytes from 192.168.178.36: icmp_seq=1 ttl=64 time=2.900 ms 64 bytes from 192.168.178.36: icmp_seq=2 ttl=64 time=3.124 ms 64 bytes from 192.168.178.36: icmp_seq=3 ttl=64 time=3.141 ms 64 bytes from 192.168.178.36: icmp_seq=4 ttl=64 time=3.422 ms 64 bytes from 192.168.178.36: icmp_seq=5 ttl=64 time=3.081 ms 64 bytes from 192.168.178.36: icmp_seq=6 ttl=64 time=2.919 ms 64 bytes from 192.168.178.36: icmp_seq=7 ttl=64 time=2.897 ms 64 bytes from 192.168.178.36: icmp_seq=8 ttl=64 time=3.005 ms 64 bytes from 192.168.178.36: icmp_seq=9 ttl=64 time=3.016 ms 64 bytes from 192.168.178.36: icmp_seq=10 ttl=64 time=2.888 ms 64 bytes from 192.168.178.36: icmp_seq=11 ttl=64 time=3.011 ms 64 bytes from 192.168.178.36: icmp_seq=12 ttl=64 time=2.923 ms 64 bytes from 192.168.178.36: icmp_seq=13 ttl=64 time=2.867 ms To be investigated further ...

Woot! Woot @libremax! it worked perfectly. Thanks for your encouragement!