My configuration: pinephone with pmOS 21.06 and sxmo 1.5.0. I have cellular data and my home wifi access point configured via the sxmo Networks menu.
Almost always when I unlock the phone from CRUST, I have no web access for one reason or another.
If I'm home, both wifi and cellular should be available. But despite waiting 30-60 seconds, often wifi does not come up. Then I navigate to the Networks menu, click on my access point, and it comes up.
If the phone is in CRUST and I leave my home, when I unlock wifi obviously isn't available, but cellular is; but data doesn't seem to work. Sometimes I can get data working by going to tthe Networks menu by stopping and starting cellular data. I speculate that this is mainly switching my DNS configuration from the wifi configuration to the cellular configuration.
However, often I get error messages about the modem not being found, and I still have no data. If I'm lucky, on the Config menu I can reset the modem and continue on. But since 1.5.0, this only works about 50-60% of the time. After a couple of failed modem reset attempts, I need to reboot the phone to get data working again.
All of this is very cumbersome and time consuming, and involves a lot of trial and error every time I unlock the phone to check something. Is there a better way?
You may suffer crashes or disconnection of the modem. This implies eg25-manager and modemanager. We cant really help you cause it is not related to Sxmo at all. Modemmanager will release in only some weeks. I hope this will bring more reliability, particulary around crust wake ups.
I mentioned this in #409, will document it here as well. The following makes DNS work better for me when both wifi and cellular data are active:
nmcli conn modify mymodemconn ipv4.dns-priority 120 nmcli conn modify mymodemconn ipv6.dns-priority 120
Does the new firmware fix this?
I had this issue and ~rbrewer's fix fixed it for me. Any idea if this change is maintained in reboots and do we want to include this as a default when we setup cellular data for the user?
I spoke too soon, after a little bit of time, I ran into the same issue. ~rbrewer how long did you test that fix for? Maybe it's just a problem with my phone
I spoke too soon, after a little bit of time, I ran into the same issue. ~rbrewer how long did you test that fix for? Maybe it's just a problem with my phone
i experience this and to me it doesnt look like a DNS problem, as i manually set my DNS servers. I suspect something in between ipv4 and/or ipv6, and maybe the way network manager handles the handover..
when it happens to me i have this enigmatic message in mako (when i try to manually enable or switch the communication) -don't have the precise wording in mind right now- that basically says it cannot reserve an IP address ("ip configuration failed - cannot assign..." or something like this...)
only solution i found = reboot :/
Also in the realm of intuition/hypothesis etc.:
- sometimes my wwan0 gets an ipv4... sometimes an ipv6... sometimes none.
- isn't there something in the way networkmanager tries, then gives up? how could we have more clarity/logging/control over this?
i realize it is more a networkmanager question than an sxmo question... but again networkmanager has such critical role in the key components of sxmo that it may be worth investigating if that lead proves to be fruitful. it means that there would be ways through configuration to address this?
does it make any sort of sense?
Im not sure, I did a quick crust and wake from crust and that fixed the issue..... I think the dns change via networkmanager fixed this issue. Im going to keep using this for a couple of weeks and if I dont run into this bug, we should add the dns commands to the add network script.
I had a related issue where data did not work after a fresh boot unless I did an explicit nmcli c down MYDATA and mncli c up MYDATA after a boot. I was baffled but I noticed errors like this in my /var/log/messages: "dhcp4 timeout..."
This is because my carrier (MINT MOBILE, a subset of T-MOBILE) was using ipv6 only. So after some digging I changed this in networkmanager:
nmcli c edit MYDATA
and changed
ipv4.method: auto
to ipv4.method: disabled
So far after a few reboots this seems to have fixed the problem, but I'm not entirely sure.
I wasn't having this problem before I upgraded to firmware 0.5.3 a couple weeks ago. But maybe this will help some people out too.
To test, I was doing:
ping -Iwwan0 www.google.com
This is still an issue on at least two carriers: Mint Mobile (USA) and VoLTE (Italy). It seems to happen regularly after a long suspend (i.e. overnight, 7-8hrs), but it will sometimes happen after shorter suspends. (I've had it happen after just one hour of suspend.) AFAIK it has never happened if I do not suspend, but I haven't tested this thoroughly.
It is noteworthy that this occurs on the pinephone and it does not happen with Phosh. One suspicion is that it might be related to the fact that sxmo suspends directly to /sys/power/state rather than via systemd or logind, and mm might want us to suspend via logind or systemd to spin down correctly (or something). That's something to investigate further.
As a temporary work around, I've added this to my sxmo_hook_postwake.sh:
# on Mint Mobile ipv4 doesn't work, so ping ipv6 address if ping -6 -Iwwan0 -q -c 1 -W 4 2607:f8b0:4009:81b::2004 >/dev/null; then sxmo_notify_user.sh "ping success. $(date)" else sxmo_notify_user.sh "ping failed. $(date)" nmcli c down Ultra # Mint Mobile nmcli c up Ultra # Mint Mobile fiETA: Wifi interference can be ruled out, since we've both tested this with wifi disabled in rfkill, and still have the issue.
Using: pmos edge biktorgj's firmware 0.7.1 ADSP firmware 003
ETA 2: testing now with ADSP firmware 006.
ETA 3: ADSP 006 also exhibits the problem. Only takes 1-2 hrs of suspend to reliably reproduce.
ETA 4: Looks like its just about the 90 minute mark of suspending when it happens. Reproduced a number of times: 60 minutes is too short.
deleted (oops)
Same experience with Deutsche Telekom on sxmo-de-sway, but not that realiable to reproduce. Sometimes it works for days with ~12 hours in CRUST overnight. On the other hand if mobile data isn't working, calling and texting aren't working neither.
Found out that modem didn't change anything by keep
mmcli --monitorrunning in a foot term.
mmcli --simple-disconnect --modem=<id>fixes it automatically most of the time if this error occurs.The real issue is that one doesn't know when this happens so you really miss important calls and messages due to this technical issue.
Hopefully it will work better with the poco f1.
delete
delete