@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!

With flashing the new image of today the device works again. All dates are lost.

@utouchuser Glad you solved it !

If this works for you , you could make a custom group and set this to dial ,this code, with pauses etc ,to give it time to work.
Travelling the usa, I had a prepaid card , and set my phone up to dial the card numbers and code, then the number I needed, it was a few years ago , there must be info ,on how to set it up.
I remember it sure saved a lot of button pressing.

thanks for your answer!
my problem was...dust
the stranger thing was the phone was charging when it was off
no problem now!

Thanks for all the responses and the breakdown of models. My main criteria for a phone is different than most people, I never use social media, seldom access the Internet and mostly just want reliable phone service and texting without invasive ads, some note taking and decent photos. Size is most crucial, I just want it to fit comfortably in my front pocket - and I don't want to spend much more than $50. The Nexus 4 is just over this size, but it's the smallest I can find that supports UT at this time. I had been using a WebOS Palm Pixi for the longest time, still the best phone I have owned.

I have not noticed overheating problems but again I don't really use my phone that much during the course of the day. UT runs fine, maybe not super speedy but not any slowness that I find noticeable. I have a handful of other issues that irk me but I want to have a phone to clone so I can safely re-install UT to see if that clears any of them up.

I will pick up another E960 and continue to experiment with alternate OSs. I like UT but still curious to see how something like Paranoid Android works. It also supports the Nexus 4.

Thanks again, really appreciate the advice

Afaik there is no such tool available.
I searched for this when I switched from Android to UT and I was unsuccessful.
But maybe things on this matter have evolved... 🤞

@Lakotaubp ty now its working

Thanks for the help.
I have tried that, it is a little bit better but not very good.

I have also tried to install the latest LineageOS and the WIFI works flawlessly. So it is not a hardware issue.
Enabling only 2.4GHz Wifi does not help.